Re: [Reproducible-builds] Bug#801621: perl: support SOURCE_DATE_EPOCH in Pod::Man

2015-10-12 Thread Holger Levsen 
Hi,

thanks for your work on perl!

On Montag, 12. Oktober 2015, Niko Tyni wrote:
> Since 5.20.1~rc1-1, Pod::Man has supported the POD_MAN_DATE environment
> variable for overriding the page footers, fixing #759405. Since then,
> the reproducible builds project has converged on the SOURCE_DATE_EPOCH
> specification, which "defines a distribution-agnostic standard for
> upstream build processes to consume this timestamp from packaging
> systems."

btw, the spec is at https://reproducible-builds.org/specs/source-date-epoch/ - 
feedback much appreciated!


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#801621: perl: support SOURCE_DATE_EPOCH in Pod::Man

2015-10-12 Thread Niko Tyni 
Package: perl
Version: 5.22.0-4
Severity: wishlist
Tags: upstream patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: Russ Allbery , 
reproducible-builds@lists.alioth.debian.org

(cc'ing Russ as the podlators upstream author)

Since 5.20.1~rc1-1, Pod::Man has supported the POD_MAN_DATE environment
variable for overriding the page footers, fixing #759405. Since then,
the reproducible builds project has converged on the SOURCE_DATE_EPOCH
specification, which "defines a distribution-agnostic standard for
upstream build processes to consume this timestamp from packaging
systems."

It would be good to have Pod::Man support the SOURCE_DATE_EPOCH
environment variable, either instead of or in addition to POD_MAN_DATE,
which is specific to the podlators modules. This would give distributions
aiming for reproducible builds automatic benefits from standardizing on
SOURCE_DATE_EPOCH, without having to add a special case for Pod::Man.

In the context of Debian, while it's possible to set POD_MAN_DATE
externally based on SOURCE_DATE_EPOCH, it's not clear which layer
should do this. Options include dpkg-buildpackage, where special casing
POD_MAN_DATE looks particularly wrong, and debhelper, where this should
probably go in the v9 based dh_auto_* build systems, perhaps only the
Perl ones (perl_build and perl_makemaker). In particular, packages using
old style debhelper debian/rules do not have a place where POD_MAN_DATE
could be injected centrally in debhelper, which would leave out many
packages that would otherwise profit from this.

The attached patch against the current podlators upstream git
repository implements support for SOURCE_DATE_EPOCH in addition to
POD_MAN_DATE. Russ, please let me know what you think. I see POD_MAN_DATE
support hasn't been released upstream yet, so I suppose even backing
that out altogether would still be a valid option if you want to avoid
duplicating the functionality.
-- 
Niko Tyni   nt...@debian.org
>From a85d0944a90867cd5f2da58b59d31bd7accf80ed Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Mon, 12 Oct 2015 17:39:33 +0300
Subject: [PATCH] Make Pod::Man honor the SOURCE_DATE_EPOCH environment
 variable

See https://reproducible-builds.org/specs/source-date-epoch/ for
the SOURCE_DATE_EPOCH specification.
---
 lib/Pod/Man.pm  | 24 ++--
 t/man/devise-date.t | 21 -
 2 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/lib/Pod/Man.pm b/lib/Pod/Man.pm
index 56a067e..2096cbc 100644
--- a/lib/Pod/Man.pm
+++ b/lib/Pod/Man.pm
@@ -894,6 +894,10 @@ sub devise_title {
 # reproducible generation of the same file even if the input file timestamps
 # are unpredictable or the POD coms from standard input.
 #
+# Otherwise, if SOURCE_DATE_EPOCH is set and can be parsed as seconds
+# since the UNIX epoch, base the timestamp on that.
+# See 
+#
 # Otherwise, use the modification date of the input if we can stat it.  Be
 # aware that Pod::Simple returns the stringification of the file handle as
 # source_filename for input from a file handle, so we'll stat some random ref
@@ -910,14 +914,22 @@ sub devise_date {
 return $ENV{POD_MAN_DATE};
 }
 
+# If SOURCE_DATE_EPOCH is set and can be parsed, use that.
+my $time;
+if (defined($ENV{SOURCE_DATE_EPOCH}) &&
+$ENV{SOURCE_DATE_EPOCH} !~ /\D/) {
+$time = $ENV{SOURCE_DATE_EPOCH};
+}
+
 # Otherwise, get the input filename and try to stat it.  If that fails,
 # use the current time.
-my $input = $self->source_filename;
-my $time;
-if ($input) {
-$time = (stat($input))[9] || time();
-} else {
-$time = time();
+if (!defined $time) {
+my $input = $self->source_filename;
+if ($input) {
+$time = (stat($input))[9] || time();
+} else {
+$time = time();
+}
 }
 
 # Can't use POSIX::strftime(), which uses Fcntl, because MakeMaker uses
diff --git a/t/man/devise-date.t b/t/man/devise-date.t
index 27271d9..5fb08e2 100755
--- a/t/man/devise-date.t
+++ b/t/man/devise-date.t
@@ -12,7 +12,7 @@ use warnings;
 use Pod::Man;
 use POSIX qw(strftime);
 
-use Test::More tests => 3;
+use Test::More tests => 6;
 
 # Check that the results of device_date matches strftime.  There is no input
 # file name, so this will use the current time.
@@ -30,3 +30,22 @@ is($parser->devise_date, '2014-01-01', 'devise_date honors POD_MAN_DATE');
 # Check that an empty environment variable is honored.
 local $ENV{POD_MAN_DATE} = q{};
 is($parser->devise_date, q{}, 'devise_date honors empty POD_MAN_DATE');
+
+# Set another environment variable and ensure that it's honored.
+local $ENV{POD_MAN_DATE};
+local $ENV{SOURCE_DATE_EPOCH} = 1439390140;
+is($parser->devise_date, '2015-08-12', 'devise_date honors SOURCE_DATE_EPOCH');
+
+# Check that POD_MAN_DATE overrides SOURCE_DATE_EPOCH
+local $ENV{POD_MAN_DATE} = '201

Re: [Reproducible-builds] timestamps_in_directories

2015-10-12 Thread Niko Tyni 
On Mon, Oct 12, 2015 at 11:11:19AM +0300, Niko Tyni wrote:

> I still think the directory timestamp issue happens because dh_installdocs
> uses find + cp --parents -p, which generates different results depending
> on the order of the find results.

First shot at a patch attached for eyeballs / testing.

The line wrapping is because t/size enforces a maximum of
160 characters per line.
-- 
Niko Tyni   nt...@debian.org
>From 7ad0f54e56e86773e18d7614da53dd76ecf0adfa Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Mon, 12 Oct 2015 14:47:35 +0300
Subject: [PATCH 1/2] dh_installexamples: use find + xargs instead of find
 -exec

Commit 71d06996481c6187b016c3b14b7e9faaf8adc432 changed most of the find
-exec invocations in dh_install* programs, but this one remains. Use
xargs instead to prepare for an additional sort command in the pipeline.
---
 dh_installexamples | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/dh_installexamples b/dh_installexamples
index c39e899..9ec6914 100755
--- a/dh_installexamples
+++ b/dh_installexamples
@@ -97,7 +97,8 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 my $pwd=`pwd`;
 chomp $pwd;
 my $exclude2 = '-type f'.$exclude;
-complex_doit("cd '$dir' && find '$basename' -type f$exclude -exec cp --reflink=auto --parents -dp {} $pwd/$tmp/usr/share/doc/$package/examples \\;");
+complex_doit("cd '$dir' && " .
+			 "find '$basename' -type f$exclude -print0 | xargs -0 -I {} cp --reflink=auto --parents -dp {} $pwd/$tmp/usr/share/doc/$package/examples");
 			}
 			else {
 doit("cp", '--reflink=auto', "-a", $example,
-- 
2.5.1

>From 7e962d5d847c7f6d365ad1a9fc256a9b56438a1a Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Mon, 12 Oct 2015 15:05:06 +0300
Subject: [PATCH 2/2] dh_install*: sort file lists passed to 'cp --parents -p'
 for reproducibility

The order in which the files are copied can affect directory
timestamps when copying subdirectory hierarchies.
---
 dh_install | 6 --
 dh_installdocs | 4 +++-
 dh_installexamples | 3 ++-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/dh_install b/dh_install
index 9c8d23c..769d9d4 100755
--- a/dh_install
+++ b/dh_install
@@ -214,11 +214,13 @@ foreach my $package (getpackages()) {
 my $pwd=`pwd`;
 chomp $pwd;
 complex_doit("cd '$dir' && " .
-			 "find '$basename' $exclude \\( -type f -or -type l \\) -print0 | xargs -0 -I {} cp --reflink=auto --parents -dp {} $pwd/$tmp/$dest/");
+			 "find '$basename' $exclude \\( -type f -or -type l \\) -print0 | LC_ALL=C sort -z | " .
+			 "xargs -0 -I {} cp --reflink=auto --parents -dp {} $pwd/$tmp/$dest/");
 # cp is annoying so I need a separate pass
 # just for empty directories
 complex_doit("cd '$dir' && " .
-			 "find '$basename' $exclude \\( -type d -and -empty \\) -print0 | xargs -0 -I {} cp --reflink=auto --parents -a {} $pwd/$tmp/$dest/");
+			 "find '$basename' $exclude \\( -type d -and -empty \\) -print0 | LC_ALL=C sort -z | " .
+			 "xargs -0 -I {} cp --reflink=auto --parents -a {} $pwd/$tmp/$dest/");
 			}
 			else {
 doit("cp", '--reflink=auto', "-a", $src, "$tmp/$dest/");
diff --git a/dh_installdocs b/dh_installdocs
index 45b5338..7eccab8 100755
--- a/dh_installdocs
+++ b/dh_installdocs
@@ -232,7 +232,9 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 my $pwd=`pwd`;
 chomp $pwd;
 my $docdir = "$pwd/$tmp/usr/share/doc/$package";
-complex_doit("cd '$dir' && find '$basename' \\( -type f -or -type l \\)$exclude -print0 | xargs -0 -I {} cp --reflink=auto --parents -dp {} $docdir");
+complex_doit("cd '$dir' && " .
+			 "find '$basename' \\( -type f -or -type l \\)$exclude -print0 | LC_ALL=C sort -z | " .
+			 "xargs -0 -I {} cp --reflink=auto --parents -dp {} $docdir");
 			}
 			else {
 doit("cp", '--reflink=auto', "-a", $doc,
diff --git a/dh_installexamples b/dh_installexamples
index 9ec6914..7b28776 100755
--- a/dh_installexamples
+++ b/dh_installexamples
@@ -98,7 +98,8 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 chomp $pwd;
 my $exclude2 = '-type f'.$exclude;
 complex_doit("cd '$dir' && " .
-			 "find '$basename' -type f$exclude -print0 | xargs -0 -I {} cp --reflink=auto --parents -dp {} $pwd/$tmp/usr/share/doc/$package/examples");
+			 "find '$basename' -type f$exclude -print0 | LC_ALL=C sort -z | " .
+			 "xargs -0 -I {} cp --reflink=auto --parents -dp {} $pwd/$tmp/usr/share/doc/$package/examples");
 			}
 			else {
 doit("cp", '--reflink=auto', "-a", $example,
-- 
2.5.1

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] dpkg has lost some of its superpowers

2015-10-12 Thread Holger Levsen 
On Montag, 12. Oktober 2015, Santiago Vila wrote:
> > check out the pu/reproducible_builds branch…
> Ah, ok. Done that as well.

Thank you!

:-)


signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] dpkg has lost some of its superpowers

2015-10-12 Thread Santiago Vila 
On Mon, Oct 12, 2015 at 01:01:24PM +0200, Holger Levsen wrote:
> check out the pu/reproducible_builds branch…

Ah, ok. Done that as well.

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] dpkg has lost some of its superpowers

