From unknown Sun Jun 15 08:52:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz Resent-From: Eric Blake Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 14 Apr 2025 16:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 77805 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Santiago Vila Cc: 77805@debbugs.gnu.org, bug-m4@gnu.org X-Debbugs-Original-Cc: bug-automake@gnu.org, bug-m4@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.174464850621395 (code B ref -1); Mon, 14 Apr 2025 16:36:02 +0000 Received: (at submit) by debbugs.gnu.org; 14 Apr 2025 16:35:06 +0000 Received: from localhost ([127.0.0.1]:48667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u4Mm1-0005Yc-Pq for submit@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 ) id 1u4Mlx-0005W7-T3 for submit@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 ) id 1u4Mlq-00030C-C1 for bug-automake@gnu.org; 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 ) id 1u4Mll-00058h-FD for bug-automake@gnu.org; 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 Message-ID: References: <02d21883-fe76-4c3e-9cf2-4f834f5c4e50@debian.org> MIME-Version: 1.0 In-Reply-To: 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@redhat.com; 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From unknown Sun Jun 15 08:52:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz References: Resent-From: Karl Berry Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 14 Apr 2025 22:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77805 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: eblake@redhat.com Cc: sanvila@debian.org, 77805@debbugs.gnu.org, bug-m4@gnu.org Received: via spool by 77805-submit@debbugs.gnu.org id=B77805.174466895620077 (code B ref 77805); Mon, 14 Apr 2025 22:16:01 +0000 Received: (at 77805) by debbugs.gnu.org; 14 Apr 2025 22:15:56 +0000 Received: from localhost ([127.0.0.1]:49379 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u4S5r-0005Dl-SE for submit@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 ) id 1u4S5p-0005DX-AJ for 77805@debbugs.gnu.org; Mon, 14 Apr 2025 18:15:53 -0400 X-Envelope-From: karl@freefriends.org 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@freefriends.org> From: Karl Berry In-Reply-To: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From unknown Sun Jun 15 08:52:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz Resent-From: Eric Blake Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 15 Apr 2025 12:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77805 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Karl Berry Cc: sanvila@debian.org, 77805@debbugs.gnu.org, bug-m4@gnu.org Received: via spool by 77805-submit@debbugs.gnu.org id=B77805.17447215844137 (code B ref 77805); Tue, 15 Apr 2025 12:54:02 +0000 Received: (at 77805) by debbugs.gnu.org; 15 Apr 2025 12:53:04 +0000 Received: from localhost ([127.0.0.1]:51101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u4fmh-00014d-R6 for submit@debbugs.gnu.org; Tue, 15 Apr 2025 08:53:04 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:40039) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u4fme-00014D-NS for 77805@debbugs.gnu.org; Tue, 15 Apr 2025 08:53:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744721579; 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: in-reply-to:in-reply-to:references:references; bh=Xog11Gco+MWbvaS1GYmn0sr01GA0K4AtOLRgmJnVfGc=; b=NVwnAOfg9RzA1QKzup1WQB483bNv/H8CuAtklNC8ZisXBGxaDYidPJQJePv0ZrW0xjzSH0 2pHdv73qtHmFeRHBYcrQRpT6HIgiUZ1A9M2ArlS0JJBuMY/06dF0fdcqu8cK0i/MgnfR3C aE1kKVp/BTim7ExDQhR9fglTUHbopAo= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-654-8AwyasCINsKEENJKEbZ8fg-1; Tue, 15 Apr 2025 08:52:53 -0400 X-MC-Unique: 8AwyasCINsKEENJKEbZ8fg-1 X-Mimecast-MFC-AGG-ID: 8AwyasCINsKEENJKEbZ8fg_1744721572 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D1C431956055; Tue, 15 Apr 2025 12:52:51 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.12]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C80291955BF1; Tue, 15 Apr 2025 12:52:49 +0000 (UTC) Date: Tue, 15 Apr 2025 07:52:47 -0500 From: Eric Blake Message-ID: References: <202504142215.53EMFniX942189@freefriends.org> MIME-Version: 1.0 In-Reply-To: <202504142215.53EMFniX942189@freefriends.org> User-Agent: NeoMutt/20250113 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: AiSgH6OPzh749hdS1OTlDi_akqb2XBMVu3rzuFhxuA4_1744721572 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Apr 14, 2025 at 04:15:49PM -0600, Karl Berry wrote: > 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. Hmm. You're right that tar preserves timestamps insofar as possible. The loss of fractional seconds (up to a resolution of 2s on less-than-stellar filesystems like FAT) shouldn't impact the times placed into version.texi, since that only goes by day, not fraction of second. I must be thinking of git checkouts - it is git that likes to alter the mtime of files to the point at which you checked out a repository, and not when the commit itself happened. So reproducibility when building from a tarball does not appear to be the issue, so much as reproducibility from a git checkout. 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. 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. > 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. Sorry for the confusion. When speaking of reproducible builds, I think of the Epoch (capital E) as 1970-01-01, and the epoch (little e) as the timestamp at which a given build is trying to reproduce. The theory of a reproducible build is that no matter how much time has elapsed between the epoch of when the build was first created and when you are later trying to reproduce it, the later reproduction SHOULD be able to get back the same outputs by telling the build machinery to pin time to the build epoch rather than the current time. This pinning can be done by faking the system clock to an older date (although that is rather undesirable), or by using environment variables and/or command line options to various tools that embed dates into their outputs. See https://reproducible-builds.org/docs/source-date-epoch/ for the documentation of $SOURCE_DATE_EPOCH, the environment variable that is most commonly used to pin timestamps during a reproducible build. > > 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. Fortunately, Simon's response made sense to me: with a bit of code added to configure.ac, it becomes possible to slam the mtime of doc/$PACKAGE.texi to the same timestamp as the last git commit (regardless of whatever other mtime git itself assigned the file), all before build-aux/mdate-sh is run, so that you can once again have UPDATED in version.texi pinned to a reliable epoch despite git itself not having the same timestamp-preserving behavior as tar. > > 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. At this point, I will have to leave any patches to mdate-sh to the larger community of people working on reproducible builds. A patch to mdate-sh might take the form of checking (possibly only when a command-line option is also specified) if $SOURCE_DATE_EPOCH is set in the environment, and if so favoring that timestamp over the mdate of its target file. Or maybe keep mdate-sh unchanged, but patch the Automake rule for doc/stamp-vti to honor SOURCE_DATE_EPOCH over mdate-sh. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org From unknown Sun Jun 15 08:52:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz Resent-From: Santiago Vila Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 15 Apr 2025 17:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77805 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Eric Blake , Karl Berry Cc: 77805@debbugs.gnu.org, bug-m4@gnu.org Received: via spool by 77805-submit@debbugs.gnu.org id=B77805.174473972015641 (code B ref 77805); Tue, 15 Apr 2025 17:56:02 +0000 Received: (at 77805) by debbugs.gnu.org; 15 Apr 2025 17:55:20 +0000 Received: from localhost ([127.0.0.1]:55115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u4kVD-00043z-82 for submit@debbugs.gnu.org; Tue, 15 Apr 2025 13:55:20 -0400 Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:48422) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u4kV9-000408-T5 for 77805@debbugs.gnu.org; Tue, 15 Apr 2025 13:55:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:Content-Transfer-Encoding:Content-Type :In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID: Reply-To:Content-ID:Content-Description; bh=FDiS/81uAeJV9ZA3ug+yqLl+kbXeEQ5cnjVZ+K+UtCg=; b=H5DwzGMLpPQWsoDd+i6VyiPxIO ZmzK4t7K/yKN0GWOyfRbkmVKXqZfGyhyLw+rKd5qVyaHBfonekXybA/PYFtJsBcaS4H3vn2lDMIy6 zFKI/o9/tZ3wgqmWRWKGlPGCC+/wBWAujxyS3z0o7MSaeDAKTMMwSamWP6AEHX5R9NSQIVQ4YpB/p DBEJ6GL16PHnqNLVbSqHLdGZPqavcRauoAxa10+djQH8e/xxkhB8m14Rq+nptrBX5SD1WxZtKuEpo uEUgWN3aNMetWjB6V3w7oG8D7UcZjoMxkDuDuIinoNzox5bjDKO1Dl0/8pxBqn8ljIGvNfDqC1O+9 Fz/3abCQ==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim 4.94.2) (envelope-from ) id 1u4kV3-00445v-Mt; Tue, 15 Apr 2025 17:55:09 +0000 Message-ID: Date: Tue, 15 Apr 2025 19:55:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <202504142215.53EMFniX942189@freefriends.org> Content-Language: en-US From: Santiago Vila In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Debian-User: sanvila X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From unknown Sun Jun 15 08:52:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz Resent-From: Eric Blake Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 16 Apr 2025 12:53:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77805 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Santiago Vila Cc: 77805@debbugs.gnu.org, bug-m4@gnu.org, Karl Berry Received: via spool by 77805-submit@debbugs.gnu.org id=B77805.174480794128143 (code B ref 77805); Wed, 16 Apr 2025 12:53:03 +0000 Received: (at 77805) by debbugs.gnu.org; 16 Apr 2025 12:52:21 +0000 Received: from localhost ([127.0.0.1]:36671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u52FX-0007Jb-NT for submit@debbugs.gnu.org; Wed, 16 Apr 2025 08:52:21 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:41933) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u52FT-0007JF-Mk for 77805@debbugs.gnu.org; Wed, 16 Apr 2025 08:52:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744807935; 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=3dLzCh95Y9HYNI4zFDSkZZOdu9lDsrNEgqYTyIi9gEs=; b=Juh9mrp9oxXUD7ayam1z2c6+GByvgWEj5sTbsWTgcIpjNgICTJCUkmSNF/XrnAw3eOZTbK Og3GGbxq8+M7y+TQIwWHHudCbLvwDILxH5A6u8pHAbfWqVEbbsQ8Ia7MM1h42p8eBXQ+Pn A1ukKFZvZuYoynBX4XJus8Di2g2h7Yo= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-640-vrG7PAo7Pxq8X7pQWzNtMA-1; Wed, 16 Apr 2025 08:52:11 -0400 X-MC-Unique: vrG7PAo7Pxq8X7pQWzNtMA-1 X-Mimecast-MFC-AGG-ID: vrG7PAo7Pxq8X7pQWzNtMA_1744807930 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 4CA6A1956096; Wed, 16 Apr 2025 12:52:09 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.12]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 0BD9F30001A1; Wed, 16 Apr 2025 12:52:06 +0000 (UTC) Date: Wed, 16 Apr 2025 07:52:04 -0500 From: Eric Blake Message-ID: References: <202504142215.53EMFniX942189@freefriends.org> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20250113 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: acpH0v2eoJV7CKeRhtB2yP9AsYsusqLmPRG3fJcMxjk_1744807930 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Apr 15, 2025 at 07:55:08PM +0200, Santiago Vila wrote: > 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. Out of curiosity, do the Debian patches alter doc/m4.texi (and thus its mtime)? > > > 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. mdate-sh's granularity is one day; so any downstream process that touches mtime but takes more than 24 hours from the original tarball is running into the reproducibility issue of the downstream manual having a different date than the original upstream tarball. Not necessarily a problem if downstream WANTS a later date, unless downstream is also worried about being able to use the SAME date each time the downstream process is re-run, even when more than 24 hours have elapsed between runs. > > 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. And that ideal is _supposed_ to be met: automake generates the file doc/version.texi to contain the mtime of doc/$PACKAGE.texi, AND includes that generated file in the tarball. If the mtime is preserved, then the tarball SHOULD be producing the same datestamp for all subsequent builds of the documentation from that tarball. So I am now questioning why Debian ever needed a patch to rip UPDATED out of the manual in the name of reproducibility. But since mtime is fragile, ideas on making the reproducibility even more reliable in the face of downstream patches to m4.texi applied at a later date not causing version.texi to be rebuilt are still worth talking about. In the short term, I may install a one-off solution in m4's configure.ac (Simon's hack to force the mtime of doc/$PACKAGE.texi to the last git commit as part of configure seems nice); but in the long term, a more generic patch to automake and mdate-sh for use by ALL packages affected by the same problem will have a better outcome. > > (Is this the same as "maintainer mode" or maybe those two things > could be independent?) I think they are independent; maintainer mode controls how many generated files are cleaned, and tends to get in the way if you don't normally check generated files into version control. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org From unknown Sun Jun 15 08:52:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz References: Resent-From: Karl Berry Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 16 Apr 2025 21:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77805 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: eblake@redhat.com Cc: sanvila@debian.org, 77805@debbugs.gnu.org, bug-m4@gnu.org Received: via spool by 77805-submit@debbugs.gnu.org id=B77805.174483904412226 (code B ref 77805); Wed, 16 Apr 2025 21:31:02 +0000 Received: (at 77805) by debbugs.gnu.org; 16 Apr 2025 21:30:44 +0000 Received: from localhost ([127.0.0.1]:43558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u5ALD-0003B8-PM for submit@debbugs.gnu.org; Wed, 16 Apr 2025 17:30:44 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:33642 helo=freefriends.org) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u5AL9-0003AQ-NJ for 77805@debbugs.gnu.org; Wed, 16 Apr 2025 17:30:40 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 53GLUaUk1142480 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Apr 2025 15:30:36 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 53GLUZoT1142479; Wed, 16 Apr 2025 15:30:35 -0600 Date: Wed, 16 Apr 2025 15:30:35 -0600 Message-Id: <202504162130.53GLUZoT1142479@freefriends.org> From: Karl Berry In-Reply-To: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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 From unknown Sun Jun 15 08:52:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz References: Resent-From: Karl Berry Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 21 Apr 2025 20:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77805 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: eblake@redhat.com Cc: sanvila@debian.org, 77805@debbugs.gnu.org, bug-m4@gnu.org Received: via spool by 77805-submit@debbugs.gnu.org id=B77805.174526814420125 (code B ref 77805); Mon, 21 Apr 2025 20:43:02 +0000 Received: (at 77805) by debbugs.gnu.org; 21 Apr 2025 20:42:24 +0000 Received: from localhost ([127.0.0.1]:39437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u6xy9-0005E1-Br for submit@debbugs.gnu.org; Mon, 21 Apr 2025 16:42:24 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:60620 helo=freefriends.org) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u6xy3-0005Cw-Im for 77805@debbugs.gnu.org; Mon, 21 Apr 2025 16:42:18 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 53LKgD2A252105 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 21 Apr 2025 14:42:13 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 53LKgD6s252104; Mon, 21 Apr 2025 14:42:13 -0600 Date: Mon, 21 Apr 2025 14:42:13 -0600 Message-Id: <202504212042.53LKgD6s252104@freefriends.org> From: Karl Berry In-Reply-To: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) A patch to mdate-sh might take the form of checking (possibly only when a command-line option is also specified) if $SOURCE_DATE_EPOCH is set in the environment, and if so favoring that timestamp over the mdate of its target file. That sounds doable. Thanks. I don't think an extra option is needed; if SOURCE_DATE_EPOCH is set, I think it's usual for tools to use it without further ado. Isn't it? Santiago, would doing this obviate Debian's desire to eliminate UPDATED? For converting the epoch-seconds of SOURCE_DATE_EPOCH to DAY MONTH YEAR. we can't assume GNU date. But I guess most people using mdate-sh will have Automake and thus also have Perl, so the simplest I can think of is: perl -e 'print scalar gmtime(1000)' # outputs -> Thu Jan 1 00:16:40 1970 and then extract fields 2, 3, 5 with awk/sed/cut/whatever. (I recently saw complaints about using awk in configure so that "minimal" systems don't have to have it. Sigh.) Does that sound viable? Is there a better way? Looking at https://reproducible-builds.org/docs/source-date-epoch/ I don't see any. Detecting GNU date vs. BSD date seems overly complicated, and besides, there are probably other dates out there. I'd rather not even try to load POSIX strftime in Perl (as shown on that page in the Perl example) since it hardly seems necessary. mdate-sh already intentionally disables all localization, so at least that's not an issue. Or maybe keep mdate-sh unchanged, but patch the Automake rule for doc/stamp-vti to honor SOURCE_DATE_EPOCH over mdate-sh. Changing mdate-sh sounds preferable to me over changing Automake. E.g., in case any non-Automake-using package uses mdate-sh. Not sure if there are any such, but maybe. Also seems simpler. --thanks, karl. From unknown Sun Jun 15 08:52:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz Resent-From: Santiago Vila Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Mon, 21 Apr 2025 20:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77805 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Karl Berry , eblake@redhat.com Cc: 77805@debbugs.gnu.org, bug-m4@gnu.org Received: via spool by 77805-submit@debbugs.gnu.org id=B77805.174526896223958 (code B ref 77805); Mon, 21 Apr 2025 20:57:02 +0000 Received: (at 77805) by debbugs.gnu.org; 21 Apr 2025 20:56:02 +0000 Received: from localhost ([127.0.0.1]:39562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u6yBO-0006E7-4K for submit@debbugs.gnu.org; Mon, 21 Apr 2025 16:56:02 -0400 Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:55150) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u6yBK-0006Dc-Ut for 77805@debbugs.gnu.org; Mon, 21 Apr 2025 16:56:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:Content-Transfer-Encoding:Content-Type :In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID: Reply-To:Content-ID:Content-Description; bh=Z4/G6RdFE3VG7ZL8IPC2GKV7GPkb7w51/aExWNGWeUI=; b=U/f/kPeQvdLDuT4NTkSrbLJhor Nv0AKN016Nok4yPN7k8kYa6TaPtPtLWduZ/h/9ohir+Y+VPOBYJ++4/VP+XmDulxT8tmqw4mY5Ops hZpkX+tD8BQvqMZR5qO91gaA2uYe0D9xTSbSNPOFAHqgfpaAP3udBhEFm7XWqndn8/Els5W1M9ESy FIQZ5lHO2DzixdSYT66jbKYa+LF9/+tqJaYzk3nnUhlqslJ/toYPWPhz5WX2y6bgGxj/uW/zQZOfE z6EcLji8Kb2yLXdpoahGoFkdN+toTICr64zmj5FdxwtBNCvW88rq9g5DLFEjMDW/Q1R4Omqvl8oCf vv6LKHZQ==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim 4.94.2) (envelope-from ) id 1u6yBD-009B1E-PA; Mon, 21 Apr 2025 20:55:51 +0000 Message-ID: Date: Mon, 21 Apr 2025 22:55:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <202504212042.53LKgD6s252104@freefriends.org> Content-Language: en-US From: Santiago Vila In-Reply-To: <202504212042.53LKgD6s252104@freefriends.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Debian-User: sanvila X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) El 21/4/25 a las 22:42, Karl Berry escribió: > A patch to mdate-sh might take the form of checking (possibly only > when a command-line option is also specified) if $SOURCE_DATE_EPOCH > is set in the environment, and if so favoring that timestamp over > the mdate of its target file. > > That sounds doable. Thanks. I don't think an extra option is needed; if > SOURCE_DATE_EPOCH is set, I think it's usual for tools to use it without > further ado. Isn't it? > > Santiago, would doing this obviate Debian's desire to eliminate UPDATED? Yes. In such case the package would be reproducible and the reference date would be the one in the Debian changelog (i.e. the reference date for the Debian source package). (I was going to stop running autoreconf anyway, in which case, if you do nothing special, the package would probably be reproducible as well). Thanks. From unknown Sun Jun 15 08:52:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz References: Resent-From: Karl Berry Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Sun, 18 May 2025 22:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77805 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: 77805@debbugs.gnu.org, sanvila@debian.org Received: via spool by 77805-submit@debbugs.gnu.org id=B77805.174760711427609 (code B ref 77805); Sun, 18 May 2025 22:26:02 +0000 Received: (at 77805) by debbugs.gnu.org; 18 May 2025 22:25:14 +0000 Received: from localhost ([127.0.0.1]:33189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uGmRV-0007BF-RP for submit@debbugs.gnu.org; Sun, 18 May 2025 18:25:14 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:45564 helo=freefriends.org) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uGmRT-0007Ag-Q4 for 77805@debbugs.gnu.org; Sun, 18 May 2025 18:25:12 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 54IMPA9g2903550 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sun, 18 May 2025 16:25:10 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 54IMPAFj2903549; Sun, 18 May 2025 16:25:10 -0600 Date: Sun, 18 May 2025 16:25:10 -0600 Message-Id: <202505182225.54IMPAFj2903549@freefriends.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="zWS2irzada" Content-Transfer-Encoding: 7bit From: Karl Berry In-Reply-To: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --zWS2irzada Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Does anyone have a BSD system (any flavor) I could get access to? Alternatively, attached is my unreleased version of mdate-sh which tries to handle SOURCE_DATE_EPOCH. It seems to work ok with GNU date. I copied the BSD date command (date -u -r ...) from https://reproducible-builds.org/docs/source-date-epoch/ but have no way to test. E.g.: SOURCE_DATE_EPOCH=123456 ./mdate-sh /tmp should output 2 January 1970 I also don't know if there are other date commands that must be supported, or if it's worth falling back to Perl, or what. Suggestions, advice, testing? Here's the important part of the diff: --- a/lib/mdate-sh +++ b/lib/mdate-sh @@ -80,6 +83,38 @@ export LC_TIME TZ=UTC0 export TZ +# https://reproducible-builds.org/docs/source-date-epoch/ +if test -n "$SOURCE_DATE_EPOCH"; then + date_fmt="+%d %B %Y" + result=`date -u --date="@$SOURCE_DATE_EPOCH" "$date_fmt" 2>/dev/null` + if test -z "$result"; then + result=`date -u -r "$SOURCE_DATE_EPOCH" "$date_fmt" 2>/dev/null` + if test -z "$result"; then + # Another possibility would be to use + # perl -e 'print scalar gmtime($SOURCE_DATE_EPOCH)' + # and cut the fields out of the output, but seems plausible that + # Perl won't always be available. + echo "$0: SOURCE_DATE_EPOCH was set, but can't convert: $SOURCE_DATE_EPOCH" >&2 + exit 1 + fi + fi + # + # Remove leading spaces and zeros. We don't want to get into the + # various date options to control this. (Not quoting $result here + # isn't important, just another way to omit leading spaces.) + result=`echo $result | sed 's/^[ 0]*//'` + if test -z "$result"; then + echo "$0: SOURCE_DATE_EPOCH was set, but converted to empty: $SOURCE_DATE_EPOCH" >&2 + exit 1 + fi + # + # Hopefully ok. + echo $result + exit 0 +fi +# end of SOURCE_DATE_EPOCH support, rest is about the normal case of +# using the mtime of the specified file. + # GNU ls changes its time format in response to the TIME_STYLE # variable. Since we cannot assume 'unset' works, revert this # variable to its documented default. --zWS2irzada Content-Type: application/octet-stream Content-Disposition: attachment; filename="mdate-sh" Content-Transfer-Encoding: base64 IyEvYmluL3NoCiMgR2V0IG1vZGlmaWNhdGlvbiB0aW1lIG9mIGEgZmlsZSBvciBkaXJlY3Rv cnkgYW5kIHByZXR0eS1wcmludCBpdC4KCnNjcmlwdHZlcnNpb249MjAyNS0wNS0xOC4yMzsg IyBVVEMKCiMgQ29weXJpZ2h0IChDKSAxOTk1LTIwMjUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0 aW9uLCBJbmMuCiMgd3JpdHRlbiBieSBVbHJpY2ggRHJlcHBlciA8ZHJlcHBlckBnbnUuYWku bWl0LmVkdT4sIEp1bmUgMTk5NQojCiMgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7 IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKIyBpdCB1bmRlciB0aGUg dGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBi eQojIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIsIG9y IChhdCB5b3VyIG9wdGlvbikKIyBhbnkgbGF0ZXIgdmVyc2lvbi4KIwojIFRoaXMgcHJvZ3Jh bSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAoj IGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdh cnJhbnR5IG9mCiMgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxB UiBQVVJQT1NFLiAgU2VlIHRoZQojIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBt b3JlIGRldGFpbHMuCiMKIyBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBjb3B5IG9mIHRo ZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQojIGFsb25nIHdpdGggdGhpcyBwcm9ncmFt LiAgSWYgbm90LCBzZWUgPGh0dHBzOi8vd3d3LmdudS5vcmcvbGljZW5zZXMvPi4KCiMgQXMg YSBzcGVjaWFsIGV4Y2VwdGlvbiB0byB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2Us IGlmIHlvdQojIGRpc3RyaWJ1dGUgdGhpcyBmaWxlIGFzIHBhcnQgb2YgYSBwcm9ncmFtIHRo YXQgY29udGFpbnMgYQojIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVyYXRlZCBieSBBdXRv Y29uZiwgeW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCiMgdGhlIHNhbWUgZGlzdHJpYnV0aW9u IHRlcm1zIHRoYXQgeW91IHVzZSBmb3IgdGhlIHJlc3Qgb2YgdGhhdCBwcm9ncmFtLgoKIyBU aGlzIGZpbGUgaXMgbWFpbnRhaW5lZCBpbiBBdXRvbWFrZSwgcGxlYXNlIHJlcG9ydAojIGJ1 Z3MgdG8gPGJ1Zy1hdXRvbWFrZUBnbnUub3JnPiBvciBzZW5kIHBhdGNoZXMgdG8KIyA8YXV0 b21ha2UtcGF0Y2hlc0BnbnUub3JnPi4KCmlmIHRlc3QgLW4gIiR7WlNIX1ZFUlNJT04rc2V0 fSIgJiYgKGVtdWxhdGUgc2gpID4vZGV2L251bGwgMj4mMTsgdGhlbgogIGVtdWxhdGUgc2gK ICBOVUxMQ01EPToKICAjIFByZS00LjIgdmVyc2lvbnMgb2YgWnNoIGRvIHdvcmQgc3BsaXR0 aW5nIG9uICR7MSsiJEAifSwgd2hpY2gKICAjIGlzIGNvbnRyYXJ5IHRvIG91ciB1c2FnZS4g IERpc2FibGUgdGhpcyBmZWF0dXJlLgogIGFsaWFzIC1nICckezErIiRAIn0nPSciJEAiJwog IHNldG9wdCBOT19HTE9CX1NVQlNUCmZpCgpjYXNlICQxIGluCiAgJycpCiAgICAgZWNobyAi JDA6IE5vIGZpbGUuICBUcnkgJyQwIC0taGVscCcgZm9yIG1vcmUgaW5mb3JtYXRpb24uIiAx PiYyCiAgICAgZXhpdCAxOwogICAgIDs7CiAgLWggfCAtLWgqKQogICAgY2F0IDw8XEVPRgpV c2FnZTogbWRhdGUtc2ggWy0taGVscF0gWy0tdmVyc2lvbl0gRklMRQoKUHJldHR5LXByaW50 IHRoZSBtb2RpZmljYXRpb24gZGF5IG9mIEZJTEUsIGluIHRoZSBmb3JtYXQ6CjEgSmFudWFy eSAxOTcwCgpJZiB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGUgU09VUkNFX0RBVEVfRVBPQ0gg aXMgc2V0LCB1c2UgaXRzIHZhbHVlIChpbgplcG9jaC1zZWNvbmRzKSBmb3IgdGhlIGRhdGUg aW5zdGVhZCBvZiBhbnkgRklMRSBtdGltZS4gIFRoZSBGSUxFCmFyZ3VtZW50IGlzIHN0aWxs IHJlcXVpcmVkIGluIHRoaXMgY2FzZSwgYnV0IGlnbm9yZWQuCgpSZXBvcnQgYnVncyB0byA8 YnVnLWF1dG9tYWtlQGdudS5vcmc+LgpHTlUgQXV0b21ha2UgaG9tZSBwYWdlOiA8aHR0cHM6 Ly93d3cuZ251Lm9yZy9zb2Z0d2FyZS9hdXRvbWFrZS8+LgpHZW5lcmFsIGhlbHAgdXNpbmcg R05VIHNvZnR3YXJlOiA8aHR0cHM6Ly93d3cuZ251Lm9yZy9nZXRoZWxwLz4uCkVPRgogICAg ZXhpdCAkPwogICAgOzsKICAtdiB8IC0tdiopCiAgICBlY2hvICJtZGF0ZS1zaCAoR05VIEF1 dG9tYWtlKSAkc2NyaXB0dmVyc2lvbiIKICAgIGV4aXQgJD8KICAgIDs7CmVzYWMKCmVycm9y ICgpCnsKICBlY2hvICIkMDogJDEiID4mMgogIGV4aXQgMQp9CgojIFByZXZlbnQgZGF0ZSBn aXZpbmcgcmVzcG9uc2UgaW4gYW5vdGhlciBsYW5ndWFnZS4KTEFORz1DCmV4cG9ydCBMQU5H CkxDX0FMTD1DCmV4cG9ydCBMQ19BTEwKTENfVElNRT1DCmV4cG9ydCBMQ19USU1FCgojIFVz ZSBVVEMgdG8gZ2V0IHJlcHJvZHVjaWJsZSByZXN1bHQuClRaPVVUQzAKZXhwb3J0IFRaCgoj IGh0dHBzOi8vcmVwcm9kdWNpYmxlLWJ1aWxkcy5vcmcvZG9jcy9zb3VyY2UtZGF0ZS1lcG9j aC8KaWYgdGVzdCAtbiAiJFNPVVJDRV9EQVRFX0VQT0NIIjsgdGhlbgogIGRhdGVfZm10PSIr JWQgJUIgJVkiCiAgcmVzdWx0PWBkYXRlIC11IC0tZGF0ZT0iQCRTT1VSQ0VfREFURV9FUE9D SCIgIiRkYXRlX2ZtdCIgMj4vZGV2L251bGxgCiAgaWYgdGVzdCAteiAiJHJlc3VsdCI7IHRo ZW4KICAgIHJlc3VsdD1gZGF0ZSAtdSAtciAiJFNPVVJDRV9EQVRFX0VQT0NIIiAiJGRhdGVf Zm10IiAyPi9kZXYvbnVsbGAKICAgIGlmIHRlc3QgLXogIiRyZXN1bHQiOyB0aGVuCiAgICAg ICMgQW5vdGhlciBwb3NzaWJpbGl0eSB3b3VsZCBiZSB0byB1c2UKICAgICAgIyAgIHBlcmwg LWUgJ3ByaW50IHNjYWxhciBnbXRpbWUoJFNPVVJDRV9EQVRFX0VQT0NIKScKICAgICAgIyBh bmQgY3V0IHRoZSBmaWVsZHMgb3V0IG9mIHRoZSBvdXRwdXQsIGJ1dCBzZWVtcyBwbGF1c2li bGUgdGhhdAogICAgICAjIFBlcmwgd29uJ3QgYWx3YXlzIGJlIGF2YWlsYWJsZS4KICAgICAg ZWNobyAiJDA6IFNPVVJDRV9EQVRFX0VQT0NIIHdhcyBzZXQsIGJ1dCBjYW4ndCBjb252ZXJ0 OiAkU09VUkNFX0RBVEVfRVBPQ0giID4mMgogICAgICBleGl0IDEKICAgIGZpCiAgZmkKICAj CiAgIyBSZW1vdmUgbGVhZGluZyBzcGFjZXMgYW5kIHplcm9zLiBXZSBkb24ndCB3YW50IHRv IGdldCBpbnRvIHRoZQogICMgdmFyaW91cyBkYXRlIG9wdGlvbnMgdG8gY29udHJvbCB0aGlz LiAoTm90IHF1b3RpbmcgJHJlc3VsdCBoZXJlCiAgIyBpc24ndCBpbXBvcnRhbnQsIGp1c3Qg YW5vdGhlciB3YXkgdG8gb21pdCBsZWFkaW5nIHNwYWNlcy4pCiAgcmVzdWx0PWBlY2hvICRy ZXN1bHQgfCBzZWQgJ3MvXlsgMF0qLy8nYAogIGlmIHRlc3QgLXogIiRyZXN1bHQiOyB0aGVu CiAgICBlY2hvICIkMDogU09VUkNFX0RBVEVfRVBPQ0ggd2FzIHNldCwgYnV0IGNvbnZlcnRl ZCB0byBlbXB0eTogJFNPVVJDRV9EQVRFX0VQT0NIIiA+JjIKICAgIGV4aXQgMQogIGZpCiAg IwogICMgSG9wZWZ1bGx5IG9rLgogIGVjaG8gJHJlc3VsdAogIGV4aXQgMApmaQojIGVuZCBv ZiBTT1VSQ0VfREFURV9FUE9DSCBzdXBwb3J0LCByZXN0IGlzIGFib3V0IHRoZSBub3JtYWwg Y2FzZSBvZgojIHVzaW5nIHRoZSBtdGltZSBvZiB0aGUgc3BlY2lmaWVkIGZpbGUuCgojIEdO VSBscyBjaGFuZ2VzIGl0cyB0aW1lIGZvcm1hdCBpbiByZXNwb25zZSB0byB0aGUgVElNRV9T VFlMRQojIHZhcmlhYmxlLiAgU2luY2Ugd2UgY2Fubm90IGFzc3VtZSAndW5zZXQnIHdvcmtz LCByZXZlcnQgdGhpcwojIHZhcmlhYmxlIHRvIGl0cyBkb2N1bWVudGVkIGRlZmF1bHQuCmlm IHRlc3QgIiR7VElNRV9TVFlMRStzZXR9IiA9IHNldDsgdGhlbgogIFRJTUVfU1RZTEU9cG9z aXgtbG9uZy1pc28KICBleHBvcnQgVElNRV9TVFlMRQpmaQoKc2F2ZV9hcmcxPSQxCgojIEZp bmQgb3V0IGhvdyB0byBnZXQgdGhlIGV4dGVuZGVkIGxzIG91dHB1dCBvZiBhIGZpbGUgb3Ig ZGlyZWN0b3J5LgppZiBscyAtTCAvZGV2L251bGwgMT4vZGV2L251bGwgMj4mMTsgdGhlbgog IGxzX2NvbW1hbmQ9J2xzIC1MIC1sIC1kJwplbHNlCiAgbHNfY29tbWFuZD0nbHMgLWwgLWQn CmZpCiMgQXZvaWQgdXNlci9ncm91cCBuYW1lcyB0aGF0IG1pZ2h0IGhhdmUgc3BhY2VzLCB3 aGVuIHBvc3NpYmxlLgppZiBscyAtbiAvZGV2L251bGwgMT4vZGV2L251bGwgMj4mMTsgdGhl bgogIGxzX2NvbW1hbmQ9IiRsc19jb21tYW5kIC1uIgpmaQoKIyBBICdscyAtbCcgbGluZSBs b29rcyBhcyBmb2xsb3dzIG9uIE9TLzIuCiMgIGRyd3hyd3gtLS0gICAgICAgIDAgQXVnIDEx ICAyMDAxIGZvbwojIFRoaXMgZGlmZmVycyBmcm9tIFVuaXgsIHdoaWNoIGFkZHMgb3duZXJz aGlwIGluZm9ybWF0aW9uLgojICBkcnd4cnd4LS0tICAgMiByb290ICByb290ICAgICAgNDA5 NiBBdWcgMTEgIDIwMDEgZm9vCiMKIyBUbyBmaW5kIHRoZSBkYXRlLCB3ZSBzcGxpdCB0aGUg bGluZSBvbiBzcGFjZXMgYW5kIGl0ZXJhdGUgb24gd29yZHMKIyB1bnRpbCB3ZSBmaW5kIGEg bW9udGguICBUaGlzIGNhbm5vdCB3b3JrIHdpdGggZmlsZXMgd2hvc2Ugb3duZXIgaXMgYQoj IHVzZXIgbmFtZWQgIkphbiIsIG9yICJGZWIiLCBldGMuICBIb3dldmVyLCBpdCdzIHVubGlr ZWx5IHRoYXQgJy8nCiMgd2lsbCBiZSBvd25lZCBieSBhIHVzZXIgd2hvc2UgbmFtZSBpcyBh IG1vbnRoLiAgU28gd2UgZmlyc3QgbG9vayBhdAojIHRoZSBleHRlbmRlZCBscyBvdXRwdXQg b2YgdGhlIHJvb3QgZGlyZWN0b3J5IHRvIGRlY2lkZSBob3cgbWFueQojIHdvcmRzIHNob3Vs ZCBiZSBza2lwcGVkIHRvIGdldCB0aGUgZGF0ZS4KCiMgT24gSFBVWCAvYmluL3NoLCAic2V0 IiBpbnRlcnByZXRzICItcnctci0tci0tIiBhcyBvcHRpb25zLCBzbyB0aGUgIngiIGJlbG93 LgpzZXQgeGAkbHNfY29tbWFuZCAvYAoKIyBGaW5kIHdoaWNoIGFyZ3VtZW50IGlzIHRoZSBt b250aC4KbW9udGg9CmNvbW1hbmQ9CnVudGlsIHRlc3QgJG1vbnRoCmRvCiAgdGVzdCAkIyAt Z3QgMCB8fCBlcnJvciAiZmFpbGVkIHBhcnNpbmcgJyRsc19jb21tYW5kIC8nIG91dHB1dCIK ICBzaGlmdAogICMgQWRkIGFub3RoZXIgc2hpZnQgdG8gdGhlIGNvbW1hbmQuCiAgY29tbWFu ZD0iJGNvbW1hbmQgc2hpZnQ7IgogIGNhc2UgJDEgaW4KICAgIEphbikgbW9udGg9SmFudWFy eTsgbnVtbW9udGg9MTs7CiAgICBGZWIpIG1vbnRoPUZlYnJ1YXJ5OyBudW1tb250aD0yOzsK ICAgIE1hcikgbW9udGg9TWFyY2g7IG51bW1vbnRoPTM7OwogICAgQXByKSBtb250aD1BcHJp bDsgbnVtbW9udGg9NDs7CiAgICBNYXkpIG1vbnRoPU1heTsgbnVtbW9udGg9NTs7CiAgICBK dW4pIG1vbnRoPUp1bmU7IG51bW1vbnRoPTY7OwogICAgSnVsKSBtb250aD1KdWx5OyBudW1t b250aD03OzsKICAgIEF1ZykgbW9udGg9QXVndXN0OyBudW1tb250aD04OzsKICAgIFNlcCkg bW9udGg9U2VwdGVtYmVyOyBudW1tb250aD05OzsKICAgIE9jdCkgbW9udGg9T2N0b2Jlcjsg bnVtbW9udGg9MTA7OwogICAgTm92KSBtb250aD1Ob3ZlbWJlcjsgbnVtbW9udGg9MTE7Owog ICAgRGVjKSBtb250aD1EZWNlbWJlcjsgbnVtbW9udGg9MTI7OwogIGVzYWMKZG9uZQoKdGVz dCAtbiAiJG1vbnRoIiB8fCBlcnJvciAiZmFpbGVkIHBhcnNpbmcgJyRsc19jb21tYW5kIC8n IG91dHB1dCIKCiMgR2V0IHRoZSBleHRlbmRlZCBscyBvdXRwdXQgb2YgdGhlIGZpbGUgb3Ig ZGlyZWN0b3J5LgpzZXQgZHVtbXkgeGBldmFsICIkbHNfY29tbWFuZCBcIlxcXCRzYXZlX2Fy ZzFcIiJgCgojIFJlbW92ZSBhbGwgcHJlY2VkaW5nIGFyZ3VtZW50cwpldmFsICRjb21tYW5k CgojIEJlY2F1c2Ugb2YgdGhlIGR1bW15IGFyZ3VtZW50IGFib3ZlLCBtb250aCBpcyBpbiAk Mi4KIwojIE9uIGEgUE9TSVggc3lzdGVtLCB3ZSBzaG91bGQgaGF2ZQojCiMgJCMgPSA1CiMg JDEgPSBmaWxlIHNpemUKIyAkMiA9IG1vbnRoCiMgJDMgPSBkYXkKIyAkNCA9IHllYXIgb3Ig dGltZQojICQ1ID0gZmlsZW5hbWUKIwojIE9uIERhcndpbiA3LjcuMCBhbmQgNy42LjAsIHdl IGhhdmUKIwojICQjID0gNAojICQxID0gZGF5CiMgJDIgPSBtb250aAojICQzID0geWVhciBv ciB0aW1lCiMgJDQgPSBmaWxlbmFtZQoKIyBHZXQgdGhlIG1vbnRoLgpjYXNlICQyIGluCiAg SmFuKSBtb250aD1KYW51YXJ5OyBudW1tb250aD0xOzsKICBGZWIpIG1vbnRoPUZlYnJ1YXJ5 OyBudW1tb250aD0yOzsKICBNYXIpIG1vbnRoPU1hcmNoOyBudW1tb250aD0zOzsKICBBcHIp IG1vbnRoPUFwcmlsOyBudW1tb250aD00OzsKICBNYXkpIG1vbnRoPU1heTsgbnVtbW9udGg9 NTs7CiAgSnVuKSBtb250aD1KdW5lOyBudW1tb250aD02OzsKICBKdWwpIG1vbnRoPUp1bHk7 IG51bW1vbnRoPTc7OwogIEF1ZykgbW9udGg9QXVndXN0OyBudW1tb250aD04OzsKICBTZXAp IG1vbnRoPVNlcHRlbWJlcjsgbnVtbW9udGg9OTs7CiAgT2N0KSBtb250aD1PY3RvYmVyOyBu dW1tb250aD0xMDs7CiAgTm92KSBtb250aD1Ob3ZlbWJlcjsgbnVtbW9udGg9MTE7OwogIERl YykgbW9udGg9RGVjZW1iZXI7IG51bW1vbnRoPTEyOzsKZXNhYwoKY2FzZSAkMyBpbgogID8/ PyopIGRheT0kMTs7CiAgKikgZGF5PSQzOyBzaGlmdDs7CmVzYWMKCiMgSGVyZSB3ZSBoYXZl IHRvIGRlYWwgd2l0aCB0aGUgcHJvYmxlbSB0aGF0IHRoZSBscyBvdXRwdXQgZ2l2ZXMgZWl0 aGVyCiMgdGhlIHRpbWUgb2YgZGF5IG9yIHRoZSB5ZWFyLgpjYXNlICQzIGluCiAgKjoqKSBz ZXQgYGRhdGVgOyBldmFsIHllYXI9XCQkIwogICAgICAgY2FzZSAkMiBpbgoJIEphbikgbnVt bW9udGh0b2Q9MTs7CgkgRmViKSBudW1tb250aHRvZD0yOzsKCSBNYXIpIG51bW1vbnRodG9k PTM7OwoJIEFwcikgbnVtbW9udGh0b2Q9NDs7CgkgTWF5KSBudW1tb250aHRvZD01OzsKCSBK dW4pIG51bW1vbnRodG9kPTY7OwoJIEp1bCkgbnVtbW9udGh0b2Q9Nzs7CgkgQXVnKSBudW1t b250aHRvZD04OzsKCSBTZXApIG51bW1vbnRodG9kPTk7OwoJIE9jdCkgbnVtbW9udGh0b2Q9 MTA7OwoJIE5vdikgbnVtbW9udGh0b2Q9MTE7OwoJIERlYykgbnVtbW9udGh0b2Q9MTI7Owog ICAgICAgZXNhYwogICAgICAgIyBGb3IgdGhlIGZpcnN0IHNpeCBtb250aCBvZiB0aGUgeWVh ciB0aGUgdGltZSBub3RhdGlvbiBjYW4gYWxzbwogICAgICAgIyBiZSB1c2VkIGZvciBmaWxl cyBtb2RpZmllZCBpbiB0aGUgbGFzdCB5ZWFyLgogICAgICAgaWYgKGV4cHIgJG51bW1vbnRo IFw+ICRudW1tb250aHRvZCkgPiAvZGV2L251bGw7CiAgICAgICB0aGVuCgkgeWVhcj1gZXhw ciAkeWVhciAtIDFgCiAgICAgICBmaTs7CiAgKikgeWVhcj0kMzs7CmVzYWMKCiMgVGhlIHJl c3VsdC4KZWNobyAkZGF5ICRtb250aCAkeWVhcgoKIyBMb2NhbCBWYXJpYWJsZXM6CiMgbW9k ZTogc2hlbGwtc2NyaXB0CiMgc2gtaW5kZW50YXRpb246IDIKIyBldmFsOiAoYWRkLWhvb2sg J2JlZm9yZS1zYXZlLWhvb2sgJ3RpbWUtc3RhbXAgbmlsIHQpCiMgdGltZS1zdGFtcC1zdGFy dDogInNjcmlwdHZlcnNpb249IgojIHRpbWUtc3RhbXAtZm9ybWF0OiAiJTp5LSUwMm0tJTAy ZC4lMDJIIgojIHRpbWUtc3RhbXAtdGltZS16b25lOiAiVVRDMCIKIyB0aW1lLXN0YW1wLWVu ZDogIjsgIyBVVEMiCiMgRW5kOgo= --zWS2irzada-- From unknown Sun Jun 15 08:52:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz Resent-From: Collin Funk Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Sun, 18 May 2025 22:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77805 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Karl Berry Cc: sanvila@debian.org, 77805@debbugs.gnu.org Received: via spool by 77805-submit@debbugs.gnu.org id=B77805.1747608630808 (code B ref 77805); Sun, 18 May 2025 22:51:02 +0000 Received: (at 77805) by debbugs.gnu.org; 18 May 2025 22:50:30 +0000 Received: from localhost ([127.0.0.1]:33298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uGmpx-0000Cw-D1 for submit@debbugs.gnu.org; Sun, 18 May 2025 18:50:29 -0400 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]:52242) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uGmpt-0000CX-Qc for 77805@debbugs.gnu.org; Sun, 18 May 2025 18:50:26 -0400 Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-74068f95d9fso3353918b3a.0 for <77805@debbugs.gnu.org>; Sun, 18 May 2025 15:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747608619; x=1748213419; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=nzzWcqpxstZvGnwyxGH7VAA6un7lv9Qd8dCAew6a9ak=; b=XaC5ryMVFxcSO+gyTeYlx6y9YM7YGDhuOzbTMqqV3uoofsCN9bm09HrVtNLG8ePipq /CIX0qv304EdnJTN5tccAJMuKoCVBLub6c8MeKRv+5uctUqilX9cKgGK2lTpfveeiyOw VlBux0hPlSXleHFJIQcdp30EZOHBvSDR2/0DUlvZguAxRIq18dn1Z+jR/uePxXGcVp8E 8MHHs8nhbcx0+GH/8+t9ik8HraqZ239st4/dF97AeTgMuYX8IzxXAamP0YcwKnzVpgJk Ur2BDR9K/40Wnf8q7kiLC6EuR0wZgpJEV3EZT6esiBzYeP3tldwOOzCSYwhI4Zbt00e+ i1cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747608619; x=1748213419; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nzzWcqpxstZvGnwyxGH7VAA6un7lv9Qd8dCAew6a9ak=; b=nMRLyu7PWj0E8aKR0Cogx5v3g9PUrNHlg4ECruYVWItru7pNkyywhOx2U4F9N4pxKS Vgh7Lj4hx4UH+1Zsd5nguOAlJ8DgSYm1KU8pBcK1PpfsD3rjjsWzZA88NgouDDNdUbIq EOppjRRHagh18YO+gCPhU2KNw/tXe6rXIbhSEO0aOfO/eWiH+WF3n7udf8FcXqPLq7K4 Bjq8jnIwqGzyETE2q44NgcxwEbgkFa7Zjga54z5HmirxYbtUBcqTw0BPuGraqV6lCgD2 SLa8q8lxJ4XC3w/YIm7l/ZiwZ55tbxrpo9Tn67f2I2lP9wae/CTkKcK3EJW8LxAdhT45 iEaA== X-Gm-Message-State: AOJu0YzurH1nGaDp4PRuMpVgNzdWrz0ce9z6GGV7WhnmeLVykAcdcRMY 9ilZLXGa1vtbg2c03jEfj559wlWSH723Mn1JB35DXl8LT8mkvaMXcNxS X-Gm-Gg: ASbGncsjEXSxi2hG6BaBe1Jip7zxzUZdQ4zYtaBOj928hmHanbtBA1Rlunb0+5PUmez SOFv9MzxBUXbdLS7ViLE+Nas/LFFbtlCVoYTQTipya37KQOLN7SIuRnNcR18s5nk1cKlNHv+33p /isn/o7MacgzjoWxPzed4adRtr6iJzKQYE0SfmExbOf7Se4YcXTiLqBJC4XpQEvbJ4FrpEE1YCc dj3sibWzN3exAYuemqiVtafPYPNtwCpfx0akb5AwUeB5bEMquObayJCiC0ZR3LP6s0OSUg7dIXo pniZM81nyPUynpE1r6K5yfo6Y1moKeGiMOGABLcRGA== X-Google-Smtp-Source: AGHT+IEm+mJr0B1e8JvLDBR9etI4D+Npc2vg49mcs7kfTHuea7leSg6NeyKxR+Ny16A1mwatt3Y0UA== X-Received: by 2002:a05:6a21:3941:b0:1f5:a3e8:64dd with SMTP id adf61e73a8af0-216f85c6d15mr16396548637.0.1747608619465; Sun, 18 May 2025 15:50:19 -0700 (PDT) Received: from fedora ([2601:646:8081:3770::9eb]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b26eaf5a44csm4957213a12.12.2025.05.18.15.50.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 May 2025 15:50:19 -0700 (PDT) From: Collin Funk In-Reply-To: <202505182225.54IMPAFj2903549@freefriends.org> References: <202505182225.54IMPAFj2903549@freefriends.org> Date: Sun, 18 May 2025 15:50:18 -0700 Message-ID: <878qmty1n9.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hi Karl, Karl Berry writes: > Does anyone have a BSD system (any flavor) I could get access to? > > Alternatively, attached is my unreleased version of mdate-sh which tries > to handle SOURCE_DATE_EPOCH. It seems to work ok with GNU date. I copied > the BSD date command (date -u -r ...) from > https://reproducible-builds.org/docs/source-date-epoch/ but have no way > to test. E.g.: > SOURCE_DATE_EPOCH=123456 ./mdate-sh /tmp > should output > 2 January 1970 > > I also don't know if there are other date commands that must be > supported, or if it's worth falling back to Perl, or what. > > Suggestions, advice, testing? You can sign-up for the GCC Compile Farm and get access to many different BSD systems [1]. The list of platforms is here [2]. Usually I do that, or just create a virtual machine which works well for most things. I'll have a look at running your test in the meantime. Collin [1] https://portal.cfarm.net/users/new/ [2] https://portal.cfarm.net/machines/list/ From unknown Sun Jun 15 08:52:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz Resent-From: Collin Funk Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Sun, 18 May 2025 23:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77805 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Karl Berry Cc: sanvila@debian.org, 77805@debbugs.gnu.org Received: via spool by 77805-submit@debbugs.gnu.org id=B77805.17476097605014 (code B ref 77805); Sun, 18 May 2025 23:10:02 +0000 Received: (at 77805) by debbugs.gnu.org; 18 May 2025 23:09:20 +0000 Received: from localhost ([127.0.0.1]:33398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uGn8B-0001Il-Qp for submit@debbugs.gnu.org; Sun, 18 May 2025 19:09:20 -0400 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]:56546) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uGn88-0001IH-4q for 77805@debbugs.gnu.org; Sun, 18 May 2025 19:09:17 -0400 Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-231e331baceso21692875ad.0 for <77805@debbugs.gnu.org>; Sun, 18 May 2025 16:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747609750; x=1748214550; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=QGGZkZoiafwobk8I2wfCCwwpQywEfg4tNQYcYgBNY1E=; b=OopKZZQyqIeGL3205/I6zXlRvzF6HgRpp4s3z/fthioDmShfx0I5t6M20QFCfwOvPu eVhIHSTMy6iS54UKKmQNEgIBCLTrpEaEinXvUZdazL2M/n2lJ1tznwLoEs1q10GW8I/L SWWCjUNlbmcisj+XJitLThirYDHzdageWZczv5jDZinHdENl2W48GrwodapQ+YWW8cZD UIF8xFsLShNOgBHZE8cDWpnMJ08xlL7Nw2LsL+4KeIsJiIBmYL24wGyDQvDfzsxQLGwF azXZV8eJVn5hIiTgG73P8orjs+u2dcsJQKTtZk+cpZWkiDu0n/Q5SrU3xL1wRpzmOZSi WD2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747609750; x=1748214550; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QGGZkZoiafwobk8I2wfCCwwpQywEfg4tNQYcYgBNY1E=; b=pfWHg0qz/rwA0sx7ftsR11dj2T1ORYQjvBtIkVo6H7uqkikHM6CGJILuogD5wz/aRI U6043GMdedzBURvyOih2L+9PgKiDmJGA76sZHoIr9Ur+IL12IYtCDWoIqtz6SW3s5l/p 6z6AbgC6ZT8wHrOUTYxEJcc2KmU3r7760de3gRfXyNVsOj79Grv2b7/fmKA4ytWBo/VU GhLAPRRN3SvliQ8h/sSm6zDtqkWQR560zgg9hBJd3VewEH/cO4pSDIA6DtlwhW91zGN0 Yblav61VEvYkHpUCcUI71fbLUqT5WMzOOWlf6e5LhLkqUUoxxQKUHHDSPD/4x5E9RlhX BOHQ== X-Gm-Message-State: AOJu0YyqL7TeI2ZSKL0kXbHJS497MSbXC+SzpVeH03Jn06TJpE2nd+u8 X7q6i6txWUQXE+BK8WLMOU/uKDuvS3Wt7iyOckMfHpQQOiRYccodxvKW X-Gm-Gg: ASbGncuotu01/wTJerpDBCMwElqxfnfe9pA/onTLwXvVPKkhB0tseyW7auzxfYLm8Xl SzW8htPIGJ/GI+oj5doyNXzTKUySvPheulM1xkaYdAY4InMVCT1rJa/EP1zSzpKNveXt06xhkcK 6X4s0IxrUvQZJTmjNlYH6RE73SB0hrDk0Cz/BS7hT5x+I6F4Jxh8MtgHdvWwV3H0Z4slL+scWrD pIqAxhXzsGXeV+8eiin5X549t+IMB6ohHa6Y1t/Gb0h0M1qtJxWnMCb95YjqNlEgl9rYQf7kYYs SCxBGOpIVEPRM3wmFZEbBv4PVZ4hLWrsu25+LGhL4Q== X-Google-Smtp-Source: AGHT+IHNdxVjBnx81bjx6jdKDKvrlckMf2o8nLkRj6GhGZ2n4ffcV1k4MWbD3sOI3Wt+nnwF3xj9pw== X-Received: by 2002:a17:902:ce8f:b0:224:1001:6787 with SMTP id d9443c01a7336-231d43d56e3mr155436525ad.4.1747609749858; Sun, 18 May 2025 16:09:09 -0700 (PDT) Received: from fedora ([2601:646:8081:3770::9eb]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-231d4ac91b7sm48254015ad.19.2025.05.18.16.09.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 May 2025 16:09:09 -0700 (PDT) From: Collin Funk In-Reply-To: <878qmty1n9.fsf@gmail.com> References: <202505182225.54IMPAFj2903549@freefriends.org> <878qmty1n9.fsf@gmail.com> Date: Sun, 18 May 2025 16:09:08 -0700 Message-ID: <871psly0rv.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hi Karl, Collin Funk writes: >> Alternatively, attached is my unreleased version of mdate-sh which tries >> to handle SOURCE_DATE_EPOCH. It seems to work ok with GNU date. I copied >> the BSD date command (date -u -r ...) from >> https://reproducible-builds.org/docs/source-date-epoch/ but have no way >> to test. E.g.: >> SOURCE_DATE_EPOCH=123456 ./mdate-sh /tmp >> should output >> 2 January 1970 >> >> I also don't know if there are other date commands that must be >> supported, or if it's worth falling back to Perl, or what. >> >> Suggestions, advice, testing? > [...] > > I'll have a look at running your test in the meantime. I did some testing on the latest BSD releases and 2 older systems (MacOS 12 and Solaris 10). Here are the results: * OpenBSD 7.7, NetBSD 10.0, FreeBSD 15.0, MacOS 12.6: $ SOURCE_DATE_EPOCH=123456 ./mdate-sh /tmp 2 January 1970 * Solaris 10: $ SOURCE_DATE_EPOCH=123456 ./mdate-sh /tmp ./mdate-sh: SOURCE_DATE_EPOCH was set, but can't convert: 123456 The Solaris failure is because their date does not support the '--date' or '-r' option. I don't mind just ignorning that platform. We do for Gnulib since it has an old unsupported Python version. In DEPENDENCIES there: Note: Solaris 10 is no longer supported as maintainer environment. Collin From unknown Sun Jun 15 08:52:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz References: Resent-From: Karl Berry Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 20 May 2025 16:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77805 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: collin.funk1@gmail.com Cc: sanvila@debian.org, 77805@debbugs.gnu.org Received: via spool by 77805-submit@debbugs.gnu.org id=B77805.174775786620973 (code B ref 77805); Tue, 20 May 2025 16:18:02 +0000 Received: (at 77805) by debbugs.gnu.org; 20 May 2025 16:17:46 +0000 Received: from localhost ([127.0.0.1]:33664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uHPez-0005S9-Ph for submit@debbugs.gnu.org; Tue, 20 May 2025 12:17:46 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:33190 helo=freefriends.org) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uHPer-0005RK-Mm; Tue, 20 May 2025 12:17:41 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 54KGHawt3078830 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 20 May 2025 10:17:36 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 54KGHZTI3078829; Tue, 20 May 2025 10:17:35 -0600 Date: Tue, 20 May 2025 10:17:35 -0600 Message-Id: <202505201617.54KGHZTI3078829@freefriends.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="NAFOtzu6wf" Content-Transfer-Encoding: 7bit From: Karl Berry In-Reply-To: <871psly0rv.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --NAFOtzu6wf Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit The Solaris failure is because their date does not support the '--date' or '-r' option. As far as I can tell, the date command on Solaris 10 (cfarm210) and 11 (cfarm211) does not support any way to print a specified date value. So I inserted a fallback to perl -e 'print scalar gmtime($SOURCE_DATE_EPOCH)' if the date commands fail. If Perl isn't available either, mdate-sh gives a warning and falls back to using the mtime of the given file. I don't mind just ignorning that platform. Not supporting gnulib-tool is one thing, but a lot of people still build and use Solaris 10. We still get bug reports for Automake from people running it there. Might as well keep mdate-sh working there, since it was easy to do. Below is the important part of the patch, and the new file. I also threw in a warning if more than one file is specified on the command line, instead of silently ignoring anything after the first. Hopefully no one's build actually passes multiple files. Anyway ... closing this bug, with fingers crossed. This was the last change I intended to make before the release. Just have to finalize the Algol 68 naming. --thanks, karl. --- a/lib/mdate-sh +++ b/lib/mdate-sh @@ -61,12 +66,35 @@ EOF ;; esac +# Warn if more than one file given. +if test $# -ne 1; then + echo "$0: warning: multiple files given, using first: $*" >&2 +fi + error () { echo "$0: $1" >&2 exit 1 } +# set $month ("January") and $nummonth (1) given arg MON ("Jan"). +mon_to_month () +{ + case $1 in + Jan) month=January; nummonth=1;; + Feb) month=February; nummonth=2;; + Mar) month=March; nummonth=3;; + Apr) month=April; nummonth=4;; + May) month=May; nummonth=5;; + Jun) month=June; nummonth=6;; + Jul) month=July; nummonth=7;; + Aug) month=August; nummonth=8;; + Sep) month=September; nummonth=9;; + Oct) month=October; nummonth=10;; + Nov) month=November; nummonth=11;; + Dec) month=December; nummonth=12;; + esac +} # Prevent date giving response in another language. LANG=C @@ -80,6 +108,56 @@ export LC_TIME TZ=UTC0 export TZ +# +# https://reproducible-builds.org/docs/source-date-epoch/ +if test -n "$SOURCE_DATE_EPOCH"; then + epoch_ok=true # be optimistic + date_fmt="+%d %B %Y" + result=`date -u --date="@$SOURCE_DATE_EPOCH" "$date_fmt" 2>/dev/null` + if test -z "$result"; then + result=`date -u -r "$SOURCE_DATE_EPOCH" "$date_fmt" 2>/dev/null` + if test -z "$result"; then + # The date command on Solaris 10 and 11 doesn't support any way + # to do this. Fall back to Perl. + # + perlout=`perl -e 'print scalar gmtime($SOURCE_DATE_EPOCH)' 2>/dev/null` + # Output is, e.g., Thu Jan 1 00:00:00 1970. Split it apart, + # since we need to convert "Jan" to "January". + # (We could use cut, but surely if a system has perl, it has awk?) + day=`echo $perlout | awk '{print $3}'` + mon=`echo $perlout | awk '{print $2}'` + mon_to_month $mon # sets $month + year=`echo $perlout | awk '{print $5}'` + result="$day $month $year" + # + if test -z "$result"; then + echo "$0: warning: SOURCE_DATE_EPOCH was set, but can't convert, ignoring: $SOURCE_DATE_EPOCH" >&2 + epoch_ok=false + fi + fi + fi + # + if $epoch_ok; then + # Remove leading spaces and zeros. We don't want to get into the + # various date options to control this. (Not quoting $result here + # isn't important, just another way to omit leading spaces.) + result=`echo $result | sed 's/^[ 0]*//'` + if test -z "$result"; then + echo "$0: SOURCE_DATE_EPOCH was set, but converted to empty: $SOURCE_DATE_EPOCH" >&2 + epoch_ok=false + fi + fi + if $epoch_ok; then + echo $result + exit 0 + else + echo "$0: SOURCE_DATE_EPOCH failed, falling back to using mtime on: $1" >&2 + fi +fi +# end of SOURCE_DATE_EPOCH support, rest is about the normal case of +# using the mtime of the specified file. + +# # GNU ls changes its time format in response to the TIME_STYLE # variable. Since we cannot assume 'unset' works, revert this # variable to its documented default. --NAFOtzu6wf Content-Type: application/octet-stream Content-Disposition: attachment; filename="mdate-sh" Content-Transfer-Encoding: base64 IyEvYmluL3NoCiMgR2V0IG1vZGlmaWNhdGlvbiB0aW1lIG9mIGEgZmlsZSBvciBkaXJlY3Rv cnksIG9yIHZhbHVlIG9mCiMgJFNPVVJDRV9EQVRFX0VQT0NILCBhbmQgcHJldHR5LXByaW50 IGl0LCBmb3JtYXR0ZWQgbGlrZSAxIEphbnVhcnkgMjAwMC4KCnNjcmlwdHZlcnNpb249MjAy NS0wNS0yMS4wMTsgIyBVVEMKCiMgQ29weXJpZ2h0IChDKSAxOTk1LTIwMjUgRnJlZSBTb2Z0 d2FyZSBGb3VuZGF0aW9uLCBJbmMuCiMgd3JpdHRlbiBieSBVbHJpY2ggRHJlcHBlciA8ZHJl cHBlckBnbnUuYWkubWl0LmVkdT4sIEp1bmUgMTk5NQojCiMgVGhpcyBwcm9ncmFtIGlzIGZy ZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKIyBp dCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFz IHB1Ymxpc2hlZCBieQojIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2 ZXJzaW9uIDIsIG9yIChhdCB5b3VyIG9wdGlvbikKIyBhbnkgbGF0ZXIgdmVyc2lvbi4KIwoj IFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwg YmUgdXNlZnVsLAojIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRo ZSBpbXBsaWVkIHdhcnJhbnR5IG9mCiMgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9S IEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQojIEdOVSBHZW5lcmFsIFB1YmxpYyBM aWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCiMKIyBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQg YSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQojIGFsb25nIHdpdGgg dGhpcyBwcm9ncmFtLiAgSWYgbm90LCBzZWUgPGh0dHBzOi8vd3d3LmdudS5vcmcvbGljZW5z ZXMvPi4KCiMgQXMgYSBzcGVjaWFsIGV4Y2VwdGlvbiB0byB0aGUgR05VIEdlbmVyYWwgUHVi bGljIExpY2Vuc2UsIGlmIHlvdQojIGRpc3RyaWJ1dGUgdGhpcyBmaWxlIGFzIHBhcnQgb2Yg YSBwcm9ncmFtIHRoYXQgY29udGFpbnMgYQojIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVy YXRlZCBieSBBdXRvY29uZiwgeW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCiMgdGhlIHNhbWUg ZGlzdHJpYnV0aW9uIHRlcm1zIHRoYXQgeW91IHVzZSBmb3IgdGhlIHJlc3Qgb2YgdGhhdCBw cm9ncmFtLgoKIyBUaGlzIGZpbGUgaXMgbWFpbnRhaW5lZCBpbiBBdXRvbWFrZSwgcGxlYXNl IHJlcG9ydAojIGJ1Z3MgdG8gPGJ1Zy1hdXRvbWFrZUBnbnUub3JnPiBvciBzZW5kIHBhdGNo ZXMgdG8KIyA8YXV0b21ha2UtcGF0Y2hlc0BnbnUub3JnPi4KCmlmIHRlc3QgLW4gIiR7WlNI X1ZFUlNJT04rc2V0fSIgJiYgKGVtdWxhdGUgc2gpID4vZGV2L251bGwgMj4mMTsgdGhlbgog IGVtdWxhdGUgc2gKICBOVUxMQ01EPToKICAjIFByZS00LjIgdmVyc2lvbnMgb2YgWnNoIGRv IHdvcmQgc3BsaXR0aW5nIG9uICR7MSsiJEAifSwgd2hpY2gKICAjIGlzIGNvbnRyYXJ5IHRv IG91ciB1c2FnZS4gIERpc2FibGUgdGhpcyBmZWF0dXJlLgogIGFsaWFzIC1nICckezErIiRA In0nPSciJEAiJwogIHNldG9wdCBOT19HTE9CX1NVQlNUCmZpCgpjYXNlICQxIGluCiAgJycp CiAgICAgZWNobyAiJDA6IE5vIGZpbGUuICBUcnkgJyQwIC0taGVscCcgZm9yIG1vcmUgaW5m b3JtYXRpb24uIiAxPiYyCiAgICAgZXhpdCAxOwogICAgIDs7CiAgLWggfCAtLWgqKQogICAg Y2F0IDw8XEVPRgpVc2FnZTogbWRhdGUtc2ggWy0taGVscF0gWy0tdmVyc2lvbl0gRklMRQoK UHJldHR5LXByaW50IHRoZSBtb2RpZmljYXRpb24gZGF5IG9mIEZJTEUsIGluIHRoZSBmb3Jt YXQ6CjEgSmFudWFyeSAxOTcwCgpJZiB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGUgU09VUkNF X0RBVEVfRVBPQ0ggaXMgc2V0LCB1c2UgaXRzIHZhbHVlIChpbgplcG9jaC1zZWNvbmRzKSBm b3IgdGhlIGRhdGUgaW5zdGVhZCBvZiBhbnkgRklMRSBtdGltZS4gIFRoZSBGSUxFCmFyZ3Vt ZW50IGlzIHN0aWxsIHJlcXVpcmVkIGluIHRoaXMgY2FzZSwgYnV0IGlnbm9yZWQuCgpSZXBv cnQgYnVncyB0byA8YnVnLWF1dG9tYWtlQGdudS5vcmc+LgpHTlUgQXV0b21ha2UgaG9tZSBw YWdlOiA8aHR0cHM6Ly93d3cuZ251Lm9yZy9zb2Z0d2FyZS9hdXRvbWFrZS8+LgpHZW5lcmFs IGhlbHAgdXNpbmcgR05VIHNvZnR3YXJlOiA8aHR0cHM6Ly93d3cuZ251Lm9yZy9nZXRoZWxw Lz4uCkVPRgogICAgZXhpdCAkPwogICAgOzsKICAtdiB8IC0tdiopCiAgICBlY2hvICJtZGF0 ZS1zaCAoR05VIEF1dG9tYWtlKSAkc2NyaXB0dmVyc2lvbiIKICAgIGV4aXQgJD8KICAgIDs7 CmVzYWMKCiMgV2FybiBpZiBtb3JlIHRoYW4gb25lIGZpbGUgZ2l2ZW4uCmlmIHRlc3QgJCMg LW5lIDE7IHRoZW4KICBlY2hvICIkMDogd2FybmluZzogbXVsdGlwbGUgZmlsZXMgZ2l2ZW4s IHVzaW5nIGZpcnN0OiAkKiIgPiYyCmZpCgplcnJvciAoKQp7CiAgZWNobyAiJDA6ICQxIiA+ JjIKICBleGl0IDEKfQoKIyBzZXQgJG1vbnRoICgiSmFudWFyeSIpIGFuZCAkbnVtbW9udGgg KDEpIGdpdmVuIGFyZyBNT04gKCJKYW4iKS4KbW9uX3RvX21vbnRoICgpCnsKICBjYXNlICQx IGluCiAgICBKYW4pIG1vbnRoPUphbnVhcnk7IG51bW1vbnRoPTE7OwogICAgRmViKSBtb250 aD1GZWJydWFyeTsgbnVtbW9udGg9Mjs7CiAgICBNYXIpIG1vbnRoPU1hcmNoOyBudW1tb250 aD0zOzsKICAgIEFwcikgbW9udGg9QXByaWw7IG51bW1vbnRoPTQ7OwogICAgTWF5KSBtb250 aD1NYXk7IG51bW1vbnRoPTU7OwogICAgSnVuKSBtb250aD1KdW5lOyBudW1tb250aD02OzsK ICAgIEp1bCkgbW9udGg9SnVseTsgbnVtbW9udGg9Nzs7CiAgICBBdWcpIG1vbnRoPUF1Z3Vz dDsgbnVtbW9udGg9ODs7CiAgICBTZXApIG1vbnRoPVNlcHRlbWJlcjsgbnVtbW9udGg9OTs7 CiAgICBPY3QpIG1vbnRoPU9jdG9iZXI7IG51bW1vbnRoPTEwOzsKICAgIE5vdikgbW9udGg9 Tm92ZW1iZXI7IG51bW1vbnRoPTExOzsKICAgIERlYykgbW9udGg9RGVjZW1iZXI7IG51bW1v bnRoPTEyOzsKICBlc2FjCn0KCiMgUHJldmVudCBkYXRlIGdpdmluZyByZXNwb25zZSBpbiBh bm90aGVyIGxhbmd1YWdlLgpMQU5HPUMKZXhwb3J0IExBTkcKTENfQUxMPUMKZXhwb3J0IExD X0FMTApMQ19USU1FPUMKZXhwb3J0IExDX1RJTUUKCiMgVXNlIFVUQyB0byBnZXQgcmVwcm9k dWNpYmxlIHJlc3VsdC4KVFo9VVRDMApleHBvcnQgVFoKCiMgDAojIGh0dHBzOi8vcmVwcm9k dWNpYmxlLWJ1aWxkcy5vcmcvZG9jcy9zb3VyY2UtZGF0ZS1lcG9jaC8KaWYgdGVzdCAtbiAi JFNPVVJDRV9EQVRFX0VQT0NIIjsgdGhlbgogIGVwb2NoX29rPXRydWUgIyBiZSBvcHRpbWlz dGljCiAgZGF0ZV9mbXQ9IislZCAlQiAlWSIKICByZXN1bHQ9YGRhdGUgLXUgLS1kYXRlPSJA JFNPVVJDRV9EQVRFX0VQT0NIIiAiJGRhdGVfZm10IiAyPi9kZXYvbnVsbGAKICBpZiB0ZXN0 IC16ICIkcmVzdWx0IjsgdGhlbgogICAgcmVzdWx0PWBkYXRlIC11IC1yICIkU09VUkNFX0RB VEVfRVBPQ0giICIkZGF0ZV9mbXQiIDI+L2Rldi9udWxsYAogICAgaWYgdGVzdCAteiAiJHJl c3VsdCI7IHRoZW4KICAgICAgIyBUaGUgZGF0ZSBjb21tYW5kIG9uIFNvbGFyaXMgMTAgYW5k IDExIGRvZXNuJ3Qgc3VwcG9ydCBhbnkgd2F5CiAgICAgICMgdG8gZG8gdGhpcy4gRmFsbCBi YWNrIHRvIFBlcmwuCiAgICAgICMKICAgICAgcGVybG91dD1gcGVybCAtZSAncHJpbnQgc2Nh bGFyIGdtdGltZSgkU09VUkNFX0RBVEVfRVBPQ0gpJyAyPi9kZXYvbnVsbGAKICAgICAgIyBP dXRwdXQgaXMsIGUuZy4sIFRodSBKYW4gIDEgMDA6MDA6MDAgMTk3MC4gU3BsaXQgaXQgYXBh cnQsCiAgICAgICMgc2luY2Ugd2UgbmVlZCB0byBjb252ZXJ0ICJKYW4iIHRvICJKYW51YXJ5 Ii4KICAgICAgIyAoV2UgY291bGQgdXNlIGN1dCwgYnV0IHN1cmVseSBpZiBhIHN5c3RlbSBo YXMgcGVybCwgaXQgaGFzIGF3az8pCiAgICAgIGRheT1gZWNobyAkcGVybG91dCB8IGF3ayAn e3ByaW50ICQzfSdgCiAgICAgIG1vbj1gZWNobyAkcGVybG91dCB8IGF3ayAne3ByaW50ICQy fSdgCiAgICAgIG1vbl90b19tb250aCAkbW9uICMgc2V0cyAkbW9udGgKICAgICAgeWVhcj1g ZWNobyAkcGVybG91dCB8IGF3ayAne3ByaW50ICQ1fSdgCiAgICAgIHJlc3VsdD0iJGRheSAk bW9udGggJHllYXIiCiAgICAgICMKICAgICAgaWYgdGVzdCAteiAiJHJlc3VsdCI7IHRoZW4K ICAgICAgICBlY2hvICIkMDogd2FybmluZzogU09VUkNFX0RBVEVfRVBPQ0ggd2FzIHNldCwg YnV0IGNhbid0IGNvbnZlcnQsIGlnbm9yaW5nOiAkU09VUkNFX0RBVEVfRVBPQ0giID4mMgog ICAgICAgIGVwb2NoX29rPWZhbHNlCiAgICAgIGZpCiAgICBmaQogIGZpCiAgIwogIGlmICRl cG9jaF9vazsgdGhlbgogICAgIyBSZW1vdmUgbGVhZGluZyBzcGFjZXMgYW5kIHplcm9zLiBX ZSBkb24ndCB3YW50IHRvIGdldCBpbnRvIHRoZQogICAgIyB2YXJpb3VzIGRhdGUgb3B0aW9u cyB0byBjb250cm9sIHRoaXMuIChOb3QgcXVvdGluZyAkcmVzdWx0IGhlcmUKICAgICMgaXNu J3QgaW1wb3J0YW50LCBqdXN0IGFub3RoZXIgd2F5IHRvIG9taXQgbGVhZGluZyBzcGFjZXMu KQogICAgcmVzdWx0PWBlY2hvICRyZXN1bHQgfCBzZWQgJ3MvXlsgMF0qLy8nYAogICAgaWYg dGVzdCAteiAiJHJlc3VsdCI7IHRoZW4KICAgICAgZWNobyAiJDA6IFNPVVJDRV9EQVRFX0VQ T0NIIHdhcyBzZXQsIGJ1dCBjb252ZXJ0ZWQgdG8gZW1wdHk6ICRTT1VSQ0VfREFURV9FUE9D SCIgPiYyCiAgICAgIGVwb2NoX29rPWZhbHNlCiAgICBmaQogIGZpCiAgaWYgJGVwb2NoX29r OyB0aGVuCiAgICBlY2hvICRyZXN1bHQKICAgIGV4aXQgMAogIGVsc2UKICAgIGVjaG8gIiQw OiBTT1VSQ0VfREFURV9FUE9DSCBmYWlsZWQsIGZhbGxpbmcgYmFjayB0byB1c2luZyBtdGlt ZSBvbjogJDEiID4mMgogIGZpCmZpCiMgZW5kIG9mIFNPVVJDRV9EQVRFX0VQT0NIIHN1cHBv cnQsIHJlc3QgaXMgYWJvdXQgdGhlIG5vcm1hbCBjYXNlIG9mCiMgdXNpbmcgdGhlIG10aW1l IG9mIHRoZSBzcGVjaWZpZWQgZmlsZS4KCiMgDAojIEdOVSBscyBjaGFuZ2VzIGl0cyB0aW1l IGZvcm1hdCBpbiByZXNwb25zZSB0byB0aGUgVElNRV9TVFlMRQojIHZhcmlhYmxlLiAgU2lu Y2Ugd2UgY2Fubm90IGFzc3VtZSAndW5zZXQnIHdvcmtzLCByZXZlcnQgdGhpcwojIHZhcmlh YmxlIHRvIGl0cyBkb2N1bWVudGVkIGRlZmF1bHQuCmlmIHRlc3QgIiR7VElNRV9TVFlMRStz ZXR9IiA9IHNldDsgdGhlbgogIFRJTUVfU1RZTEU9cG9zaXgtbG9uZy1pc28KICBleHBvcnQg VElNRV9TVFlMRQpmaQoKc2F2ZV9hcmcxPSQxCgojIEZpbmQgb3V0IGhvdyB0byBnZXQgdGhl IGV4dGVuZGVkIGxzIG91dHB1dCBvZiBhIGZpbGUgb3IgZGlyZWN0b3J5LgppZiBscyAtTCAv ZGV2L251bGwgMT4vZGV2L251bGwgMj4mMTsgdGhlbgogIGxzX2NvbW1hbmQ9J2xzIC1MIC1s IC1kJwplbHNlCiAgbHNfY29tbWFuZD0nbHMgLWwgLWQnCmZpCiMgQXZvaWQgdXNlci9ncm91 cCBuYW1lcyB0aGF0IG1pZ2h0IGhhdmUgc3BhY2VzLCB3aGVuIHBvc3NpYmxlLgppZiBscyAt biAvZGV2L251bGwgMT4vZGV2L251bGwgMj4mMTsgdGhlbgogIGxzX2NvbW1hbmQ9IiRsc19j b21tYW5kIC1uIgpmaQoKIyBBICdscyAtbCcgbGluZSBsb29rcyBhcyBmb2xsb3dzIG9uIE9T LzIuCiMgIGRyd3hyd3gtLS0gICAgICAgIDAgQXVnIDExICAyMDAxIGZvbwojIFRoaXMgZGlm ZmVycyBmcm9tIFVuaXgsIHdoaWNoIGFkZHMgb3duZXJzaGlwIGluZm9ybWF0aW9uLgojICBk cnd4cnd4LS0tICAgMiByb290ICByb290ICAgICAgNDA5NiBBdWcgMTEgIDIwMDEgZm9vCiMK IyBUbyBmaW5kIHRoZSBkYXRlLCB3ZSBzcGxpdCB0aGUgbGluZSBvbiBzcGFjZXMgYW5kIGl0 ZXJhdGUgb24gd29yZHMKIyB1bnRpbCB3ZSBmaW5kIGEgbW9udGguICBUaGlzIGNhbm5vdCB3 b3JrIHdpdGggZmlsZXMgd2hvc2Ugb3duZXIgaXMgYQojIHVzZXIgbmFtZWQgIkphbiIsIG9y ICJGZWIiLCBldGMuICBIb3dldmVyLCBpdCdzIHVubGlrZWx5IHRoYXQgJy8nCiMgd2lsbCBi ZSBvd25lZCBieSBhIHVzZXIgd2hvc2UgbmFtZSBpcyBhIG1vbnRoLiAgU28gd2UgZmlyc3Qg bG9vayBhdAojIHRoZSBleHRlbmRlZCBscyBvdXRwdXQgb2YgdGhlIHJvb3QgZGlyZWN0b3J5 IHRvIGRlY2lkZSBob3cgbWFueQojIHdvcmRzIHNob3VsZCBiZSBza2lwcGVkIHRvIGdldCB0 aGUgZGF0ZS4KCiMgT24gSFBVWCAvYmluL3NoLCAic2V0IiBpbnRlcnByZXRzICItcnctci0t ci0tIiBhcyBvcHRpb25zLCBzbyB0aGUgIngiIGJlbG93LgpzZXQgeGAkbHNfY29tbWFuZCAv YAoKIyBGaW5kIHdoaWNoIGFyZ3VtZW50IGlzIHRoZSBtb250aC4KbW9udGg9CmNvbW1hbmQ9 CnVudGlsIHRlc3QgJG1vbnRoCmRvCiAgdGVzdCAkIyAtZ3QgMCB8fCBlcnJvciAiZmFpbGVk IHBhcnNpbmcgJyRsc19jb21tYW5kIC8nIG91dHB1dCIKICBzaGlmdAogICMgQWRkIGFub3Ro ZXIgc2hpZnQgdG8gdGhlIGNvbW1hbmQuCiAgY29tbWFuZD0iJGNvbW1hbmQgc2hpZnQ7Igog IG1vbl90b19tb250aCAkMQpkb25lCgp0ZXN0IC1uICIkbW9udGgiIHx8IGVycm9yICJmYWls ZWQgcGFyc2luZyAnJGxzX2NvbW1hbmQgLycgb3V0cHV0IgoKIyBHZXQgdGhlIGV4dGVuZGVk IGxzIG91dHB1dCBvZiB0aGUgZmlsZSBvciBkaXJlY3RvcnkuCnNldCBkdW1teSB4YGV2YWwg IiRsc19jb21tYW5kIFwiXFxcJHNhdmVfYXJnMVwiImAKCiMgUmVtb3ZlIGFsbCBwcmVjZWRp bmcgYXJndW1lbnRzCmV2YWwgJGNvbW1hbmQKCiMgQmVjYXVzZSBvZiB0aGUgZHVtbXkgYXJn dW1lbnQgYWJvdmUsIG1vbnRoIGlzIGluICQyLgojCiMgT24gYSBQT1NJWCBzeXN0ZW0sIHdl IHNob3VsZCBoYXZlCiMgJCMgPSA1CiMgJDEgPSBmaWxlIHNpemUKIyAkMiA9IG1vbnRoCiMg JDMgPSBkYXkKIyAkNCA9IHllYXIgb3IgdGltZQojICQ1ID0gZmlsZW5hbWUKIwojIE9uIERh cndpbiA3LjcuMCBhbmQgNy42LjAsIHdlIGhhdmUKIyAkIyA9IDQKIyAkMSA9IGRheQojICQy ID0gbW9udGgKIyAkMyA9IHllYXIgb3IgdGltZQojICQ0ID0gZmlsZW5hbWUKCiMgR2V0IHRo ZSBtb250aC4KbW9uX3RvX21vbnRoICQyCgpjYXNlICQzIGluCiAgPz8/KikgZGF5PSQxOzsK ICAqKSBkYXk9JDM7IHNoaWZ0OzsKZXNhYwoKIyBIZXJlIHdlIGhhdmUgdG8gZGVhbCB3aXRo IHRoZSBwcm9ibGVtIHRoYXQgdGhlIGxzIG91dHB1dCBnaXZlcyBlaXRoZXIKIyB0aGUgdGlt ZSBvZiBkYXkgb3IgdGhlIHllYXIuCmNhc2UgJDMgaW4KICAqOiopIHNldCBgZGF0ZWA7IGV2 YWwgeWVhcj1cJCQjCiAgICAgICBjYXNlICQyIGluCgkgSmFuKSBudW1tb250aHRvZD0xOzsK CSBGZWIpIG51bW1vbnRodG9kPTI7OwoJIE1hcikgbnVtbW9udGh0b2Q9Mzs7CgkgQXByKSBu dW1tb250aHRvZD00OzsKCSBNYXkpIG51bW1vbnRodG9kPTU7OwoJIEp1bikgbnVtbW9udGh0 b2Q9Njs7CgkgSnVsKSBudW1tb250aHRvZD03OzsKCSBBdWcpIG51bW1vbnRodG9kPTg7OwoJ IFNlcCkgbnVtbW9udGh0b2Q9OTs7CgkgT2N0KSBudW1tb250aHRvZD0xMDs7CgkgTm92KSBu dW1tb250aHRvZD0xMTs7CgkgRGVjKSBudW1tb250aHRvZD0xMjs7CiAgICAgICBlc2FjCiAg ICAgICAjIEZvciB0aGUgZmlyc3Qgc2l4IG1vbnRocyBvZiB0aGUgeWVhciB0aGUgdGltZSBu b3RhdGlvbiBjYW4gYWxzbwogICAgICAgIyBiZSB1c2VkIGZvciBmaWxlcyBtb2RpZmllZCBp biB0aGUgbGFzdCB5ZWFyLgogICAgICAgaWYgKGV4cHIgJG51bW1vbnRoIFw+ICRudW1tb250 aHRvZCkgPi9kZXYvbnVsbDsKICAgICAgIHRoZW4KCSB5ZWFyPWBleHByICR5ZWFyIC0gMWAK ICAgICAgIGZpOzsKICAqKSB5ZWFyPSQzOzsKZXNhYwoKIyBUaGUgcmVzdWx0LgplY2hvICRk YXkgJG1vbnRoICR5ZWFyCgojIExvY2FsIFZhcmlhYmxlczoKIyBtb2RlOiBzaGVsbC1zY3Jp cHQKIyBzaC1pbmRlbnRhdGlvbjogMgojIGV2YWw6IChhZGQtaG9vayAnYmVmb3JlLXNhdmUt aG9vayAndGltZS1zdGFtcCBuaWwgdCkKIyB0aW1lLXN0YW1wLXN0YXJ0OiAic2NyaXB0dmVy c2lvbj0iCiMgdGltZS1zdGFtcC1mb3JtYXQ6ICIlOnktJTAybS0lMDJkLiUwMkgiCiMgdGlt ZS1zdGFtcC10aW1lLXpvbmU6ICJVVEMwIgojIHRpbWUtc3RhbXAtZW5kOiAiOyAjIFVUQyIK IyBFbmQ6Cg== --NAFOtzu6wf-- From unknown Sun Jun 15 08:52:54 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Eric Blake Subject: bug#77805: closed (Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz) Message-ID: References: <202505201617.54KGHZTI3078829@freefriends.org> X-Gnu-PR-Message: they-closed 77805 X-Gnu-PR-Package: automake Reply-To: 77805@debbugs.gnu.org Date: Tue, 20 May 2025 16:18:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1747757883-21108-1" This is a multi-part message in MIME format... ------------=_1747757883-21108-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz which was filed against the automake package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 77805@debbugs.gnu.org. --=20 77805: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D77805 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1747757883-21108-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 77805-done) by debbugs.gnu.org; 20 May 2025 16:17:45 +0000 Received: from localhost ([127.0.0.1]:33662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uHPez-0005S3-1k for submit@debbugs.gnu.org; Tue, 20 May 2025 12:17:45 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:33190 helo=freefriends.org) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uHPer-0005RK-Mm; Tue, 20 May 2025 12:17:41 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 54KGHawt3078830 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 20 May 2025 10:17:36 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 54KGHZTI3078829; Tue, 20 May 2025 10:17:35 -0600 Date: Tue, 20 May 2025 10:17:35 -0600 Message-Id: <202505201617.54KGHZTI3078829@freefriends.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="NAFOtzu6wf" Content-Transfer-Encoding: 7bit From: Karl Berry To: collin.funk1@gmail.com Subject: Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz In-Reply-To: <871psly0rv.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 77805-done Cc: sanvila@debian.org, 77805@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --NAFOtzu6wf Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit The Solaris failure is because their date does not support the '--date' or '-r' option. As far as I can tell, the date command on Solaris 10 (cfarm210) and 11 (cfarm211) does not support any way to print a specified date value. So I inserted a fallback to perl -e 'print scalar gmtime($SOURCE_DATE_EPOCH)' if the date commands fail. If Perl isn't available either, mdate-sh gives a warning and falls back to using the mtime of the given file. I don't mind just ignorning that platform. Not supporting gnulib-tool is one thing, but a lot of people still build and use Solaris 10. We still get bug reports for Automake from people running it there. Might as well keep mdate-sh working there, since it was easy to do. Below is the important part of the patch, and the new file. I also threw in a warning if more than one file is specified on the command line, instead of silently ignoring anything after the first. Hopefully no one's build actually passes multiple files. Anyway ... closing this bug, with fingers crossed. This was the last change I intended to make before the release. Just have to finalize the Algol 68 naming. --thanks, karl. --- a/lib/mdate-sh +++ b/lib/mdate-sh @@ -61,12 +66,35 @@ EOF ;; esac +# Warn if more than one file given. +if test $# -ne 1; then + echo "$0: warning: multiple files given, using first: $*" >&2 +fi + error () { echo "$0: $1" >&2 exit 1 } +# set $month ("January") and $nummonth (1) given arg MON ("Jan"). +mon_to_month () +{ + case $1 in + Jan) month=January; nummonth=1;; + Feb) month=February; nummonth=2;; + Mar) month=March; nummonth=3;; + Apr) month=April; nummonth=4;; + May) month=May; nummonth=5;; + Jun) month=June; nummonth=6;; + Jul) month=July; nummonth=7;; + Aug) month=August; nummonth=8;; + Sep) month=September; nummonth=9;; + Oct) month=October; nummonth=10;; + Nov) month=November; nummonth=11;; + Dec) month=December; nummonth=12;; + esac +} # Prevent date giving response in another language. LANG=C @@ -80,6 +108,56 @@ export LC_TIME TZ=UTC0 export TZ +# +# https://reproducible-builds.org/docs/source-date-epoch/ +if test -n "$SOURCE_DATE_EPOCH"; then + epoch_ok=true # be optimistic + date_fmt="+%d %B %Y" + result=`date -u --date="@$SOURCE_DATE_EPOCH" "$date_fmt" 2>/dev/null` + if test -z "$result"; then + result=`date -u -r "$SOURCE_DATE_EPOCH" "$date_fmt" 2>/dev/null` + if test -z "$result"; then + # The date command on Solaris 10 and 11 doesn't support any way + # to do this. Fall back to Perl. + # + perlout=`perl -e 'print scalar gmtime($SOURCE_DATE_EPOCH)' 2>/dev/null` + # Output is, e.g., Thu Jan 1 00:00:00 1970. Split it apart, + # since we need to convert "Jan" to "January". + # (We could use cut, but surely if a system has perl, it has awk?) + day=`echo $perlout | awk '{print $3}'` + mon=`echo $perlout | awk '{print $2}'` + mon_to_month $mon # sets $month + year=`echo $perlout | awk '{print $5}'` + result="$day $month $year" + # + if test -z "$result"; then + echo "$0: warning: SOURCE_DATE_EPOCH was set, but can't convert, ignoring: $SOURCE_DATE_EPOCH" >&2 + epoch_ok=false + fi + fi + fi + # + if $epoch_ok; then + # Remove leading spaces and zeros. We don't want to get into the + # various date options to control this. (Not quoting $result here + # isn't important, just another way to omit leading spaces.) + result=`echo $result | sed 's/^[ 0]*//'` + if test -z "$result"; then + echo "$0: SOURCE_DATE_EPOCH was set, but converted to empty: $SOURCE_DATE_EPOCH" >&2 + epoch_ok=false + fi + fi + if $epoch_ok; then + echo $result + exit 0 + else + echo "$0: SOURCE_DATE_EPOCH failed, falling back to using mtime on: $1" >&2 + fi +fi +# end of SOURCE_DATE_EPOCH support, rest is about the normal case of +# using the mtime of the specified file. + +# # GNU ls changes its time format in response to the TIME_STYLE # variable. Since we cannot assume 'unset' works, revert this # variable to its documented default. --NAFOtzu6wf Content-Type: application/octet-stream Content-Disposition: attachment; filename="mdate-sh" Content-Transfer-Encoding: base64 IyEvYmluL3NoCiMgR2V0IG1vZGlmaWNhdGlvbiB0aW1lIG9mIGEgZmlsZSBvciBkaXJlY3Rv cnksIG9yIHZhbHVlIG9mCiMgJFNPVVJDRV9EQVRFX0VQT0NILCBhbmQgcHJldHR5LXByaW50 IGl0LCBmb3JtYXR0ZWQgbGlrZSAxIEphbnVhcnkgMjAwMC4KCnNjcmlwdHZlcnNpb249MjAy NS0wNS0yMS4wMTsgIyBVVEMKCiMgQ29weXJpZ2h0IChDKSAxOTk1LTIwMjUgRnJlZSBTb2Z0 d2FyZSBGb3VuZGF0aW9uLCBJbmMuCiMgd3JpdHRlbiBieSBVbHJpY2ggRHJlcHBlciA8ZHJl cHBlckBnbnUuYWkubWl0LmVkdT4sIEp1bmUgMTk5NQojCiMgVGhpcyBwcm9ncmFtIGlzIGZy ZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKIyBp dCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFz IHB1Ymxpc2hlZCBieQojIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2 ZXJzaW9uIDIsIG9yIChhdCB5b3VyIG9wdGlvbikKIyBhbnkgbGF0ZXIgdmVyc2lvbi4KIwoj IFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwg YmUgdXNlZnVsLAojIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRo ZSBpbXBsaWVkIHdhcnJhbnR5IG9mCiMgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9S IEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQojIEdOVSBHZW5lcmFsIFB1YmxpYyBM aWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCiMKIyBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQg YSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQojIGFsb25nIHdpdGgg dGhpcyBwcm9ncmFtLiAgSWYgbm90LCBzZWUgPGh0dHBzOi8vd3d3LmdudS5vcmcvbGljZW5z ZXMvPi4KCiMgQXMgYSBzcGVjaWFsIGV4Y2VwdGlvbiB0byB0aGUgR05VIEdlbmVyYWwgUHVi bGljIExpY2Vuc2UsIGlmIHlvdQojIGRpc3RyaWJ1dGUgdGhpcyBmaWxlIGFzIHBhcnQgb2Yg YSBwcm9ncmFtIHRoYXQgY29udGFpbnMgYQojIGNvbmZpZ3VyYXRpb24gc2NyaXB0IGdlbmVy YXRlZCBieSBBdXRvY29uZiwgeW91IG1heSBpbmNsdWRlIGl0IHVuZGVyCiMgdGhlIHNhbWUg ZGlzdHJpYnV0aW9uIHRlcm1zIHRoYXQgeW91IHVzZSBmb3IgdGhlIHJlc3Qgb2YgdGhhdCBw cm9ncmFtLgoKIyBUaGlzIGZpbGUgaXMgbWFpbnRhaW5lZCBpbiBBdXRvbWFrZSwgcGxlYXNl IHJlcG9ydAojIGJ1Z3MgdG8gPGJ1Zy1hdXRvbWFrZUBnbnUub3JnPiBvciBzZW5kIHBhdGNo ZXMgdG8KIyA8YXV0b21ha2UtcGF0Y2hlc0BnbnUub3JnPi4KCmlmIHRlc3QgLW4gIiR7WlNI X1ZFUlNJT04rc2V0fSIgJiYgKGVtdWxhdGUgc2gpID4vZGV2L251bGwgMj4mMTsgdGhlbgog IGVtdWxhdGUgc2gKICBOVUxMQ01EPToKICAjIFByZS00LjIgdmVyc2lvbnMgb2YgWnNoIGRv IHdvcmQgc3BsaXR0aW5nIG9uICR7MSsiJEAifSwgd2hpY2gKICAjIGlzIGNvbnRyYXJ5IHRv IG91ciB1c2FnZS4gIERpc2FibGUgdGhpcyBmZWF0dXJlLgogIGFsaWFzIC1nICckezErIiRA In0nPSciJEAiJwogIHNldG9wdCBOT19HTE9CX1NVQlNUCmZpCgpjYXNlICQxIGluCiAgJycp CiAgICAgZWNobyAiJDA6IE5vIGZpbGUuICBUcnkgJyQwIC0taGVscCcgZm9yIG1vcmUgaW5m b3JtYXRpb24uIiAxPiYyCiAgICAgZXhpdCAxOwogICAgIDs7CiAgLWggfCAtLWgqKQogICAg Y2F0IDw8XEVPRgpVc2FnZTogbWRhdGUtc2ggWy0taGVscF0gWy0tdmVyc2lvbl0gRklMRQoK UHJldHR5LXByaW50IHRoZSBtb2RpZmljYXRpb24gZGF5IG9mIEZJTEUsIGluIHRoZSBmb3Jt YXQ6CjEgSmFudWFyeSAxOTcwCgpJZiB0aGUgZW52aXJvbm1lbnQgdmFyaWFibGUgU09VUkNF X0RBVEVfRVBPQ0ggaXMgc2V0LCB1c2UgaXRzIHZhbHVlIChpbgplcG9jaC1zZWNvbmRzKSBm b3IgdGhlIGRhdGUgaW5zdGVhZCBvZiBhbnkgRklMRSBtdGltZS4gIFRoZSBGSUxFCmFyZ3Vt ZW50IGlzIHN0aWxsIHJlcXVpcmVkIGluIHRoaXMgY2FzZSwgYnV0IGlnbm9yZWQuCgpSZXBv cnQgYnVncyB0byA8YnVnLWF1dG9tYWtlQGdudS5vcmc+LgpHTlUgQXV0b21ha2UgaG9tZSBw YWdlOiA8aHR0cHM6Ly93d3cuZ251Lm9yZy9zb2Z0d2FyZS9hdXRvbWFrZS8+LgpHZW5lcmFs IGhlbHAgdXNpbmcgR05VIHNvZnR3YXJlOiA8aHR0cHM6Ly93d3cuZ251Lm9yZy9nZXRoZWxw Lz4uCkVPRgogICAgZXhpdCAkPwogICAgOzsKICAtdiB8IC0tdiopCiAgICBlY2hvICJtZGF0 ZS1zaCAoR05VIEF1dG9tYWtlKSAkc2NyaXB0dmVyc2lvbiIKICAgIGV4aXQgJD8KICAgIDs7 CmVzYWMKCiMgV2FybiBpZiBtb3JlIHRoYW4gb25lIGZpbGUgZ2l2ZW4uCmlmIHRlc3QgJCMg LW5lIDE7IHRoZW4KICBlY2hvICIkMDogd2FybmluZzogbXVsdGlwbGUgZmlsZXMgZ2l2ZW4s IHVzaW5nIGZpcnN0OiAkKiIgPiYyCmZpCgplcnJvciAoKQp7CiAgZWNobyAiJDA6ICQxIiA+ JjIKICBleGl0IDEKfQoKIyBzZXQgJG1vbnRoICgiSmFudWFyeSIpIGFuZCAkbnVtbW9udGgg KDEpIGdpdmVuIGFyZyBNT04gKCJKYW4iKS4KbW9uX3RvX21vbnRoICgpCnsKICBjYXNlICQx IGluCiAgICBKYW4pIG1vbnRoPUphbnVhcnk7IG51bW1vbnRoPTE7OwogICAgRmViKSBtb250 aD1GZWJydWFyeTsgbnVtbW9udGg9Mjs7CiAgICBNYXIpIG1vbnRoPU1hcmNoOyBudW1tb250 aD0zOzsKICAgIEFwcikgbW9udGg9QXByaWw7IG51bW1vbnRoPTQ7OwogICAgTWF5KSBtb250 aD1NYXk7IG51bW1vbnRoPTU7OwogICAgSnVuKSBtb250aD1KdW5lOyBudW1tb250aD02OzsK ICAgIEp1bCkgbW9udGg9SnVseTsgbnVtbW9udGg9Nzs7CiAgICBBdWcpIG1vbnRoPUF1Z3Vz dDsgbnVtbW9udGg9ODs7CiAgICBTZXApIG1vbnRoPVNlcHRlbWJlcjsgbnVtbW9udGg9OTs7 CiAgICBPY3QpIG1vbnRoPU9jdG9iZXI7IG51bW1vbnRoPTEwOzsKICAgIE5vdikgbW9udGg9 Tm92ZW1iZXI7IG51bW1vbnRoPTExOzsKICAgIERlYykgbW9udGg9RGVjZW1iZXI7IG51bW1v bnRoPTEyOzsKICBlc2FjCn0KCiMgUHJldmVudCBkYXRlIGdpdmluZyByZXNwb25zZSBpbiBh bm90aGVyIGxhbmd1YWdlLgpMQU5HPUMKZXhwb3J0IExBTkcKTENfQUxMPUMKZXhwb3J0IExD X0FMTApMQ19USU1FPUMKZXhwb3J0IExDX1RJTUUKCiMgVXNlIFVUQyB0byBnZXQgcmVwcm9k dWNpYmxlIHJlc3VsdC4KVFo9VVRDMApleHBvcnQgVFoKCiMgDAojIGh0dHBzOi8vcmVwcm9k dWNpYmxlLWJ1aWxkcy5vcmcvZG9jcy9zb3VyY2UtZGF0ZS1lcG9jaC8KaWYgdGVzdCAtbiAi JFNPVVJDRV9EQVRFX0VQT0NIIjsgdGhlbgogIGVwb2NoX29rPXRydWUgIyBiZSBvcHRpbWlz dGljCiAgZGF0ZV9mbXQ9IislZCAlQiAlWSIKICByZXN1bHQ9YGRhdGUgLXUgLS1kYXRlPSJA JFNPVVJDRV9EQVRFX0VQT0NIIiAiJGRhdGVfZm10IiAyPi9kZXYvbnVsbGAKICBpZiB0ZXN0 IC16ICIkcmVzdWx0IjsgdGhlbgogICAgcmVzdWx0PWBkYXRlIC11IC1yICIkU09VUkNFX0RB VEVfRVBPQ0giICIkZGF0ZV9mbXQiIDI+L2Rldi9udWxsYAogICAgaWYgdGVzdCAteiAiJHJl c3VsdCI7IHRoZW4KICAgICAgIyBUaGUgZGF0ZSBjb21tYW5kIG9uIFNvbGFyaXMgMTAgYW5k IDExIGRvZXNuJ3Qgc3VwcG9ydCBhbnkgd2F5CiAgICAgICMgdG8gZG8gdGhpcy4gRmFsbCBi YWNrIHRvIFBlcmwuCiAgICAgICMKICAgICAgcGVybG91dD1gcGVybCAtZSAncHJpbnQgc2Nh bGFyIGdtdGltZSgkU09VUkNFX0RBVEVfRVBPQ0gpJyAyPi9kZXYvbnVsbGAKICAgICAgIyBP dXRwdXQgaXMsIGUuZy4sIFRodSBKYW4gIDEgMDA6MDA6MDAgMTk3MC4gU3BsaXQgaXQgYXBh cnQsCiAgICAgICMgc2luY2Ugd2UgbmVlZCB0byBjb252ZXJ0ICJKYW4iIHRvICJKYW51YXJ5 Ii4KICAgICAgIyAoV2UgY291bGQgdXNlIGN1dCwgYnV0IHN1cmVseSBpZiBhIHN5c3RlbSBo YXMgcGVybCwgaXQgaGFzIGF3az8pCiAgICAgIGRheT1gZWNobyAkcGVybG91dCB8IGF3ayAn e3ByaW50ICQzfSdgCiAgICAgIG1vbj1gZWNobyAkcGVybG91dCB8IGF3ayAne3ByaW50ICQy fSdgCiAgICAgIG1vbl90b19tb250aCAkbW9uICMgc2V0cyAkbW9udGgKICAgICAgeWVhcj1g ZWNobyAkcGVybG91dCB8IGF3ayAne3ByaW50ICQ1fSdgCiAgICAgIHJlc3VsdD0iJGRheSAk bW9udGggJHllYXIiCiAgICAgICMKICAgICAgaWYgdGVzdCAteiAiJHJlc3VsdCI7IHRoZW4K ICAgICAgICBlY2hvICIkMDogd2FybmluZzogU09VUkNFX0RBVEVfRVBPQ0ggd2FzIHNldCwg YnV0IGNhbid0IGNvbnZlcnQsIGlnbm9yaW5nOiAkU09VUkNFX0RBVEVfRVBPQ0giID4mMgog ICAgICAgIGVwb2NoX29rPWZhbHNlCiAgICAgIGZpCiAgICBmaQogIGZpCiAgIwogIGlmICRl cG9jaF9vazsgdGhlbgogICAgIyBSZW1vdmUgbGVhZGluZyBzcGFjZXMgYW5kIHplcm9zLiBX ZSBkb24ndCB3YW50IHRvIGdldCBpbnRvIHRoZQogICAgIyB2YXJpb3VzIGRhdGUgb3B0aW9u cyB0byBjb250cm9sIHRoaXMuIChOb3QgcXVvdGluZyAkcmVzdWx0IGhlcmUKICAgICMgaXNu J3QgaW1wb3J0YW50LCBqdXN0IGFub3RoZXIgd2F5IHRvIG9taXQgbGVhZGluZyBzcGFjZXMu KQogICAgcmVzdWx0PWBlY2hvICRyZXN1bHQgfCBzZWQgJ3MvXlsgMF0qLy8nYAogICAgaWYg dGVzdCAteiAiJHJlc3VsdCI7IHRoZW4KICAgICAgZWNobyAiJDA6IFNPVVJDRV9EQVRFX0VQ T0NIIHdhcyBzZXQsIGJ1dCBjb252ZXJ0ZWQgdG8gZW1wdHk6ICRTT1VSQ0VfREFURV9FUE9D SCIgPiYyCiAgICAgIGVwb2NoX29rPWZhbHNlCiAgICBmaQogIGZpCiAgaWYgJGVwb2NoX29r OyB0aGVuCiAgICBlY2hvICRyZXN1bHQKICAgIGV4aXQgMAogIGVsc2UKICAgIGVjaG8gIiQw OiBTT1VSQ0VfREFURV9FUE9DSCBmYWlsZWQsIGZhbGxpbmcgYmFjayB0byB1c2luZyBtdGlt ZSBvbjogJDEiID4mMgogIGZpCmZpCiMgZW5kIG9mIFNPVVJDRV9EQVRFX0VQT0NIIHN1cHBv cnQsIHJlc3QgaXMgYWJvdXQgdGhlIG5vcm1hbCBjYXNlIG9mCiMgdXNpbmcgdGhlIG10aW1l IG9mIHRoZSBzcGVjaWZpZWQgZmlsZS4KCiMgDAojIEdOVSBscyBjaGFuZ2VzIGl0cyB0aW1l IGZvcm1hdCBpbiByZXNwb25zZSB0byB0aGUgVElNRV9TVFlMRQojIHZhcmlhYmxlLiAgU2lu Y2Ugd2UgY2Fubm90IGFzc3VtZSAndW5zZXQnIHdvcmtzLCByZXZlcnQgdGhpcwojIHZhcmlh YmxlIHRvIGl0cyBkb2N1bWVudGVkIGRlZmF1bHQuCmlmIHRlc3QgIiR7VElNRV9TVFlMRStz ZXR9IiA9IHNldDsgdGhlbgogIFRJTUVfU1RZTEU9cG9zaXgtbG9uZy1pc28KICBleHBvcnQg VElNRV9TVFlMRQpmaQoKc2F2ZV9hcmcxPSQxCgojIEZpbmQgb3V0IGhvdyB0byBnZXQgdGhl IGV4dGVuZGVkIGxzIG91dHB1dCBvZiBhIGZpbGUgb3IgZGlyZWN0b3J5LgppZiBscyAtTCAv ZGV2L251bGwgMT4vZGV2L251bGwgMj4mMTsgdGhlbgogIGxzX2NvbW1hbmQ9J2xzIC1MIC1s IC1kJwplbHNlCiAgbHNfY29tbWFuZD0nbHMgLWwgLWQnCmZpCiMgQXZvaWQgdXNlci9ncm91 cCBuYW1lcyB0aGF0IG1pZ2h0IGhhdmUgc3BhY2VzLCB3aGVuIHBvc3NpYmxlLgppZiBscyAt biAvZGV2L251bGwgMT4vZGV2L251bGwgMj4mMTsgdGhlbgogIGxzX2NvbW1hbmQ9IiRsc19j b21tYW5kIC1uIgpmaQoKIyBBICdscyAtbCcgbGluZSBsb29rcyBhcyBmb2xsb3dzIG9uIE9T LzIuCiMgIGRyd3hyd3gtLS0gICAgICAgIDAgQXVnIDExICAyMDAxIGZvbwojIFRoaXMgZGlm ZmVycyBmcm9tIFVuaXgsIHdoaWNoIGFkZHMgb3duZXJzaGlwIGluZm9ybWF0aW9uLgojICBk cnd4cnd4LS0tICAgMiByb290ICByb290ICAgICAgNDA5NiBBdWcgMTEgIDIwMDEgZm9vCiMK IyBUbyBmaW5kIHRoZSBkYXRlLCB3ZSBzcGxpdCB0aGUgbGluZSBvbiBzcGFjZXMgYW5kIGl0 ZXJhdGUgb24gd29yZHMKIyB1bnRpbCB3ZSBmaW5kIGEgbW9udGguICBUaGlzIGNhbm5vdCB3 b3JrIHdpdGggZmlsZXMgd2hvc2Ugb3duZXIgaXMgYQojIHVzZXIgbmFtZWQgIkphbiIsIG9y ICJGZWIiLCBldGMuICBIb3dldmVyLCBpdCdzIHVubGlrZWx5IHRoYXQgJy8nCiMgd2lsbCBi ZSBvd25lZCBieSBhIHVzZXIgd2hvc2UgbmFtZSBpcyBhIG1vbnRoLiAgU28gd2UgZmlyc3Qg bG9vayBhdAojIHRoZSBleHRlbmRlZCBscyBvdXRwdXQgb2YgdGhlIHJvb3QgZGlyZWN0b3J5 IHRvIGRlY2lkZSBob3cgbWFueQojIHdvcmRzIHNob3VsZCBiZSBza2lwcGVkIHRvIGdldCB0 aGUgZGF0ZS4KCiMgT24gSFBVWCAvYmluL3NoLCAic2V0IiBpbnRlcnByZXRzICItcnctci0t ci0tIiBhcyBvcHRpb25zLCBzbyB0aGUgIngiIGJlbG93LgpzZXQgeGAkbHNfY29tbWFuZCAv YAoKIyBGaW5kIHdoaWNoIGFyZ3VtZW50IGlzIHRoZSBtb250aC4KbW9udGg9CmNvbW1hbmQ9 CnVudGlsIHRlc3QgJG1vbnRoCmRvCiAgdGVzdCAkIyAtZ3QgMCB8fCBlcnJvciAiZmFpbGVk IHBhcnNpbmcgJyRsc19jb21tYW5kIC8nIG91dHB1dCIKICBzaGlmdAogICMgQWRkIGFub3Ro ZXIgc2hpZnQgdG8gdGhlIGNvbW1hbmQuCiAgY29tbWFuZD0iJGNvbW1hbmQgc2hpZnQ7Igog IG1vbl90b19tb250aCAkMQpkb25lCgp0ZXN0IC1uICIkbW9udGgiIHx8IGVycm9yICJmYWls ZWQgcGFyc2luZyAnJGxzX2NvbW1hbmQgLycgb3V0cHV0IgoKIyBHZXQgdGhlIGV4dGVuZGVk IGxzIG91dHB1dCBvZiB0aGUgZmlsZSBvciBkaXJlY3RvcnkuCnNldCBkdW1teSB4YGV2YWwg IiRsc19jb21tYW5kIFwiXFxcJHNhdmVfYXJnMVwiImAKCiMgUmVtb3ZlIGFsbCBwcmVjZWRp bmcgYXJndW1lbnRzCmV2YWwgJGNvbW1hbmQKCiMgQmVjYXVzZSBvZiB0aGUgZHVtbXkgYXJn dW1lbnQgYWJvdmUsIG1vbnRoIGlzIGluICQyLgojCiMgT24gYSBQT1NJWCBzeXN0ZW0sIHdl IHNob3VsZCBoYXZlCiMgJCMgPSA1CiMgJDEgPSBmaWxlIHNpemUKIyAkMiA9IG1vbnRoCiMg JDMgPSBkYXkKIyAkNCA9IHllYXIgb3IgdGltZQojICQ1ID0gZmlsZW5hbWUKIwojIE9uIERh cndpbiA3LjcuMCBhbmQgNy42LjAsIHdlIGhhdmUKIyAkIyA9IDQKIyAkMSA9IGRheQojICQy ID0gbW9udGgKIyAkMyA9IHllYXIgb3IgdGltZQojICQ0ID0gZmlsZW5hbWUKCiMgR2V0IHRo ZSBtb250aC4KbW9uX3RvX21vbnRoICQyCgpjYXNlICQzIGluCiAgPz8/KikgZGF5PSQxOzsK ICAqKSBkYXk9JDM7IHNoaWZ0OzsKZXNhYwoKIyBIZXJlIHdlIGhhdmUgdG8gZGVhbCB3aXRo IHRoZSBwcm9ibGVtIHRoYXQgdGhlIGxzIG91dHB1dCBnaXZlcyBlaXRoZXIKIyB0aGUgdGlt ZSBvZiBkYXkgb3IgdGhlIHllYXIuCmNhc2UgJDMgaW4KICAqOiopIHNldCBgZGF0ZWA7IGV2 YWwgeWVhcj1cJCQjCiAgICAgICBjYXNlICQyIGluCgkgSmFuKSBudW1tb250aHRvZD0xOzsK CSBGZWIpIG51bW1vbnRodG9kPTI7OwoJIE1hcikgbnVtbW9udGh0b2Q9Mzs7CgkgQXByKSBu dW1tb250aHRvZD00OzsKCSBNYXkpIG51bW1vbnRodG9kPTU7OwoJIEp1bikgbnVtbW9udGh0 b2Q9Njs7CgkgSnVsKSBudW1tb250aHRvZD03OzsKCSBBdWcpIG51bW1vbnRodG9kPTg7OwoJ IFNlcCkgbnVtbW9udGh0b2Q9OTs7CgkgT2N0KSBudW1tb250aHRvZD0xMDs7CgkgTm92KSBu dW1tb250aHRvZD0xMTs7CgkgRGVjKSBudW1tb250aHRvZD0xMjs7CiAgICAgICBlc2FjCiAg ICAgICAjIEZvciB0aGUgZmlyc3Qgc2l4IG1vbnRocyBvZiB0aGUgeWVhciB0aGUgdGltZSBu b3RhdGlvbiBjYW4gYWxzbwogICAgICAgIyBiZSB1c2VkIGZvciBmaWxlcyBtb2RpZmllZCBp biB0aGUgbGFzdCB5ZWFyLgogICAgICAgaWYgKGV4cHIgJG51bW1vbnRoIFw+ICRudW1tb250 aHRvZCkgPi9kZXYvbnVsbDsKICAgICAgIHRoZW4KCSB5ZWFyPWBleHByICR5ZWFyIC0gMWAK ICAgICAgIGZpOzsKICAqKSB5ZWFyPSQzOzsKZXNhYwoKIyBUaGUgcmVzdWx0LgplY2hvICRk YXkgJG1vbnRoICR5ZWFyCgojIExvY2FsIFZhcmlhYmxlczoKIyBtb2RlOiBzaGVsbC1zY3Jp cHQKIyBzaC1pbmRlbnRhdGlvbjogMgojIGV2YWw6IChhZGQtaG9vayAnYmVmb3JlLXNhdmUt aG9vayAndGltZS1zdGFtcCBuaWwgdCkKIyB0aW1lLXN0YW1wLXN0YXJ0OiAic2NyaXB0dmVy c2lvbj0iCiMgdGltZS1zdGFtcC1mb3JtYXQ6ICIlOnktJTAybS0lMDJkLiUwMkgiCiMgdGlt ZS1zdGFtcC10aW1lLXpvbmU6ICJVVEMwIgojIHRpbWUtc3RhbXAtZW5kOiAiOyAjIFVUQyIK IyBFbmQ6Cg== --NAFOtzu6wf-- ------------=_1747757883-21108-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 14 Apr 2025 16:35:06 +0000 Received: from localhost ([127.0.0.1]:48667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u4Mm1-0005Yc-Pq for submit@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 ) id 1u4Mlx-0005W7-T3 for submit@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 ) id 1u4Mlq-00030C-C1 for bug-automake@gnu.org; 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 ) id 1u4Mll-00058h-FD for bug-automake@gnu.org; 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 To: Santiago Vila Subject: Re: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz Message-ID: References: <02d21883-fe76-4c3e-9cf2-4f834f5c4e50@debian.org> MIME-Version: 1.0 In-Reply-To: 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@redhat.com; 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@gnu.org, bug-m4@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 ------------=_1747757883-21108-1-- From unknown Sun Jun 15 08:52:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz Resent-From: Collin Funk Original-Sender: "Debbugs-submit" Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 20 May 2025 21:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77805 X-GNU-PR-Package: automake X-GNU-PR-Keywords: To: Karl Berry Cc: sanvila@debian.org, 77805@debbugs.gnu.org Received: via spool by 77805-submit@debbugs.gnu.org id=B77805.174777769532076 (code B ref 77805); Tue, 20 May 2025 21:49:01 +0000 Received: (at 77805) by debbugs.gnu.org; 20 May 2025 21:48:15 +0000 Received: from localhost ([127.0.0.1]:37631 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uHUoo-0008LA-ML for submit@debbugs.gnu.org; Tue, 20 May 2025 17:48:15 -0400 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]:51328) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uHUom-0008KD-E7 for 77805@debbugs.gnu.org; Tue, 20 May 2025 17:48:12 -0400 Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-7370a2d1981so4824598b3a.2 for <77805@debbugs.gnu.org>; Tue, 20 May 2025 14:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747777686; x=1748382486; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=UYo8XsK0KbEOpjoxAaNFUUCI3H0R816ZfjIzhaPT7hI=; b=D38SNKfH5rADErUE//2cNr4nJkxTAlqgVA/Y5bydg+D3ucZOCKKhgoutQNeWDbzn5f o1cEfHp1NXI98pGKaFfZ4ZctIyNBk841nbqP5EmbzPtzIv0N7ldX5k0B9/koxrsnMo5S 3kZ8/U3/gixgkEHhxcmf4b9lwel8GTah8QnvtcI0uPpOQUU/+7cN8nzby10UNcm/gxgl Je+giIvqhBOywpJ4K5UuLLlm4FEbZWG5jMlnZ5Dm81VYhz8Sit2d9rkpagenAb3FrWzY qd+INYOLork/uhpgW8FAAaF3QMl53z5/qcrsKpUqYNimnY4ZztXWpWVlFL/wWJhjZU9u 6KcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747777686; x=1748382486; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UYo8XsK0KbEOpjoxAaNFUUCI3H0R816ZfjIzhaPT7hI=; b=H10+sOY5Roey0WhsM2LaYAZaVXax1b/VGWeQ2uiQQTT5fF7F35JMVeGgFdDwBYGrVe 9LMaQuY3rMJ2c/wkPW1wGgV/KL6bFRFczOKZUgDGsPIneVcIUBLWDXhaod5gig9E4XD/ O910E2yCl9S00D2NsJ7kQbYg0Xb8TeqiHrMoHY9g6W/pdSRplL2LOtDg9tqL6hHgbHsj iPo/t7pe//yLsk7e4MpeULsuX3s0sKlD0SlIY8RPc5+G5s6njtM7nUpXT6mYr8U0oPpb hUVFkHn7ke0R3/oRMivu93c5pfRB8fjWk+EEAML0ZMTpt1AdrnpU2KEc1Vdu6Y4ytr4X eSgg== X-Gm-Message-State: AOJu0YwvGrGdb3O75QlsoPc3sMxLG0PYLa18Z0QWHQtEmZ/+YLjwTHeg J59sX40N6iWfu4pYPmWEqPbBE4x4TtOeLCVmCCHHeQmF0BFvPEAw99RW X-Gm-Gg: ASbGncuG2DKnS4V89WtXRbviv7RYyEXSPjsYOQBltXx+8JM1eL2wkfxoFcYRSCBhmdl Nugl9mR5liZB37YfmT0jlcN4GYoZwbecfUiWOQR06w+qWTHo6RA0qMkYj8DP7DiwnpPrjsWFa9n 8CvMSostl6E1DDpKKelj8LrTGdt5OThZFtunpfTQGyskJIPIoy2ZsXR+I4YS50vFT2JyIhKW8r/ TYcwnEzt2mNB6D+D3sMCGqTPZrCi99i8LaNHHNjusQVCpxn6XhTquqC7Dge+a296s74iTgxEf35 6DtCMR6ns0mUOecnoDQnbuwWnR5pAHI= X-Google-Smtp-Source: AGHT+IGOHI+MRnX6FGsMqO+llNvYJWd62BtGElSm+9f/nt2DzBjQblbFw08KzgDWfNGn9wA4PbNfbQ== X-Received: by 2002:a05:6a20:a129:b0:1f5:72eb:8b3f with SMTP id adf61e73a8af0-2170ccb2daemr28263465637.24.1747777686020; Tue, 20 May 2025 14:48:06 -0700 (PDT) Received: from fedora ([2601:646:8081:3770::9eb]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b26eb0a9893sm8523897a12.72.2025.05.20.14.48.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 May 2025 14:48:05 -0700 (PDT) From: Collin Funk In-Reply-To: <202505201617.54KGHZTI3078829@freefriends.org> References: <202505201617.54KGHZTI3078829@freefriends.org> Date: Tue, 20 May 2025 14:48:04 -0700 Message-ID: <87ldqrq7hn.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Karl Berry writes: > As far as I can tell, the date command on Solaris 10 (cfarm210) and 11 > (cfarm211) does not support any way to print a specified date value. So > I inserted a fallback to perl -e 'print scalar > gmtime($SOURCE_DATE_EPOCH)' if the date commands fail. > > If Perl isn't available either, mdate-sh gives a warning and falls back > to using the mtime of the given file. That sounds like a good solution to me. > I don't mind just ignorning that platform. > > Not supporting gnulib-tool is one thing, but a lot of people still build > and use Solaris 10. We still get bug reports for Automake from people > running it there. Might as well keep mdate-sh working there, since it > was easy to do. > > Below is the important part of the patch, and the new file. > I also threw in a warning if more than one file is specified on the > command line, instead of silently ignoring anything after the first. > Hopefully no one's build actually passes multiple files. > > Anyway ... closing this bug, with fingers crossed. This was the last > change I intended to make before the release. Just have to finalize the > Algol 68 naming. --thanks, karl. Sounds good to me. I had assumed most people use Solaris 11, but I didn't notice that 'date' doesn't work there too. Thanks, Collin