Re: [Reproducible-builds] Second build on failures

2015-12-21 Thread Holger Levsen
Hi,

cc:ing the bug and thus leaving some more context…

On Montag, 21. Dezember 2015, Vagrant Cascadian wrote:
> On 2015-12-21, Holger Levsen wrote:
> >> For now, relying on the fact that there are different actual kernels on
> >> various builds (4.x vs. 3.x) will hopefully be good enough to detect the
> >> issue that using "linux64 --uname-2.6" was trying to solve.
> > 
> > yeah. what I don't like about this is that it forces us to do that. I
> > liked the flexibility using --uname-2.6 gave us…
> 
> The impression I got was the patch implementation was rejected upstream,
> but in theory a better patch could be written. Aurelian wasn't planning
> on working on it.

I've got the same impression.
 
> So if it's wanted for reproducible builds purposes, probably need to
> come up with a patch that would get accepted upstream...

Yup. Any takers? :-)


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] Second build on failures

2015-12-21 Thread Holger Levsen
Hi,

On Donnerstag, 3. Dezember 2015, Vagrant Cascadian wrote:
> Filed against libc-bin:
>   https://bugs.debian.org/806911
> Aurelian Jarno filed a patch upstream to support using the uname26
> personality:
>   https://sourceware.org/ml/libc-alpha/2015-12/msg00028.html

ok, cool, thanks!
 
> So it might get fixed in future versions ...although we'd need to run
> From within sid (or backport util-linux) to run on jenkins any time
> soon...

yeah :/
 
> For now, relying on the fact that there are different actual kernels on
> various builds (4.x vs. 3.x) will hopefully be good enough to detect the
> issue that using "linux64 --uname-2.6" was trying to solve.

yeah. what I don't like about this is that it forces us to do that. I liked 
the flexibility using --uname-2.6 gave us…


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] Second build on failures

2015-12-21 Thread Vagrant Cascadian
On 2015-12-21, Holger Levsen wrote:
> On Donnerstag, 3. Dezember 2015, Vagrant Cascadian wrote:
>> Filed against libc-bin:
>>   https://bugs.debian.org/806911
>> Aurelian Jarno filed a patch upstream to support using the uname26
>> personality:
>>   https://sourceware.org/ml/libc-alpha/2015-12/msg00028.html
>
> ok, cool, thanks!
>  
>> So it might get fixed in future versions ...although we'd need to run
>> From within sid (or backport util-linux) to run on jenkins any time
>> soon...
>
> yeah :/
>  
>> For now, relying on the fact that there are different actual kernels on
>> various builds (4.x vs. 3.x) will hopefully be good enough to detect the
>> issue that using "linux64 --uname-2.6" was trying to solve.
>
> yeah. what I don't like about this is that it forces us to do that. I liked 
> the flexibility using --uname-2.6 gave us…

The impression I got was the patch implementation was rejected upstream,
but in theory a better patch could be written. Aurelian wasn't planning
on working on it.

So if it's wanted for reproducible builds purposes, probably need to
come up with a patch that would get accepted upstream...

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

Re: [Reproducible-builds] Second build on failures

2015-12-03 Thread Holger Levsen
Hi,

thanks Vagrant for catching and reporting this…!

On Mittwoch, 2. Dezember 2015, Vagrant Cascadian wrote:
> I suspect this is also an issue with amd64, though it shows up when
> trying to install build-deps:
>   https://reproducible.debian.net/unstable/amd64/index_last_24h.html

yeah :/ it's also very visible in the graphs already…

So I've disabled this now with a84a80c to jenkins.debian.net.git.

> Looks like some change in libc6, will file a bug about it...

please do! (also feel free to just file it against qa.debian.org, usertag 
jenkins.debian.net so there is at least some trackable bug… - if you are 
uncomfortable about the right package. qa.d.o is definitly a correct 
pseudopackage for this bug…)


cheers,
Holger, enjoying a very productive reproducible meeting in Athens
 right now


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] Second build on failures

