$ rpm -qi sylpheed|grep 'Build Date' Release : 3 Build Date: Fri 24 Aug 2007 01:21:16 PM CEST
$ grep -B2 POP3 sylpheed.spec %changelog * Fri Aug 24 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3 - Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
But:
$ LANG=C rpm -q sylpheed --changelog|head -3 * Sat Aug 25 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3 - Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
*All* entries are off by one day forward. Bug or PEBKAC?
Michael Schwendt wrote:
$ rpm -qi sylpheed|grep 'Build Date' Release : 3 Build Date: Fri 24 Aug 2007 01:21:16 PM CEST
$ grep -B2 POP3 sylpheed.spec %changelog
- Fri Aug 24 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
- Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
But:
$ LANG=C rpm -q sylpheed --changelog|head -3
- Sat Aug 25 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
- Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
*All* entries are off by one day forward. Bug or PEBKAC?
What's your timezone set to?
On Wed, 29 Aug 2007 14:45:16 -0400, Peter Jones wrote:
Michael Schwendt wrote:
$ rpm -qi sylpheed|grep 'Build Date' Release : 3 Build Date: Fri 24 Aug 2007 01:21:16 PM CEST
$ grep -B2 POP3 sylpheed.spec %changelog
- Fri Aug 24 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
- Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
But:
$ LANG=C rpm -q sylpheed --changelog|head -3
- Sat Aug 25 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
- Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
*All* entries are off by one day forward. Bug or PEBKAC?
What's your timezone set to?
$ cat /etc/sysconfig/clock ZONE="Europe/Berlin" UTC=true ARC=false
On Wed, 29 Aug 2007 20:56:21 +0200, Michael Schwendt wrote:
On Wed, 29 Aug 2007 14:45:16 -0400, Peter Jones wrote:
Michael Schwendt wrote:
$ rpm -qi sylpheed|grep 'Build Date' Release : 3 Build Date: Fri 24 Aug 2007 01:21:16 PM CEST
$ grep -B2 POP3 sylpheed.spec %changelog
- Fri Aug 24 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
- Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
But:
$ LANG=C rpm -q sylpheed --changelog|head -3
- Sat Aug 25 2007 Michael Schwendt <mschwendt[AT]users.sf.net> - 2.4.4-3
- Patch POP3 format string vulnerability CVE-2007-2958 (#254123).
*All* entries are off by one day forward. Bug or PEBKAC?
What's your timezone set to?
$ cat /etc/sysconfig/clock ZONE="Europe/Berlin" UTC=true ARC=false
Fedora 7 is affected, too. All F7 Test Updates, for example, don't pass this check.
The Test Update announcements print changelog dates that doesn't match the rpm --changelog query, which is off by one into the future compared with what the spec file contains. E.g.:
metacity announcement says:
* Tue Sep 11 2007 Ray Strode <rstrode redhat com> - 2.18.5-2 - don't dereference a NULL pointer (crash on logout, leading to weird problems on next login, bug 243761)
rpm says:
* Wed Sep 12 2007 Ray Strode <rstrode redhat com> - 2.18.5-2 - don't dereference a NULL pointer (crash on logout, leading to weird problems on next login, bug 243761)
yum announcement says:
* Mon Sep 10 2007 Seth Vidal <skvidal at fedoraproject org> - 3.2.5-1 - 3.2.5 - prune unnecessary patches
rpm says:
* Tue Sep 11 2007 Seth Vidal <skvidal at fedoraproject org> - 3.2.5-1 - 3.2.5 - prune unnecessary patches
Michael Schwendt (mschwendt.tmp0701.nospam@arcor.de) said:
metacity announcement says:
- Tue Sep 11 2007 Ray Strode <rstrode redhat com> - 2.18.5-2
- don't dereference a NULL pointer (crash on logout, leading to weird problems on next login, bug 243761)
rpm says:
- Wed Sep 12 2007 Ray Strode <rstrode redhat com> - 2.18.5-2
- don't dereference a NULL pointer (crash on logout, leading to weird problems on next login, bug 243761)
It's to do with your timezone settings, and how rpm is interpreting stored changelog time. Whether that's a bug or not, I'm not sure.
Bill
On Mon, 17 Sep 2007 13:42:16 -0400, Bill Nottingham wrote:
metacity announcement says:
- Tue Sep 11 2007 Ray Strode <rstrode redhat com> - 2.18.5-2
- don't dereference a NULL pointer (crash on logout, leading to weird problems on next login, bug 243761)
rpm says:
- Wed Sep 12 2007 Ray Strode <rstrode redhat com> - 2.18.5-2
- don't dereference a NULL pointer (crash on logout, leading to weird problems on next login, bug 243761)
It's to do with your timezone settings, and how rpm is interpreting stored changelog time. Whether that's a bug or not, I'm not sure.
Bill
There is a bug (or design problem) somewhere for sure.
I assume because the hours, minutes and seconds are not specified in the spec file and no TZ is given either, conversion of the date strings is faulty under special conditions.
I write a spec on Fri Aug 24 (without giving a TZ in the spec), send it to the buildsys and receive a binary rpm where the changelog is one day into the future, Sat Aug 25. And the build date is one day before that. :)
The changelog times are not stored as date strings in the binary RPM header, but most likely are preconverted to ordinary time() values by rpmbuild, assuming arbitrary values for the missing h:m:s (possibly 0:0:0).
However, the spec changelog date strings don't contain a TZ, so rpmbuild running on a build-slave doesn't know *my* TZ offset. It creates the time() value from my date string for the reference Epoch time() of the buildsys TZ. When for the buildsys it still is the previous day of the week compared with my TZ, my date string is one full day in the future, and the calculated time value reflects that (with +24 hours). Converting it back to a date string adds the same weekday+1 here, too.
Michael Schwendt (mschwendt.tmp0701.nospam@arcor.de) said:
The changelog times are not stored as date strings in the binary RPM header, but most likely are preconverted to ordinary time() values by rpmbuild, assuming arbitrary values for the missing h:m:s (possibly 0:0:0).
They're stored as seconds-since-the-epoch - see CHANGELOGTIMES in an rpm query.
Bill
Bill Nottingham wrote:
Michael Schwendt (mschwendt.tmp0701.nospam@arcor.de) said:
The changelog times are not stored as date strings in the binary RPM header, but most likely are preconverted to ordinary time() values by rpmbuild, assuming arbitrary values for the missing h:m:s (possibly 0:0:0).
They're stored as seconds-since-the-epoch - see CHANGELOGTIMES in an rpm query.
And more specifically, the date in the specfile is interpreted as noon on that day, UTC.
Peter Jones (pjones@redhat.com) said:
Bill Nottingham wrote:
Michael Schwendt (mschwendt.tmp0701.nospam@arcor.de) said:
The changelog times are not stored as date strings in the binary RPM header, but most likely are preconverted to ordinary time() values by rpmbuild, assuming arbitrary values for the missing h:m:s (possibly 0:0:0).
They're stored as seconds-since-the-epoch - see CHANGELOGTIMES in an rpm query.
And more specifically, the date in the specfile is interpreted as noon on that day, UTC.
... which means you *shouldn't* be able to get an off-by-one-date, barring being located in the South Pacific and weirdness with leap seconds.
Bill
On Thu, 20 Sep 2007 16:16:39 -0400, Bill Nottingham wrote:
Peter Jones (pjones redhat com) said:
Bill Nottingham wrote:
Michael Schwendt (mschwendt.tmp0701.nospam@arcor.de) said:
The changelog times are not stored as date strings in the binary RPM header, but most likely are preconverted to ordinary time() values by rpmbuild, assuming arbitrary values for the missing h:m:s (possibly 0:0:0).
They're stored as seconds-since-the-epoch - see CHANGELOGTIMES in an rpm query.
And more specifically, the date in the specfile is interpreted as noon on that day, UTC.
noon is midday, but Midnight Commander displays 00:00:00 for the changelogs. (perhaps that's another bug in mc, though)
... which means you *shouldn't* be able to get an off-by-one-date, barring being located in the South Pacific and weirdness with leap seconds.
Since there is no time zone specified in the changelog, the off-by-one error *could* be the result of interpreting and converting the specfile in different time zones, not accounting for a change in the weekday if the implicit time zone offset is large enough.
Contrary to my first post in this thread, I *currently* don't get the off-by-one error for "sylpheed", but for e.g. "yum" (Sep 10 -> Sep 11) and (Sep 11 -> Sep 12).
With sylpheed I don't see a time zone offset that is large enough and which would cause a constant off-by-one error:
http://koji.fedoraproject.org/koji/buildinfo?buildID=15872
build-job started: Fri, 24 Aug 2007 04:10:10 MST that is UTC-7 for Phoenix/AZ (or UTC-5 for Raleigh/NC) in Germany it is UTC+1 plus daylight-saving specfile also contains "Fri 24 Aug" => the time zone difference of +8/+9 hours (for AZ) doesn't matter, => it doesn't change the weekday
Even for Fri 24 Aug 12:00 UTC-7, the converted time() value would end at Fri 24 Aug 20:00 UTC+1 when converted back.
For the yum and metacity builds, the offset is even less (<= 2 hours inside the U.S.), but still they are off by one here currently. :)