[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#51609: version.texi UPDATED field does not account for timezone; can
bug#51609: version.texi UPDATED field does not account for timezone; can cause unnecessary documentation rebuilds, which could fail
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 <firstname.lastname@example.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.
> 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 <email@example.com> (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
> * lib/mdate-sh: Set 'TZ' to UTC which ensures reproducible output.
> * NEWS: Announce bug fix.