2015-12-02 Thread Vagrant Cascadian
On 2015-12-01, Reiner Herrmann  wrote:
> On Tue, Dec 01, 2015 at 02:13:07PM -0800, Vagrant Cascadian wrote:
>> Hey, I think all of the second builds on armhf are failing to set up the
>> build environment:
>> 
>>   
>> https://reproducible.debian.net/logs/unstable/armhf/gb_0.3.2-1.build2.log.gz
>> 
>>   I: Installing the build-deps
>>   I: user script 
>> /srv/workspace/pbuilder/5651/tmp/hooks/D01_modify_environment starting
>>   FATAL: kernel too old
>
> Interesting... According to codesearch this comes from glibc [1].
> It could be related to "linux64 --uname-2.6", which we use use to fake a 
> different
> kernel version.
>
> [1]: 
> https://sources.debian.net/src/glibc/2.19-18/sysdeps/unix/sysv/linux/dl-osinfo.h/?hl=45#L45

Indeed, the "linux64 --uname-2.6" seems to be the culprit.

I first tested removing the linux64 call on two of the nodes, and they
were the only ones successfully running second builds for the last
several hours... so I've just now removed the linux64 calls on all the
armhf nodes.

Would be best to investigate the issue further...

On a related note, it might be worth trying "setarch uname26" instead of
linux64 (which is just a symlink to setarch). But I doubt if this will
change anything with the above issue.

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

Re: [Reproducible-builds] Second build on failures

2015-12-01 Thread Reiner Herrmann
On Tue, Dec 01, 2015 at 02:13:07PM -0800, Vagrant Cascadian wrote:
> Hey, I think all of the second builds on armhf are failing to set up the
> build environment:
> 
>   https://reproducible.debian.net/logs/unstable/armhf/gb_0.3.2-1.build2.log.gz
> 
>   I: Installing the build-deps
>   I: user script 
> /srv/workspace/pbuilder/5651/tmp/hooks/D01_modify_environment starting
>   FATAL: kernel too old

Interesting... According to codesearch this comes from glibc [1].
It could be related to "linux64 --uname-2.6", which we use use to fake a 
different
kernel version.

[1]: 
https://sources.debian.net/src/glibc/2.19-18/sysdeps/unix/sysv/linux/dl-osinfo.h/?hl=45#L45

> 
> 
> Also saw this message on an amd64/experimental build, although much
> later in the build environment setup:
> 
>   
> https://reproducible.debian.net/logs/experimental/amd64/python-letsencrypt_0.0.0.dev20151123-1.build2.log.gz
> 
>   Traitement des actions différées (« triggers ») pour libc-bin (2.21-1)...
>   FATAL: kernel too old
>   Segmentation fault
>   FATAL: kernel too old
>   Segmentation fault
>   dpkg: erreur de traitement du paquet libc-bin (--unpack)



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

Re: [Reproducible-builds] Second build on failures

2015-12-01 Thread Mattia Rizzolo
Hi there!
To be clear, I'm in Athens atm and I don't really have time now to look
better at this, but:

On Tue, Dec 01, 2015 at 02:13:07PM -0800, Vagrant Cascadian wrote:
> Hey, I think all of the second builds on armhf are failing to set up the
> build environment:
> 
>   https://reproducible.debian.net/logs/unstable/armhf/gb_0.3.2-1.build2.log.gz
> 
>   I: Installing the build-deps
>   I: user script 
> /srv/workspace/pbuilder/5651/tmp/hooks/D01_modify_environment starting
>   FATAL: kernel too old

This must me some toolchain stuff.  That menas something inside the hook
failed, and thanks to `set -e` (luckily) the whole script failed, so did
the build.  The head of that script is:

#!/bin/sh
set -e
# exit if we are in the same UTS namespace as init ( != 2nd build )
[ "$(readlink /proc/1/ns/uts)" = "$(readlink /proc/self/ns/uts)" ] && exit 0
echo "I: Changing host+domainname to test build reproducibility" >&2

Given that I don't the text on that echo, I've got to assume it fails
eariler, but I can't even think how...

> Also saw this message on an amd64/experimental build, although much
> later in the build environment setup:
> 
>   
> https://reproducible.debian.net/logs/experimental/amd64/python-letsencrypt_0.0.0.dev20151123-1.build2.log.gz
> 
>   Traitement des actions différées (« triggers ») pour libc-bin (2.21-1)...
>   FATAL: kernel too old
>   Segmentation fault
>   FATAL: kernel too old
>   Segmentation fault
>   dpkg: erreur de traitement du paquet libc-bin (--unpack)
> 
> Hrm.

wow.
Just looking at the error triggers no ideas to me... boooh

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


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