Re: [Reproducible-builds] Bug#806984: debian-installer: FTBFS: File not found:libtextwrap.so.1

[Cyril Brulebois]

Hi,

Val Lorentz  (2015-12-03):
> While working on the “reproducible builds” effort [1], we have noticed
> that debian-installer could not be built in some configurations.
> It could be an effect of any of the commands in [2], but it is likely to
> be the locale.
> 
> The attached file contains the full build logs.
> 
>  [1]: https://wiki.debian.org/ReproducibleBuilds
>  [2]:
> https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=reproducible/misc.git;a=blob;f=prebuilder/pbuilderhooks/A02_user;h=a3c8ceb9a4e5b0aa069e146bc50d3757d89a2e1f;hb=b012c16d7349a30b3c906851c171670abbced407
> 
> Regards,
> Valentin

Focusing on that part:

> Les NOUVEAUX paquets suivants seront installés :
>   acpi-modules-4.2.0-1-amd64-di alsa-utils-udeb anna archdetect
>   ata-modules-4.2.0-1-amd64-di bogl-bterm-udeb brltty-udeb busybox-udeb
>   cdebconf-gtk-terminal cdebconf-gtk-udeb cdebconf-newt-terminal
>   cdebconf-newt-udeb cdebconf-priority cdebconf-text-udeb cdebconf-udeb
>   cdrom-checker cdrom-core-modules-4.2.0-1-amd64-di cdrom-detect
>   cdrom-retriever console-setup-linux-fonts-udeb console-setup-pc-ekmap
>   console-setup-udeb core-modules-4.2.0-1-amd64-di
>   crc-modules-4.2.0-1-amd64-di di-utils di-utils-reboot di-utils-shell
>   di-utils-terminfo env-preseed espeak-data-udeb espeakup-udeb
>   event-modules-4.2.0-1-amd64-di fat-modules-4.2.0-1-amd64-di
>   fb-modules-4.2.0-1-amd64-di file-preseed
>   firewire-core-modules-4.2.0-1-amd64-di fontconfig-udeb fonts-android-udeb
>   fonts-farsiweb-udeb fonts-khmeros-udeb fonts-knda-udeb fonts-lao-udeb
>   fonts-lklug-sinhala-udeb fonts-lohit-guru-udeb fonts-mlym-udeb
>   fonts-sil-abyssinica-udeb fonts-sil-padauk-udeb fonts-taml-udeb
>   fonts-telu-udeb fonts-thai-tlwg-udeb fonts-tibetan-machine-udeb
>   fonts-ukij-uyghur-udeb gtk2-engines-udeb hw-detect
>   hyperv-modules-4.2.0-1-amd64-di i2c-modules-4.2.0-1-amd64-di initrd-preseed
>   input-modules-4.2.0-1-amd64-di installation-locale
>   isofs-modules-4.2.0-1-amd64-di kbd-udeb kernel-image-4.2.0-1-amd64-di
>   libasound2-udeb libatk1.0-udeb libblkid1-udeb libc6-udeb libcairo2-udeb
>   libdebconfclient0-udeb libdebian-installer4-udeb libdrm2-udeb libevdev2-udeb
>   libexpat1-udeb libffi6-udeb libfontenc1-udeb libfreetype6-udeb
>   libfribidi0-udeb libgdk-pixbuf2.0-0-udeb libglib2.0-udeb libgtk2.0-0-udeb
>   libharfbuzz0-udeb libkmod2-udeb libmtdev1-udeb libnss-dns-udeb
>   libnss-files-udeb libpango1.0-udeb libpciaccess0-udeb libpcre3-udeb
>   libpixman-1-0-udeb libpng12-0-udeb libslang2-udeb libtextwrap1-udeb
>   libudev1-udeb libuuid1-udeb libvte9-udeb libx11-6-udeb libxau6-udeb
>   libxcb1-udeb libxcursor1-udeb libxdmcp6-udeb libxext6-udeb libxfixes3-udeb
>   libxfont1-udeb libxft2-udeb libxi6-udeb libxinerama1-udeb libxkbfile1-udeb
>   libxrender1-udeb libxshmfence1-udeb load-cdrom localechooser lowmemcheck
>   main-menu media-retriever mmc-core-modules-4.2.0-1-amd64-di
>   mmc-modules-4.2.0-1-amd64-di mountmedia mouse-modules-4.2.0-1-amd64-di
>   nano-udeb pata-modules-4.2.0-1-amd64-di pciutils-udeb
>   pcmcia-modules-4.2.0-1-amd64-di pcmcia-storage-modules-4.2.0-1-amd64-di
>   pcmciautils-udeb preseed-common rescue-check rootskel rootskel-gtk
>   sata-modules-4.2.0-1-amd64-di save-logs scsi-common-modules-4.2.0-1-amd64-di
>   scsi-core-modules-4.2.0-1-amd64-di scsi-modules-4.2.0-1-amd64-di
>   serial-modules-4.2.0-1-amd64-di sound-modules-4.2.0-1-amd64-di
>   speakup-modules-4.2.0-1-amd64-di ttf-dejavu-mono-udeb ttf-dejavu-udeb
>   ttf-freefont-udeb udev-udeb udpkg uinput-modules-4.2.0-1-amd64-di
>   usb-modules-4.2.0-1-amd64-di usb-serial-modules-4.2.0-1-amd64-di
>   usb-storage-modules-4.2.0-1-amd64-di util-linux-udeb x11-xkb-utils-udeb
>   xkb-data-udeb xserver-xorg-core-udeb xserver-xorg-input-evdev-udeb
>   xserver-xorg-video-fbdev-udeb zlib1g-udeb