2015-10-12 Thread Holger Levsen 
Hi Santiago,

On Montag, 12. Oktober 2015, Santiago Vila wrote:
> Done

cool, thanks!

> but I have had to do it without the git stuff because it seems
> to be broken at this moment:
[...]
> warning: remote HEAD refers to nonexistent ref, unable to checkout.

no, it works as documented. check out the pu/reproducible_builds branch…
 
> Attached the trivial patch I've applied.

…and please push and commit your changes.

I'll now build armf packages and upload those…


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] dpkg has lost some of its superpowers

2015-10-12 Thread Santiago Vila 
On Mon, Oct 12, 2015 at 10:09:29AM +0200, Holger Levsen wrote:
> Could someone please rebuild dpkg with that fix, test if this fixes the 
> problem and if so, upload to our repo? I'm a bit swamped to do this right now…

Done, but I have had to do it without the git stuff because it seems
to be broken at this moment:

Cloning into 'dpkg'...
remote: Counting objects: 76098, done.
remote: Compressing objects: 100% (14920/14920), done.
remote: Total 76098 (delta 63711), reused 73079 (delta 60765)
Receiving objects: 100% (76098/76098), 52.53 MiB | 1.36 MiB/s, done.
Resolving deltas: 100% (63711/63711), done.
Checking connectivity... done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

