Subject: bug#77805: closed (Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 20 May 2025 16:18:03 +0000

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 [email-masked].

-- 
77805: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77805
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
From: Karl Berry <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 20 May 2025 10:17:35 -0600
List-Id: <debbugs-submit.debbugs.gnu.org>

    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.

Subject: Re: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
From: Eric Blake <[email-masked]>
To: Santiago Vila <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Mon, 14 Apr 2025 11:34:38 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

[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