GNU bug report logs -
#77805
new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 25 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.