On 2018-08-02 08:47, Paul Eggert wrote:
> Bernhard M. Wiedemann wrote:
>> This allows for reproducible output of
>> echo foo | gzip | md5sum
>
> gzip -n already does that, so we don't need to change the gzip source
> code to get reproducible output.
I know that it does, but patching hundreds of p
in order to make builds reproducible.
See https://reproducible-builds.org/ for why this is good
and https://reproducible-builds.org/specs/source-date-epoch/
for the definition of this variable.
---
1st draft: probably has some year-2038 problems left
---
zip.c | 7 ++-
1 file changed, 6 inser
On 08/02/2018 01:31 AM, Bernhard M. Wiedemann wrote:
I know that it does, but patching hundreds of packages [1] (including
ones still to be created) doing
tar -czf $file
to do instead
tar -c | gzip -n > $file
This would be something that tar could and should address, I'd think.
Is there a goo
On 08/02/2018 02:03 AM, Bernhard M. Wiedemann wrote:
+if ((source_date_epoch = getenv("SOURCE_DATE_EPOCH")) == NULL ||
(stamp = strtol(source_date_epoch, NULL, 10))
That won't work after 2038 on x32. Also, I'm leery of having environment
variables affect standard utilities' behavior,
On Thu, Aug 2, 2018 at 6:01 PM, Paul Eggert wrote:
> On 08/02/2018 02:03 AM, Bernhard M. Wiedemann wrote:
>>
>> +if ((source_date_epoch = getenv("SOURCE_DATE_EPOCH")) == NULL ||
>> (stamp = strtol(source_date_epoch, NULL, 10))
>
>
> That won't work after 2038 on x32. Also, I'm leery of hav
On 08/02/2018 09:12 AM, Jim Meyering wrote:
I had the same initial negative reaction to adding support for an
envvar, but given the minor effect and worthy goal, I think the
balance has tipped in favor of allowing this one.
Yes, on further thought I'm inclined to go whole hog and just fix the
