GNU bug report logs -
#77805
new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Tue, 20 May 2025 10:17:35 -0600
with message-id <202505201617.54KGHZTI3078829 <at> freefriends.org>
and subject line Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
has caused the debbugs.gnu.org bug report #77805,
regarding new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
77805: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77805
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[dropping gnulib, but adding automake, for the reproducibility issue]
On Mon, Apr 14, 2025 at 06:04:53PM +0200, Santiago Vila wrote:
> El 14/4/25 a las 16:36, Eric Blake escribió:
> > Also, I see two
> > uses of @value{UPDATED} in m4.texi, but your patch only removed one;
> > is the other one not an issue?
>
> You are right. I don't know. For some reason, only the patch I posted before
> was necessary at least for the 1.4.19 version, as shown here:
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/m4.html
It _could_ be that automake's mdate-sh was older at the time 1.4.19
was cut; it has changed in the meantime, although I could not quickly
ascertain if any of those changes would be important to the issue at
hand in this email.
>
> Those tests check the produced .debs (m4 and m4-doc in this case).
>
> The m4 package contains the info manual, and the m4-doc package contains
> the manual in html format.
>
> If the variation only happened in the .dvi or the .pdf, for example,
> the above tests would still mark the Debian package as reproducible,
> as we don't distribute those artifacts in binary packages.
>
> I have not tested the new snapshot yet for reproducibility issues, but
> will probably try for the next snapshot.
According to 'info automake', version.texi is supposed to be generated
with contents including:
‘UPDATED’
This holds the date the primary ‘.texi’ file was last modified.
and this is done via the build-aux/mdate-sh script. It looks like
that script is hard-coded to scrape the date a file was last modified
(which hurts in reproducibility, since unpacking the tarball in
different months may inadverently result in two environments with
different dates on the file, and thus different contents generated
into version.texi).
Wouldn't it be better for the universe of reproducible builds if
automake's generation of version.texi were improved to allow the
caller to specify an epoch that a particular build should place into
version.texi, regardless of file timestamps being newer than that
specified epoch? Then, manuals could continue to use @value{UPDATED},
as recommended by the texinfo manual.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
[Message part 3 (message/rfc822, inline)]
[Message part 4 (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)]
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.