[Reproducible-builds] new armhf node (Odroid-C1+)

[Vagrant Cascadian]

It might not come online for real until Sunday evening (just need to
move it into place with all the others), but figured I'd announce it
now:

odc1-armhf-rb.debian.net:
Odroid-C1+, quad-core Amlogic (meson8b? cortex-a5), 1GB ram, ~60GB USB3 SATA SSD
ssh port: 2231
ssh fingerprints:
256 9e:09:96:a8:98:b6:a2:3b:36:16:eb:a3:28:5f:df:e9 
/etc/ssh/ssh_host_ecdsa_key.pub (ECDSA)
2048 82:ee:b4:5f:00:36:05:f5:2d:ed:9e:96:2b:d1:52:a2 
/etc/ssh/ssh_host_rsa_key.pub (RSA)

This is the first one running an older version of linux, 3.10, and using
the kernel package from odrobian, rather than a kernel from debian, or a
lightly/moderately patched kernel based on debian's kernel packaging.

The u-boot is terribly old...

This one has been a bit finicky to set up, but hopefully it'll add a few
more CPU cycles to the build network...


live well,
  vagrant


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

[Reproducible-builds] Bug#807111: libperl-apireference-perl: Make the stored data reproducible between builds

[Niko Tyni]

Package: libperl-apireference-perl
Version: 0.21-1
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

This module recently switched to using Sereal::Encoder instead of
Data::Dumper to store pre-parsed data. The stored data representation
now varies between builds.  The attached patch fixes this, rendering
the build reproducible again.

See https://wiki.debian.org/ReproducibleBuilds for more information
about the "reproducible builds" effort.
-- 
Niko Tyni   nt...@debian.org
>From 1b27b06805350932aac7af089c793fef692ffd39 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sat, 5 Dec 2015 14:43:02 +0200
Subject: [PATCH] Make the stored data reproducible between builds

The 'canonical' option makes Sereal::Encoder produce serialized data
structures that don't vary between builds.  This makes the build
result reproducible.
---
 lib/Perl/APIReference.pm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/Perl/APIReference.pm b/lib/Perl/APIReference.pm
index d10b05a..561ee9d 100644
--- a/lib/Perl/APIReference.pm
+++ b/lib/Perl/APIReference.pm
@@ -141,6 +141,7 @@ sub _dump_as_class {
   require Sereal::Encoder;
   my $data = $self->{'index'};
   my $dump = Sereal::Encoder->new({
+canonical  => 1,
 compress   => Sereal::Encoder::SRL_ZLIB(),
 compress_level => 9,
 dedupe_strings => 1,
-- 
2.6.2

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

Re: [Reproducible-builds] Bug#807111: libperl-apireference-perl: Make the stored data reproducible between builds

[Niko Tyni]

On Sat, Dec 05, 2015 at 05:32:13PM +0100, Axel Beckert wrote:
> Niko Tyni wrote:
> > This module recently switched to using Sereal::Encoder instead of
> > Data::Dumper to store pre-parsed data. The stored data representation
> > now varies between builds.  The attached patch fixes this, rendering
> > the build reproducible again.

> >my $dump = Sereal::Encoder->new({
> > +canonical  => 1,

> I wonder if it's wise to patch the module itself in such a permanent
> way instead of maybe adding a switch and setting canonical=1 only
> during the build or the running of the test suite.
> 
> Maybe users of that module won't be happy if canonical=1 is hardcoded
> that way, e.g. for (guessed) performance reasons as the above likely
> includes sorting which always has an performance impact at some scale.

This code path is in a private function that is only used during the
build (by Perl::APIReference::Generator) to serialize API documentation
structures inline into the module in a __DATA__ section, to avoid parsing
perlapi.pod files at runtime.

I doubt the canonical representation is much slower to decode, but that
phase (API documentation lookups) doesn't seem like a performance critical
thing to me.

A hypothetical performance critical subclass of
Perl::APIReference::Generator might suffer, but IMO this is very
contrived.

The old Data-Dumper based implementation used to set
$Data::Dumper::Sortkeys, so the loss of reproducibility is a regression.

I've also forwarded the patch upstream, so the author can protest
if he judges this loss of performance unacceptable.

I hope this addresses your concerns.
-- 
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] Bug#807111: libperl-apireference-perl: Make the stored data reproducible between builds

[Axel Beckert]

Hi Niko,

Niko Tyni wrote:
> This module recently switched to using Sereal::Encoder instead of
> Data::Dumper to store pre-parsed data. The stored data representation
> now varies between builds.  The attached patch fixes this, rendering
> the build reproducible again.
[…]
> --- a/lib/Perl/APIReference.pm
> +++ b/lib/Perl/APIReference.pm
> @@ -141,6 +141,7 @@ sub _dump_as_class {
>require Sereal::Encoder;
>my $data = $self->{'index'};
>my $dump = Sereal::Encoder->new({
> +canonical  => 1,
>  compress   => Sereal::Encoder::SRL_ZLIB(),
>  compress_level => 9,
>  dedupe_strings => 1,

I wonder if it's wise to patch the module itself in such a permanent
way instead of maybe adding a switch and setting canonical=1 only
during the build or the running of the test suite.

Maybe users of that module won't be happy if canonical=1 is hardcoded
that way, e.g. for (guessed) performance reasons as the above likely
includes sorting which always has an performance impact at some scale.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

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

[Reproducible-builds] Bug#807084: libjs-jcrop: please make the build reproducible

[Chris Lamb]

Source: libjs-jcrop
Version: 0.9.12+dfsg-2
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi David,

Thanks for closing #779588. However, we've now added even more variation
in our test framework, exposing that the fix was incomplete.

Another patch is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2015-12-05 09:42:10.758251726 +0200
--- b/debian/rules  2015-12-05 09:51:58.484426475 +0200
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 export JCROP_BUILD = debian/$(shell dpkg-parsechangelog --show-field Version)
+export JCROP_COPYRIGHT = $(shell date --date="$$(dpkg-parsechangelog 
--show-field Date)" +%Y)
 
 %:
dh $@
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds