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