This list of packages is identical when building locally (with a regular
locale):

$ locale
LANG=en_GB.UTF-8
LANGUAGE=
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

(except mine is about NEW packages.)

> set -e; \
> oldsize=0; oldblocks=0; oldcount=0; for udeb in udebs/*.udeb ; do \
>   if [ -f "$udeb" ]; then \
>   pkg=`basename $udeb` ; \
>dpkg --force-overwrite --path-include='*' --log=/dev/null 
> --root=./tmp/cdrom_gtk/tree --unpack $udeb ; \
>   newsize=`du -bs ./tmp/cdrom_gtk/tree | awk '{print $1}'` ; \
>   newblocks=`du -s ./tmp/cdrom_gtk/tree | awk '{print $1}'` ; \
>   newcount=`find ./tmp/cdrom_gtk/tree -type f | wc -l | awk 
> '{print $1}'` ; \
>   usedsize=`echo $newsize - $oldsize | bc`; \
>   usedblocks=`echo $newblocks - $oldblocks | bc`; \
>   

[Reproducible-builds] Bug#806945: bash: Please make bash build reproducibly

[Maria Valentina Marin]

Source: bash
Version: 4.3-14
Severity: wishlist
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps

Hi,

While working on the “reproducible builds” effort [1], we have noticed
that bash could not be built reproducibly.

There are two problems:
1. Bash uses an embedded copy of man2html which produces html that
   contains timestamps, it is recommended to drop this internal copy and
   instead depend on the Debian man2html which contains a patch [4].

2. The pdf files created by dvipdfmx contain fonts with indeterministic
   order and naming [2]. This can be fixed by not generating the pdf in
   the first place as gnu codding standards makes pdf generation
   optional [3]. This has to be solved upstream.

Regards,
akira

 [1]: https://wiki.debian.org/ReproducibleBuilds
 [2]: 
https://reproducible.debian.net/issues/unstable/fonts_in_pdf_files_issue.html
 [3]: https://www.gnu.org/prep/standards/standards.html#Standard-Targets
 [4]: 
http://sources.debian.net/src/man2html/1.6g-8/debian/patches/035-source-date-epoch.patch/

___
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

[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

[Reproducible-builds] Bug#806974: xpra: please make the build reproducible

[Reiner Herrmann]

Source: xpra
Version: 0.15.8+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that xpra could not be built reproducibly.

The attached patch tells date to interpret the changelog date as UTC.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/buildinfo.patch b/debian/patches/buildinfo.patch
index d504895..9480189 100644
--- a/debian/patches/buildinfo.patch
+++ b/debian/patches/buildinfo.patch
@@ -31,8 +31,8 @@ Description: customise build info
 -set_prop(props, "BUILD_CPU", get_cpuinfo())
 +set_prop(props, "BUILT_BY", "Debian")
 +set_prop(props, "BUILT_ON", "Debian")
-+set_prop(props, "BUILD_DATE", subprocess.Popen("date --date=\"$(dpkg-parsechangelog -SDate)\" +%F", stdin=None, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True).stdout.read()[:-1])
-+set_prop(props, "BUILD_TIME", subprocess.Popen("date --date=\"$(dpkg-parsechangelog -SDate)\" +%R", stdin=None, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True).stdout.read()[:-1])
++set_prop(props, "BUILD_DATE", subprocess.Popen("date -u --date=\"$(dpkg-parsechangelog -SDate)\" +%F", stdin=None, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True).stdout.read()[:-1])
++set_prop(props, "BUILD_TIME", subprocess.Popen("date -u --date=\"$(dpkg-parsechangelog -SDate)\" +%R", stdin=None, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True).stdout.read()[:-1])
 +set_prop(props, "BUILD_CPU", "Generic CPU")
  set_prop(props, "BUILD_BIT", platform.architecture()[0])
  set_prop(props, "BUILD_OS", get_platform_name())
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] blacklist armhf: vxl qtbase-opensource-src

[Holger Levsen]

Hi Vagrant,

On Donnerstag, 3. Dezember 2015, Vagrant Cascadian wrote:
> Please (add to the growing) blacklist on armhf: vxl qtbase-opensource-src

done

> Both hit the 12 hour timeout at least once, and armhf is slow enough,
> and hasn't neared 100% enough to keep building these...

no need to justify things, I assume you know what you're doing :)


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] Bug#763822: ftp.debian.org: please include .buildinfo file in the archive

[Daniel Kahn Gillmor]

Hi there!

In https://bugs.debian.org/763822, lunar asked ftp.debian.org to accept
.buildinfo files when they are uploaded with a .changes file.

This is a followup to make the request concrete by specifying how we
hope the archive will sanity-check the included .buildinfo files, and
with a suggestion of how they could be distributed across the mirrors in
a way that will be reasonably convenient for users and downstreams
without making mirror operators crazy.

I'm writing this after discussions with Jelmer, Niels, Lunar, and others
involved in the Reproducible Builds project.

Constraints guiding the suggestions below
-

We want an archive user to be able to find and fetch all .buildinfo
files that produced a given binary package

We want the eventual possibility of multiple .buildinfo files per


We understsand that mirror operators don't like small files because
rsync gets fussy with them.

We want both buildds and debian developers to be able to upload
.buildinfo files.


Asks of ftp-master
--

We hope that the archive will verify .buildinfo files uploaded by
buildds and DDs or DMs.  We don't expect to require buildds or DDs or
DMs to upload .buildinfo files at this time, though we hope they'll
start to do so once the archive can accept them.

Here's how we think the archive might sanity-check them:

   * There may be 0 or more .buildinfo files included in a .changes
 file.  Each .buildinfo file describes an environment that was used
 to produce some of the binary artifacts (e.g. .deb, .udeb, etc) in
 this upload.

   * To validate each .buildinfo file:

 * ensure that the filename is of the form
   __.buildinfo where:
 *  matches the source name in the Source: field
 *  equals the Version: field
 *  is /[-a-z0-9]+/

 * ensure that this filename is not already in the archive.

 * the file should be clearsigned OpenPGP in UTF-8, with nothing
   outside the OpenPGP framing.  It should have a valid signature
   from the same OpenPGP key that signed the .changes file.

 * The signed part of the file must be a valid control file.

 * ensure that Source: and Version: fields in the .buildinfo
   matches the Source: and Version: fields in the .changes file.

 * the .buildinfo must include the same .dsc as the .changes file,
   with the same checksum.

 * in addition, the .buildinfo file should list at least one binary
   artifact.

 * for every binary artifact listed in the .buildinfo file:

* ensure that it is listed in the .changes file with the same
  checksum(s).  (fwiw, if anyone is concerned about minimizing
  the size of the .buildinfo file, there is no need to include
  the md5 or sha1 checksums of the artifacts. The
  Checksums-Sha256: sub-stanza is sufficient for our purposes)

If an included .buildinfo file doesn't validate, please reject the
entire upload.


Once an upload that includes some .buildinfo files is accepted, we want
users to be able to find the .buildinfo(s) for a binary package if they
want to try to reproduce it.

Here's a concrete suggestion for how to do that in a way that might not
make mirror operators sad (if you have a different or preferred
suggestion, that'd be great too):

* collect all .buildinfo files in the archive that produced binary
  artifacts for a given architecture in a tarball named Buildinfos.tgz
  which is distributed alongside Packages.  (for example,
  binary-amd64/Buildinfos.tgz and binary-all/Buildinfos.tgz).

* the structure of the tarball could be
  //__.buildinfo
  (with the same expansions as above)

* the gzip layer of the tarball should be --rsyncable

* When re-creating the Buildinfos.tgz file after some binary artifacts
  have been removed from a suite, any .buildinfo file that only
  references artifacts no longer in the suite can be removed.

Does this seem like a reasonable way to distribute this information?


Clarifications from original bug report
---

In the time since this bug was originally posted, we have a clearer
understanding of what a .buildinfo file represents, and how it can be
used.  For clarity and future documentation, i'll amend/nitpick a few
comments from the original text of the bug report below:

> .buildinfo files would capture from the build environment as much
> information as needed to reproduce the build.

The .buildinfo file *may* contain more information than is needed to
reproduce the build.  The goal is to have it provide enough of a record
of the build environment to be able to reproduce the build, but it's
also possible to include additional, unneeded information, and that's
OK.  (e.g. we are likely to include the exact version number of some
essential packages, even though going from coreutils 8.17-1 to 8.17-2 is
unlikely to affect the build).

>  * A .buildinfo file 

[Reproducible-builds] blacklist armhf: vxl qtbase-opensource-src

[Vagrant Cascadian]

Please (add to the growing) blacklist on armhf: vxl qtbase-opensource-src

Both hit the 12 hour timeout at least once, and armhf is slow enough,
and hasn't neared 100% enough to keep building these...

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