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

From: Karl Berry <karl <at> freefriends.org>
To: eblake <at> redhat.com
Cc: sanvila <at> debian.org, 77805 <at> debbugs.gnu.org, bug-m4 <at> gnu.org
Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
Date: Wed, 16 Apr 2025 15:30:35 -0600

Hi Eric and all,

eb> now questioning why Debian ever needed a patch to rip UPDATED out of
eb> the manual in the name of reproducibility.

Me too.

If the mtime isn't changed, then the original UPDATED should be
unchanged, and there's no problem.

If the mtime is intentionally changed by a patch or some such, then
UPDATED should, in fact, be updated. Seems to me.

If the mtime is changed incorrectly, e.g., because git didn't preserve
mtimes (is that in fact the original cause?), isn't it up to whatever
process created the problem to also fix it?  How can Automake know
whether an mtime change is "real" or not?  Automake certainly can't
assume that the project is using git, or following particular
conventions with releases, or whatever.  And adding another file to be
updated by hand would make the problem worse, not better, so far as I
can see. So I'm stumped.

> by ALL packages affected by the same problem will

I still don't understand what the "problem" is. I.e., how the mtime gets
changed in the first place.

In general, it seems unfortunate to me to eliminate useful information
from the manual because of a reproducibility bug elsewhere in the build
process. Expedient, yes, I can see that, but unfortunate, and not in
users' best interests. -k

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.