[Reproducible-builds] Second build on failures

[Vagrant Cascadian]

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


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.


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

[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

[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

Re: [Reproducible-builds] [pdftex] Please make the CreationDate, ModDate and ID field deterministic

[Akira Kakuto]

Dear Maria,


I was wondering what has happened with this proposal since I did not get
any reply since August.


Thanh applied your SOURCE_DATE_EPOCH patch on 18, August.

Thanks,
Akira Kakuto


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

[Reproducible-builds] Extended Deadline for 6th IEEE IACC2016

[IACC2016]

6th IEEE International Advance Computing Conference (IACC - 2016)

27-28 February 2016, S R K R Engineering College, Bhimavaram, Andhra
Pradesh, India

Dear Researchers,

 

Greetings!

 

The Last date for submitting the papers is extended to 7th December2015. 

 

Accepted and presented papers will be published in IEEE Xplore. The ISBN
number of IEEE Xplore for IACC 2016 is 978-1-4673-8285-4.  

 

 For a detailed list of topics please visit the conference website
 http://www.iacc2016.com

 

 

Looking forward to your participation,

Dr. M.S.V.S. Bhadri Raju,

General Co-Chair, IACC 2016

Professor in CSE
SRKR Engineering College

BHIMAVARM - 534204

Andhra Pradesh, India

 

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

Re: [Reproducible-builds] [pdftex] Please make the CreationDate, ModDate and ID field deterministic

[Maria Valentina Marin]

Hi,

I was wondering what has happened with this proposal since I did not get
any reply since August.

On 08/12/2015 01:08 PM, Maria Valentina Marin wrote:
> On 07/14/2015 12:39 AM, Karl Berry wrote:
>> Thanh is away for ~3 weeks.  He will review both the SOURCE_DATE_EPOCH
>> patch (which I suspect will be fine) and Nicolas's other comments when
>> he's back.
> 
> In addition to my patch to honour $SOURCE_DATE_EPOCH please find
> attached an additional patch which uses UTC in the printed timestamps to
> also make the timezone reproducible.
> 
> I have patched the function makepdftime to use gmtime if
> $SOURCE_DATE_EPOCH is set. Otherwise the old behaviour will be kept.
> 
> I have tested the patch in our autobuilders against 4 Debian packages
> that use pdflatex and these become reproducible.

Thanks!
akira

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