Subject: Re: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
From: Eric Blake <[email-masked]>
To: Santiago Vila <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Mon, 14 Apr 2025 11:34:38 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

[dropping gnulib, but adding automake, for the reproducibility issue]

On Mon, Apr 14, 2025 at 06:04:53PM +0200, Santiago Vila wrote:
> El 14/4/25 a las 16:36, Eric Blake escribió:
> > Also, I see two
> > uses of @value{UPDATED} in m4.texi, but your patch only removed one;
> > is the other one not an issue?
> 
> You are right. I don't know. For some reason, only the patch I posted before
> was necessary at least for the 1.4.19 version, as shown here:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/m4.html

It _could_ be that automake's mdate-sh was older at the time 1.4.19
was cut; it has changed in the meantime, although I could not quickly
ascertain if any of those changes would be important to the issue at
hand in this email.

> 
> Those tests check the produced .debs (m4 and m4-doc in this case).
> 
> The m4 package contains the info manual, and the m4-doc package contains
> the manual in html format.
> 
> If the variation only happened in the .dvi or the .pdf, for example,
> the above tests would still mark the Debian package as reproducible,
> as we don't distribute those artifacts in binary packages.
> 
> I have not tested the new snapshot yet for reproducibility issues, but
> will probably try for the next snapshot.

According to 'info automake', version.texi is supposed to be generated
with contents including:

‘UPDATED’
     This holds the date the primary ‘.texi’ file was last modified.

and this is done via the build-aux/mdate-sh script.  It looks like
that script is hard-coded to scrape the date a file was last modified
(which hurts in reproducibility, since unpacking the tarball in
different months may inadverently result in two environments with
different dates on the file, and thus different contents generated
into version.texi).

Wouldn't it be better for the universe of reproducible builds if
automake's generation of version.texi were improved to allow the
caller to specify an epoch that a particular build should place into
version.texi, regardless of file timestamps being newer than that
specified epoch?  Then, manuals could continue to use @value{UPDATED},
as recommended by the texinfo manual.

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