GNU bug report logs -
#51609
version.texi UPDATED field does not account for timezone; can cause unnecessary documentation rebuilds, which could fail
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51609 in the body.
You can then email your comments to 51609 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-automake <at> gnu.org
:
bug#51609
; Package
automake
.
(Fri, 05 Nov 2021 14:51:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ryan Schmidt <automake <at> ryandesign.com>
:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org
.
(Fri, 05 Nov 2021 14:51:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The method by which automake decides to regenerate version.texi and thereby to regenerate texinfo-based documentation is flawed because it does not account for the fact that the user's timezone may be different from the developer's timezone. The version.texi UPDATED and UPDATED-MONTH fields do not specify a timezone. If configure has been modified and if the user's timezone is sufficiently different from the developer's, then UPDATED or less frequently UPDATED-MONTH may change even though the texinfo sources' timestamps have not, which will cause an unnecessary documentation rebuild, which may fail. For a build failure that was caused by this flaw, see:
https://trac.macports.org/ticket/63570#comment:5
Information forwarded
to
bug-automake <at> gnu.org
:
bug#51609
; Package
automake
.
(Sat, 06 Nov 2021 21:11:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 51609 <at> debbugs.gnu.org (full text, mbox):
Hi Ryan - thanks for the report. In Automake, those version.texi
variables are updated by the auxiliary script mdate-sh. In Automake
1.16, it seems mdate-sh was changed to compute the dates using UTC
(ChangeLog entry below, describing exactly what you saw, it seems),
with these lines:
# Use UTC to get reproducible result.
TZ=UTC0
export TZ
You can get the latest mdate-sh from automake or gnulib and just put it
in place independent of any other updates.
If you already have the latest mdate-sh, then I'd appreciate seeing a
recipe to reproduce, hopefully with smaller than gdbm itself
.. --thanks, karl.
2017-09-15 Reiner Herrmann <reiner <at> reiner-h.de> (tiny change)
mdate-sh: Ensure reproducible time output
This change fixes automake bug#20314.
[ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20314 ]
'mdate-sh' pretty-prints the modification time of a file. But it's
output can vary depending on the timezone of the caller. Someone in
timezone GMT-12 will get a different result (day) than someone in
timezone GMT+12. As this output is also used to create/update stamp
files, which influence the further build process, the build result can
vary.
* lib/mdate-sh: Set 'TZ' to UTC which ensures reproducible output.
* NEWS: Announce bug fix.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#51609
; Package
automake
.
(Sun, 07 Nov 2021 16:54:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 51609 <at> debbugs.gnu.org (full text, mbox):
Thanks Karl, that must be the same problem. Apologies for not finding that in my searches prior to filing this bug.
gdbm 1.22 ships with mdate-sh "scriptversion=2010-08-21.06; # UTC" so it must not yet include this fix. Looks like their makefiles are generated with automake 1.15. I'll file a bug report with gdbm asking them to regenerate with automake 1.16 or later.
> On Nov 6, 2021, at 16:10, Karl Berry <karl <at> freefriends.org> wrote:
>
> Hi Ryan - thanks for the report. In Automake, those version.texi
> variables are updated by the auxiliary script mdate-sh. In Automake
> 1.16, it seems mdate-sh was changed to compute the dates using UTC
> (ChangeLog entry below, describing exactly what you saw, it seems),
> with these lines:
>
> # Use UTC to get reproducible result.
> TZ=UTC0
> export TZ
>
> You can get the latest mdate-sh from automake or gnulib and just put it
> in place independent of any other updates.
>
> If you already have the latest mdate-sh, then I'd appreciate seeing a
> recipe to reproduce, hopefully with smaller than gdbm itself
> .. --thanks, karl.
>
>
> 2017-09-15 Reiner Herrmann <reiner <at> reiner-h.de> (tiny change)
>
> mdate-sh: Ensure reproducible time output
>
> This change fixes automake bug#20314.
> [ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20314 ]
>
> 'mdate-sh' pretty-prints the modification time of a file. But it's
> output can vary depending on the timezone of the caller. Someone in
> timezone GMT-12 will get a different result (day) than someone in
> timezone GMT+12. As this output is also used to create/update stamp
> files, which influence the further build process, the build result can
> vary.
>
> * lib/mdate-sh: Set 'TZ' to UTC which ensures reproducible output.
> * NEWS: Announce bug fix.
>
>
Reply sent
to
Karl Berry <karl <at> freefriends.org>
:
You have taken responsibility.
(Sun, 28 Nov 2021 01:46:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ryan Schmidt <automake <at> ryandesign.com>
:
bug acknowledged by developer.
(Sun, 28 Nov 2021 01:46:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 51609-done <at> debbugs.gnu.org (full text, mbox):
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 26 Dec 2021 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 84 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.