GNU logs - #77805, boring messages

Message sent to bug-automake@HIDDEN:

Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
Resent-From: Eric Blake <eblake@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-automake@HIDDEN
Resent-Date: Mon, 14 Apr 2025 16:36:02 +0000
Resent-Message-ID: <handler.77805.B.174464850621395 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Santiago Vila <sanvila@HIDDEN>
Cc: 77805 <at> debbugs.gnu.org, bug-m4@HIDDEN
Date: Mon, 14 Apr 2025 11:34:38 -0500
From: Eric Blake <eblake@HIDDEN>
Message-ID: <g62cndt46msjadd7paxj6s72gqet7d3l4mdpmaxlibp4fpl7iq@exxcn7ty7quc>
References: <t7xpsxicg3xikrag7h4fagsxh4j57i2ljbkdcfg53yezn4lre7@xocyiap357an>
 <02d21883-fe76-4c3e-9cf2-4f834f5c4e50@HIDDEN>
 <yncaaf25qcyibrmq35z5xxueedwyl7savllii75ynn4eo2rzku@hc66c5fbqsuz>
 <a0d39607-d5a2-417f-a410-a83d15ca06c8@HIDDEN>
MIME-Version: 1.0
In-Reply-To: <a0d39607-d5a2-417f-a410-a83d15ca06c8@HIDDEN>
User-Agent: NeoMutt/20250113
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=170.10.129.124; envelope-from=eblake@HIDDEN;
 helo=us-smtp-delivery-124.mimecast.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,
 DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
 RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.1 (/)

[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

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Eric Blake <eblake@HIDDEN>
Subject: bug#77805: Acknowledgement (new snapshot available:
 m4-1.4.19.60-6ebfc.tar.xz)
Message-ID: <handler.77805.B.174464850621395.ack <at> debbugs.gnu.org>
References: <g62cndt46msjadd7paxj6s72gqet7d3l4mdpmaxlibp4fpl7iq@exxcn7ty7quc>
X-Gnu-PR-Message: ack 77805
X-Gnu-PR-Package: automake
Reply-To: 77805 <at> debbugs.gnu.org
Date: Mon, 14 Apr 2025 16:36:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-automake@HIDDEN

If you wish to submit further information on this problem, please
send it to 77805 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
77805: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D77805
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-automake@HIDDEN:

Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
References: <g62cndt46msjadd7paxj6s72gqet7d3l4mdpmaxlibp4fpl7iq@exxcn7ty7quc>
Resent-From: Karl Berry <karl@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-automake@HIDDEN
Resent-Date: Mon, 14 Apr 2025 22:16:01 +0000
Resent-Message-ID: <handler.77805.B77805.174466895620077 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: eblake@HIDDEN
Cc: sanvila@HIDDEN, 77805 <at> debbugs.gnu.org, bug-m4@HIDDEN
Date: Mon, 14 Apr 2025 16:15:49 -0600
Message-Id: <202504142215.53EMFniX942189@HIDDEN>
From: Karl Berry <karl@HIDDEN>
In-Reply-To: <g62cndt46msjadd7paxj6s72gqet7d3l4mdpmaxlibp4fpl7iq@exxcn7ty7quc>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi Eric and all,

    mdate-sh was older at the time 1.4.19
    was cut; it has changed in the meantime

The only changes to mdate-sh in recent years have been trivialities
involving the help message and induced Emacs incompatibilities for the
Local Variables block. The actual code hasn't changed in ages.

    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.

    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.

    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.

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.

Last modified: Mon, 14 Apr 2025 22:30:03 UTC

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