David Hrbáč wrote:
Ralph Angenendt napsal(a):
Yes, I'm seeing that too:
Even if that is changed to UTC, it still is May 13th (and it doesn't explain why subsequent changelog entries are one day off, too.
Thanks Ralph. Yes, it has nothing to do with time zone.
It has. I don't know why, yet.
I'm not sure if I've seen it before last rpmbuild update.
Also happens when you use *5.2* in mock to build the packages. And that has an older version of rpm.
Watch and cry (I Cc: centos-devel, as I know that JBJ reads there, too). Please do answer in centos-devel, thanks.
JBJ:
Here's what happens: I take a src.rpm:
[angenenr@shutdown SRPMS]$rpm -qp --@hangelog canlock-2b-3.el5.src.rpm |head -2 * Tue May 19 2009 Ralph Angenendt ralph@centos.org -2b.2 - This is a test bump
I rebuild it with rpmbuild:
[angenenr@shutdown SRPMS]$rpmbuild --rebuild canlock-2b-3.el5.src.rpm [angenenr@shutdown SRPMS]$rpm -qp --changelog ../RPMS/x86_64/canlock-2b-3.el5.x86_64.rpm |head -2 * Tue May 19 2009 Ralph Angenendt ralph@centos.org -2b.2 - This is a test bump
All is fine. Now let me churn it through mock.
[angenenr@shutdown SRPMS]$mock -r centos-5-x86_64 --autocache canlock-2b-3.el5.src.rpm [...] [angenenr@shutdown SRPMS]$rpm -qp --changelog /var/lib/mock/centos-5-x86_64/result/canlock-2b-3.el5.x86_64.rpm |head -2 * Wed May 20 2009 Ralph Angenendt ralph@centos.org -2b.2 - This is a test bump
Ummm?
[angenenr@shutdown SRPMS]$date Tue May 19 13:19:25 CEST 2009
Yay! I invented a time machine! (or someone did).
Okay, let's move the machine from Germany to the UK
[angenenr@shutdown SRPMS]$sudo cp /usr/share/zoneinfo/Europe/London /etc/localtime [angenenr@shutdown SRPMS]$date Tue May 19 12:20:17 BST 2009 [angenenr@shutdown SRPMS]$rpm -qp --changelog /var/lib/mock/centos-5-x86_64/result/canlock-2b-3.el5.x86_64.rpm |head -2 * Tue May 19 2009 Ralph Angenendt ralph@centos.org -2b.2 - This is a test bump
Hmmm. Who moved the international date line to the Channel?
What about mock? Let's move the machine back to Germany first.
[angenenr@shutdown SRPMS]$sudo cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime [angenenr@shutdown SRPMS]$date Tue May 19 13:22:08 CEST 2009 [angenenr@shutdown SRPMS]$mock -r centos-5-x86_64 shell init mock-chroot> date Tue May 19 07:22:18 EDT 2009
So mock uses EDT which is 6 hours behind. Which does not explain why moving from BST (EDT +0500) still gives me the correct date in the changelog, moving the machine one step further to CEST (EDT +0600) moves me to the next day, though.
What about the rpm built with rpmbuild? Let's move the machine to Sidney:
[root@shutdown etc]# cp /usr/share/zoneinfo/Australia/Sydney localtime [root@shutdown etc]# date Tue May 19 21:27:50 EST 2009 [root@shutdown etc]# rpm -qp --changelog /home/angenenr/redhat/RPMS/x86_64/canlock-2b-3.el5.x86_64.rpm * Tue May 19 2009 Ralph Angenendt ralph@centos.org -2b.2 - This is a test bump
Strange. This is 8 hours in the future (and not 6), but still shows me the correct date.
Something is not right here. Is this something to worry about? How and why does that happen? Why are there even calculations on the date line in a changelog?
Cheers,
Ralph
On May 19, 2009, at 7:29 AM, Ralph Angenendt wrote:
Yay! I invented a time machine! (or someone did).
;-) Well, rpm *will* correct the day of the week for you in case you've forgotten. Try and see ...
Something is not right here. Is this something to worry about? How and why does that happen? Why are there even calculations on the date line in a changelog?
There aren't any calculations, but there are two conversions involved.
During build a straightforward date/time parser (hint: which doesn't use day of week) parses the string in the spec file into a struct tm time; Note that %changelog cannot specify a timezone. Silly but true.
Then these transforms are applied to attempt to get UTC:
*secs = mktime(&time); if (*secs == -1) return -1;
/* determine timezone offset */ /*@-nullpass@*/ /* gmtime(3) unlikely to return NULL soon. */ timezone_offset = mktime(gmtime(secs)) - *secs; /*@=nullpass@*/
/* adjust to UTC */ *secs += timezone_offset;
and what *should* be seconds since epoch in UTC is stored in header. But since there was no unambigous way to specify timezone, there's the usual timezone shifting implicit in how build machine (or mock) is configured.
Then rpm -qp --changelog converts from seconds back to display time using the "standard" conversion
const char * strftimeFormat = _("%a %b %d %Y"); ... struct tm * tstruct; char buf[50];
/* this is important if sizeof(rpmuint64_t) ! sizeof(time_t) */ { time_t dateint = he->p.ui64p[0]; <== this is seconds since epoch tstruct = localtime(&dateint); } buf[0] = '\0'; if (tstruct) (void) strftime(buf, sizeof(buf) - 1, strftimeFormat, tstruct);
So in essence, the spec file is parsed wrto one local time zone, and -- changelog is displayed wrto another local time zone, and what's in the header is in UTC (assuming the build system was configured correctly and the spec file was written in local time).
I wouldn't worry too much. The real flaw is in the %changelog parser, and heaven forbids changing to include a timezone indicator in %changelog entries without collusion between God and the Devil.
But rpm *will* get the day of week correct even if its incorrectly entered into the spec file %changelog.
hth
73 de Jeff
Jeff Johnson wrote:
On May 19, 2009, at 7:29 AM, Ralph Angenendt wrote:
Yay! I invented a time machine! (or someone did).
;-) Well, rpm *will* correct the day of the week for you in case you've forgotten. Try and see ...
Hmmm. * Tue May 19 2009 looks correct to me, the calendar applet on my Desktop tells me the same, as does my mobile phone.
Something is not right here. Is this something to worry about? How and why does that happen? Why are there even calculations on the date line in a changelog?
There aren't any calculations, but there are two conversions involved.
During build a straightforward date/time parser (hint: which doesn't use day of week) parses the string in the spec file into a struct tm time;
I'm still not getting your hint :)
Note that %changelog cannot specify a timezone. Silly but true.
Then these transforms are applied to attempt to get UTC:
*secs = mktime(&time); if (*secs == -1) return -1; /* determine timezone offset *//*@-nullpass@*/ /* gmtime(3) unlikely to return NULL soon. */ timezone_offset = mktime(gmtime(secs)) - *secs; /*@=nullpass@*/
/* adjust to UTC */ *secs += timezone_offset;and what *should* be seconds since epoch in UTC is stored in header. But since there was no unambigous way to specify timezone, there's the usual timezone shifting implicit in how build machine (or mock) is configured.
Meaning: If my mock runs in EDT (as it seemingly does for me), finds out that it is at 7:29 am, it then shifts to UTC (4 hours ahead), making it 11:29 am then. This still is Tue May 19 2009 in this case. Am I correct with that assumption?
Then rpm -qp --changelog converts from seconds back to display time using the "standard" conversion
const char * strftimeFormat = _("%a %b %d %Y"); ... struct tm * tstruct; char buf[50];
/* this is important if sizeof(rpmuint64_t) ! sizeof(time_t) */ { time_t dateint = he->p.ui64p[0]; <== this is secondssince epoch tstruct = localtime(&dateint); } buf[0] = '\0'; if (tstruct) (void) strftime(buf, sizeof(buf) - 1, strftimeFormat, tstruct);
So in essence, the spec file is parsed wrto one local time zone, and -- changelog is displayed wrto another local time zone, and what's in the header is in UTC (assuming the build system was configured correctly and the spec file was written in local time).
This is what I don't get. I'm UTC +0200 - why do I get a shift of date to the next day in there, essentially leaving me on May 20th? Why don't I get that when I'm on BST (UTC +0100)?
I wouldn't worry too much. The real flaw is in the %changelog parser, and heaven forbids changing to include a timezone indicator in %changelog entries without collusion between God and the Devil.
Okay. We were worried that other parts of the rpm might also be affected in one or the other way.
But rpm *will* get the day of week correct even if its incorrectly entered into the spec file %changelog.
I still don't get that. Care to expand on it? I still assume that I entered the weekday correctly :)
Cheers,
Ralph
On May 19, 2009, at 9:53 AM, Ralph Angenendt wrote:
Jeff Johnson wrote:
Meaning: If my mock runs in EDT (as it seemingly does for me), finds out that it is at 7:29 am, it then shifts to UTC (4 hours ahead), making it 11:29 am then. This still is Tue May 19 2009 in this case. Am I correct with that assumption?
You can test the above by changing timezones and displaying the changelogtime as integer seconds, not (as --changelog does) converting back to a displayformat.
rpm -qp --qf '[%{changelogtime}\n]' foo*.src.rpm vs ...............%{changelogtime:day}............. is the essential difference between what is in the RPMTAG_CHANGELOGTIME int32 array (i.e. seconds since 1/1/1970) and what is displayed.
So in essence, the spec file is parsed wrto one local time zone, and -- changelog is displayed wrto another local time zone, and what's in the header is in UTC (assuming the build system was configured correctly and the spec file was written in local time).
This is what I don't get. I'm UTC +0200 - why do I get a shift of date to the next day in there, essentially leaving me on May 20th? Why don't I get that when I'm on BST (UTC +0100)?
I can't tell precisely without a reproducer. Does one get an extra hour of life in the spring or the fall? All depends on reference points of comparison, not the time itself. There are similar reference points implicit in parsing times from %changelog entries and attempting to convert to UTC.
But rpm *will* get the day of week correct even if its incorrectly entered into the spec file %changelog.
I still don't get that. Care to expand on it? I still assume that I entered the weekday correctly :)
I was trying to illustrate the "reference point" problem using day of week, albeit obscurely.
Edit a spec file, change the day of week in some entry.
Build.
Use rpm -qp --changelog foo*.rpm.
The day of the week will be corrected in the displayed output.
The point is that WYSIWYG can/will mislead you when there are conversions involved.
73 de Jeff
Jeff Johnson wrote:
On May 19, 2009, at 9:53 AM, Ralph Angenendt wrote:
But rpm *will* get the day of week correct even if its incorrectly entered into the spec file %changelog.
I still don't get that. Care to expand on it? I still assume that I entered the weekday correctly :)
The point is that WYSIWYG can/will mislead you when there are conversions involved.
Ah okay. Still strange, though :)
Cheers,
Ralph
On May 19, 2009, at 10:49 AM, Ralph Angenendt wrote:
Ah okay. Still strange, though :)
And yes it is RPM mis-feature that can never really be fixed.
Is there anyone around who wants to re-edit every *.spec in existence to become "standard" compliant across time zones?
Even drawing a line in the sand, and saying henceforth spec changelogs will use "standard" times, adds what is likely an intolerable (imho) configuration change for every RPM based build system in the world.
And so it goes, strange and quirky.
73 de Jeff
Jeff Johnson wrote:
On May 19, 2009, at 10:49 AM, Ralph Angenendt wrote:
Ah okay. Still strange, though :)
Even drawing a line in the sand, and saying henceforth spec changelogs will use "standard" times, adds what is likely an intolerable (imho) configuration change for every RPM based build system in the world.
And so it goes, strange and quirky.
Okay, I keep on living in the future then, knowing that normal life is just a timezone away :)
Thanks,
Ralph
Ralph Angenendt wrote:
Jeff Johnson wrote:
On May 19, 2009, at 10:49 AM, Ralph Angenendt wrote:
Ah okay. Still strange, though :)
Even drawing a line in the sand, and saying henceforth spec changelogs will use "standard" times, adds what is likely an intolerable (imho) configuration change for every RPM based build system in the world.
And so it goes, strange and quirky.
Okay, I keep on living in the future then, knowing that normal life is just a timezone away :)
/me offers 4.000.000 Euro for advanced info on the lottery numbers from .ro.
-
Jeff Johnson -
Manuel Wolfshant -
Ralph Angenendt