GNU bug report logs - #77805
new snapshot available: m4-1.4.19.60-6ebfc.tar.xz

Previous Next

Full log

Message #35 received at 77805 <at> debbugs.gnu.org (full text, mbox):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: sanvila <at> debian.org, 77805 <at> debbugs.gnu.org
Subject: Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz
Date: Sun, 18 May 2025 16:09:08 -0700

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.