[Reproducible-builds] Bug#779963: debian-keyring: please make the build reproducible (part 2)
Package: debian-keyring Version: 2015.03.04 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 debian-keyring could not be built reproducibly. The attached patch removes timestamps from the build system. Once applied, debian-keyring can be built reproducibly in our current experimental framework. I'm sorry for this second bug, I hope we have not bothered you too much. [1]: https://wiki.debian.org/ReproducibleBuilds -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo diff -Nru debian-keyring-2015.03.04/debian/changelog debian-keyring-2015.03.04+nmu1/debian/changelog --- debian-keyring-2015.03.04/debian/changelog 2015-03-04 16:22:02.0 +0100 +++ debian-keyring-2015.03.04+nmu1/debian/changelog 2015-03-06 22:20:17.0 +0100 @@ -1,3 +1,10 @@ +debian-keyring (2015.03.04+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Really made the package build reproducible. + + -- Mattia Rizzolo mat...@mapreri.org Fri, 06 Mar 2015 22:20:01 +0100 + debian-keyring (2015.03.04) unstable; urgency=medium [ Gunnar Wolf ] diff -Nru debian-keyring-2015.03.04/debian/rules debian-keyring-2015.03.04+nmu1/debian/rules --- debian-keyring-2015.03.04/debian/rules 2015-03-04 16:22:02.0 +0100 +++ debian-keyring-2015.03.04+nmu1/debian/rules 2015-03-06 22:19:54.0 +0100 @@ -9,6 +9,8 @@ # paternity under the Copyright, Designs and Patents Act 1988.) # This file may have to be extensively modified +BUILD_DATE := $(shell dpkg-parsechangelog --show-field Date) + install_dir=install -d -m 755 install_file=install -m 644 install_script=install -m 755 @@ -53,6 +55,9 @@ cd debian/tmp find . -type f ! -regex '.*DEBIAN/.*' -printf '%P\0' | xargs -r0 md5sum DEBIAN/md5sums + find debian/tmp -depth -newermt '$(BUILD_DATE)' -print0 | \ + xargs -0r touch --no-dereference --date='$(BUILD_DATE)' + dpkg --build debian/tmp .. binary-arch: 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] Missing dependencies aren't actually missing
On Mon, Mar 02, 2015 at 08:42:32AM -0800, Nikolaus Rath wrote: On Mar 01 2015, Mattia Rizzolo mat...@mapreri.org wrote: On Sun, Mar 01, 2015 at 12:04:13PM -0800, Nikolaus Rath wrote: On Mar 01 2015, Mattia Rizzolo mattia-p8aev1vil9rafugrpc6...@public.gmane.org wrote: On Sat, Feb 28, 2015 at 09:59:01PM -0800, Nikolaus Rath wrote: https://reproducible.debian.net/rb-pkg/s3ql.html claims that S3QL has We performed a rebuild, and your package still FTBFS. This time it looks like it fails at a test with the error dugong.ConnectionClosed: connection closed unexpectedly which is quite nasty at the sight (I don't know what that means). Does this mean that the package tries to connect to the internet? No, it should not. It opens its own mock server on localhost using the any available port. Are you sure about the any available port part? Almost certain. I could be certain if I could see the log with the failed test, but it seems that port 80 on reproducible.debian.net is down at the moment: $weird_things_happen again. https://reproducible.debian.net/rbuild/sid/amd64/s3ql_2.13+dfsg-1.rbuild.log not sure what's wrong at that time. -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo 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] Missing dependencies aren't actually missing
On Sun, Mar 01, 2015 at 12:04:13PM -0800, Nikolaus Rath wrote: On Mar 01 2015, Mattia Rizzolo mattia-p8aev1vil9rafugrpc6...@public.gmane.org wrote: On Sat, Feb 28, 2015 at 09:59:01PM -0800, Nikolaus Rath wrote: https://reproducible.debian.net/rb-pkg/s3ql.html claims that S3QL has We performed a rebuild, and your package still FTBFS. This time it looks like it fails at a test with the error dugong.ConnectionClosed: connection closed unexpectedly which is quite nasty at the sight (I don't know what that means). Does this mean that the package tries to connect to the internet? No, it should not. It opens its own mock server on localhost using the any available port. Are you sure about the any available port part? 8080 is a common port for whatever, I'd not be surprised. Holger, apart from jenkins' and squid's, what others uncommon ports are busy? Any chance this is also due to $weird_things? Both the reguphinxar unstable build and the last ci test from two days ago with don't have that problem (cf. http://ci.debian.net/packages/s/s3ql/unstable/amd64/). Anyway, I performed a local build and this is what debbindiff outputs: http://volatile.mapreri.org/2015-03-01/b46eb200e612629e11c7b6a1c925da36/s3ql.dbd.html e.g. timestamps in sphinx docs. -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo 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
[Reproducible-builds] Bug#781280: Bug#781280: --text crashes when encountering empty files
control: tag -1 pending On Thu, Mar 26, 2015 at 9:43 PM, Helmut Grohne hel...@subdivi.de wrote: Package: debbindiff Version: 11 Tags: patch debbindiff --text crashes when it encounters an empty file. Thanks for the patch, merged correcting a typo and committed to git. -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#782415: the package build-depends on mkdocs, which is a virtual package
Source: djangorestframework Version: 3.0.5-0.2 Severity: important X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org,b...@debian.org [CCing the NMUer] Dear maintainer, the current package in experimental could not be built due to the package build-depending on mkdocs. pbuilder and sbuild swear it is a virutal package, though a grep of mine trough /var/lib/apt/lists of 'mkdocs' just fails. whatever the cause (virtual package or non-existing package), this is a issue. FTR, I found this while working on the “reproducible builds” effort [1] [1]: https://wiki.debian.org/ReproducibleBuilds Thanks for maintaining djangorestframework -- 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: 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] Bug#783882: jodconverter: please make the build reproducible
[removing the bug from the recipients list...] On Fri, May 1, 2015 at 1:36 PM, Reiner Herrmann rei...@reiner-h.de wrote: On 05/01/2015 11:30 AM, Holger Levsen wrote: That said, according to https://wiki.debian.org/ReproducibleBuilds/TimestampsInDocumentationGeneratedByJavadoc strip-nondeterminism should work around the issue too, anyone got an idea why this doesnt happen? jodconverter uses neither dh, nor cdbs, so strip-nondeterminism is not called. you said you think not many packages call javadoc directly, and javahelper now passes -notimestamps. Do we know how many affected packages strip-nondeterminism fixes? maybe is the case to remove that code from strip-nondeterminism and fix the remaining packages? -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#782253: debbindiff left temporary directories under /tmp when it crashes
Package: debbindiff Version: 15 Severity: normal debbindiff creates temporary directory under /tmp, but when it crashes it does not have chances to cleanup. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armel, armhf, s390x Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debbindiff depends on: ii python 2.7.9-1 ii python-debian 0.1.26 ii python-magic 1:5.22+15-2 ii python-rpm 4.11.3-1.1 Versions of packages debbindiff recommends: ii acl 2.2.52-2 ii binutils-multiarch 2.25-6 ii bzip2 1.0.6-7+b3 ii cpio2.11+dfsg-4.1 ii file1:5.22+15-2 ii fontforge-extras0.3-4 ii gettext 0.19.3-2 ii ghc 7.6.3-21 ii gnupg 1.4.18-7 ii pdftk 2.02-2 ii poppler-utils 0.26.5-2 ii rpm2cpio4.11.3-1.1 ii sng 1.0.2-7 ii squashfs-tools 1:4.2+20130409-2 ii unzip 6.0-16 ii vim-common 2:7.4.488-7 ii xz-utils5.1.1alpha+20120614-2+b3 debbindiff suggests no packages. -- no debconf information -- 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: Digital 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:#775362: ergo: FTBFS when higly parallelized: test suite fails+hangs
control: tags -1 - patch control: retitle -1 ergo: FTBFS when higly parallelized: test suite fails+hangs control: user reproducible-builds@lists.alioth.debian.org control: usertag -1 cpu I noted this while working for the reproducible builds project [0], where we built ergo with parallel=23. This is an extract of the build log: make check-TESTS make[4]: Entering directory '/tmp/buildd/ergo-3.4.0/test' make[5]: Entering directory '/tmp/buildd/ergo-3.4.0/test' FAIL: test_hf_blsz2.sh FAIL: test_hf_blsz1.sh FAIL: test_uhf.sh FAIL: test_6_d_funcs.sh PASS: test_hf_fd.sh FAIL: test_dft_hicu.sh FAIL: test_dft_sparse.sh FAIL: test_lr_exc_hf.sh PASS: test_ghost.sh PASS: test_lowacc.sh PASS: test_extracharges.sh FAIL: test_mixedbasis.sh PASS: test_fmm_b3lyp.sh PASS: test_ci.sh PASS: test_dipole_moment.sh PASS: test_dft_hybrid.sh PASS: test_roks.sh PASS: test_fmm_camb3lyp.sh PASS: test_fmm.sh PASS: test_ext_elec_field.sh PASS: test_dft_pure.sh PASS: test_hf.sh PASS: test_gradient.sh FAIL: test_tdhf_dynamics.sh Terminated Mon Apr 6 14:03:53 UTC 2015 - /srv/jenkins/bin/reproducible_build.sh stopped running as /tmp/jenkins-script-En1spHPa, which will now be removed. Mon Apr 6 14:03:53 UTC 2015 - /srv/jenkins/bin/reproducible_build.sh stopped running as /tmp/jenkins-script-En1spHPa, which will now be removed. Build was aborted Considering that the build started at Sun Apr 5 16:50:50 UTC 2015 (nearly 21 hours!) I think the build as hanged. you can see the full build log at https://jenkins.debian.net/view/edu_devel/job/reproducible_builder_zeta/2867/console [0] https://wiki.debian.org/ReproducibleBuilds -- 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: 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] Bug#786695: inn2 ftbfs: sh: 1: cannot create DEBIAN/md5sums: Directory nonexistent
On Sun, May 24, 2015 at 03:44:21PM +0200, Holger Levsen wrote: While working on the “reproducible builds” effort [1], I have noticed that inn2 fails to build from source in this setup (using pbuilder on wheezy) while it builds on my laptop (also using pbuilder on wheezy). And the failure is rather strange: dh_installdeb dh_md5sums sh: 1: cannot create DEBIAN/md5sums: Directory nonexistent dh_md5sums: (cd debian/.debhelper/inn2/ddeb-root /dev/null ; find . -type f ! -regex './DEBIAN/.*' -printf '%P\0' | LC_ALL=C sort -z | xargs -r0 md5sum DEBIAN/md5sums) /dev/null returned exit code 2 debian/rules:193: recipe for target 'install5' failed make: *** [install5] Error 2 The full log is at https://reproducible.debian.net/rbuild/unstable/amd64/inn2_2.5.4-3.rbuild.log At the moment I'm a bit clueless where this bug comes from (and whether inn2 is buggy or something on jenkins.d.n), help welcome! Turned out it was a bug in our patched debhelper. Fixed now. Now inn2 builds fine and reproducibly! Sorry for the noise! -- 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: Digital 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#790102: subversion fails to build with -Wdate-time in CPPFLAGS
Source: subversion,unbound,swig Severity: wishlist User: reproducible-builds@lists.alioth.debian.org Usertags: toolchain x-debbugs-cc: reproducible-builds@lists.alioth.debian.org Hi subversion, unbound and swig maintainers, we in the Reproducible Builds effort use a non default dpkg which export -Wdate-time through dpkg-buildflags. There are package that pass CPPFLAGS (for example) quite unchanged to swig. Sadly swig does not recognize -Wdate-time and choke and fail on it badly, e.g. /usr/bin/swig -I. -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/python2.7 -I/usr/include/python2.7 -o pythonmod/interface.h -python ./pythonmod/interface.i swig error : Unrecognized option -Wdate-time Use 'swig -help' for available options. Makefile:369: recipe for target 'pythonmod/interface.h' failed make[1]: *** [pythonmod/interface.h] Error 1 Needless to say, I'd like to build those packages with such flag (that we also would like to get into the default set, see the bug #762683 for a start). Possible solutions i see for this: a. swig stops failing so badly on unrecognized options. If you really want to validate the options at least stop failing on unrecognized -W? Seems quite logical to pass CPPFLAGS to swig to me, and as such sounds sane b. people stop passing CPPFLAGS to swig. I've already saw a CPPFLAGS cleaner on subversion's configure script. Please I don't want to see another Even if I do have preference I don't have a strong opinion on this, so if you agree this is not a bug in swig (which I could even accept, given that the accepted flags are well documented), I'll just clone+reassign this bug around. Thanks for maintaining such packages! -- 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: Digital 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#790103: FTBFS if CPPFLAGS contains -Wdate-time
Source: expeyes Version: 3.4.0-1 Severity: wishlist User: reproducible-builds@lists.alioth.debian.org Usertag: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Hi expeyes maintainer, Your package currently fails to build in the reproducible build env due to it passing -Wdate-time to avr-gcc. You can see a full (double) build log on https://reproducible.debian.net/rbuild/unstable/amd64/expeyes_3.4.0-1.rbuild.log I'm not sure whether the bug is in your package passing something random over gcc-avr or due to it not groking it correctly. If that's the case please just reassing the bug to gcc-avr. Thanks for maintaining expeyes! -- 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: 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] Undelivered Mail Returned to Sender
On Thu, May 28, 2015 at 05:55:07PM +, Mail Delivery System wrote: This is the mail system at host jenkins.debian.net. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. I'm so sorry. This was meant to be a test for a new feature of rb.d.n. But i can't do anything without typoing things (like pckages instead of packages this time) :) FYI, the second test went well ^^ For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system licenseut...@pckages.debian.org: Host or domain name not found. Name service error for name=pckages.debian.org type=: Host not found Reporting-MTA: dns; jenkins.debian.net X-Postfix-Queue-ID: D9E251EFD1 X-Postfix-Sender: rfc822; reproducible-builds@lists.alioth.debian.org Arrival-Date: Thu, 28 May 2015 17:55:07 + (UTC) Final-Recipient: rfc822; licenseut...@pckages.debian.org Action: failed Status: 5.4.4 Diagnostic-Code: X-Postfix; Host or domain name not found. Name service error for name=pckages.debian.org type=: Host not found Date: Thu, 28 May 2015 17:55:07 + (UTC) From: reproducible-builds@lists.alioth.debian.org To: licenseut...@pckages.debian.org Subject: test email for rep team X-Mailer: mail (GNU Mailutils 2.99.97) test email ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds -- 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: 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] Bug#790844: probably caused by timezone changes
On Sat, Jul 04, 2015 at 05:21:01PM +0200, Alexandre Detiste wrote: thanks for caring about reproducible builds and filing bugs against your own packages! :-) I got conviced (and a bit entertained) by the talk at FOSDEM ;-) ;D I think that Mattia's guess was closer: eheh, that was really a guess! /me goes making some bets Quite some FTBFS on our infrastructure are do to us using DEB_BUILD_OPTIONS=parallel=23 (e.g. very high) and some packages not coping fine with it. I finally found ou the likely cause: 'install' target in Makefile.in is split in tiny chunks. I didn't look at any way at the package other than the build log. I don't know if it still make any sense, this was already done that way before the SVN - Git transition from 2005, and I'm maintaining this for less than a year. install : install1 install11 install2 installdirs cruft If 'install11' run before 'intall1'; it fails. Adding a simple sleep 0.1at the top of intall1 always trigger an error in install11. Adding an extra mkdir -p $(DESTDIR)/usr/lib/cruft/ fix this permanently (?) https://github.com/a-detiste/cruft/commit/4e8a48999bd1c77c0d902c803f4151f3c09f471a well, maybe if they are too tiny even mergning them can make sense To achieve reproducibility you will also need to normalize the timezone during build (eg set TZ=UTC) or wait til debhelper does this for you. All the previous run that didn't FTBFS were reproducible; are there any other changes needed ? umh, indeed. Holger? -- 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: Digital 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#791435: The dropped transitive packages libgd2-{xpm, noxmp}-dev are still used by other packages
Source: libgd2
Version: 2.1.1-2
Severity: serious
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs toolchain
[serious because breaks other package builds without a good reason]
Dear maintainer,
the 2.1.1-2 changelog reads:
* Drop libgd2-{xpm,noxmp}-dev dummy packages
though there are still packages (build-)depending on them.
I see no bugs against those packages asking for changing such build-dep (I
chkecked only a handful of them), and as such now those packages can't be built
anymore.
Please add at least a Provides: so that package can continue using such
transitive packages and open a bug against them asking for such change.
Following there is what the daily cruft report reports, you can find some more
with grep-dctrl since there are packages with such build-dep masked by an
alternative.
* source package libgd2 version 2.1.1-2 no longer builds
binary package(s): libgd2-noxpm-dev libgd2-xpm-dev
on
amd64,arm64,armel,armhf,hurd-i386,i386,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,ppc64el,s390x,sparc
- suggested command:
dak rm -m [auto-cruft] NBS (no longer built by libgd2) -s unstable -a
amd64,arm64,armel,armhf,hurd-i386,i386,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,ppc64el,s390x,sparc
-p -R -b libgd2-noxpm-dev libgd2-xpm-dev
- broken Depends:
haskell-gd: libghc-gd-dev [sparc]
- broken Build-Depends:
analog: libgd2-noxpm-dev (= 2.0.1-18)
apcupsd: libgd2-noxpm-dev
awffull: libgd2-xpm-dev |libgd2-noxpm-dev
cvsgraph: libgd2-noxpm-dev |libgd2-xpm-dev
dvipng: libgd2-noxpm-dev
embassy-domainatrix: libgd2-xpm-dev
embassy-domalign: libgd2-xpm-dev
embassy-domsearch: libgd2-xpm-dev
embassy-phylip/non-free: libgd2-xpm-dev
falconpl: libgd2-xpm-dev
fceux: libgd2-xpm-dev
fsl/non-free: libgd2-noxpm-dev (= 2.0.33) |libgd2-xpm-dev (= 2.0.33)
fswebcam: libgd2-noxpm-dev |libgd2-xpm-dev
grads: libgd2-xpm-dev
graphviz: libgd2-noxpm-dev (= 2.0.35)
haskell-gd: libgd2-xpm-dev
lcd4linux: libgd2-xpm-dev
libgdchart-gd2: libgd2-noxpm-dev ( 2.0.28)
libgphoto2: libgd2-xpm-dev
libpst: libgd2-noxpm-dev |libgd2-xpm-dev
libpuzzle: libgd2-noxpm-dev
libpwiz: libgd2-xpm-dev (= 2.0.35)
mldonkey: libgd2-xpm-dev
mrtg: libgd2-noxpm-dev
nagios3: libgd2-noxpm-dev (= 2.0.1) |libgd2-xpm-dev (= 2.0.1)
ntop: libgd2-noxpm-dev
oggvideotools: libgd2-xpm-dev
osmium: libgd2-xpm-dev
pdl: libgd2-xpm-dev
php-ps: libgd2-xpm-dev ( 2.0.0)
ploticus: libgd2-noxpm-dev
plplot: libgd2-noxpm-dev |libgd2-xpm-dev
png2html: libgd2-noxpm-dev
polybori: libgd2-xpm-dev
pygdchart2: libgd2-noxpm-dev |libgd2-xpm-dev
sarg: libgd2-noxpm-dev |libgd2-xpm-dev
webdruid: libgd2-noxpm-dev
wims: libgd2-xpm-dev |libgd2-noxpm-dev
--
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: 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] debug-sym packages?
On Mon, May 25, 2015 at 11:19:14AM +0200, Joachim Breitner wrote: Hi, Hi there! Why does it build ghc-dbgsym at all? I do not define that in debian/rules. And https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain does not mention a change in that direction either. We use the patched version of debhelper that builds .ddeb packages. That for either test debhelper at generating them and (TTBMK) helped understanding some differences (given that it contains some informations that would have been stripped otherwise). Also, is there any way to find out for what binary this debug file is? Or would it be visible if readelf would not fail on these files? you can use the build-id. The differences in that file comes from ./usr/lib/ghc/unix_G4Yo1pNtYrk8nCq1cx8P9d/libHSunix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d-ghc7.10.1.so -- 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: Digital 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#796196: strip .py suffix from diffoscope within sources repo as well)
On Thu, Aug 20, 2015 at 07:59:50AM -0400, Yaroslav Halchenko wrote: On Thu, 20 Aug 2015, Mattia Rizzolo wrote: ignore the patch I have submitted (done in a rush, incorrect). But what about the idea in general? Umh, but why? Shipped package does not have .py. Also, why should we move the script to an another directory? (and then we would need to set PYTHONPATH to be able to do anything…) Can you elaborate on your rationale? Sure! 1. debian policy on not having suffix is not really Debian-specific -- it is a general recommendation. In your case diffoscope as utility could later be rewritten in some other language etc, which would then reflect itself in changing the suffix That thing relates to the installed binary, and indeed we do not have a suffix in the /usr/bin/diffoscope file name. The git repository is something for the development, and the development of diffoscope depends on the current implementation. 2. There is now a dichotomy between how diffoscope should be executed as installed from debian package (without suffix) and then if someone installs it using setup.py (with the suffix) or just reading your documentation (e.g. README) This to my experience is normal development. stuff in a VCS tends to be a bit different than installed one. The README tells about how to use it out of the vcs clone. I do appreciate though the fact that with such a change and relocation setting of PYTHONPATH is necessary if someone wants to invoke diffoscope without e.g. 'python setup.py develop' (ideally within a virtualenv). Within fail2ban we even made some ugly workaround for such invocations, e.g. if os.path.exists(diffoscope/__init__.py): sys.path.insert(0, .) so someone could invoke directly within source code-base. This is currently really possible and easy to do, just `./diffoscope.py ...`. Alternative to all of the above could be moving that script entirely under diffoscope/ module codebase and just establishing entry points with setuptools' setup() call. E.g. how we do in e.g. datalad https://github.com/datalad/datalad/blob/master/setup.py#L30 which would then allow you to craft a test to verify functionality of the code in the script. The current structure seems really sensible and sane to me, while I wouldn't understand having the program entry point inside the module. Anyways -- decision is yours to make ;) To me your proposals makes really little sense. But let's wait for the main developer to show up :) -- 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: 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] SOURCE_DATE_EPOCH specification document
On Sat, Aug 22, 2015 at 01:15:05PM +0100, Chris Lamb wrote:
Hi all,
After a hint from doko, I've started work on an official-looking spec
for SOURCE_DATE_EPOCH and pushed it to source-date-epoch-spec.git on
Alioth. I've loosely based it on the look and feel of FreeDesktop.org
specs in case they are familiar to you.
I plan to dump the rest of what's in my head today (depending on the
level of sun) but other contributions are, of course, welcome.
great.
So, where should we push it?
Lamby pointed out that this is not something debian-related, so it would be
great to have it outsite a debian.{org,net} site.
OTOH also the howto is not strictly debian-related, and both documents are
related to reproducibly.
My personal proposal is to merge the two documents and move them to a new more
meaningful url (under rb.d.n).
--
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: 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] Reproducible debootstrap
On Thu, Aug 20, 2015 at 10:00:04PM -0400, Chris Lamb wrote:
Hi,
Got a bit curious and wondered just what it would take to make the output of
debootstrap reproducible. Just two simple invokations and I only get the
following differences:
* {m,a}times varying over the entire tree
* /etc/machine-id (systemd!)
* /var/cache/ldconfig/aux-cache (probably trivially deletable?)
* /var/log/{alternatives,bootstrap,dpkg}.log (hmm..)
Also see https://wiki.debian.org/ReproducibleInstalls
There is also a todo entry to add this test on jenkins, if somebody wants to
pick it up :)
--
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: 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] python-requirements-detector: FTBFS in reproducible builds CI
On Tue, Jun 30, 2015 at 03:09:08PM +0200, Daniel Stender wrote: Hi, Hi there! :D for the new python-requirements-detector I've got a UnicodeDecodeError in the tests against Python 3.4 [1] from reproducible builds CI [2]. That usually points to the locale set to some non-UTF-8 (like C), but which isn't the case here? Yes, the first build is not done in a unicode (like en_US.utf-8). Actually the locale is not set at all. In fact I can get the very same error in my pbuilder on my notebook. I saw somewhere (I don't really recall where/when) that something without any locale setted picked up something near the standard C locale in situation like that. The second build (which your package didn't even reached) is run with LC_ALL=fr_CH.UTF-8 instead. Thanks for hints, You're welcome, again thanks for caring! :) You are also welcome to join us on IRC, #debian-reproducible @ OFTC [1] https://bugs.debian.org/790569 Thats, eh, wow! Really, no need for such an high severity. We somehow builds stuff in weird environments, not (yet) required by policy or the like. Though, your call, and we're happy maintainers care about our project! -- 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: 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] Too many repreoducible build emails? (was Re: [Pkg-haskell-maintainers] haskell-mime-mail status changed: reproducible - FTBFS)
On Tue, Jun 30, 2015 at 10:19:31AM +0100, Iain Lane wrote: The Haskell team seems to get a *lot* of these emails, since it tends to be that many of our packages change state (e.g. to and from FTBFS or get fixed/broken) at the same time. I also wonder how many (I don't dare checking!) email you got the last two days after the ghc 7.8 migration :) I wonder if the emails could be consolidated so that you, for example, send a maximum of one mail per maintainer per day with all of the collated status changes from that period? oh, I've never thought about that. IMHO that could be a great idea! Take the status changes happened in the last 24 hours and sending them out daily for the packages that required such notification. We already save the build history, so that is a matter of writing some valuable SQL queries. Not really sure when I can look at it, probably by the end of the week, hoping you won't get too bothered by that time :) -- 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: 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] b-d recommends
On Fri, Jul 31, 2015 at 12:56:32PM +0200, Holger Levsen wrote: Hi Clint, On Freitag, 31. Juli 2015, Clint Adams wrote: I suggest comparing builds with and without the Recommends of the Build-Depends installed. I think thats out of scope for our project currently: buildds don't install recommends, so we also don't install them. I agree. We already vary a lot of stuff between builds, and soon we'll vary even more (the date). For what I'm concerned we should defer more variation once more patches land in the archive It's probably still worthwhile testing this, but IMO probably rather as a one time whole archive rebuild. If the point is finding out whether the package FTBFS or not I suggest looking at https://wiki.debian.org/qa.debian.org/ArchiveTesting (even if the results are presented in a less shiny format than ours) btw, where are these fields defined? I couldn't find Build-Recommends: in https://www.debian.org/doc/debian-policy/ch-relationships.html ? I believe he means with APT::Install-Recommends=true and false on the host. -- 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: 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] Notifications for Reproducible Builds
On Tue, Aug 11, 2015 at 10:04:57AM -0500, Kenneth Pronovici wrote: On Fri, Aug 7, 2015 at 10:02 AM, Kenneth Pronovici prono...@debian.org wrote: On Thu, Aug 6, 2015 at 4:45 PM, Mattia Rizzolo mat...@mapreri.org wrote: On Wed, Aug 05, 2015 at 02:51:39PM -0500, Kenneth Pronovici wrote: cedar-backup3 (sitting in NEW queue) can't currently add package which are not in the archive, sorry. but do feel free to poke us once it passes! Understood. This hit the archive yesterday. Could you please add it? mattia@jenkins ~ % sudo -u jenkins /srv/jenkins/bin/reproducible_setup_notify.py -p cedar-backup3 INFO: Starting at 2015-08-11 16:24:10.049163 INFO: finding out which usertagged bugs have been closed or at least have patches INFO: Activating notification for package cedar-backup3 INFO: Packages with notification enabled now available at https://reproducible.debian.net/index_notify.html INFO: Notifications enabled for 1 package(s) INFO: Finished at 2015-08-11 16:24:12.713296, took: 0:00:02.664153 mattia@jenkins ~ % Thanks! enjoy! :D -- 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: 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] Notifications for Reproducible Builds
[ keeping you in To since i don't see you in the subscriber list] On Wed, Aug 05, 2015 at 02:51:39PM -0500, Kenneth Pronovici wrote: Hi, Hi there, thanks for contacting us! I was poking around (https://reproducible.debian.net/index_notify.html) and realized that I can get notifications if/when my packages change state. Could you please enable notifications? My packages are: cedar-backup2 cedar-backup3 (sitting in NEW queue) can't currently add package which are not in the archive, sorry. but do feel free to poke us once it passes! cproto epydoc gtml ncompress pychecker This seems to be team maintained by the DPAT, i don't know whether they are ok (at least, i saw no thread whatsoever in d-python), so i'd rather avoid enabling notification for this. Just FYI, we mail $p...@packages.debian.org, which (ttbomk) forwards both to the maintainer listed in the package and to $pkg_cont...@packages.qa.debian.org (or without _contanct, not sure right now, whathever) (that's the contact keyword of the PTS, the PTS in turns forwards to @tracker.debian.org \o/ semplicity), so the d-python ML would receive notification mails for your package, not sure whether they are welcomed or not. BTW, we already received a proposal to add a reproducible keywork in the PTS, which would have several advantages. sopwith I insteaad ran: mattia@jenkins ~ % sudo -u jenkins /srv/jenkins/bin/reproducible_setup_notify.py -m prono...@debian.org INFO: Starting at 2015-08-06 21:34:17.823094 INFO: finding out which usertagged bugs have been closed or at least have patches INFO: Packages maintained by prono...@debian.org: INFO: cedar-backup2, cproto, epydoc, gtml, ncompress, sopwith INFO: Activating notification for package cedar-backup2 INFO: Activating notification for package cproto INFO: Activating notification for package epydoc INFO: Activating notification for package gtml INFO: Activating notification for package ncompress INFO: Activating notification for package sopwith INFO: Packages with notification enabled now available at https://reproducible.debian.net/index_notify.html INFO: Notifications enabled for 6 package(s) INFO: Finished at 2015-08-06 21:34:24.492975, took: 0:00:06.669906 mattia@jenkins ~ % :) I believe all of these except ncompress are reproducible already. I uploaded changes to ncompress today which should make v4.2.4.4-12 reproducible cool! please tell us whatever doubt you might have about whatever and improvments to our infrastructure you might see! :) -- 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: Digital 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#788568: Bug#788568: Bug#788568: Bug#788568: still there?
On Fri, Jul 24, 2015 at 07:41:30PM +0200, Holger Levsen wrote: On Freitag, 24. Juli 2015, Mattia Rizzolo wrote: you won't find anything on /tmp because we set TMPDIR on the debbindiff call to a the temporary directory we delete just after the build. do we delete this TMPDIR also when we notify about the problem and ask for debugging it? If so we should either stop deleting it or drop the notification. (And if not, what happens to those temp dirs?) actually we don't, and in the past you could see what was left in the artifacts directory.. I'm not sure why this time there is none. Though for us is not a problem anymore /tmp, it's still for our user. I renamed the bug title to reflect the current+real problem. cool, thanks! [erm... re-reading my sentence above i see how awful it is :\ sorry] -- 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: Digital 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#788568: Bug#788568: still there?
Control: retitle -1 debbindiff: cleanup the temporary dir after SIGTERM On Fri, Jul 24, 2015 at 06:41:37PM +0200, Holger Levsen wrote: Hi, upon seeing this: [18:37] - KGB-2- | (#debian-reproducible) debbindiff calls on https://reproducible.debian.net/unstable/amd64/icedove or https://jenkins.debian.net/job/reproducible_builder_epsilon/21466/console left cruft, please help investigate and fix 788568 [18:39] - KGB-2- | (#debian-reproducible) https://reproducible.debian.net/artifacts/r00t-me/icedove_unstable_tmp-5QgiE/ published, debbindiff 26 had troubles with these... I checked /tmp and found nothing related: root@jenkins:~# find /tmp -maxdepth 1 -name tmp*debbindiff | xargs ls -ld drwx-- 15 root root 12288 Jul 20 13:33 . root@jenkins:~# So I wonder if this bug can be closed and the irc notification turned off? Yes, it's still there. you won't find anything on /tmp because we set TMPDIR on the debbindiff call to a the temporary directory we delete just after the build. Though for us is not a problem anymore /tmp, it's still for our user. I renamed the bug title to reflect the current+real problem. -- 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: 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] GSoC 2015 Week 9: Move forward reproducible builds
On Sat, Jul 25, 2015 at 05:24:50PM +0200, Holger Levsen wrote: On Samstag, 25. Juli 2015, Dhole wrote: [...] I have also uploaded the package in our APT repository. [...] For next week I plan to send the ghostscript patches to debian and probably upstream[...] I'm aware that some people only want to file bugs with working and verified patches and that uploading to our repo is a good way to achieve that, but at the same time I'm worried that such work might get lost if no tracking bug is filed from the start... Or do you (all) think it's enough to track such work via patches in a git repo? (And then file a bug once the patch is ready - and should the driving person of this go MIA we will notice and have the git repo?!?) I do believe that testing the patches before sending out the bug is somehow important. As we have this awesome policy to strive to attach patches to bugs from us i very like it, and as a maintainer I'd really prefer getting a single email with patch than several with maybe days between. IMO the better approach would be: 1) working on it and get a patch 2) test it out (uploading to our repo + schedule something is good+enough) 3) if that works fine go ahead, otherwise back to point 1. 4) file a bug (always file it in the debian BTS) 5) edit the package our repos to add the bug # to the patch header (see DEP-3) and the changelog entry As i seen it this usually takes few days to go from 1 to 5, imho we don't risk too much to lost track of it. and anyway looks like some of us ciclely look at our repo state farly often. Another option would be to file a tracking bug against qa.d.o (usertagged reproducible.d.n) for patch development + tracking...?!? nah, that would annoy people on -qa@ who are not interested in reproducible stuff, for a start. Holger, who really loves bug #s but maybe a bit too much... ;-) ;) Be assured, I agree that once we have something on our hands attaching it to a bug is a must! :) -- 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: Digital 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#792591: prettytable: FTBFS when locale-all is installed instead of locales
Source: prettytable Version: 0.7.2-3 Severity: normal User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs Dear maintainer, Your package fails to build from source if locale-all is installed instead of locales. locale-all actually satisfy the build-dependecy on locales since it Provides:locales, even if it does not provide all the files the real locales packages has. This is also a bug in locale-all, that is tracked in #788352, but we also asked the affected packages to Build-Conflicts on locale-all, please follow that bug too see other examples. Thanks for maintaining prettytable! -- 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: Digital 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#792589: python-geopandas: FTBFS: E: pybuild pybuild:256: test: plugin distutils failed with: exit code=139: cd /tmp/buildd/python-geopandas-0.1.1/.pybuild/pythonX.Y_3.4/build
Source: python-geopandas
Version: 0.1.1-1
Severity: important
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Dear maintainer,
your package FTBFS as follow:
make[1]: Leaving directory '/tmp/buildd/python-geopandas-0.1.1'
dh_auto_test -O--buildsystem=pybuild
pybuild --test -i python{version} -p 2.7 --dir .
I: pybuild base:170: cd
/tmp/buildd/python-geopandas-0.1.1/.pybuild/pythonX.Y_2.7/build; python2.7 -m
pytest tests -k not test_geocode
= test session starts ==
platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.7.2
rootdir: /tmp/buildd/python-geopandas-0.1.1, inifile:
collected 102 items
tests/test_geodataframe.py ...ss.
tests/test_geom_methods.py
tests/test_geoseries.py
tests/test_io.py .ss
tests/test_plotting.py ...
tests/test_types.py
== 6 tests deselected by '-knot test_geocode' ==
= 92 passed, 4 skipped, 6 deselected in 16.96 seconds ==
pybuild --test -i python{version} -p 3.4 --dir .
I: pybuild base:170: cd
/tmp/buildd/python-geopandas-0.1.1/.pybuild/pythonX.Y_3.4/build; python3.4 -m
pytest tests -k not test_geocode
= test session starts ==
platform linux -- Python 3.4.3 -- py-1.4.30 -- pytest-2.7.2
rootdir: /tmp/buildd/python-geopandas-0.1.1, inifile:
collected 102 items
tests/test_geodataframe.py ...ss.
tests/test_geom_methods.py
tests/test_geoseries.py
tests/test_io.py .ss
tests/test_plotting.py ...
tests/test_types.py
== 6 tests deselected by '-knot test_geocode' ==
= 92 passed, 4 skipped, 6 deselected in 17.84 seconds ==
Segmentation fault (core dumped)
E: pybuild pybuild:256: test: plugin distutils failed with: exit code=139: cd
/tmp/buildd/python-geopandas-0.1.1/.pybuild/pythonX.Y_3.4/build; python3.4 -m
pytest tests -k not test_geocode
dh_auto_test: pybuild --test -i python{version} -p 3.4 --dir . returned exit
code 13
debian/rules:11: recipe for target 'build' failed
make: *** [build] Error 13
dpkg-buildpackage: error: debian/rules build gave error exit status 2
E: Failed autobuilding of package
This is not reliable. This thing sometimes segfaults sometimes not, as such not
marking as serious. Though it would have been nice if this was track down and
solved.
Also, feel free to adjust the severity at willing.
For what I'm concerned, this package failed 2 times out of 3 on the
reproducible CI, while 1 out of 2 on my local pbuilder:
id name version suite architecture status
build_datebuild_duration builder
- -- -- ---
-- -
15870 python-geopandas 0.1.1-1 unstableamd64 FTBFS
2015-07-09 17:38 372 beta/54727
16615 python-geopandas 0.1.1-1 testing amd64 FTBFS
2015-07-15 08:42 195 theta/20396
16790 python-geopandas 0.1.1-1 unstableamd64 reproducible
2015-07-16 14:35 499 beta/55865
Thanks for maintaining this package.
--
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: Digital 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#791574: Bug#791574: strip-nondeterminism: failure in zip.pm, breaking package builds
On Fri, Jul 17, 2015 at 03:52:15PM +0200, Andreas Tille wrote: I tried to reproduce this problem but was unable to reproduce it in a pbuilder environment. Are any specific build options needed to reproduce this (since in my build log dh_strip_nondeterminism -O--parallel is not even called: ... dh_link -O--parallel debian/rules override_dh_compress ... Well, currently it's called by our modified debhelper. The bug to get it mainlined is #759895. Either you install our patched debhelper or you modify the package to call it. dh patch: https://anonscm.debian.org/cgit/reproducible/debhelper.git/commit/?id=cb27ff633c19deb7e027045e219771668e598fb0 -- 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: 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] Bug#791574: strip-nondeterminism: failure in zip.pm, breaking package builds
[o.o the subject somehow went huge! ] On Fri, Jul 17, 2015 at 01:14:41PM -0700, Andrew Ayer wrote: On Fri, 17 Jul 2015 19:53:27 + Mattia Rizzolo mat...@mapreri.org wrote: i was aware some packages started build-depending on it, but nothing like this. Also, broken (and also missing, fwiw) build-dep does not causes removal from testing [1], so that's sound weird+wrong. Can you tell me of such package so i can get a look at what's going on more closely? Hi Mattia, According to https://packages.qa.debian.org/s/strip-nondeterminism.html: The removal of strip-nondeterminism will also cause the removal of (transitive) reverse dependencies: astroquery cpl-plugin-amber cpl-plugin-fors cpl-plugin-giraf cpl-plugin-hawki cpl-plugin-kmos cpl-plugin-muse cpl-plugin-sinfo cpl-plugin-uves cpl-plugin-vimos cpl-plugin-visir cpl-plugin-xshoo debram pyavm pyfits pyscanfcs python-astropy python-cpl python-pywcs veusz Thanks. I'm a tracker.d.o user and that does not provide such info (= #792738) Anyway, i asked for a bit of help to the RT [0] and discovered some things, like that autoremovals calculations is done by UDD and not anything run by them and that it does consider also build-dependencies. Looks like python-astropy build-dep on strip-nondetermism, and that (sadly) you (= astro team) did [1]. Personally I find shameful that a maintainer need such hack for a fail on our parts, please DO poke use more hardly the next time. strip-nondetermism is already fixed in git, soon will be uploaded too, so i think you can drop that workaround. And please accept my forgivness for this. [0] that means nthykier and adsb, thank you! [1] http://anonscm.debian.org/cgit/debian-astro/packages/python-astropy.git/commit/?id=0c73b4e109897ed5bf885815304c0a96342e59ff -- 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: Digital 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#792504: Dependency on libghc-setlocale-dev-1.0.0.2-35138 not satisfiable
Package: haskell-hgettext-dev Version: 0.1.30-9 Severity: serious User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs toolchain mattia@chase ~ % sudo apt install libghc-hgettext-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libghc-hgettext-dev : Depends: libghc-setlocale-dev-1.0.0.2-35138 but it is not installable E: Unable to correct problems, you have held broken packages. 100 mattia@chase ~ % This makes all packages somehow build-depending on this failing, such as https://reproducible.debian.net/rb-pkg/unstable/amd64/bustle.html -- 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: 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] Reproducibility of apt-listbugs
[ following the Reply-To I won't add Francesco to the To/Cc ] On Wed, Nov 11, 2015 at 11:20:06PM +0100, Francesco Poli wrote: > On Wed, 11 Nov 2015 23:16:39 +0100 Reiner Herrmann wrote: > > On Wed, Nov 11, 2015 at 07:23:45PM +0100, Francesco Poli wrote: > > > Is this something that should be fixed in rdtool [3]? If this is the > > > case, could you please file a bug report against rdtool? > > Yes, you are right. This is something that should be fixed in rdtool, > > probably by adding support there for SOURCE_DATE_EPOCH [2]. > > OK, good, you were already aware of the issue. I added a note linking apt-listbugs to that rdtool issue. > Please do not hesitate to file a bug report against apt-listbugs, in > case there's anything I can change in apt-listbugs itself in order to > help. Thanks :) -- 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
[Reproducible-builds] Bug#804838: eztrace: build process generates huge file
Source: eztrace
Version: 1.1-2
Severity: minor
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
User: reproducible-builds@lists.alioth.debian.org
Usertag: ftbfs
Dear maintainer,
in the context of Reproducible Builds, we noticed that eztrace can't
reliably be built because it (can?) generate very huge files that fills
the entire file system (and we have a 200GB file system).
For example:
mattia@profitbricks-build5-amd64 /srv/workspace/pbuilder % sudo lsof
2>/dev/null | grep deleted | grep eztrace
sh64627 1w REG 0,34 205408100352
2360061294
/srv/workspace/pbuilder/3308/build/eztrace-1.1/build-mpich/test/automake/testlog0.txt
(deleted)
litl_prin 64628 1w REG 0,34 205408100352
2360061294
/srv/workspace/pbuilder/3308/build/eztrace-1.1/build-mpich/test/automake/testlog0.txt
(deleted)
litl_prin 64628 3r REG 0,34 570
2360034123 /srv/workspace/pbuilder/3308/tmp/pbuilder1_eztrace_log_rank_1
(deleted)
mattia@profitbricks-build5-amd64 /srv/workspace/pbuilder %
That means a ~200GB file got written (actually is still getting
written), then removed but the process keeping it open (for writing) is
still open.
This is the 3rd time I have to kill extrace after having messed up with
our builders (and now I'm going to blacklist it from testing...).
That's not the only file, the other day I noticed that after killing
those 2 processes keeping that file opened 2 other started growing very
fast (like 1GB every 30 seconds), and in very little time they reached
50+ GB.
I noticed this only happens in amd64, not in armhf, I believe this is
some kind of issue with highly parallelized builds, since we build with
parallel=16.
Furthermore the tests are not considered in the build process, so they
are actually completely useless, so I even wonder what's the whole point
on running them...
override_dh_auto_test:
-dh_auto_test -Bbuild-mpich -- -k
Thanks for maintaining eztrace.
--
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
[Reproducible-builds] package uploaded to our repo
libxslt_1.1.28-2.1.0~reproducible1.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] package uploaded to our repo
perl_5.20.2-6.0~reproducible0.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] enable -Wdate-time by default [was: GCC patch reviewed. Proposed mail for gcc-patches mailing list]
On Tue, Nov 10, 2015 at 01:44:59PM +0100, Jérémy Bobbio wrote:
> Well, I still would like to push to add `-Wdate-time` to our default set
> of CFLAGS. Even with Dhole's patch, developpers would see the warning
> and ask themselves if it's the right thing to do.
Good that.
We are now down to 2 packages which FTBFS with -Wdate-time
https://reproducible.debian.net/rb-pkg/unstable/amd64/expeyes.html
https://bugs.debian.org/790103
https://reproducible.debian.net/rb-pkg/unstable/amd64/wsjt.html
no bug filed
https://reproducible.debian.net/issues/unstable/ftbfs_wdatetime_issue.html
And other 2 packages (subversion and unbound) which fails due to swig
https://bugs.debian.org/790102
https://reproducible.debian.net/issues/unstable/ftbfs_wdatetime_due_to_swig_issue.html
This is what should be done to achive our goal:
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F
To me it seems only the d-d thread is missing, maybe after filing the
missing bug against src:wsjt.
If nobody object I can start that thread.
dpkg bug with the first "timeless" feature:
https://bugs.debian.org/762683
--
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
[Reproducible-builds] Bug#804672: FTBFS if CPPFLAGS contains -Wdate-time
Source: wsjt
Version: 9.7.r3639+dfsg-1
Severity: wishlist
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
User: reproducible-builds@lists.alioth.debian.org
Usertag: ftbfs
Hi wsjt maintainer,
Your package currently fails to build in the reproducible build env due
to it passing -Wdate-time to f2py.
You can see a full build log on
https://reproducible.debian.net/rbuild/unstable/amd64/wsjt_9.7.r3639+dfsg-1.1.rbuild.log
I'm not sure whether the bug is in your package passing something
"random" over f2py or due to it not groking it correctly. If that's the
case please just reassing the bug to f2py
Thanks for maintaining wsjt.
--
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] Recent issues with faketime in debian/rules during reproducible-builds builds
On Mon, Oct 19, 2015 at 10:10:27AM +, Santiago Vila wrote: > Hello Axel. o/ :) I rescheduled src:mp4h and it built correctly. No clue what happened, but building 2 times 7k packages per day sometimes something happen... > > Are not all chroots used by the reproducible-builds project setup > > the same way? > > Assuming that by "setup the same way" we are not talking about all the > things that change between build1 and build2, yes, the chroots should > probably be setup "the same way" (or at least in a way that do not > break packages gratuitously). Yes they are. For reference, the very same chroots (except the machines are different for the same job) are used for both builds. > > Should the reproducible-builds not take care that especially > > faketime works in all their chroots? > > We should take care that *everything* works! :-) I don't think that > faketime is a lot special about this. Most of the time a simple > "touch" and options like tar's --owner and --group are enough to > achieve reproducibility. Personally, I have not seen faketime to be > used a lot, but this is just a personal feeling. We saw faketime causes quite some troubles. Yet we strive to get all packages building in our infrastructure, and this is no exception. Anyway, there are a lot other packages using /dev/shm, so it is there. > Also, we have such amount of things to fix and diffoscope logs to look > at that for many things we rely on people telling us what's wrong, as > in this case (btw: please consider joining us :-). yay ^^ > > Does the project use pbuilder on Wheezy occassionally but not > > always? > > Holger and Mattia (root @ jenkins) can check this. Well, actually I'm not root there. Anyway, all the machines run jessie, and the pbuilder from jessie-bpo (which I uploaded only yesterday :P) -- 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] Build environment changes between build1 and build2
On Thu, Oct 08, 2015 at 04:55:35PM +0200, Holger Levsen wrote: > Hi, > > On Donnerstag, 8. Oktober 2015, Santiago Vila wrote: > > I've seen several cases where a package is considered not reproducible > > just because the build environment changed between build1 and build2. > > this should not happen… end of the story. If it happens, its a bug in the CI. > > and today it also happened because of adding the new builders... (i'll spare > myself explaining the exact details, just we dont add builders every day, so > meh.) > > > However, I can think of some workarounds: > > yes, we too… > > I'm sorry but I'm severely overloaded and these problems are well known, well > discussed and being worked on. Explaining them here again, just takes away > time to work on these issues. Well, long story short: the build script compares the two .buildinfo just after the build and if Build-Environment differes it re-runs the build a 3rd time. If that fields differs again (this might be the case for very long running builds that spawn several dinstall and different toolchain packages change during the day) it just gives up and mark the package as unreproducible > It might be helpful to join irc to discuss with us in realtime. Agree, be assured discussing some stuff on IRC is really quicker than email. Though when it comes to #debian-reproducible following everything might be sometimes annoying due to the volume of the chats, but imho is still worthwhile :) -- 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] Weird localedef failures
On Sun, Oct 18, 2015 at 11:12:18AM +0300, Esa Peuha wrote: > On Sat, Oct 17, 2015 at 5:09 PM, Santiago Vila <sanv...@debian.org> wrote: > > For the same reason (not being build-essential), it is ok that it's > > not pre-installed in pbuilder chroot, and in fact, usually it's not. > > Huh? How is the second build supposed to be able to set the locale to > fr_CH without the locales package? > > > For example, it's not here: > > > > https://reproducible.debian.net/buildinfo/unstable/amd64/base-files_9.4_amd64.buildinfo > > A .buildinfo file doesn't (and isn't meant to) list all installed > packages, only those that are actually needed for the build. > > > If you can verify that installing the locales package fixes the error, > > then it would be clearly a "missing build-depends: locales" bug. > > No, that is not the problem. If you look at > > https://reproducible.debian.net/rbuild/unstable/amd64/apertium-en-ca_0.9.3~r61232-1.rbuild.log > > you can see that locales is in the Build-Depends list, but pbuilder > doesn't try to install it, so either there is something wrong with What's going on is the following: in our chroot locales-all is preinstalled, and that package Provides:locales. But locales-all does not ship everything locales does. This is #788352. In the past we bugged maintainers to add a Build-Conflicts on locales-all, but given that is allegedly fixed in experimental now I'd tag packages affected by this, so to remove them from our list, and then rebuild them once fixed glibc hit unstable. -- 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] Bug#801675: libsys-filesystem-perl: FTBFS: no regular filesystems
On Tue, Oct 13, 2015 at 02:21:38PM +0300, Niko Tyni wrote: > Apparently the test fails when it can't find any "regular" (as opposed > to "special") filesystems. In this age of building on virtual hosts > and chroots, I'm not sure this is a valid assumption, though it does > look strange that the build on reproducible.d.n doesn't report anything > mounted as the root file system. I've no clue which file systems are considered "regular" and which ones are "special" for Sys::Filesystem, but what I'm pretty confident about is that a pbuilder's /proc/mounts usually contains no entry for the root file system. So I assume the absence of an entry for / is not the cause of the ftbfs, since that's also what happen on "build 1" (and on the test build I just ran here locally). -- 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] Bug#801675: libsys-filesystem-perl: FTBFS: no regular filesystems
On Tue, Oct 13, 2015 at 05:22:09PM +0300, Niko Tyni wrote: > On Tue, Oct 13, 2015 at 12:16:17PM +0000, Mattia Rizzolo wrote: > > I've no clue which file systems are considered "regular" and which ones > > are "special" for Sys::Filesystem, > > Reading lib/Sys/Filesystem/Linux.pm, the full list of "special"file system > types is > > binfmt_misc, debugfs, devpts, fusectl, fuse.gvfs-fuse-daemon, > mini_fo, nfsd, proc, procbususb, securityfs, swap, sysfs, tmpfs, > udev umh, ok. > > but what I'm pretty confident about > > is that a pbuilder's /proc/mounts usually contains no entry for the root > > file system. > > So I assume the absence of an entry for / is not the cause of the ftbfs, > > since that's also what happen on "build 1" (and on the test build I just > > ran here locally). > > There's lots of diagnostic output in the build1 log including > > # filesystem - mounted - special - device - options - format - volume - > label - type > # / - 1 - 0 - /dev/vda1 - rw,relatime,errors=remount-ro,data=ordered - ext4 > - 1 - 1 - ext4 > > and a long list of other file systems like things under > /srv/workspace/pbuilder/61616. Attached there is a build log I ran on my machine. I don't see any / in the output. > It looks like these come from either /etc/fstab or /proc/mounts. So > perhaps the difference between the chroots is in /etc/fstab ? umh, I'm not sure, really, the presence of / looks weird to me. -- 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 `- I: using fakeroot in build. I: pbuilder: network access will be disabled during build I: Current time: Tue Oct 13 12:07:00 UTC 2015 I: pbuilder-time-stamp: 1444738020 I: Building the build Environment I: extracting base tarball [/home/mattia/pbuilder/sid-amd64-base.tgz] I: copying local configuration I: Installing apt-lines I: mounting /proc filesystem I: mounting /run/shm filesystem I: mounting /dev/pts filesystem I: Mounting /home/mattia/pbuilder/cache/ccache I: Mounting /home/mattia/pbuilder/repository I: policy-rc.d already exists I: Setting up ccache I: Installing the build-deps I: user script /var/cache/pbuilder/build/19068/tmp/hooks/D05deps starting + cd /home/mattia/pbuilder/repository + apt-ftparchive packages . I: user script /var/cache/pbuilder/build/19068/tmp/hooks/D05deps finished I: user script /var/cache/pbuilder/build/19068/tmp/hooks/D10dpkg-speedup starting I: user script /var/cache/pbuilder/build/19068/tmp/hooks/D10dpkg-speedup finished I: user script /var/cache/pbuilder/build/19068/tmp/hooks/D15no-man-db-rebuild starting I: Preseed man-db/auto-update to false I: user script /var/cache/pbuilder/build/19068/tmp/hooks/D15no-man-db-rebuild finished I: user script /var/cache/pbuilder/build/19068/tmp/hooks/D20compiler-wrappers starting I: user script /var/cache/pbuilder/build/19068/tmp/hooks/D20compiler-wrappers finished I: user script /var/cache/pbuilder/build/19068/tmp/hooks/D30update starting Ign file: ./ InRelease Ign file: ./ Release.gpg Ign file: ./ Release Err file: ./ Packages Err file: ./ Packages Err file: ./ Packages Get:1 http://ftp.de.debian.org sid InRelease [250 kB] Ign http://ftp.mapreri.org sid InRelease Ign http://ftp.mapreri.org sid Release.gpg Hit http://ftp.mapreri.org sid Release Ign http://ftp.mapreri.org sid/main amd64 Packages/DiffIndex Err http://ftp.mapreri.org sid/main amd64 Packages Err http://ftp.mapreri.org sid/main amd64 Packages Get:2 http://ftp.de.debian.org sid/main amd64 Packages/DiffIndex [7876 B] Err http://ftp.mapreri.org sid/main amd64 Packages Hit http://ftp.mapreri.org sid/main amd64 Packages Get:3 http://ftp.de.debian.org sid/main amd64 2015-10-10-2037.34.pdiff [4159 B] Get:4 http://ftp.de.debian.org sid/main amd64 2015-10-11-0238.18.pdiff [12.7 kB] Get:5 http://ftp.de.debian.org sid/main amd64 2015-10-11-0837.04.pdiff [4333 B] Get:6 http://ftp.de.debian.org sid/main amd64 2015-10-11-1437.13.pdiff [33.5 kB] Get:7 http://ftp.de.debian.org sid/main amd64 2015-10-11-2037.28.pdiff [45.1 kB] Get:8 http://ftp.de.debian.org sid/main amd64 2015-10-12-0239.40.pdiff [52.1 kB] Get:9 http://ftp.de.debian.org sid/main amd64 2015-10-12-0838.59.pdiff [3343 B] Get:10 http://ftp.de.debian.org sid/main amd64 2015-10-12-1438.25.pdiff [20.8 kB] Get:11 http://ftp.de.debian.org sid/main amd64 2015-10-12-2037.48.pdiff [41.2 kB] Get:12 http://ftp.de.debian.org sid/main amd64 2015-10-13-0244.06.pdiff [40.8 kB] Get:13 http://ftp.de.debian.org sid/main amd64 2015-10-13-0839.50.pdiff [34.5 kB] Get:14 http://ftp.de.debian.org sid/main amd64 2015-10-13-
[Reproducible-builds] Bug#791755: go-md2man: FTFBFS: src/github.com/russross/blackfriday/sanitize.go:6:2: code in directory /tmp/buildd/go-md2man-1.0.2/obj-x86_64-linux-gnu/src/code.google.com/p/go.ne
Source: go-md2man Version: 1.0.2-1 Severity: serious User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs Dear maintianer, you package FTBFS as follow in my pbuilder: debian/rules build dh build --buildsystem=golang --with=golang debian/rules override_dh_auto_build make[1]: Entering directory '/tmp/buildd/go-md2man-1.0.2' dh_auto_build cd obj-x86_64-linux-gnu go install -v github.com/cpuguy83/go-md2man github.com/cpuguy83/go-md2man/mangen src/github.com/russross/blackfriday/sanitize.go:6:2: code in directory /tmp/buildd/go-md2man-1.0.2/obj-x86_64-linux-gnu/src/code.google.com/p/go.net/html expects import golang.org/x/net/html dh_auto_build: go install -v github.com/cpuguy83/go-md2man github.com/cpuguy83/go-md2man/mangen returned exit code 1 debian/rules:13: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 1 make[1]: Leaving directory '/tmp/buildd/go-md2man-1.0.2' debian/rules:10: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Alternative (full) build log: https://reproducible.debian.net/rb-pkg/unstable/amd64/go-md2man.html -- 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: 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] dh_shlibdeps dependency ordering not stable if alternate dependency templates are used
On Thu, Jul 09, 2015 at 08:23:12PM +0200, Holger Levsen wrote: The issue is nondeterministic - a first rebuild after partly fixing another reproducibility issue has not shown this again. btw: https://reproducible.debian.net/rb-pkg/unstable/amd64/pyopencl.html I recall some other cases, where it turned out that the problem is not dpkg's and neither dh's. from dpkg-gencontrol(1): The order of dependencies is preserved as best as possible: if any dependency must be discarded due to another dependency appearing further in the field, the superseding dependency will take the place of the discarded one. That means that whatever passes them to dpkg, has to sort them. I quickly looked to dh_shlibdeps, and (if i got that right) it just call dpkg-shlibdeps. Now I don't have a clue of the order used by this one, and the manpage is way too long to be read in 5 minutes, but I'm fairly sure we didn't patch that file (at least, the changelog does not state so). -- 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: Digital 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#792048: xdemorse: FTBFS: ***Error***: You must have automake = 1.9 installed
Package: xdemorse
Version: 2.9-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
The package depends on automake, but it checks up to automake 1.14, while now
the default is 1.15.
Please either expand the check or build-depend on a fixed automake version (the
former is slightly preferred).
Build log tail:
dh_autoreconf /tmp/buildd/xdemorse-2.9/autogen.sh
find ! -ipath ./debian/* -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec
md5sum {} \; debian/autoreconf.before
/tmp/buildd/xdemorse-2.9/autogen.sh
checking for autoconf = 2.53...
testing autoconf2.50... not found.
testing autoconf... found 2.69
checking for automake = 1.9...
testing automake-1.14... not found.
testing automake-1.13... not found.
testing automake-1.12... not found.
testing automake-1.11... not found.
testing automake-1.10... not found.
testing automake-1.9... not found.
***Error***: You must have automake = 1.9 installed
to build Package. Download the appropriate package for
from your distribution or get the source tarball at
http://ftp.gnu.org/pub/gnu/automake/automake-1.9.tar.gz
find ! -ipath ./debian/* -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec
md5sum {} \; debian/autoreconf.after
dh_autoreconf: /tmp/buildd/xdemorse-2.9/autogen.sh returned exit code 1
debian/rules:10: recipe for target 'override_dh_autoreconf' failed
make[1]: *** [override_dh_autoreconf] Error 2
make[1]: Leaving directory '/tmp/buildd/xdemorse-2.9'
debian/rules:7: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
E: Failed autobuilding of package
You can see a full build log at
https://reproducible.debian.net/rb-pkg/unstable/amd64/xdemorse.html
--
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: 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] Bug#790103: new default build flag from dpkg: -Wdate-time
On Wed, Nov 18, 2015 at 08:26:24PM +0100, Hakan Ardo wrote:
> That means avr-gcc will be upgraded to the atmel release 3.5.0 based on gcc
> 4.9.2 soon.
soon = ?
> Will that help? Otherwise my suggestion would be that we
> introduce a new package, say avr-gcc5, that we base on the gnu release
> 5.2.0 and keep avr-gcc following the atmel releases.
sounds a lot of work for very little gain.
Only one package would FTBFS with this, and there are other workarounds
as well.
--
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] Bug#790103: new default build flag from dpkg: -Wdate-time
On Wed, Nov 18, 2015 at 09:40:51PM +0100, Hakan Ardo wrote: > On Wed, Nov 18, 2015 at 8:31 PM, Mattia Rizzolo <mat...@mapreri.org> wrote: > > On Wed, Nov 18, 2015 at 08:26:24PM +0100, Hakan Ardo wrote: > > > That means avr-gcc will be upgraded to the atmel release 3.5.0 based on > > gcc > > > 4.9.2 soon. > > soon = ? > Within a week or three... That's totally fine. This thing won't happen before for sure..... -- 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
[Reproducible-builds] Bug#796935: crash while comparing wine-development. ValueError + OSError
/dist-packages/diffoscope/comparators/xz.py, line 74, in compare_details return my_container.compare(other_container, source) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/xz.py, line 60, in compare return [diffoscope.comparators.compare_files(my_file, other_file, source)] File /usr/lib/python2.7/dist-packages/diffoscope/comparators/__init__.py, line 79, in compare_files return file1.compare(file2, source) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 75, in wrapper return original_method(self, other, *args, **kwargs) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 175, in compare difference = self._compare_using_details(other, source) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 148, in _compare_using_details details = [d for d in self.compare_details(other, source) if d is not None] File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 75, in wrapper return original_method(self, other, *args, **kwargs) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/deb.py, line 160, in compare_details differences.extend(my_container.compare(other_container, source)) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/utils.py, line 181, in compare difference = diffoscope.comparators.compare_files(my_file, other_file) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/__init__.py, line 79, in compare_files return file1.compare(file2, source) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 75, in wrapper return original_method(self, other, *args, **kwargs) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 183, in compare difference = self.compare_bytes(other, source=source) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 75, in wrapper return original_method(self, other, *args, **kwargs) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 145, in compare_bytes return compare_binary_files(self.path, other.path, source) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 58, in compare_binary_files with xxd(path1) as xxd1: File /usr/lib/python2.7/contextlib.py, line 17, in __enter__ return self.gen.next() File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 39, in xxd stderr=subprocess.PIPE, close_fds=True) File /usr/lib/python2.7/subprocess.py, line 710, in __init__ errread, errwrite) File /usr/lib/python2.7/subprocess.py, line 1335, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory + RESULT=2 -- 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: Digital 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#796935: Also aspectj affected
/comparators/binary.py, line 144, in _compare_using_details details = [d for d in self.compare_details(other, source) if d is not None] File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 75, in wrapper return original_method(self, other, *args, **kwargs) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/deb.py, line 161, in compare_details differences.extend(my_container.compare(other_container, source)) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/utils.py, line 180, in compare my_file, other_file, source=name)) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/__init__.py, line 79, in compare_files return file1.compare(file2, source) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 75, in wrapper return original_method(self, other, *args, **kwargs) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 171, in compare difference = self._compare_using_details(other, source) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 144, in _compare_using_details details = [d for d in self.compare_details(other, source) if d is not None] File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 75, in wrapper return original_method(self, other, *args, **kwargs) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/zip.py, line 108, in compare_details differences.extend(my_container.compare(other_container, source)) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/utils.py, line 180, in compare my_file, other_file, source=name)) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/__init__.py, line 79, in compare_files return file1.compare(file2, source) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 75, in wrapper return original_method(self, other, *args, **kwargs) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 174, in compare difference = self.compare_bytes(other, source=source) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 75, in wrapper return original_method(self, other, *args, **kwargs) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 141, in compare_bytes return compare_binary_files(self.path, other.path, source) File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 58, in compare_binary_files with xxd(path1) as xxd1: File /usr/lib/python2.7/contextlib.py, line 17, in __enter__ return self.gen.next() File /usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py, line 39, in xxd stderr=subprocess.PIPE, close_fds=True) File /usr/lib/python2.7/subprocess.py, line 710, in __init__ errread, errwrite) File /usr/lib/python2.7/subprocess.py, line 1335, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory -- 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: Digital 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#798398: diffoscope: another case of UnicodeDecodeError
compare(file2, source) File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py", line 77, in wrapper return original_method(self, other, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py", line 177, in compare difference = self._compare_using_details(other, source) File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py", line 150, in _compare_using_details details = [d for d in self.compare_details(other, source) if d is not None] File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py", line 77, in wrapper return original_method(self, other, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/deb.py", line 160, in compare_details differences.extend(my_container.compare(other_container)) File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/utils.py", line 197, in compare difference = diffoscope.comparators.compare_files(my_file, other_file) File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/__init__.py", line 96, in compare_files return file1.compare(file2, source) File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py", line 77, in wrapper return original_method(self, other, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py", line 177, in compare difference = self._compare_using_details(other, source) File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py", line 150, in _compare_using_details details = [d for d in self.compare_details(other, source) if d is not None] File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/binary.py", line 77, in wrapper return original_method(self, other, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/elf.py", line 87, in compare_details return _compare_elf_data(self.path, other.path) File "/usr/lib/python2.7/dist-packages/diffoscope/comparators/elf.py", line 74, in _compare_elf_data differences.append(Difference.from_command(ReadelfDebugDump, path1, path2)) File "/usr/lib/python2.7/dist-packages/diffoscope/difference.py", line 342, in from_command difference = Difference.from_feeder(feeder1, feeder2, path1, path2, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/diffoscope/difference.py", line 298, in from_feeder unified_diff = diff(feeder1, feeder2) File "/usr/lib/python2.7/dist-packages/diffoscope/difference.py", line 267, in diff return run_diff(fd1, fd2, end_nl_q1, end_nl_q2) File "/usr/lib/python2.7/contextlib.py", line 24, in __exit__ self.gen.next() File "/usr/lib/python2.7/dist-packages/diffoscope/difference.py", line 210, in fd_from_feeder t.join() File "/usr/lib/python2.7/dist-packages/diffoscope/difference.py", line 188, in join raise except_type, except_class, None UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 78: ordinal not in range(128) -- 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: Digital 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#797781: Bug#797781: diffoscope does not seem to work with schroot
On Wed, Sep 02, 2015 at 01:41:23PM +, Santiago Vila wrote: > Package: diffoscope > Version: 31 > > Greetings. I'm running jessie with several chroots created with > schroot. As a normal user, I do this: > > schroot -c sid > diffoscope some.deb someother.deb > > and this is the result: > > CRITICAL /dev/shm is not available or not on a tmpfs. Unable to create > semaphore. > > I believe such error is not supposed to happen. Well, quite a lot of stuff requires shm nowadays. Consider that we rb people run diffoscope inside scrhoot, and it just works. We have /dev/shm/dev/shmnonerw,bind 0 0 in /etc/schroot/default/fstab. Personally I'd not consider this a diffoscope bug. -- 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: Digital 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#797611: dh-strip-nondeterminism: Please provide a standalone strip-nondeterminism binary
On Mon, Aug 31, 2015 at 11:02:20PM +0200, Chris Lamb wrote:
> Please provide a non-standalone binary that will do the same things that
> calling dh_strip_nondeterminism would do, but I can point it at a
> specific file or directory and it will normalise it, eg.
>
> $ /usr/bin/strip-nondeterminism has-timestamps.png
>
> I would find this useful for testing dh-strip-nondeterminism itself and
> also for testing reproducible fixes.
Sounds like exactly what currently is in the binary package named
strip-nondeterminism.
There is exactly a file /usr/bin/strip-nondeterminism that behaves
exactly as you described :)
Does this satisfy you? :)
--
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: Digital 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#796930: pyzmq: FTBFS with several tests error
/usr/lib/python2.7/doctest.py, line 1315, in __run
compileflags, 1) in test.globs
File doctest zmq.eventloop.minitornado.util.import_object[1], line 1,
in module
import_object('tornado.escape') is tornado.escape
File
/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/eventloop/minitornado/util.py,
line 40, in import_object
obj = __import__('.'.join(parts[:-1]), None, None, [parts[-1]], 0)
ImportError: No module named tornado
--
File
/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/eventloop/minitornado/util.py,
line 27, in zmq.eventloop.minitornado.util.import_object
Failed example:
import_object('tornado.escape.utf8') is tornado.escape.utf8
Exception raised:
Traceback (most recent call last):
File /usr/lib/python2.7/doctest.py, line 1315, in __run
compileflags, 1) in test.globs
File doctest zmq.eventloop.minitornado.util.import_object[2], line 1,
in module
import_object('tornado.escape.utf8') is tornado.escape.utf8
File
/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/eventloop/minitornado/util.py,
line 40, in import_object
obj = __import__('.'.join(parts[:-1]), None, None, [parts[-1]], 0)
ImportError: No module named tornado.escape
--
File
/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/eventloop/minitornado/util.py,
line 29, in zmq.eventloop.minitornado.util.import_object
Failed example:
import_object('tornado') is tornado
Exception raised:
Traceback (most recent call last):
File /usr/lib/python2.7/doctest.py, line 1315, in __run
compileflags, 1) in test.globs
File doctest zmq.eventloop.minitornado.util.import_object[3], line 1,
in module
import_object('tornado') is tornado
File
/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/eventloop/minitornado/util.py,
line 37, in import_object
return __import__(name, None, None)
ImportError: No module named tornado
--
File
/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/eventloop/minitornado/util.py,
line 31, in zmq.eventloop.minitornado.util.import_object
Failed example:
import_object('tornado.missing_module')
Expected:
Traceback (most recent call last):
...
ImportError: No module named missing_module
Got:
Traceback (most recent call last):
File /usr/lib/python2.7/doctest.py, line 1315, in __run
compileflags, 1) in test.globs
File doctest zmq.eventloop.minitornado.util.import_object[4], line 1,
in module
import_object('tornado.missing_module')
File
/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/eventloop/minitornado/util.py,
line 40, in import_object
obj = __import__('.'.join(parts[:-1]), None, None, [parts[-1]], 0)
ImportError: No module named tornado
==
FAIL: Doctest: zmq.eventloop.zmqstream.ZMQStream
--
Traceback (most recent call last):
File /usr/lib/python2.7/doctest.py, line 2226, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for zmq.eventloop.zmqstream.ZMQStream
File /pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/eventloop/zmqstream.py,
line 53, in ZMQStream
--
File /pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build/zmq/eventloop/zmqstream.py,
line 85, in zmq.eventloop.zmqstream.ZMQStream
Failed example:
stream.bind is stream.socket.bind
Exception raised:
Traceback (most recent call last):
File /usr/lib/python2.7/doctest.py, line 1315, in __run
compileflags, 1) in test.globs
File doctest zmq.eventloop.zmqstream.ZMQStream[0], line 1, in module
stream.bind is stream.socket.bind
NameError: name 'stream' is not defined
--
Ran 181 tests in 24.837s
FAILED (SKIP=19, errors=3, failures=2)
E: pybuild pybuild:262: test: plugin distutils failed with: exit code=1: cd
/pyzmq-14.4.0/.pybuild/pythonX.Y_2.7/build; python2.7 -m nose --with-doctest
dh_auto_test: pybuild --test --test-nose -i python{version} -p 2.7 --dir .
returned exit code 13
debian/rules:51: recipe for target 'override_dh_auto_test' failed
--
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: Digital signature
___
Reproducible-builds
Re: [Reproducible-builds] Bug#798826: DDPO: displays not-for-us in reproducible builds column for architectures excluded in the package
On Sun, Sep 13, 2015 at 12:44:12PM +0200, Sebastian Ramacher wrote:
>
> On my DDPO page intel-vaapi-driver is displayed as not-for-us in the
> reproducible build column which is caused by r.d.n reporting
> intel-vaapi-driver
> as not-for-us on armhf. This is expected since intel-vaapi-driver restricts
> its
> Architecture field to i386, amd64, kfreebsd-i386 and kfreebsd-amd64. So please
> ignore results for architectures that are explicitely excluded in the package.
>
> This issue may be an issue in the data provided by r.d.n. In this case please
> reassign it.
Well, the data in reproducible.d.n/reproducible.json is just that: data.
We already had to filter out some stuff (like packages failing to build
due to weird stuff in our infrastracture [0]).
There is a bug somewhere i can't find anymore about using another data
source, so we can keep reproducible.json full with real data, while
using a different .json to feed stuff like ddpo. I believe that's the
wrong approach.
We provide data and consumers needs to be aware on how to use it. Doing
dumb dumps of data inside a table is rarely useful.
In particular I believe the followings:
* not-for-us needs to be filtered by the DDPO: there is no point in
throwing them at the user
* needs support for multiple architecture (it's very new: less than a
month)
* maybe care only about unstable: if a version in unstable is repr.
while the lower version in testing is not, then there is no need to
notify the user
If somebody wants to improve this I'm willing to support the rb side
(anwering questions about packages states in our infrastracture or even
changin rb.d.n behaviour).
[0]
https://reproducible.debian.net/issues/unstable/ftbfs_in_jenkins_setup_issue.html
↑ Note: I'm all for filtering out this particular issue ('cause
it're really tied to our infra), personally I'm not that much about
other things.
--
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: 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] Wrong version displayed for gcin in reproducible status page
On Mon, Sep 14, 2015 at 12:37:25PM +0800, ChangZhuo Chen wrote: > On Sun, Sep 13, 2015 at 05:36:58PM +, Santiago Vila wrote: > > Now the package is in "uncategorized state", which means it fails to > > build reproducibly but we don't know the exact reason, so it will need > > to be investigated. > > > > If you have some idea why this package does not build reproducibly, > > we can write a new note for it. > > > > (Or you could also join us and write the note yourself :-). > > I will investigate it, but how can I join the team and update the note? Just ask to join the alioth team, you'll get commit access to the git repository. https://alioth.debian.org/projects/reproducible -- 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: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Please whitelist reproducible mails
Dear pkg-apparmor-team ML admins, looks like we Reproducible Builds got a request notify reproducible-related changes to the status of apparmor. Though this mailing list is moderated and the mail got filtered. I'd ask you to either whitelist our mail, or to completely open the ML (as a silent standard in Debian). -- 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: Digital 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#798776: testdisk: please make the build reproducible (timestamps)
Source: testdisk
Version: 6.14-3
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org, Christophe GRENIER
<gren...@cgsecurity.org>
Hi!
While working on the “reproducible builds” effort [1], we have noticed
that testdisk could not be built reproducibly.
On Sat, Sep 12, 2015 at 03:20:38PM +0200, Christophe GRENIER wrote:
> You may use this patch to avoid timestamps_from_cpp_macros by default
> when compiling testdisk.
> http://git.cgsecurity.org/cgit/testdisk/commit/?id=ebfc0ed789a852625121f67878db5e2a7526a5e3
Yay, very thank you for this! :)
As you may guess we reproducible builds team does not apply patches
directly to the packages.
With this email I'm opening a bug against the testdisk package in Debian
so that the testdisk maintainer is aware and can apply the patch.
[1]: https://wiki.debian.org/ReproducibleBuilds
--
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: 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] libibatis-java changed in testing: reproducible -> FTBFS
On Tue, Sep 29, 2015 at 11:00:30AM -0300, Miguel Landaeta wrote: > On Mon, Sep 28, 2015 at 11:05:15PM +, Reproducible builds folks wrote: > > More information on > > https://reproducible.debian.net/testing/amd64/libibatis-java, feel free to > > reply to this email to get more help. > > Hi folks, Hi, > Thank you very much for your helpful periodic email reports about > packages reproducibility. eheh, they are not so periodic, they are sent right after the build. > However, you should be more careful about false positive FTBFS reports > since in this case the failure came from lack of disk space in the > autobuilder. I'm very sorry about those particular emails. The last two days we had sever issues with the build host that cause a really big bunch of FTBFS due to ENOSPC. All the affected packages are already queued up for rebuilding, but it takes time to rebuild all of them (FYI, currently there are more than 750 build in the queue only for this, used to be ~1000 this morning). ps. > "Faith means not wanting to know what is true." -- Nietzsche nice words :) -- 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] libibatis-java changed in testing: reproducible -> FTBFS
On Wed, Sep 30, 2015 at 11:26:39AM -0300, Miguel Landaeta wrote:
> BTW, can another builds be retried?
yes, every team member has a mean to schedule packages for building.
> I was interested on retriggering jruby build since is tagged as FTBFS
> since some days ago and I know for sure is not FTBFS. When I inspect
> the log for the failed build I found out[1] an incomplete log file, so
> I suspect it was also a disk space related problem as well.
personally I don't think it's caused by ENOSCP, but I scheduled it
anyway.
The last build lasted 43213 seconds, and we timeout builds at 12 hours
(with SIGTERM) and 12h6m with SIGKILL. so it reached the timeout and
all those errors are from some java thinghy erroring out due to SIGTERM,
imho.
from a look at the past builds this seems to be started with the 1.7.22
upload:
id nameversion suite architecture status
build_datebuild_duration builder
- -- -- -- ---
-- -
24387 jruby 1.5.6-9 testing amd64 unreproducible
2015-03-26 15:22 1991
50111 jruby 1.5.6-9 testing amd64 unreproducible
2015-04-17 12:26 992
68362 jruby 1.5.6-10unstableamd64 unreproducible
2015-05-05 09:20 1096
73002 jruby 1.5.6-10testing amd64 unreproducible
2015-05-08 14:20 1361
11257 jruby 1.5.6-10unstableamd64 unreproducible
2015-06-03 03:31 1263
13163 jruby 1.7.19-1experiment amd64 FTBFS
2015-06-16 02:40 3
13473 jruby 1.7.19-1experiment amd64 unreproducible
2015-06-17 07:51 2791
13552 jruby 1.5.6-10testing amd64 unreproducible
2015-06-17 20:14 1125
13866 jruby 1.7.20.1-1 experiment amd64 FTBFS
2015-06-20 06:57 1428
14090 jruby 1.7.20.1-2 unstableamd64 unreproducible
2015-06-21 16:01 2630
14612 jruby 1.7.20.1-2 testing amd64 FTBFS
2015-06-28 11:36 18
16076 jruby 1.7.21-1unstableamd64 FTBFS
2015-07-11 02:49 157 beta/55072
16720 jruby 1.7.21-1testing amd64 FTBFS
2015-07-16 05:00 39 gamma/55754
18549 jruby 1.7.21-2unstableamd64 unreproducible
2015-07-29 22:09 7979zeta/23067
18852 jruby 1.7.21-2testing amd64 FTBFS
2015-08-01 12:01 60 zeta/23429
21071 jruby 1.7.21-2testing amd64 depwait
2015-08-13 22:28 19 alpha/60854
22091 jruby 1.7.21-2testing amd64 depwait
2015-08-21 23:58 32 gamma/62859
24007 jruby 1.7.21-2testing amd64 depwait
2015-09-03 15:50 34 gamma/65105
24398 jruby 1.7.21-2unstablearmhf FTBFS
2015-09-05 15:04 19278 armhf_3/325
24548 jruby 1.7.21-2unstablearmhf FTBFS
2015-09-06 18:41 16542 armhf_1/459
25272 jruby 1.7.21-2testing amd64 depwait
2015-09-10 19:49 45 amd64_3/753
26175 jruby 1.7.21-2unstableamd64 unreproducible
2015-09-16 10:09 2602amd64_8/1634
26537 jruby 1.7.21-2unstableamd64 FTBFS
2015-09-17 22:35 2768amd64_4/3308
26629 jruby 1.7.22-1unstableamd64 FTBFS
2015-09-18 00:34 43213 amd64_6/3043
26771 jruby 1.7.22-1unstablearmhf FTBFS
2015-09-18 22:49 25378 armhf_2/587
27150 jruby 1.7.21-2testing amd64 FTBFS
2015-09-20 01:32 44709 amd64_3/2590
28098 jruby 1.7.22-1testing amd64 depwait
2015-09-24 23:24 234 amd64_13/1021
28121 jruby 1.7.22-1testing amd64 FTBFS
2015-09-25 00:09 12191 amd64_9/2831
Everything I said can be true for unstable, but not for testing, since
the failure there happens only in the second build with tests errors:
3354 files, 19543 examples, 52878 expectations, 5 failures, 4 errors
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: http://mapreri.org : :' :
Launchpad user: https://launchp
Re: [Reproducible-builds] libibatis-java changed in testing: reproducible -> FTBFS
On Wed, Sep 30, 2015 at 11:26:39AM -0300, Miguel Landaeta wrote:
> BTW, can another builds be retried?
yes, every team member has a mean to schedule packages for building.
> I was interested on retriggering jruby build since is tagged as FTBFS
> since some days ago and I know for sure is not FTBFS. When I inspect
> the log for the failed build I found out[1] an incomplete log file, so
> I suspect it was also a disk space related problem as well.
personally I don't think it's caused by ENOSCP, but I scheduled it
anyway.
The last build lasted 43213 seconds, and we timeout builds at 12 hours
(with SIGTERM) and 12h6m with SIGKILL. so it reached the timeout and
all those errors are from some java thinghy erroring out due to SIGTERM,
imho.
From a look at the past builds this seems to be started with the 1.7.22
upload:
id nameversion suite architecture status
build_datebuild_duration builder
- -- -- -- ---
-- -
24387 jruby 1.5.6-9 testing amd64 unreproducible
2015-03-26 15:22 1991
50111 jruby 1.5.6-9 testing amd64 unreproducible
2015-04-17 12:26 992
68362 jruby 1.5.6-10unstableamd64 unreproducible
2015-05-05 09:20 1096
73002 jruby 1.5.6-10testing amd64 unreproducible
2015-05-08 14:20 1361
11257 jruby 1.5.6-10unstableamd64 unreproducible
2015-06-03 03:31 1263
13163 jruby 1.7.19-1experiment amd64 FTBFS
2015-06-16 02:40 3
13473 jruby 1.7.19-1experiment amd64 unreproducible
2015-06-17 07:51 2791
13552 jruby 1.5.6-10testing amd64 unreproducible
2015-06-17 20:14 1125
13866 jruby 1.7.20.1-1 experiment amd64 FTBFS
2015-06-20 06:57 1428
14090 jruby 1.7.20.1-2 unstableamd64 unreproducible
2015-06-21 16:01 2630
14612 jruby 1.7.20.1-2 testing amd64 FTBFS
2015-06-28 11:36 18
16076 jruby 1.7.21-1unstableamd64 FTBFS
2015-07-11 02:49 157 beta/55072
16720 jruby 1.7.21-1testing amd64 FTBFS
2015-07-16 05:00 39 gamma/55754
18549 jruby 1.7.21-2unstableamd64 unreproducible
2015-07-29 22:09 7979zeta/23067
18852 jruby 1.7.21-2testing amd64 FTBFS
2015-08-01 12:01 60 zeta/23429
21071 jruby 1.7.21-2testing amd64 depwait
2015-08-13 22:28 19 alpha/60854
22091 jruby 1.7.21-2testing amd64 depwait
2015-08-21 23:58 32 gamma/62859
24007 jruby 1.7.21-2testing amd64 depwait
2015-09-03 15:50 34 gamma/65105
24398 jruby 1.7.21-2unstablearmhf FTBFS
2015-09-05 15:04 19278 armhf_3/325
24548 jruby 1.7.21-2unstablearmhf FTBFS
2015-09-06 18:41 16542 armhf_1/459
25272 jruby 1.7.21-2testing amd64 depwait
2015-09-10 19:49 45 amd64_3/753
26175 jruby 1.7.21-2unstableamd64 unreproducible
2015-09-16 10:09 2602amd64_8/1634
26537 jruby 1.7.21-2unstableamd64 FTBFS
2015-09-17 22:35 2768amd64_4/3308
26629 jruby 1.7.22-1unstableamd64 FTBFS
2015-09-18 00:34 43213 amd64_6/3043
26771 jruby 1.7.22-1unstablearmhf FTBFS
2015-09-18 22:49 25378 armhf_2/587
27150 jruby 1.7.21-2testing amd64 FTBFS
2015-09-20 01:32 44709 amd64_3/2590
28098 jruby 1.7.22-1testing amd64 depwait
2015-09-24 23:24 234 amd64_13/1021
28121 jruby 1.7.22-1testing amd64 FTBFS
2015-09-25 00:09 12191 amd64_9/2831
Everything I said can be true for unstable, but not for testing, since
the failure there happens only in the second build with tests errors:
3354 files, 19543 examples, 52878 expectations, 5 failures, 4 errors
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: http://mapreri.org : :' :
Launchpad user: https://launchp
[Reproducible-builds] package uploaded to our repo
debhelper_9.20150811.0~reproducible5.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] adding a new PTS keyword (Re: Usefulness of periodic reproducible builds e-mails
On Sat, Oct 03, 2015 at 09:13:19PM +0200, Raphael Hertzog wrote: > Hello, > > > On Mittwoch, 30. September 2015, Mattia Rizzolo wrote: > > > > I think there is value in receiving these notifications, they provide > > > > timely feedback about the status of our packages. > > > > > > > > Maybe we can setup a mailing list for this, something like > > > > pkg-java-bui...@lists.alioth.debian.org? (we already have > > > > pkg-java-commits, for example). > > > > > > This wouldn't work with the current implementation, which is emailing > > > $p...@packages.debian.org. Anyway, I received a suggestion of setting up > > > a new PTS keyword, so then people can go and subscribe there, maybe > > > using the team facility of the new tracker to subscribe to the whole lot > > > (i beliebe it works that way?). > > > > > > Does anybody knows how to achive that? > > What kind of mails are we referring to? We are talking about very short mails, actually one-liners like 2015-10-03 11:43 https://reproducible.debian.net/unstable/amd64/derby changed from FTBFS -> unreproducible (this one will be sent out this evening) > In general, it's OK to use the package tracker to relay important data > about the packages... but I don't think that a dedicated keyword helps > here. We have a "build" keyword already and I believe that reproducible > mails should be sent via that keyword as well. > > That said it depends on the mails... we really want only notifications > when something significant changes. Well, we'd like a dedicate keywoard exactly because for a lot of people this is not significant. The current implementation of sending mails to $pkg@packages.d.o makes the mail use the "contact" keyword, and imho this is bad, usually people interested in contact only are not interested in this kind of info. > About the implementation it can be done simply by mailing a specific > email address that encodes both the package and the keyword. Yes, but I guess this require something "qa side", or is it enough to just start sending mails to package_reproduci...@packages.qa.debian.org (or package_reproduci...@tracker.debian.org, but that way old PTS user wouldn't get those mails) ?? > -- > Raphaël Hertzog ◈ Debian Developer > > Support Debian LTS: http://www.freexian.com/services/debian-lts.html > Learn to master Debian: http://debian-handbook.info/get/ > -- 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
[Reproducible-builds] package uploaded to our repo
debhelper_9.20151005.0~reproducible0.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] package uploaded to our repo
debhelper_9.20151005.0~reproducible1.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ 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#791815: libxslt: please support timestamps from environment
control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=751621
control: tags -1 + upstream fixed-upstream
On Wed, Jul 08, 2015 at 06:44:00PM +0200, Dhole wrote:
> While working on the “reproducible builds” effort [1], we have noticed
> that libxslt embeds timestamps when generating documentation.
>
> We have a proposal for using a deterministic timestamp [2] (based on
> the latest debian/changelog entry) which is contained in the environment
> variable SOURCE_DATE_EPOCH (currently exported by debhelper in our
> experimental framework).
>
> The attached patch proposes a way to use this variable to get
> reproducible timestamps when generating docs, if the variable has been
> set (if not, it falls back to the old behavior).
The attached here patch was NACK'ed by upstream, though he came up with
another one, which was tested during the last 2 months by us.
Let me set some bug metadata (for easier tracking of this) :)
--
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
[Reproducible-builds] Bug#800359: [diffoscope] diffing two .dsc should diff the whole sources
Package: diffoscope Version: 36 Severity: wishlist Hi there. I tend to use diffoscope to check the differences between two uploads because I like it's output much more than a plain debdiff. So, I'd like to compare the source, and I feed diffoscope with the 2 .dsc; it shows me only the diff of the .dsc files iteself, which is quite uselss. I'd prefer diffosocpe to behave the same why it does with .changes and diff all the files listed in the Files: field of the .dscs. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages diffoscope depends on: ii python3 3.4.3-6 ii python3-debian0.1.27 ii python3-libarchive-c 2.1-3 ii python3-magic 1:5.25-2 ii python3-rpm 4.12.0.1+dfsg1-3 ii python3-tlsh 3.2.1+20150727-2 pn python3:any Versions of packages diffoscope recommends: ii acl 2.2.52-2 ii binutils-multiarch2.25.1-3 ii bzip2 1.0.6-8 ii cpio 2.11+dfsg-4.1 ii default-jdk [java-sdk]2:1.7-52 ii fontforge-extras 0.3-4 ii genisoimage 9:1.1.11-3 ii gettext 0.19.6-1 ii ghc 7.8.4-9 ii gnupg 1.4.19-5 ii mono-utils3.2.8+dfsg-10 ii openjdk-7-jdk [java-sdk] 7u85-2.6.1-3 ii pdftk 2.02-3 ii poppler-utils 0.26.5-4 ii rpm2cpio 4.12.0.1+dfsg1-3 ii sng 1.0.6-2 ii sqlite3 3.8.11.1-1 ii squashfs-tools1:4.3-2 ii unzip 6.0-18 ii vim-common2:7.4.826-1 ii xz-utils 5.1.1alpha+20120614-2.1 diffoscope suggests no packages. -- no debconf information -- 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
[Reproducible-builds] package uploaded to our repo
debhelper_9.20151005.0~reproducible2.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#799901: [diffoscope] TypeError: 'differences' must contains Difference objects'
re(file2, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line
78, in wrapper
return original_method(self, other, *args, **kwargs)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line
176, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line
153, in _compare_using_details
difference.add_details(details)
File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 390, in
add_details
raise TypeError("'differences' must contains Difference objects'")
TypeError: 'differences' must contains Difference objects'
--
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: 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
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
[Reproducible-builds] Bug#808104: diffoscope 43 KeyError's with several packages
Package: diffoscope
Version: 43
Seen on rb.d.n, with several packages, e.g.
dhcpdump/1.8-2 on testing/amd64
console-data/2:1.12-5 on testing/amd64
Wed Dec 16 01:52:13 UTC 2015 - diffoscope 43 will be used to compare the two
builds:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/diffoscope/__main__.py", line 177, in
main
sys.exit(run_diffoscope(parsed_args))
File "/usr/lib/python3/dist-packages/diffoscope/__main__.py", line 148, in
run_diffoscope
parsed_args.file1, parsed_args.file2)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py",
line 93, in compare_root_paths
return compare_files(file1, file2)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py",
line 109, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line
192, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line
167, in _compare_using_details
details.extend(filter(None, self.as_container.compare(other.as_container)))
File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py",
line 112, in compare_commented_files
difference = compare_files(file1, file2, source=source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py",
line 109, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line
192, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line
167, in _compare_using_details
details.extend(filter(None, self.as_container.compare(other.as_container)))
File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py",
line 112, in compare_commented_files
difference = compare_files(file1, file2, source=source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py",
line 109, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line
192, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line
167, in _compare_using_details
details.extend(filter(None, self.as_container.compare(other.as_container)))
File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py",
line 112, in compare_commented_files
difference = compare_files(file1, file2, source=source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py",
line 109, in compare_files
return file1.compare(file2, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line
192, in compare
difference = self._compare_using_details(other, source)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line
167, in _compare_using_details
details.extend(filter(None, self.as_container.compare(other.as_container)))
File "/usr/lib/python3/dist-packages/diffoscope/comparators/deb.py", line 90,
in comparisons
my_md5sums = self.source.container.source.container.source.md5sums
File "/usr/lib/python3/dist-packages/diffoscope/comparators/deb.py", line 46,
in md5sums
md5sums_file = self.as_container.lookup_file('control.tar.gz',
'control.tar', './md5sums')
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils.py", line
184, in lookup_file
return container.lookup_file(*remainings)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils.py", line
184, in lookup_file
return container.lookup_file(*remainings)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils.py", line
174, in lookup_file
file = self.get_member(name)
File "/usr/lib/python3/dist-packages/diffoscope/comparators/libarchive.py",
line 150, in get_member
raise KeyError('%s not found in archive', member_name)
KeyError: ('%s not found in archive', './md5sums')
--
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
[Reproducible-builds] Bug#810509: apt: please make the build reproducible (randomness)
Source: apt Version: 1.1.10 Severity: wishlist Tags: patch User: reproducible-builds@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Hi! While working on the “reproducible builds” effort [1], we have noticed that apt could not be built reproducibly. The attached patch removes extra randomness from the build system, ensuring a stable file order when linking the built object. This particular issues is currently visible only on our armhf builds due to a limit in our infrastructure, but can be tested by performing the builds using the fuse fs disorderfs. Once applied, apt can be built reproducibly in our current experimental framework. [1]: https://wiki.debian.org/ReproducibleBuilds -- 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 `- From 18405011c3cdb8eff2f41fe674787f746092b27e Mon Sep 17 00:00:00 2001 From: Mattia Rizzolo <mat...@debian.org> Date: Sat, 9 Jan 2016 10:45:34 + Subject: [PATCH] fix reproducibly issue due to readdir() order by sorting the list of sources to be built and linked --- apt-inst/makefile| 4 ++-- apt-pkg/makefile | 4 ++-- apt-private/makefile | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/apt-inst/makefile b/apt-inst/makefile index 2883cbc..5601cd9 100644 --- a/apt-inst/makefile +++ b/apt-inst/makefile @@ -20,7 +20,7 @@ SLIBS=$(PTHREADLIB) -lapt-pkg APT_DOMAIN:=libapt-inst$(MAJOR) LIBRARYDEPENDS=$(LIB)/libapt-pkg.so -SOURCE = $(wildcard *.cc */*.cc) -HEADERS = $(addprefix apt-pkg/,$(notdir $(wildcard *.h */*.h))) +SOURCE = $(sort $(wildcard *.cc */*.cc)) +HEADERS = $(addprefix apt-pkg/,$(notdir $(sort $(wildcard *.h */*.h include $(LIBRARY_H) diff --git a/apt-pkg/makefile b/apt-pkg/makefile index 9236f81..e3e6e20 100644 --- a/apt-pkg/makefile +++ b/apt-pkg/makefile @@ -31,7 +31,7 @@ SLIBS+= -llz4 endif APT_DOMAIN:=libapt-pkg$(LIBAPTPKG_MAJOR) -SOURCE = $(wildcard *.cc */*.cc) -HEADERS = $(addprefix apt-pkg/,$(notdir $(wildcard *.h */*.h))) +SOURCE = $(sort $(wildcard *.cc */*.cc)) +HEADERS = $(addprefix apt-pkg/,$(notdir $(sort $(wildcard *.h */*.h include $(LIBRARY_H) diff --git a/apt-private/makefile b/apt-private/makefile index 9a3fbdb..1934db1 100644 --- a/apt-private/makefile +++ b/apt-private/makefile @@ -15,7 +15,7 @@ MINOR=0 SLIBS=$(PTHREADLIB) -lapt-pkg CXXFLAGS += -fvisibility=hidden -fvisibility-inlines-hidden -SOURCE = $(wildcard *.cc) -HEADERS = $(addprefix apt-private/,$(wildcard *.h)) +SOURCE = $(sort $(wildcard *.cc)) +HEADERS = $(addprefix apt-private/,$(sort $(wildcard *.h))) include $(LIBRARY_H) -- 2.7.0.rc3 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] package uploaded to our repo
debhelper_9.2015125.0~reproducible0.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] package uploaded to our repo
debhelper_9.20151225.0~reproducible0.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#809056: xca: FTBFS due to CPPFLAGS containing spaces
Source: xca Version: 1.0.0-2 Severity: wishlist User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Your package fails to build in current sid: debian/rules build dh_testdir CF=-Wdate-time -D_FORTIFY_SOURCE=2 docdir=/usr/share/doc/xca prefix=/usr ./configure /bin/sh: 1: -D_FORTIFY_SOURCE=2: not found debian/rules:9: recipe for target 'Local.mak' failed make: *** [Local.mak] Error 127 dpkg-buildpackage: error: debian/rules build gave error exit status 2 This usually means that you should quote CPPFLAGS before passing it over. -- 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
[Reproducible-builds] Bug#809053: xindy FTBFS due to CPPFLAGS containing spaces
Package: src:xindy
Version: 2.4-1.3
Severity: serious
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
xindy FTBFS in current sid.
tail of the build log:
fakeroot debian/rules binary
test -d debian/patched || install -d debian/patched
dpatch apply-all
applying patch fix-echo-expansion to ./ ... ok.
applying patch fix-FHS to ./ ... ok.
applying patch help-option to ./ ... ok.
applying patch config.guess+sub to ./ ... ok.
applying patch fix-alphabets-doc-geometry to ./ ... ok.
applying patch fix-configure to ./ ... ok.
applying patch fix-entry-with-command to ./ ... ok.
dpatch cat-all >>patch-stampT
mv -f patch-stampT patch-stamp
dh_testdir
if [ -e config.status ]; then \
rm -f build-arch-stamp build-indep-stamp; \
/usr/bin/make distclean || true; \
fi
./configure LDFLAGS="-Wl,-z,relro -Wl,-z,defs" CFLAGS="-g -O2
-fstack-protector-strong -Wformat -Werror=format-security" CPPFLAGS=-Wdate-time
-D_FORTIFY_SOURCE=2 --host=x86_64-linux-gnu --build=x86_64-linux-gnu
--prefix=/usr --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
--docdir=\${prefix}/share/doc/xindy-rules
configure: error: unrecognized option: -D_FORTIFY_SOURCE=2
Try `./configure --help' for more information.
debian/rules:33: recipe for target 'config.status-with-latex' failed
make: *** [config.status-with-latex] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
--
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
[Reproducible-builds] Bug#809074: spark: FTBFS due to CPPFLAGS containing spaces
unless load is below N.
-L, --check-symlink-times Use the latest mtime between symlinks and target.
-n, --just-print, --dry-run, --recon
Don't actually run any recipe; just print them.
-o FILE, --old-file=FILE, --assume-old=FILE
Consider FILE to be very old and don't remake it.
-O[TYPE], --output-sync[=TYPE]
Synchronize output of parallel jobs by TYPE.
-p, --print-data-base Print make's internal database.
-q, --question Run no recipe; exit status says if up to date.
-r, --no-builtin-rules Disable the built-in implicit rules.
-R, --no-builtin-variables Disable the built-in variable settings.
-s, --silent, --quiet Don't echo recipes.
-S, --no-keep-going, --stop
Turns off -k.
-t, --touch Touch targets instead of remaking them.
--trace Print tracing information.
-v, --version Print the version number of make and exit.
-w, --print-directory Print the current directory.
--no-print-directoryTurn off -w, even if it was turned on implicitly.
-W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE
Consider FILE to be infinitely new.
--warn-undefined-variables Warn when an undefined variable is referenced.
This program built for x86_64-pc-linux-gnu
Report bugs to <bug-m...@gnu.org>
Makefile:56: recipe for target 'vct-target' failed
make[4]: *** [vct-target] Error 2
make[4]: Leaving directory '/build/spark-2012.0.deb/victor'
Makefile:88: recipe for target 'makeall' failed
make[3]: *** [makeall] Error 2
make[3]: Leaving directory '/build/spark-2012.0.deb'
Makefile:79: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/build/spark-2012.0.deb'
dh_auto_build: make -j1 returned exit code 2
debian/rules:28: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/build/spark-2012.0.deb'
debian/rules:22: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
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
[Reproducible-builds] Bug#809076: bowtie2: FTBFS when CPPFLAGS contains spaces
Source: bowtie2
Version: 2.2.6-1
Severity: serious
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps fileordering
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Your package fails to build in current sid.
This usually means that you should quote CPPFLAGS before passing it
over.
Tail of the build log:
ld --parallel
dh_testdir -O--parallel
dh_auto_configure -O--parallel
debian/rules override_dh_auto_build
make[1]: Entering directory '/build/bowtie2-2.2.6'
dh_auto_build -- EXTRA_FLAGS=-Wl,-z,relro CPPFLAGS=-Wdate-time
-D_FORTIFY_SOURCE=2 WITH_TBB=1
make -j18 EXTRA_FLAGS=-Wl,-z,relro CPPFLAGS=-Wdate-time
-D_FORTIFY_SOURCE=2 WITH_TBB=1
make: invalid option -- 'D'
make: invalid option -- '_'
make: invalid option -- 'F'
Usage: make [options] [target] ...
Options:
-b, -m Ignored for compatibility.
-B, --always-make Unconditionally make all targets.
-C DIRECTORY, --directory=DIRECTORY
Change to DIRECTORY before doing anything.
-d Print lots of debugging information.
--debug[=FLAGS] Print various types of debugging information.
-e, --environment-overrides
Environment variables override makefiles.
--eval=STRING Evaluate STRING as a makefile statement.
-f FILE, --file=FILE, --makefile=FILE
Read FILE as a makefile.
-h, --help Print this message and exit.
-i, --ignore-errors Ignore errors from recipes.
-I DIRECTORY, --include-dir=DIRECTORY
Search DIRECTORY for included makefiles.
-j [N], --jobs[=N] Allow N jobs at once; infinite jobs with no arg.
-k, --keep-goingKeep going when some targets can't be made.
-l [N], --load-average[=N], --max-load[=N]
Don't start multiple jobs unless load is below N.
-L, --check-symlink-times Use the latest mtime between symlinks and target.
-n, --just-print, --dry-run, --recon
Don't actually run any recipe; just print them.
-o FILE, --old-file=FILE, --assume-old=FILE
Consider FILE to be very old and don't remake it.
-O[TYPE], --output-sync[=TYPE]
Synchronize output of parallel jobs by TYPE.
-p, --print-data-base Print make's internal database.
-q, --question Run no recipe; exit status says if up to date.
-r, --no-builtin-rules Disable the built-in implicit rules.
-R, --no-builtin-variables Disable the built-in variable settings.
-s, --silent, --quiet Don't echo recipes.
-S, --no-keep-going, --stop
Turns off -k.
-t, --touch Touch targets instead of remaking them.
--trace Print tracing information.
-v, --version Print the version number of make and exit.
-w, --print-directory Print the current directory.
--no-print-directoryTurn off -w, even if it was turned on implicitly.
-W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE
Consider FILE to be infinitely new.
--warn-undefined-variables Warn when an undefined variable is referenced.
This program built for x86_64-pc-linux-gnu
Report bugs to <bug-m...@gnu.org>
dh_auto_build: make -j18 EXTRA_FLAGS=-Wl,-z,relro CPPFLAGS=-Wdate-time
-D_FORTIFY_SOURCE=2 WITH_TBB=1 returned exit code 2
debian/rules:21: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/build/bowtie2-2.2.6'
debian/rules:18: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
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
[Reproducible-builds] package uploaded to our repo
debhelper_9.20151219.0~reproducible0.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#808541: diffoscope TypeError with openocd/0.9.0-1 in testing/amd64
Package: diffoscope Version: 44 Seen in rb.d.n with openocd/0.9.0-1 in testing/amd64: Sat Dec 19 07:03:44 UTC 2015 - diffoscope 44 will be used to compare the two builds: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/diffoscope/__main__.py", line 177, in main sys.exit(run_diffoscope(parsed_args)) File "/usr/lib/python3/dist-packages/diffoscope/__main__.py", line 148, in run_diffoscope parsed_args.file1, parsed_args.file2) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 93, in compare_root_paths return compare_files(file1, file2) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 109, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 192, in compare difference = self._compare_using_details(other, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 167, in _compare_using_details details.extend(filter(None, self.as_container.compare(other.as_container))) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 112, in compare_commented_files difference = compare_files(file1, file2, source=source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 109, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 192, in compare difference = self._compare_using_details(other, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 167, in _compare_using_details details.extend(filter(None, self.as_container.compare(other.as_container))) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 112, in compare_commented_files difference = compare_files(file1, file2, source=source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 109, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 192, in compare difference = self._compare_using_details(other, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 167, in _compare_using_details details.extend(filter(None, self.as_container.compare(other.as_container))) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 112, in compare_commented_files difference = compare_files(file1, file2, source=source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 109, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 192, in compare difference = self._compare_using_details(other, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 167, in _compare_using_details details.extend(filter(None, self.as_container.compare(other.as_container))) File "/usr/lib/python3/dist-packages/diffoscope/comparators/deb.py", line 97, in comparisons for my_member, other_member, comment in super().comparisons(other): File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils.py", line 198, in comparisons for name in sorted(my_members.keys() & other_members.keys()): TypeError: unorderable types: bytes() < str() -- 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] [Reproducible-commits] [notes] 01/01: In addition to scsh-0.6, we should not be trying to build these packages on amd64:
On Thu, Nov 26, 2015 at 09:04:19PM +0100, Holger Levsen wrote:
> another thing: I think I've seen some packages which should be tagged
> "ftbfs_due_to_virtual_dependencies" in notes.git, though OTOH I seem to
> recall pbuilder learned to cope with that. Hm.
Currently there are 0 packages tagged with that.
Anyway, pbuilder doesn't really care about this afaik, but I don't even
recall it ever caring.
For dependencies resolution it just passes the list of deps to something
else, in our cases it creates a fake .deb with the needed build-dep (=>
stripping build-profiles and arch restrictements after evaluating
them), install it and then asking aptitude to fix the deps. I believe
this can deal with virtual dep just fine (though it's not like I even
explicetely tried this out, and for sure now nothing is failing due to
that.
ISTR that tag was done due to apt saying
Depends: $pkg which is a virtual package
when it cannot find it for whatever reason (look at the depwait packages
to see). That string is actually misleading...
--
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
[Reproducible-builds] package uploaded to our repo
debhelper_9.20151126.0~reproducible0.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ 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#805321: Bug#805321: debian-installer: builds unreproducible netboot images
On Sat, Nov 28, 2015 at 12:08:44AM +, Steven Chamberlain wrote: > > FWIW, I'm not exactly entirely convinced by the exporting of the > > SOURCE_DATE_EPOCH variable from debian/rules; all other variables have > > been passed without exporting so I'm wondering if we shouldn't adapt > > this to behave like other variables, reducing possible surprise for > > users. > > Just to explain that -- if it's defined in the environment, it requires > no special handling and doesn't need to be (re-)exported. I think this > is maybe the case now for dpkg-buildpackage in sid? it's not, dpkg hasn't merged that patch (tbh I'm not even sure we forwarded that). Though debhelper exports SOURCE_DATE_EPOCH when using the dh sequencer. -- 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] Bug#801621: perl: support SOURCE_DATE_EPOCH in Pod::Man
On Sun, Nov 29, 2015 at 10:55:34AM +0200, Niko Tyni wrote:
> Russ has just fixed this upstream in podlators-4.00.
\o/
This just appeared in my RSS reader:
http://www.eyrie.org/~eagle/journal/2015-11/003.html
> I'll backport it to our 5.22 packages (but probably not 5.20 at
> this point.)
That's fine, since we've our patched perl.
Hopefully the per 5.22 transition will start soon everybody will be
happier ^^
--
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] On which arch should Arch:all packages be built? addition to scsh-0.6, we should not be trying to build these packages on amd64:
On Sun, Nov 29, 2015 at 09:57:55AM +0100, Jérémy Bobbio wrote: > Santiago Vila: > > If we had a case like this, an architecture field in the source > > package saying "i386 all" would mean that we could do all this: > > > > "dpkg-buildpackage" under i386 to build the i386.deb and the all.deb. > > "dpkg-buildpackage -A" under i386 to build only the all.deb. > > "dpkg-buildpackage -B" under i386 to build only the i386.deb. > > > > and at the same time it would be possible that the source package is > > just not designed or ready to build the all.deb under, say, amd64. > > While I agree, I really think you've identified a hole in the policy > here. Either we need a formal agreement that "i386 all" = "Arch: all" > packages must be built on i386 or an extra field somewhere to indicate > that. > > I would suggest moving the discussion to a better suited communication > channel as this is a general issue. Maybe debian-dpkg@l.d.o? I think you hit the following issue: ftbfs_build_depends_not_available_on_amd64: description: | Package build depends on some package(s), which are not available on amd64. Relevant URLs: - https://wiki.debian.org/Build-Depends-Indep - https://bugs.launchpad.net/launchpad/+bug/217427 If I understand this particular issue, I think it's the same highlighted and solved in ubuntu in that bug, with the addition of Build-Indep-Architecture. Please correct me if I'm wrong. -- 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
[Reproducible-builds] Bug#806149: diffoscope TypeError processing openjfx/8u60-b27-4
t-packages/diffoscope/difference.py", line 195, in
feed
end_nl = feeder(f)
File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 254, in
feeder
end_nl = make_feeder_from_raw_reader(command.stdout,
command.filter)(out_file)
File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 235, in
feeder
out_file.write(filter(buf))
File "/usr/lib/python3/dist-packages/diffoscope/comparators/elf.py", line 47,
in filter
return line.replace(self.path, self._basename).encode('utf-8')
TypeError: Can't convert 'bytes' object to str implicitly
--
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
[Reproducible-builds] package uploaded to our repo
debhelper_9.20151117.0~reproducible0.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#805774: diffoscope AttributeError processing bnd/2.1.0-2
re(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 80, in wrapper return original_method(self, other, *args, **kwargs) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 197, in compare difference = self._compare_using_details(other, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 170, in _compare_using_details details = [d for d in self.compare_details(other, source) if d is not None] File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 80, in wrapper return original_method(self, other, *args, **kwargs) File "/usr/lib/python3/dist-packages/diffoscope/comparators/deb.py", line 132, in compare_details differences.extend(my_container.compare(other_container)) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils.py", line 209, in compare return list(starmap(diffoscope.comparators.compare_commented_files, self.comparisons(other))) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 109, in compare_commented_files difference = compare_files(file1, file2, source=source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 106, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 80, in wrapper return original_method(self, other, *args, **kwargs) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 197, in compare difference = self._compare_using_details(other, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 170, in _compare_using_details details = [d for d in self.compare_details(other, source) if d is not None] File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 80, in wrapper return original_method(self, other, *args, **kwargs) File "/usr/lib/python3/dist-packages/diffoscope/comparators/zip.py", line 118, in compare_details differences.extend(my_container.compare(other_container)) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils.py", line 209, in compare return list(starmap(diffoscope.comparators.compare_commented_files, self.comparisons(other))) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 109, in compare_commented_files difference = compare_files(file1, file2, source=source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/__init__.py", line 106, in compare_files return file1.compare(file2, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 80, in wrapper return original_method(self, other, *args, **kwargs) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 197, in compare difference = self._compare_using_details(other, source) File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 170, in _compare_using_details details = [d for d in self.compare_details(other, source) if d is not None] File "/usr/lib/python3/dist-packages/diffoscope/comparators/binary.py", line 80, in wrapper return original_method(self, other, *args, **kwargs) File "/usr/lib/python3/dist-packages/diffoscope/comparators/zip.py", line 116, in compare_details with ZipContainer(self).open() as my_container, \ File "/usr/lib/python3.4/contextlib.py", line 59, in __enter__ return next(self.gen) File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils.py", line 261, in open self._archive = self.open_archive(self.source.path) File "/usr/lib/python3/dist-packages/diffoscope/comparators/zip.py", line 77, in open_archive return zipfile.ZipFile(path, 'r') File "/usr/lib/python3.4/zipfile.py", line 937, in __init__ self._RealGetContents() File "/usr/lib/python3.4/zipfile.py", line 974, in _RealGetContents endrec = _EndRecData(fp) File "/usr/lib/python3.4/zipfile.py", line 237, in _EndRecData fpin.seek(0, 2) AttributeError: 'bytes' object has no attribute 'seek' -- 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] ftbfs_build-indep_not_build_on_armhf, and add bochs to it
On Fri, Jun 03, 2016 at 09:13:29PM +, Santiago Vila wrote: > On Fri, Jun 03, 2016 at 04:49:10PM +, Holger Levsen wrote: > > +ftbfs_build-indep_not_build_on_armhf: > > + description: | > > +- ftbfs_build-indep_not_build_on_armhf probably this tag name should lose the 'armhf' word in it, anyway. > Sometimes, packages generating "Arch: all" binary packages have good > reasons to require that those packages are built only under certain > architectures. yes, it's an annoying thing, but it's true. I'd like to see https://bugs.launchpad.net/launchpad/+bug/217427 for that. > An "issue" suggests to me "something which has eventually to be fixed", > but frankly, I don't think we should really require that those > packages generate their "Arch: all" binary packages from any other > architecture. that was not the idea of this issue at all. It's called "issue", but it's better read as "tag" in these occasion. > So, instead of "this package needs to be fixed", those packages would > maybe deserve a "this package should not be built on such architecture > because it is simply not supposed to work". This issue, coupled with a change in jenkins code, makes possible for us to not export the failure notice towards tracker.d.o/DDPO, so maintainers should not be bothered with the "FTBFS" notice. https://anonscm.debian.org/git/qa/jenkins.debian.net.git/commit/?id=f5c5274cea8cc4d7b58e374c7114f01c07019035 > Do you think it would be possible to achieve the same result with a > "banned packages" list which is architecture-specific instead of this > funny issue? nobody likes blacklisting packages :( -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://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
[Reproducible-builds] Bug#826330: UnicodeDecodeError with psychtoolbox-3/3.0.12.20160414.dfsg1-1 in unstable/armhf
b/python3.5/threading.py", line 862, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 192, in feed end_nl = feeder(f) File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 234, in feeder for buf in in_file: File "/usr/lib/python3/dist-packages/diffoscope/comparators/deb.py", line 138, in strip_checksum for line in f: File "/usr/lib/python3.5/codecs.py", line 321, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb2 in position 3170: invalid start byte I think this is because the package is broken and produces a non-ascii md5sums in the second build with locale it_CH.UTF-8, nonetheless diffoscope should cope with it, of course. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://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
[Reproducible-builds] package uploaded to our repo
dpkg_1.18.7.0~reproducible1.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] dropping texlive from our archive
Hi humans.
I'd like to take a deeper stab at texlive.
The current status is: nearly everything was merged, but one patch.
https://anonscm.debian.org/git/reproducible/texlive-bin.git/tree/debian/patches/source-date-epoch-tex-primitives-defaults-to-1?id=c6dede514f6c724228ad6bbaa90531b27e78f1eb
That patch is basically what makes \today reproducible follow S_D_E
always instead of when somebody enables it with Yet Another Env Var.
As HW42 pointed out on IRC what's left to us is:
1) convice upstream
2) convince Debian maintainer
3) manualy fix packages
4) export a tex specific variable in debhelper
In my opinion:
1+2 were already tried, with very poor results, with both upstream and
debian maintainer not interested at all at even listening to us.
We could still try again though.
4 is a very very ugly thing which would set a very bad precendent for
debhelper.
3 is instead a reasonable choice: according to my codesearch.d.n lookup
there are 149 packages¹ with '\today' somewhere in their code.
I expect that way less than half of them are actually going to effect
output, but I'm going to put my idea of worst case here to half: 75
packages. It would still be a reasonable enough number of packages to
fix.
I think that before going to make a choice on it (even if that choice is
"prod upstream some more") we should try to move aside the patched
texlive-bin package from our archive and see how many packages are
actually affected by this.
¹ the list of the resulting packages are attached to this email, would
be nice if somebody could check it against reproducible.json (thing that
I'd do before dropping texlive-bin to be able to compare the results).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://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] Question about build environments used for i386
On Thu, May 26, 2016 at 08:08:07AM +0200, Gert Wollny wrote: > looking at the non-reproducibility of dcmtk [1], I found that for some > reason on i386 in one build cmake obtains "x86_64" as system processor > versus "i686" the in other build. That's because for i386 one build is done with a i386 kernel, and the other with a amd64 kernel, but both with a i386 userland. > CMake supposedly uses "uname -p" to obtain this information and now I'm > wondering about the build environment of the first build? `uname -p` sounds like an ugly choice, also considering this: mattia@chase ~ % uname -p unknown > Unfortunately, the provided logs are only for amd64. Not sure what are you referring to here. For i386 there are both logs for build builds done on i386. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://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] [buildd-tools-devel] Bug#825991: Bug#825991: sbuild: /etc/sbuild/sbuild.conf leaks the user home path
On Wed, Jun 01, 2016 at 11:08:27AM +0200, Johannes Schauer wrote:
> Though I am surprised that the reproducible builds machinery didn't catch this
> at all. It seems that sbuild is still marked as reproducible:
>
> https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/sbuild.html
>
> Is there something wrong with how $HOME is set in the reproducible builds
> pbuilder?
It wasn't varied, indeed. Now it is, and sbuild is not reproducible
anymore:
https://tests.reproducible-builds.org/rb-pkg/unstable/armhf/sbuild.html
Thanks for bringing this up.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://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] dropping texlive from our archive
On Wed, Jun 01, 2016 at 10:16:40AM +0200, Alexis Bienvenüe wrote:
> Note that when the TeX primitives do not honour S_D_E, xetex output is
> not reproducible (even if \today is not used) because of the /Creator
> string which includes a date that is build from these primitives :
>
> https://anonscm.debian.org/cgit/debian-tex/texlive-bin.git/tree/texk/web2c/xetexdir/xetex.web#n13872
>
> So solution 3 should include a bugfix to make xetex's Creator string
> either strip the build date either honour S_D_E.
Consider that that's a thing in the PDF header.
We should be able to have that thing not to use the same primitives, or
anyway have that follows SDE.
Such a part alone might have a chance to be accepted upstream, as IIUC
their main concern was about changing the actual visible output, but
they should be fine with changing the headers (as they already did in
other parts).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://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
[Reproducible-builds] package uploaded to our repo
doxygen_1.8.11-2.0~reproducible0.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] FontForge needs a new patch to learn about S_D_E
FYI:
On Tue, May 10, 2016 at 11:43:53AM +, Mattia Rizzolo wrote:
> Our FontForge package is unused since quite some time.
> While rebasing it wouldn't be hard, it actually needs some more work.
I've now moved the package away from our apt repository into the "attic"
at https://reproducible.alioth.debian.org/old-packages/
I haven't touched the git repository.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://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
[Reproducible-builds] package uploaded to our repo
findutils_4.6.0+git+20160517-3.0~reproducible0.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] licencing reproducible/presentations.git
On Thu, Feb 04, 2016 at 11:07:41AM +0100, Holger Levsen wrote: > but in any case the question is: are you fine to licence your work under > Creative Commons Attribution-Share Alike 3.0 License or (at the choice of the I'm going to assume you mean the unported "variant" here. > user of the works) under GNU Free Documentation License, Version 1.3 or > later, > with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts? > > If so: please reply to this mail. I'm ok with this. (even if I'm not sure why we would want to double license them with the GFDL..) > Unless I hear compelling not to, I will go with the full list of contributors > as copyright owners and I also only plan to stick this licence on the FOSDEM > 16 talk and future ones. btw, to the question "can slides have a different license than videos", I'm tempted to see the recordings as a derivative work of the slides when they also frame them (the projection), so I'd say that the videos needs to be in compliant (which doesn't necessary mean it's the same) license as the slides, not the other way around. Anyway, I'm just playing evil's advocate, I'm fine with anything that's DFSG-ok for whatever contribution I did, just heed to be compatible to what we used inside (images?) and to what already derivated from them (videos?). -- 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] Bug#812428: libgcrypt20: please make the build reproducible (timestamps)
On Sun, Jan 24, 2016 at 05:00:55PM +0100, Axel Beckert wrote:
> Hi again,
>
> Axel Beckert wrote:
> > > /usr/share/doc/autotools-dev/README.Debian.gz says:
> > >
> > > >> Do NOT use dh-autoreconf and dh_autotools-dev_* helpers at the same
> > > >> time, dh-autoreconf takes care of updating config.sub and
> > > >> config.guess by itself.
> >
> > It still says that? I thought that got fixed.
>
> Yeah, in dh-autoreconf (#698765), but not in autotools-dev obviously.
> Will file a bug report for that, too.
Please also have a look at https://wiki.debian.org/Autoreconf
Now, the cases where autotools-dev *and* autoreconf are needed are/were
pretty rare.
Furthermore consider that since the last debhelper release
config.{sub,guess} are automatically updated before the build by
dh_update_autotools_config(1), so I believe calling autotools-dev
manually now is more useless than ever.
IOW: it's probably better/cleaner to just remove --with autotools-dev.
--
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
[Reproducible-builds] Bug#807669: Bug#807669: dh-strip-nondeterminism: Breaks some jar file
On Tue, Jan 26, 2016 at 03:07:33PM +0100, Jérémy Bobbio wrote: > Control: tag -1 + patch > > Raphael Hertzog: > > On Mon, 14 Dec 2015, Raphael Hertzog wrote: > > > Your analysis is correct but dh_strip_nondeterminisn should detect the > > > signature and avoid messing up with the file in that case. > > > > > > That's what this bug is about. > > > > And we got another case where dh_strip_nondeterminism actually broke a > > working package... https://bugs.kali.org/view.php?id=3019 > > > > Is there anything we can do to ensure that this bug gets a timely fix? > > Attached is a patch which I think could work. I'm not confident enough > in my Perl skills to commit directly though. Andrew, can you please look at this? TBH, this kind of bug would fit my definition of severity:serious, it's not nice to break other packages :) -- 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
