Re: [Reproducible-builds] Bug#806984: debian-installer: FTBFS: File not found:libtextwrap.so.1
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`; \ > usedcount=`echo $newcount - $
Re: [Reproducible-builds] Bug#763822: ftp.debian.org: please include .buildinfo file in the archive
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 is generated for each
Re: [Reproducible-builds] blacklist armhf: vxl qtbase-opensource-src
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
[Reproducible-builds] blacklist armhf: vxl qtbase-opensource-src
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
Re: [Reproducible-builds] Second build on failures
affects 806911 qa.debian.org thanks On 2015-12-03, Holger Levsen wrote: > 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. Thanks for pushing the workaround! >> 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…) 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 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... 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. Glad to hear athens is going well! 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#806974: xpra: please make the build reproducible
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
[Reproducible-builds] Bug#806945: bash: Please make bash build reproducibly
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
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