GNU bug report logs -
#77805
new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
Previous Next
To reply to this bug, email your comments to 77805 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-automake <at> gnu.org:
bug#77805; Package
automake.
(Mon, 14 Apr 2025 16:36:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eric Blake <eblake <at> redhat.com>:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org.
(Mon, 14 Apr 2025 16:36:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[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
Information forwarded
to
bug-automake <at> gnu.org:
bug#77805; Package
automake.
(Mon, 14 Apr 2025 22:16:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 77805 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-automake <at> gnu.org:
bug#77805; Package
automake.
(Tue, 15 Apr 2025 12:54:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 77805 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-automake <at> gnu.org:
bug#77805; Package
automake.
(Tue, 15 Apr 2025 17:56:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 77805 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-automake <at> gnu.org:
bug#77805; Package
automake.
(Wed, 16 Apr 2025 12:53:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 77805 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-automake <at> gnu.org:
bug#77805; Package
automake.
(Wed, 16 Apr 2025 21:31:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 77805 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-automake <at> gnu.org:
bug#77805; Package
automake.
(Mon, 21 Apr 2025 20:43:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 77805 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-automake <at> gnu.org:
bug#77805; Package
automake.
(Mon, 21 Apr 2025 20:57:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 77805 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-automake <at> gnu.org:
bug#77805; Package
automake.
(Sun, 18 May 2025 22:26:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 77805 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[mdate-sh (application/octet-stream, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#77805; Package
automake.
(Sun, 18 May 2025 22:51:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 77805 <at> debbugs.gnu.org (full text, mbox):
Hi Karl,
Karl Berry <karl <at> freefriends.org> 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/
Information forwarded
to
bug-automake <at> gnu.org:
bug#77805; Package
automake.
(Sun, 18 May 2025 23:10:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 77805 <at> debbugs.gnu.org (full text, mbox):
Hi Karl,
Collin Funk <collin.funk1 <at> gmail.com> 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.
<https://lists.gnu.org/archive/html/bug-gnulib/2024-07/msg00076.html>
Collin
Information forwarded
to
bug-automake <at> gnu.org:
bug#77805; Package
automake.
(Tue, 20 May 2025 16:18:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 77805 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[mdate-sh (application/octet-stream, attachment)]
Reply sent
to
Karl Berry <karl <at> freefriends.org>:
You have taken responsibility.
(Tue, 20 May 2025 16:18:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Eric Blake <eblake <at> redhat.com>:
bug acknowledged by developer.
(Tue, 20 May 2025 16:18:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-automake <at> gnu.org:
bug#77805; Package
automake.
(Tue, 20 May 2025 21:49:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 77805 <at> debbugs.gnu.org (full text, mbox):
Karl Berry <karl <at> freefriends.org> 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
This bug report was last modified 25 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.