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.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ryan Schmidt <automake <at> ryandesign.com>
To: bug-automake <at> gnu.org
Subject: version.texi UPDATED field does not account for timezone; can cause
 unnecessary documentation rebuilds, which could fail
Date: Fri, 5 Nov 2021 06:01:44 -0500

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

Message #8 received at 51609 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: automake <at> ryandesign.com
Cc: 51609 <at> debbugs.gnu.org
Subject: Re: bug#51609: version.texi UPDATED field does not account for
 timezone; 
 can cause unnecessary documentation rebuilds, which could fail
Date: Sat, 6 Nov 2021 15:10:43 -0600

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.

Message #11 received at 51609 <at> debbugs.gnu.org (full text, mbox):

From: Ryan Schmidt <automake <at> ryandesign.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: 51609 <at> debbugs.gnu.org
Subject: Re: bug#51609: version.texi UPDATED field does not account for
 timezone; can cause unnecessary documentation rebuilds, which could fail
Date: Sun, 7 Nov 2021 10:27:15 -0600

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.
> 
> 

Message #16 received at 51609-done <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: 51609-done <at> debbugs.gnu.org
Subject: Re: bug#51609: version.texi UPDATED field does not account for
 timezone; 
 can cause unnecessary documentation rebuilds, which could fail
Date: Sat, 27 Nov 2021 18:45:18 -0700

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.