So, plain old dpkg-source from our repo + changes + upload.

Attached the trivial patch I've applied.

Thanks.
diff -ru dpkg-1.18.3.0~reproducible2.original/debian/changelog 
dpkg-1.18.3.0~reproducible2/debian/changelog
--- dpkg-1.18.3.0~reproducible2.original/debian/changelog   2015-10-08 
18:40:17.0 +0200
+++ dpkg-1.18.3.0~reproducible2/debian/changelog2015-10-12 
11:35:55.385268393 +0200
@@ -1,3 +1,10 @@
+dpkg (1.18.3.0~reproducible3) UNRELEASED; urgency=low
+
+  * scripts/dpkg-buildpackage.pl: Use SOURCE_DATE_EPOCH instead
+of DEB_BUILD_TIMESTAMP, to be in sync with dpkg-deb.
+
+ -- Santiago Vila   Mon, 12 Oct 2015 11:35:30 +0200
+
 dpkg (1.18.3.0~reproducible2) UNRELEASED; urgency=low
 
   [ Jérémy Bobbio ]
diff -ru dpkg-1.18.3.0~reproducible2.original/scripts/dpkg-buildpackage.pl 
dpkg-1.18.3.0~reproducible2/scripts/dpkg-buildpackage.pl
--- dpkg-1.18.3.0~reproducible2.original/scripts/dpkg-buildpackage.pl   
2015-10-08 18:40:09.0 +0200
+++ dpkg-1.18.3.0~reproducible2/scripts/dpkg-buildpackage.pl2015-10-12 
11:32:00.833844266 +0200
@@ -445,10 +445,10 @@
 $maintainer = mustsetvar($changelog->{maintainer}, g_('source changed 
by'));
 }
 
-if (!$ENV{DEB_BUILD_TIMESTAMP}) {
+if (!$ENV{SOURCE_DATE_EPOCH}) {
 my $timestamp = `date -d'$changelog->{date}' +%s`;
 chomp $timestamp;
-$ENV{DEB_BUILD_TIMESTAMP} = $timestamp;
+$ENV{SOURCE_DATE_EPOCH} = $timestamp;
 }
 
 my @arch_opts;
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] package uploaded to our repo

2015-10-12 Thread Santiago Vila 
dpkg_1.18.3.0~reproducible3.dsc has just been uploaded to 
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] timestamps_in_directories

