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 <k...@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 <rei...@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. > >
