[Reproducible-builds] Bug#793580: FTBFS: missing build-dep on B::Hooks::Parser::Install::Files(?)
Source: libsignatures-perl Version: 0.12-1 Severity: serious Tags: sid stretch Justification: fails to build from source (but built successfully in the past) User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs Dear Maintainer, The package fails to build: dh_auto_configure perl Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2" "LD=cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" *** Can't load dependency information for B::Hooks::Parser: Can't locate B/Hooks/Parser/Install/Files.pm in @INC (you may need to install the B::Hooks::Parser::Install::Files module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at /usr/share/perl5/ExtUtils/Depends.pm line 185. Full build log: https://reproducible.debian.net/rb-pkg/unstable/amd64/libsignatures-perl.html -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.19.0-23-generic (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#793581: FTBFS: Can't exec "automake-1.14" [..] Autom4te/FileUtils.pm
Source: libgadu
Version: 1:1.12.0-5
Severity: serious
Tags: sid stretch
Justification: fails to build from source (but built successfully in the past)
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Dear Maintainer,
The package fails to build:
libtoolize: copying file `m4/lt~obsolete.m4'
Can't exec "automake-1.14": No such file or directory at
/usr/share/autoconf/Autom4te/FileUtils.pm line 326, line 5.
autoreconf: failed to run automake-1.14: No such file or directory
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: autoreconf -f -i returned exit code 1
debian/rules:19: recipe for target 'build' failed
Looks like automake transitioned 1.14 -> 1.15 ~ 2015-07-15.
Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/libgadu.html
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.19.0-23-generic (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#793582: FTBFS: geronimo/mail/Activator.java: error: package org.apache.geronimo.osgi.locator does not exist
Source: geronimo-javamail-1.4-spec
Version: 1.7.1-2
Severity: serious
Tags: sid stretch
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Dear Maintainer,
The package fails to build:
Get: 160 http://ftp.de.debian.org/debian/ unstable/main
libgeronimo-osgi-support-java all 1.1-1 [22.6 kB]
Get: 161 http://ftp.de.debian.org/debian/ unstable/main
libgeronimo-jpa-2.0-spec-java all 1.1-2 [81.0 kB]
[javac]
/geronimo-javamail-1.4-spec-1.7.1/src/main/java/javax/mail/Session.java:43:
error: package org.apache.geronimo.osgi.locator does not exist
[javac] import org.apache.geronimo.osgi.locator.ProviderLocator;
[javac]^
[javac]
/geronimo-javamail-1.4-spec-1.7.1/src/main/java/org/apache/geronimo/mail/Activator.java:41:
error: package org.apache.geronimo.osgi.locator does not exist
[javac] public class Activator extends
org.apache.geronimo.osgi.locator.Activator {
[javac]^
[javac]
/geronimo-javamail-1.4-spec-1.7.1/src/main/java/javax/mail/Session.java:492:
error: cannot find symbol
[javac] clazz =
ProviderLocator.loadClass(provider.getClassName(), this.getClass(), cl);
Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/geronimo-javamail-1.4-spec.html
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.19.0-23-generic (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#793588: FTBFS: ERROR: dependency ‘foreach’ is not available for package ‘gam’
Source: r-cran-gam Version: 1.12-1 Severity: serious Tags: sid Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs Dear Maintainer, The package fails to build: dh_installdirs usr/lib/R/site-library echo "R:Depends=r-base-core (>= 3.2.1-4), r-api-3" >> debian/r-cran-gam.substvars if test -f /usr/bin/xvfb-run; then \ MAKEFLAGS="LDFLAGS=-Wl,-z,relro" xvfb-run -a \ R CMD INSTALL -l /r-cran-gam-1.12/debian/r-cran-gam/usr/lib/R/site-library --clean \ . \ "--built-timestamp=\"Tue, 14 Jul 2015 20:03:17 -0400\"" \ ; \ else\ MAKEFLAGS="LDFLAGS=-Wl,-z,relro" R CMD INSTALL -l /r-cran-gam-1.12/debian/r-cran-gam/usr/lib/R/site-library \ --clean . \ "--built-timestamp=\"Tue, 14 Jul 2015 20:03:17 -0400\"" \ ; \ fi ERROR: dependency ‘foreach’ is not available for package ‘gam’ * removing ‘/r-cran-gam-1.12/debian/r-cran-gam/usr/lib/R/site-library/gam’ /usr/share/R/debian/r-cran.mk:98: recipe for target 'R_any_arch' failed Full build log: https://reproducible.debian.net/rb-pkg/unstable/amd64/r-cran-gam.html -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.19.0-23-generic (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#793586: FTBFS: POM 'org.codehaus.modello:modello-maven-plugin' not found in repository
Source: maven-javadoc-plugin Version: 2.9.1-2 Severity: serious Tags: sid stretch Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs Dear Maintainer, The package fails to build: [INFO] Scanning for projects... [INFO] [INFO] Building Apache Maven Javadoc Plugin [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.codehaus.modello:modello-maven-plugin Reason: POM 'org.codehaus.modello:modello-maven-plugin' not found in repository: System is offline. org.codehaus.modello:modello-maven-plugin:pom:1.1 for project org.codehaus.modello:modello-maven-plugin Full build log: https://reproducible.debian.net/rb-pkg/unstable/amd64/maven-javadoc-plugin.html -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.19.0-23-generic (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#793590: FTBFS: require(/phpunit-dbunit-1.4.0/PHPUnit/TestCase.php): No such file or directory
Source: phpunit-dbunit Version: 1.4.0-1 Severity: serious Tags: sid stretch Justification: fails to build from source User: reproducible-builds@lists.alioth.debian.org Usertags: ftbfs Dear Maintainer, The package fails to build: phpunit: phpunit: [exec] PHP Warning: require(/phpunit-dbunit-1.4.0/PHPUnit/TestCase.php): failed to open stream: No such file or directory in /phpunit-dbunit-1.4.0/PHPUnit/Extensions/Database/Autoload.php on line 124 [exec] PHP Fatal error: require(): Failed opening required '/phpunit-dbunit-1.4.0/PHPUnit/TestCase.php' (include_path='.:/usr/share/php:/usr/share/pear') in /phpunit-dbunit-1.4.0/PHPUnit/Extensions/Database/Autoload.php on line 124 BUILD FAILED /phpunit-dbunit-1.4.0/build.xml:150: exec returned: 255 Full build log: https://reproducible.debian.net/rb-pkg/unstable/amd64/phpunit-dbunit.html -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.19.0-23-generic (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Your message to Pkg-mozext-maintainers awaits moderator approval
Your mail to 'Pkg-mozext-maintainers' with the subject https-everywhere changed: unreproducible -> reproducible Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.alioth.debian.org/cgi-bin/mailman/confirm/pkg-mozext-maintainers/c818c37867368fdaeffa5e3a3f4b8080fa04a95e ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] GSoC 2015 Week 9: Move forward reproducible builds
Hi, This week I have patched the two remaining packages tagged by the issue timestamps_difference_by_unzip [1], plus another one also affected by this issue which wasn't tagged: - torbutton https://bugs.debian.org/793126 - pdf.js https://bugs.debian.org/793127 - deejayd https://bugs.debian.org/793300 I have been looking at a package affected by timestamps in zip (moin). I managed to get rid of some of the unreproducibility issues: the timestamps in the metadata shown by zipinfo, out of which some are files mtimes that differ by timezone (solved by settings TZ=UTC before zip/unzip calls), and others are localtime timestamps (solved by replacing timestamps with SOURCE_DATE_EPOCH). After this, some differences still appear, now not seen by zipinfo but in the file treated in binary form. This package adds files to zip through a python script during the build. It requieres further study. I have also studied the issue pdf_created_by_ghostscript [2] which has 18 unreproducible affected packages. There was a tentative patch for ghostcript in our git repository from January, but it had never been submited. The patch allowed the embedded timestamps to be replaced by an exported variable, originally DEB_BUILD_TIMESTAMP, which I changed to SOURCE_DATE_EPOCH to follow our current normalized timestamp proposal. I have also added code to normalize the timezone to UTC in case SOURCE_DATE_EPOCH is used, so that the results are timezone invariant. The commit with the patch can be found at: https://anonscm.debian.org/cgit/reproducible/ghostscript.git/commit/?h=pu/reproducible_builds I have also uploaded the package in our APT repository. I have tested this patched ghostscript with some of the packages affected by pdf_created_by_ghostscript. Unluckily none of them become reproducible without any change. This is because the commands to generate the documentation that use ghostscript don't happen under dh, which currently is the only place where SOURCE_DATE_ECPOH is automatically exported. Upon exporting this variable manually in debian/rules, I obtained the following results: - glosstex (becomes reproducible) - kimwitu++ (timestamp differences from ghostscript disappear. Remaining timestamps come from pdflatex due to timezone variation, akira is working on that) - autoconf (timestamp differences from ghostscript disappear. Remaining timestamps come from other places, further inspection requiered) - cvs (same results obtained, it seems this package was misstagged and actually uses latex to produce pdfs) - proxy-suite (becomes reproducible) - lprng-doc (becomes reproducible) - gstreamer1.0 (timestamp differences from ghostscript disappear. Variable timestamps in .ps files remain, further inspection requiered) - transfig (timestamp differences from ghostscript disappear. Remaining timestamps come from pdflatex due to timezone variation, akira is working on that) For next week I plan to send the ghostscript patches to debian and probably upstream. I'll look further at the remaining issues from the packages I studied this week (the ones affected by pdf_created_by_ghostscript). I may continue looking into moin. [1] https://reproducible.debian.net/issues/unstable/timestamps_difference_by_unzip_issue.html [2] https://reproducible.debian.net/issues/pdf_created_by_ghostscript_issue.html Best regards, Dhole pgpEZnyRJinWQ.pgp Description: OpenPGP 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
Hi Dhole, thanks for your continious reports and cheers and kudos for all the nice work! Besides thinking "yay" this sparked one question: 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[...] [general comment, more or less] 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?!?) Another option would be to file a tracking bug against qa.d.o (usertagged reproducible.d.n) for patch development + tracking...?!? cheers, Holger, who really loves bug #s but maybe a bit too much... ;-) signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#793648: htdig: please make the build reproducible
Source: htdig Version: 1:3.2.0b6-13 Severity: wishlist Tags: patch User: reproducible-builds@lists.alioth.debian.org Usertags: environment X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Hi, While working on the "reproducible builds" effort [1], we have noticed that htdig could not be built reproducibly. The attached patch removes the (rather useless) Makefiles from the html docs dir, in particular Makefile.gz which captured environment from the build system (eg. USER, etc). Once applied, htdig can be built reproducibly in our reproducible toolchain. [1]: https://wiki.debian.org/ReproducibleBuilds Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diff --git a/debian/rules b/debian/rules index 1457d59..c224a51 100755 --- a/debian/rules +++ b/debian/rules @@ -54,6 +54,7 @@ binary-indep: build debian/htdig-doc/usr/share/doc/htdig-doc/examples/htdig mkdir -p debian/htdig-doc/usr/share/doc/htdig-doc/html cp -r htdoc/* debian/htdig-doc/usr/share/doc/htdig-doc/html + rm -f debian/htdig-doc/usr/share/doc/htdig-doc/html/Makefile* rm -f debian/htdig-doc/usr/share/doc/htdig-doc/html/COPYING rm -f debian/htdig-doc/usr/share/doc/htdig-doc/examples/rtf2html/COPYING rmdir debian/htdig-doc/usr/share/doc/htdig-doc/examples/xmlsearch ___ 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