2015-10-12 Thread Holger Levsen 
Hi,

On Montag, 12. Oktober 2015, Santiago Vila wrote:
> Indeed. Just replace "disorderfs" by "different filesystem ordering"
> and we still have a likely reason for the differences.
 
on possible source for this variation is the kernel, Ben said on irc that it's 
possible that tmpfs from 3.16 and 4.1 is causing this.

Atm we are using:

pb-b1: 3.16
pb-b2: 4.1 (this is a bug, it should run 3.16)
pb-b5: 4.1
pb-b6: 4.1

and then the jobs build like this

1st build   2nd build
b1  b5
b1  b6
b2  b5
b2  b6
b5  b1
b5  b2
b6  b1
b6  b2

IOW: 50% of the amd64 builds take place on 4.1 kernels only, while 50% run on 
3.16 and 4.1

I could (try harder to) downgrade b2 to 3.16, which would give us 100% running 
on different kernels...


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] timestamps_in_directories

2015-10-12 Thread Santiago Vila 
On Mon, Oct 12, 2015 at 11:11:19AM +0300, Niko Tyni wrote:
> On Sun, Oct 11, 2015 at 07:50:49PM +0200, Holger Levsen wrote:
> > On Sonntag, 11. Oktober 2015, Niko Tyni wrote:
> > > It's indeed an unfortunate interaction of dh_installdocs and disorderfs
> > > when installing directory hierarchies.
> > 
> > we don't use disorderfs since weeks:
> 
> Ah, I'm pretty sure it was still on the list of variations on the
> reproducible.d.n front page yesterday when I checked that. So I thought
> the issues had been fixed. Never mind & thanks for fixing the list.
> 
> In that case, I think something else has introduced file ordering
> variation between build1 and build2 lately, highlighting this issue
> (and others in for instance perl and libapache2-mod-perl2). 
> This is a good thing, of course.
> 
> I still think the directory timestamp issue happens because dh_installdocs
> uses find + cp --parents -p, which generates different results depending
> on the order of the find results.

Indeed. Just replace "disorderfs" by "different filesystem ordering"
and we still have a likely reason for the differences.

Not using disorderfs does not automatically make filesystem ordering
to be deterministic.

Thanks.

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] timestamps_in_directories

