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

From: Santiago Vila <[email-masked]>
Date: Tue, 15 Apr 2025 19:55:08 +0200

El 15/4/25 a las 14:52, Eric Blake escribió:
> 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.

Debian uses the original tarball plus a series of patches in quilt format
(from another small tarball containing only debian/* files), which are applied
in a given order before the build.

So the procedure is not exactly how you describe, but the mechanism by which
reproducibility may be lost is very similar.

> 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.

Maybe a different timestamp is a change too small to regenerate the date
which is used in the manual as the date in which the manual is published.

Ideally, the date would be chosen and stored in a static file as part of
your upstream release process, i.e. when you are about to release m4-1.4.20,
and we should not change such file unless we really meant a different time.

(Is this the same as "maintainer mode" or maybe those two things
could be independent?)

Thanks.