Received: (at 77805) by debbugs.gnu.org; 14 Apr 2025 22:15:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 14 18:15:56 2025
Received: from localhost ([127.0.0.1]:49379 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4S5r-0005Dl-SE
for submit <at> debbugs.gnu.org; Mon, 14 Apr 2025 18:15:56 -0400
Received: from frenzy.freefriends.org ([198.99.81.75]:43914
helo=freefriends.org)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <karl@HIDDEN>)
id 1u4S5p-0005DX-AJ
for 77805 <at> debbugs.gnu.org; Mon, 14 Apr 2025 18:15:53 -0400
X-Envelope-From: karl@HIDDEN
Received: from freefriends.org (localhost [127.0.0.1])
by freefriends.org (8.16.1/8.16.1) with ESMTPS id 53EMFnMr942190
(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT);
Mon, 14 Apr 2025 16:15:49 -0600
Received: (from apache@localhost)
by freefriends.org (8.16.1/8.14.7/Submit) id 53EMFniX942189;
Mon, 14 Apr 2025 16:15:49 -0600
Date: Mon, 14 Apr 2025 16:15:49 -0600
Message-Id: <202504142215.53EMFniX942189@HIDDEN>
From: Karl Berry <karl@HIDDEN>
To: eblake@HIDDEN
Subject: Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
In-Reply-To: <g62cndt46msjadd7paxj6s72gqet7d3l4mdpmaxlibp4fpl7iq@exxcn7ty7quc>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 77805
Cc: sanvila@HIDDEN, 77805 <at> debbugs.gnu.org, bug-m4@HIDDEN
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: -3.3 (---)
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.
bug-automake@HIDDEN:bug#77805; Package automake.
Full text available.
Received: (at submit) by debbugs.gnu.org; 14 Apr 2025 16:35:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 14 12:35:06 2025
Received: from localhost ([127.0.0.1]:48667 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1u4Mm1-0005Yc-Pq
for submit <at> debbugs.gnu.org; Mon, 14 Apr 2025 12:35:06 -0400
Received: from lists.gnu.org ([2001:470:142::17]:53442)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eblake@HIDDEN>) id 1u4Mlx-0005W7-T3
for submit <at> debbugs.gnu.org; Mon, 14 Apr 2025 12:35:03 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eblake@HIDDEN>) id 1u4Mlq-00030C-C1
for bug-automake@HIDDEN; Mon, 14 Apr 2025 12:34:54 -0400
Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eblake@HIDDEN>) id 1u4Mll-00058h-FD
for bug-automake@HIDDEN; Mon, 14 Apr 2025 12:34:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1744648488;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references;
bh=8ya5ElHNShUCMEMlbfYeiYtYjZExSQxo7MWSZ4b1yck=;
b=QxXOL5dhe6ndLaw1ISo6FOOD7p/jF9a0IWOGm0lXB1IAUNggdVNuxQsyUJH/il5TTnIxj7
HJL/PXj5xwoTEoYHMLaUTqa1U/Rbdj5zI0/uZoiO3thVxbFBg0E5wRFspPjdPP/aQ8txAB
ICDlJ9o1S6gsYpMRJCGq2EqPUh/p7EQ=
Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com
(ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by
relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,
cipher=TLS_AES_256_GCM_SHA384) id us-mta-685-uNSPCWO4Og6l1yp3iNahsQ-1; Mon,
14 Apr 2025 12:34:44 -0400
X-MC-Unique: uNSPCWO4Og6l1yp3iNahsQ-1
X-Mimecast-MFC-AGG-ID: uNSPCWO4Og6l1yp3iNahsQ_1744648483
Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com
(mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
id 8FB001801A1A; Mon, 14 Apr 2025 16:34:43 +0000 (UTC)
Received: from redhat.com (unknown [10.2.16.12])
by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS
id 33DF5180B487; Mon, 14 Apr 2025 16:34:41 +0000 (UTC)
Date: Mon, 14 Apr 2025 11:34:38 -0500
From: Eric Blake <eblake@HIDDEN>
To: Santiago Vila <sanvila@HIDDEN>
Subject: Re: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
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
X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: s2vKijeoYnKmsYGGC9NFncq4fB54GshWG9jeS_Bh0uY_1744648483
X-Mimecast-Originator: redhat.com
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-Debbugs-Envelope-To: submit
Cc: bug-automake@HIDDEN, bug-m4@HIDDEN
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
Eric Blake <eblake@HIDDEN>:bug-automake@HIDDEN.
Full text available.bug-automake@HIDDEN:bug#77805; Package automake.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.