Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz

From: Eric Blake <[email-masked]>
Date: Tue, 15 Apr 2025 07:52:47 -0500

On Mon, Apr 14, 2025 at 04:15:49PM -0600, Karl Berry wrote:
>     since unpacking the tarball in different months may inadverently
>     result in two environments with different dates on the file
> 
> It could? Shouldn't the mtime in the tarball be preserved when
> unpacking, on any reasonable system? And if the .texi in fact changes,
> then isn't it fine for the new date (mtime) to be used? I'm missing
> something.

Hmm.  You're right that tar preserves timestamps insofar as possible.
The loss of fractional seconds (up to a resolution of 2s on
less-than-stellar filesystems like FAT) shouldn't impact the times
placed into version.texi, since that only goes by day, not fraction of
second.  I must be thinking of git checkouts - it is git that likes to
alter the mtime of files to the point at which you checked out a
repository, and not when the commit itself happened.  So
reproducibility when building from a tarball does not appear to be the
issue, so much as reproducibility from a git checkout.

I'm not sure the exact process Debian uses to do downstream builds,
but my guess is that it involves a downstream git repository for their
patches to be applied on top of the upstream tarball - and it is the
very act of applying those patches from git which can alter the mtime
of $PACKAGE.texi, which in turn changes the date that
build-aux/mdate-sh installs into version.texi, which then breaks
reproducible builds.  And on that front, I could argue that anyone not
building directly from the tarball, and who therefore triggers a
different timestamp as part of their downstream process, should be
fixing their downstream process to address reproducibility, rather
than patching upstream to rip out dates just to make downstream's life
easier.

>     caller to specify an epoch that a particular build should place into
>     version.texi, regardless of file timestamps being newer than that
>     specified epoch?
> 
> I'm not sure what you mean by "epoch". I think of "epoch" as meaning
> 1970-01-01, in our world. Not as a value to be specified.

Sorry for the confusion.  When speaking of reproducible builds, I
think of the Epoch (capital E) as 1970-01-01, and the epoch (little e)
as the timestamp at which a given build is trying to reproduce.  The
theory of a reproducible build is that no matter how much time has
elapsed between the epoch of when the build was first created and when
you are later trying to reproduce it, the later reproduction SHOULD be
able to get back the same outputs by telling the build machinery to
pin time to the build epoch rather than the current time.  This
pinning can be done by faking the system clock to an older date
(although that is rather undesirable), or by using environment
variables and/or command line options to various tools that embed
dates into their outputs.

See https://reproducible-builds.org/docs/source-date-epoch/ for the
documentation of $SOURCE_DATE_EPOCH, the environment variable that is
most commonly used to pin timestamps during a reproducible build.

> 
>     Then, manuals could continue to use @value{UPDATED},
> 
> Well, that is clearly desirable.  I looked at the bug-m4 thread from
> https://lists.gnu.org/archive/html/bug-m4/2025-04/msg00043.html
> but I'm afraid I understand neither the problem nor the given solutions.

Fortunately, Simon's response made sense to me: with a bit of code
added to configure.ac, it becomes possible to slam the mtime of
doc/$PACKAGE.texi to the same timestamp as the last git commit
(regardless of whatever other mtime git itself assigned the file), all
before build-aux/mdate-sh is run, so that you can once again have
UPDATED in version.texi pinned to a reliable epoch despite git itself
not having the same timestamp-preserving behavior as tar.

> 
> Anyway, if there's a change to be made to mdate-sh or Automake, let me
> know.  Ideally with a patch (and even more ideally also with a test).
> 
> I'm hoping to make a new Automake release soonly. If there's something
> to do for this problem, clearly it would be nice to include. --thanks, karl.

At this point, I will have to leave any patches to mdate-sh to the
larger community of people working on reproducible builds.  A patch to
mdate-sh might take the form of checking (possibly only when a
command-line option is also specified) if $SOURCE_DATE_EPOCH is set in
the environment, and if so favoring that timestamp over the mdate of
its target file.  Or maybe keep mdate-sh unchanged, but patch the
Automake rule for doc/stamp-vti to honor SOURCE_DATE_EPOCH over
mdate-sh.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org