2015-10-12 Thread Niko Tyni 
On Sun, Oct 11, 2015 at 07:50:49PM +0200, Holger Levsen wrote:
> On Sonntag, 11. Oktober 2015, Niko Tyni wrote:
> > It's indeed an unfortunate interaction of dh_installdocs and disorderfs
> > when installing directory hierarchies.
> 
> we don't use disorderfs since weeks:

Ah, I'm pretty sure it was still on the list of variations on the
reproducible.d.n front page yesterday when I checked that. So I thought
the issues had been fixed. Never mind & thanks for fixing the list.

In that case, I think something else has introduced file ordering
variation between build1 and build2 lately, highlighting this issue
(and others in for instance perl and libapache2-mod-perl2). 
This is a good thing, of course.

I still think the directory timestamp issue happens because dh_installdocs
uses find + cp --parents -p, which generates different results depending
on the order of the find results.
-- 
Niko Tyni   nt...@debian.org

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] dpkg has lost some of its superpowers

2015-10-12 Thread Holger Levsen 
Hi Niko,

On Montag, 12. Oktober 2015, Niko Tyni wrote:
> The 5eacc4dbec35525468ad195e6b026a857dc12220 commit message (in
> dpkg pu/reproducible_builds) talks about dpkg-buildpackage setting
> SOURCE_DATE_EPOCH, but the code uses DEB_BUILD_TIMESTAMP.

Ah!
 
> So if I understand this correctly, dpkg-buildpackage now sets
> DEB_BUILD_TIMESTAMP but dpkg-deb looks at SOURCE_DATE_EPOCH.
> 
> Looks like an accidental merge/rebase error to me?

To me too!

Could someone please rebuild dpkg with that fix, test if this fixes the 
problem and if so, upload to our repo? I'm a bit swamped to do this right now…


cheers,
Holger, glad that this has been found




signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] dpkg has lost some of its superpowers

2015-10-12 Thread Niko Tyni 
On Sun, Oct 11, 2015 at 06:30:28PM +, Santiago Vila wrote:
> On Sun, Oct 11, 2015 at 12:35:18PM +, Santiago Vila wrote:
> 
> > │ -rw-r--r-- 0/0  4 Oct 11 12:08 2015 debian-binary
> > │ -rw-r--r-- 0/0   4814 Oct 11 12:08 2015 control.tar.gz
> > │ -rw-r--r-- 0/0 250668 Oct 11 12:08 2015 data.tar.xz
> > │ +rw-r--r-- 0/0  4 Oct 11 12:10 2015 debian-binary
> > │ +rw-r--r-- 0/0   4814 Oct 11 12:10 2015 control.tar.gz
> > │ +rw-r--r-- 0/0 250668 Oct 11 12:10 2015 data.tar.xz
> 
> Ok, as an experiment I managed this to be 1970-01-01 by setting
> SOURCE_DATE_EPOCH=0 before dpkg-buildpackage.
> 
> But I don't think setting such variable should be required, because
> then: why Bug #75 talks about the latest changelog entry?
> 
> This is supposed to be automatic, right?

The perl package is affected too fwiw.

The 5eacc4dbec35525468ad195e6b026a857dc12220 commit message (in
dpkg pu/reproducible_builds) talks about dpkg-buildpackage setting
SOURCE_DATE_EPOCH, but the code uses DEB_BUILD_TIMESTAMP.

So if I understand this correctly, dpkg-buildpackage now sets
DEB_BUILD_TIMESTAMP but dpkg-deb looks at SOURCE_DATE_EPOCH. 

Looks like an accidental merge/rebase error to me?
-- 
Niko Tyni   nt...@debian.org

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] CI testbuilds LC_ALL vs. LANG

2015-10-12 Thread Holger Levsen 
Hi Andreas,

On Freitag, 9. Oktober 2015, Andreas Metzler wrote:
> Personally I tend to disagree here[1]. However coming back to the main
> point of my message (setting LC_ALL on testbuild): If I were upstream
> I might accept
> 
> -sort
> +env LC_COLLATE=C sort.
> and reject
> -sort
> +env LC_ALL=C sort

works for me :)
 
> Reproducible builds always require some work on the side of the
> builder in reproducing the toolchain and libraries used for the build.
> I would say the environment, including locale settings falls in the
> same category.  But I guess this decision already had some major
> discussion, and my comment just rehashes old arguments.

I'm not so sure about the last sentence here. Or to phrase it differently: I 
think you could be right, I don't really see a downside in your approach, 
neither now, nor three days ago when I first read it.

I'm curious what will other have to say. I've also noted this as a topic to 
discuss as the upcoming reproducible builds summit in December.


cheers,
Holger




signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds