[Reproducible-builds] Bug#794239: zipios++: please make the build reproducible (timestamps)
Source: zipios++ Version: 0.1.5.9+cvs.2007.04.28-5.1 Severity: wishlist Tags: patch User: reproducible-builds@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Hi! While working on the “reproducible builds” effort [1], we have noticed that zipios++ could not be built reproducibly since it suffers from timestamps in manpages generated by doxygen [2]. The reproducible builds team is building packages using a version of doxygen which has been patched to honour the environment variable $SOURCE_DATE_EPOCH [3]. This results in doxygen using the last date in debian/changelog as the timestamp for its man page output which causes packages to become reproducible [4]. During our tests $SOURCE_DATE_EPOCH is exported by the debhelper from our experimental git repository which we have patched such that packages using dh (debhelper = 9) in debian/rules become automatically reproducible. This unfortunately does not make the package zipios++ reproducible because it does not use dh in debian/rules but instead classic debhelper. There are two solutions for zipios++ : 1. To rewrite debian/rules to use dh 2. To implement the attached patch which exports $SOURCE_DATE_EPOCH in debian/rules. Kind Regards, akira [1] https://wiki.debian.org/ReproducibleBuilds/About [2]https://reproducible.debian.net/issues/unstable/timestamps_in_manpages_generated_by_doxygen_issue.html [3] https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal [4] https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain#doxygen diff -u zipios++-0.1.5.9+cvs.2007.04.28/debian/changelog zipios++-0.1.5.9+cvs.2007.04.28/debian/changelog --- zipios++-0.1.5.9+cvs.2007.04.28/debian/changelog +++ zipios++-0.1.5.9+cvs.2007.04.28/debian/changelog @@ -1,3 +1,11 @@ +zipios++ (0.1.5.9+cvs.2007.04.28-5.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Export environment variable $SOURCE_DATE_EPOCH to produce reproducible +timestamps in manpage output + + -- akira marival...@gmail.com Fri, 31 Jul 2015 14:14:33 +0200 + zipios++ (0.1.5.9+cvs.2007.04.28-5.1) unstable; urgency=low * Non-maintainer upload. diff -u zipios++-0.1.5.9+cvs.2007.04.28/debian/rules zipios++-0.1.5.9+cvs.2007.04.28/debian/rules --- zipios++-0.1.5.9+cvs.2007.04.28/debian/rules +++ zipios++-0.1.5.9+cvs.2007.04.28/debian/rules @@ -10,6 +10,8 @@ DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +export SOURCE_DATE_EPOCH = $(shell date -d $$(dpkg-parsechangelog --count 1 -SDate) +%s) + # Include dpatch stuff. include /usr/share/dpatch/dpatch.make signature.asc 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
[Reproducible-builds] dpkg_1.18.1.0~reproducible5 ftbfs
Hi, so yesterday I tried to build http://reproducible.alioth.debian.org/debian/dpkg_1.18.1.0~reproducible5.dsc with pbuilder on sid/armhf and that failed _exactly_ like https://reproducible.debian.net/rbuild/unstable/amd64/dpkg_1.18.1.0~reproducible5.rbuild.log I then tried to build dpkg_1.18.1.dsc from sid proper and that built flawlessly on sid/armhf. Thus I conclude our reproducible patches cause this, whatever this is. Yet I lack time atm to debug this, so this mail is merely a note to Guillem and a call for help to the reproducible folks. I've now also added dpkg to the https://reproducible.debian.net/issues/unstable/ftbfs_in_jenkins_setup_issue.html issues, which will make sure the ftbfs issue will soon (tomorrow, I think) not show up on https://tracker.debian.org/pkg/dpkg anymore. cheers, Holger (Note that the armhf build environment is a clean sid system, without any packages from our toolchain whatsoever.) 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#794225: libsyncml: please make the build reproducible (timestamps)
Source: libsyncml Version: 0.5.4-2.2 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 libsyncml could not be built reproducibly since it suffers from timestamps in manpages generated by doxygen [2]. The reproducible builds team is building packages using a version of doxygen which has been patched to honour the environment variable $SOURCE_DATE_EPOCH [3]. This results in doxygen using the last date in debian/changelog as the timestamp for its man page output which causes packages to become reproducible [4]. During our tests $SOURCE_DATE_EPOCH is exported by the debhelper from our experimental git repository which we have patched such that packages using dh (debhelper = 9) in debian/rules become automatically reproducible. This unfortunately does not make the package libsyncml reproducible because it does not use dh in debian/rules but instead classic debhelper. There are two solutions for libsyncml: 1. To rewrite debian/rules to use dh 2. To implement the attached patch which exports $SOURCE_DATE_EPOCH in debian/rules. Kind Regards, akira [1] https://wiki.debian.org/ReproducibleBuilds/About [2] https://reproducible.debian.net/issues/unstable/timestamps_in_manpages_generated_by_doxygen_issue.html [3] https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal [4] https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain#doxygen Cheers, akira diff -u libsyncml-0.5.4/debian/changelog libsyncml-0.5.4/debian/changelog --- libsyncml-0.5.4/debian/changelog +++ libsyncml-0.5.4/debian/changelog @@ -1,3 +1,11 @@ +libsyncml (0.5.4-2.3) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Export environment variable $SOURCE_DATE_EPOCH to produce reproducible +timestamps in manpage output + + -- akira marival...@gmail.com Fri, 31 Jul 2015 11:21:17 +0200 + libsyncml (0.5.4-2.2) unstable; urgency=medium * Non-maintainer upload. diff -u libsyncml-0.5.4/debian/rules libsyncml-0.5.4/debian/rules --- libsyncml-0.5.4/debian/rules +++ libsyncml-0.5.4/debian/rules @@ -11,6 +11,8 @@ DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +export SOURCE_DATE_EPOCH = $(shell date -d $$(dpkg-parsechangelog --count 1 -SDate) +%s) + CFLAGS = -Wall -g ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O0 signature.asc 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
[Reproducible-builds] Bug#794241: cdbs: please export $SOURCE_DATE_EPOCH to produce reproducible output
Source: cdbs Version: 0.4.130 Severity: wishlist Tags: patch User: reproducible-builds@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org Hi! The Debian reproducible builds team [1] recently proposed a new environment variable $SOURCE_DATE_EPOCH to be used by packages to produce reproducible timestamps (for example in documentation) [2]. This environment variable is currently being exported by debhelper from our experimental git repository which we have patched such that packages using dh (debhelper = 9) in debian/rules become automatically reproducible. The patch to debhelper does not affect packages which use cdbs as their build system. Therefore I propose the attached patch which makes cdbs export $SOURCE_DATE_EPOCH. A version of cdbs with this patch is currently being used in the reproducible builds git repository and it has been successful at making a package become reproducible. This bug is in addition to this other bug from the reproducible builds team: https://bugs.debian.org/764478 Kind Regards, akira [1] https://wiki.debian.org/ReproducibleBuilds/About [2] https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal diff --git a/1/rules/debhelper.mk.in b/1/rules/debhelper.mk.in index 2aec68d..7be6d72 100644 --- a/1/rules/debhelper.mk.in +++ b/1/rules/debhelper.mk.in @@ -75,6 +75,8 @@ # Completely override argument passing to dh_perl. +export SOURCE_DATE_EPOCH = $(shell date -d $$(dpkg-parsechangelog --count 1 -SDate) +%s) + #PATH_RULES# ifndef _cdbs_rules_debhelper diff --git a/debian/changelog b/debian/changelog index be3a7ed..5b10c15 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +cdbs (0.4.130.0~reproducible3) UNRELEASED; urgency=medium + + * Export environment variable $SOURCE_DATE_EPOCH to produce reproducible +output + + -- akira marival...@gmail.com Wed, 29 Jul 2015 16:07:07 +0200 + cdbs (0.4.130.0~reproducible2) UNRELEASED; urgency=medium * Remove call of dh_fixmtimes, which is now part of dh_builddeb. signature.asc 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] dpkg_1.18.1.0~reproducible5 ftbfs
Hi! On Fri, 2015-07-31 at 16:49:13 +0200, Holger Levsen wrote: so yesterday I tried to build http://reproducible.alioth.debian.org/debian/dpkg_1.18.1.0~reproducible5.dsc with pbuilder on sid/armhf and that failed _exactly_ like https://reproducible.debian.net/rbuild/unstable/amd64/dpkg_1.18.1.0~reproducible5.rbuild.log I then tried to build dpkg_1.18.1.dsc from sid proper and that built flawlessly on sid/armhf. Thus I conclude our reproducible patches cause this, whatever this is. Yet I lack time atm to debug this, so this mail is merely a note to Guillem and a call for help to the reproducible folks. Right, I noticed this quite some time ago, but forgot to bring it up. W/o having checked anything, it might be that whoever prepared the release perhaps forgot to «autoreconf -f -i» the sources and prepared it from a previous .dsc instead of a git tree? I've now also added dpkg to the https://reproducible.debian.net/issues/unstable/ftbfs_in_jenkins_setup_issue.html issues, which will make sure the ftbfs issue will soon (tomorrow, I think) not show up on https://tracker.debian.org/pkg/dpkg anymore. Appreciated. Thanks, Guillem ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#794270: FTBFS: oniguruma.h: error: conflicting types for 'OnigUChar'
Source: ruby-mkrf Version: 0.2.3+dfsg-5 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: In file included from /usr/include/ruby-2.1.0/ruby/encoding.h:23:0, from /usr/include/ruby-2.1.0/ruby/io.h:24, from /usr/include/ruby-2.1.0/ruby/backward/rubyio.h:6, from libxml.h:17, from libxml.c:5: /usr/include/ruby-2.1.0/ruby/oniguruma.h:108:15: error: conflicting types for 'OnigUChar' #define UChar OnigUChar ^ /usr/include/ruby-2.1.0/ruby/oniguruma.h:111:24: note: previous declaration of 'OnigUChar' was here typedef unsigned char OnigUChar; ^ rake aborted! Command failed with status (1): [gcc -fPIC -g -O2 -fstack-protector-strong ...] Full build log: https://reproducible.debian.net/rb-pkg/unstable/amd64/ruby-mkrf.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#794275: FTBFS: tests fail: undefined method `have' for #RSpec::ExampleGroups::OrgmodeHeadline:
Source: ruby-org Version: 0.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: 2) Orgmode::Headline should understand a single tag Failure/Error: h.should have(1).tags NoMethodError: undefined method `have' for #RSpec::ExampleGroups::OrgmodeHeadline:0x00022b5398 # ./spec/headline_spec.rb:49:in `block (2 levels) in top (required)' 3) Orgmode::Line should tell comments Failure/Error: line.comment?.should be_true expected 0 to respond to `true?` or perhaps you meant `be true` or `be_truthy` # ./spec/line_spec.rb:9:in `block (3 levels) in top (required)' # ./spec/line_spec.rb:7:in `each' # ./spec/line_spec.rb:7:in `block (2 levels) in top (required)' 210 examples, 39 failures Full build log: https://reproducible.debian.net/rb-pkg/unstable/amd64/ruby-org.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#794274: FTBFS: tests fail: undefined method `stub!' for #OmniAuth::Strategies::GitHub
Source: ruby-omniauth-github Version: 1.1.2-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: 1) OmniAuth::Strategies::GitHub client options should have correct site Failure/Error: subject.stub!(:access_token).and_return(access_token) NoMethodError: undefined method `stub!' for #OmniAuth::Strategies::GitHub # ./spec/omniauth/strategies/github_spec.rb:28:in `block (2 levels) in top (required)' 2) OmniAuth::Strategies::GitHub client options should have correct authorize url Failure/Error: subject.stub!(:access_token).and_return(access_token) NoMethodError: undefined method `stub!' for #OmniAuth::Strategies::GitHub # ./spec/omniauth/strategies/github_spec.rb:28:in `block (2 levels) in top (required)' Full build log: https://reproducible.debian.net/rb-pkg/unstable/amd64/ruby-omniauth-github.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#794267: FTBFS: in `block in const_missing': uninitialized constant RSpec::Runner (NameError)
Source: ruby-merb-assets Version: 1.1.3-2 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: /usr/bin/ruby2.1 /usr/bin/rspec --pattern ./spec/\*_spec.rb ~ No Gemfile found! If you're generating new app with merb-gen this is fine, otherwise run: bundle init to create Gemfile Digest::Digest is deprecated; use Digest /usr/lib/ruby/vendor_ruby/rspec/core.rb:179:in `block in const_missing': uninitialized constant RSpec::Runner (NameError) from /usr/lib/ruby/vendor_ruby/rspec/core.rb:179:in `fetch' from /usr/lib/ruby/vendor_ruby/rspec/core.rb:179:in `const_missing' from /tmp/buildd/ruby-merb-assets-1.1.3/spec/spec_helper.rb:21:in `top (required)' from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /tmp/buildd/ruby-merb-assets-1.1.3/spec/merb-assets_spec.rb:1:in `top (required)' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1327:in `load' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1327:in `block in load_spec_files' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1325:in `each' from /usr/lib/ruby/vendor_ruby/rspec/core/configuration.rb:1325:in `load_spec_files' from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:103:in `setup' from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:89:in `run' from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:74:in `run' from /usr/lib/ruby/vendor_ruby/rspec/core/runner.rb:42:in `invoke' from /usr/bin/rspec:4:in `main' /usr/bin/ruby2.1 /usr/bin/rspec --pattern ./spec/\*_spec.rb failed ERROR: Test ruby2.1 failed. Exiting. Full build log: https://reproducible.debian.net/rb-pkg/unstable/amd64/ruby-merb-assets.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#794268: FTBFS: Mercenary::Option compares itself with other options well fails
Source: ruby-mercenary Version: 0.3.4-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: Failures: 1) Mercenary::Option compares itself with other options well Failure/Error: expect(option.eql?(new_option)).to be_true expected true to respond to `true?` or perhaps you meant `be true` or `be_truthy` # ./spec/option_spec.rb:31:in `block (2 levels) in top (required)' Full build log: https://reproducible.debian.net/rb-pkg/unstable/amd64/ruby-mercenary.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#794272: FTBFS: 'parse a valid XML document with an attribute type=boolean' and others fail
Source: ruby-multi-xml
Version: 0.5.5-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:
Failures:
1) MultiXml LibXML parser behaves like a parser .parse a valid XML document
with an attribute type=boolean when true returns true
Failure/Error: expect(MultiXml.parse(xml)['tag']).to
instance_eval(be_#{boolean})
expected true to respond to `true?` or perhaps you meant `be true` or
`be_truthy`
Shared Example Group: a parser called from ./spec/multi_xml_spec.rb:37
# ./spec/parser_shared_example.rb:148:in `block (7 levels) in top
(required)'
2) MultiXml LibXML parser behaves like a parser .parse a valid XML document
with an attribute type=boolean when false returns false
Failure/Error: expect(MultiXml.parse(xml)['tag']).to
instance_eval(be_#{boolean})
expected false to respond to `false?` or perhaps you meant `be false` or
`be_falsey`
Shared Example Group: a parser called from ./spec/multi_xml_spec.rb:37
# ./spec/parser_shared_example.rb:148:in `block (7 levels) in top
(required)'
Finished in 0.44516 seconds (files took 1.03 seconds to load)
328 examples, 16 failures
Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/ruby-multi-xml.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#794247: whizzytex: please make the build reproducible
Source: whizzytex
Version: 1.3.2-1.3
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 whizzytex could not be built reproducibly.
The attached patch removes timestamps from the documentation. Once
applied, whizzytex can be built reproducibly in our current experimental
framework.
[1]: https://wiki.debian.org/ReproducibleBuilds
Regards,
--
Dhole
diff -Nru whizzytex-1.3.2/debian/changelog whizzytex-1.3.2/debian/changelog
--- whizzytex-1.3.2/debian/changelog2014-09-15 04:44:18.0 +0200
+++ whizzytex-1.3.2/debian/changelog2015-07-31 16:10:39.0 +0200
@@ -1,3 +1,10 @@
+whizzytex (1.3.2-1.4) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Timestamp removed from docs to make package build reproducibly.
+
+ -- Eduard Sanou dh...@openmailbox.org Fri, 31 Jul 2015 16:10:22 +0200
+
whizzytex (1.3.2-1.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru whizzytex-1.3.2/debian/patches/remove_docs_timestamp.patch
whizzytex-1.3.2/debian/patches/remove_docs_timestamp.patch
--- whizzytex-1.3.2/debian/patches/remove_docs_timestamp.patch 1970-01-01
01:00:00.0 +0100
+++ whizzytex-1.3.2/debian/patches/remove_docs_timestamp.patch 2015-07-31
16:11:06.0 +0200
@@ -0,0 +1,21 @@
+Description: Remove timestamp from docs
+ .
+ whizzytex (1.3.2-1.4) UNRELEASED; urgency=medium
+ .
+ * Non-maintainer upload.
+ * Timestamp removed from docs to make package build reproducibly.
+Author: Eduard Sanou dh...@openmailbox.org
+
+---
+
+--- whizzytex-1.3.2.orig/doc/manual.tex
whizzytex-1.3.2/doc/manual.tex
+@@ -43,7 +43,7 @@
+ \end{rawhtml}
+ \pagestyle {empty}
+ \author {\rightline {Didier R{\'e}my}}
+-\date {\hfill Version {\version}, \today}
++\date {\hfill Version {\version}}
+ \begingroup
+ \let \@\relax
+ \title {
diff -Nru whizzytex-1.3.2/debian/patches/series
whizzytex-1.3.2/debian/patches/series
--- whizzytex-1.3.2/debian/patches/series 2013-10-06 09:16:11.0
+0200
+++ whizzytex-1.3.2/debian/patches/series 2015-07-31 16:10:51.0
+0200
@@ -1,3 +1,4 @@
07_bash_makefile.patch
09_compat_config.patch
11_boxsep_boolean.patch
+remove_docs_timestamp.patch
signature.asc
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] proposal: store information in one place instead of multiple ones
Johannes Schauer: here are several questions I have which, for me boil down to information being duplicated and stored in different locations, leading to possible confusion for contributors and added work when adding new bugs and issues: Before I go further with answering: it seems you assume there's well-thoughts reasons for the current state of things. For most of your questions, that is not the case. Things grew organically from experiments and different people making things better when they see they could. 1. Why is the set of bts usertags different from the set of r-b issues? The bts usertags seem to be way more broad. That was their point initially. I wanted to be able to make statistics on which kind of class of issues were most prevalent. A solution would be to ditch the current usertags and use the issue names instead. This would allow a one-to-one mapping between issue and bug number. This would make creating a new issue much harder. Usertags are not a nice part of the BTS to interact with. We have been adding a couple issues every week for a good while. See the weekly reports. 2. Why does packages.yml store the bug number(s) for each package? This information can easily retrieved from the bts and then will also not be outdated. packages.yml easily lags behind the actual bts information if not regularly updated by someone. packages.yml was meant to be self-contained at first. Some bugs affecting reproducibility could not be reproducibility issues per-se. 3. Why are the issues explained in issues.yml *and* in the wiki? There should be one canonical place to describe them because currently, any new issue that is identified requires to edit multiple resources and then link between the two. This not only requires more work when creating the issue but when looking up issues it is also unclear which resource is the authoritative one and which one will give the desired information. Instead, the information should be stored in one place only. Here I can see a real reason: they have different audiences. issues.yml is mainly for people involved in the whole effort where the wiki page should be accessible to maintainers of a single package. Some issues are systemic and individual maintainer should not really care about these. The wiki has a richer syntax and makes nicer page. So my proposal is: 1. Instead of using the current usertags toolchain, infrastructure, timestamps and so on, use issue names instead. Since each bugs can have multiple usertags, the old tags could even be kept and the issue names be added in addition. Since packages.yml exists, much of this conversion could probably be even automated (except for packages with more than one bug open for them). Sometimes, reproducibility problems only affect a single package and in that case it would create too much overhead to create a new issue for it. But in that case, why not just create a dummy issue just for the purpose to associate this kind of bugs to the reproducible builds team? I tend to feel this would be much less flexible than how we currently do things. We don't have an issue for every single type of patch. 2. Do not add bug numbers to packages.yml. The bts already stores the information which source package has which bugs by the reproducible builds team. That means we have to tag every bug that affects the build on our environment. I don't like the idea that much, but since Faux started adding `ftbfs`, I guess this opened the gates. 3. Use the wiki only to describe issues and ditch issues.yml. The advantages are that the Debian wiki offers a much richer syntax and is also editable by everybody in Debian and not only the reproducible builds team. Creating a page on the wiki is much more work than adding a couple of lines in issues.yml. Categorizing issues is not a super-fun task, and the less frictions there are, the better. I've seen myself being lazy and even if I saw a pattern, not create an issue straight away because I wanted to avoid interacting with the wiki. 4. After this is done, it is hard to say why the notes.git is useful in the first place. The content of issues.yml is described in the Debian wiki and the bug numbers are stored in the bts. One last task of packages.yml would probably be to store some tiny notes for packages for which there doesn't exist a bug. But I'd say to also move these notes into the bts. I think that filing a bug about a package's unreproducibility should be done even without having a fix for it. In fact many packages with such bugs exist simply for the reason that at the time the bug was filed, jenkins did less checks than it does now, so the patch which is currently in the bts does not make the package fully reproducibly anymore. Furthermore, storing these notes in the bts might make the package maintainer
Re: [Reproducible-builds] ARM build machines
On 2015-07-27, Vagrant Cascadian wrote: The current specs: bpi0-armhf-rb.debian.net: Banana PI, dual-core, 1GB ram, ~20GB mSATA. ssh port: ssh fingerprints: 2048 8f:0a:d0:77:a8:59:c0:bb:d0:76:de:14:13:5b:a6:56 (RSA) 256 af:b4:13:04:21:30:46:b3:e8:79:ff:7d:99:20:86:f0 (ECDSA) hb0-armhf-rb.debian.net: HummingBoard i2ex, dual-core, 1GB ram, ~20GB mSATA. ssh port: 2224 ssh fingerprints: - 2048 04:af:b4:e8:f0:13:13:66:25:7b:e3:d6:ee:b3:0d:0a (RSA) - 256 2f:1b:3a:fb:55:cf:27:3f:f6:de:e4:3d:e1:4c:59:c8 (ECDSA) Added new machine... wbq0-armhf-rb.debian.net: Wandboard Quad, quad-core, 2GB ram, ~50GB SATA SSD ssh port: 2225 ssh fingerprints: - 2048 ca:04:3e:d6:92:7c:32:20:1e:2f:d7:41:df:29:19:15 (RSA) - 256 4f:57:be:2e:aa:a4:7d:b2:6d:18:8a:d3:35:5e:df:a6 (ECDSA) Holger, I've added access for you with the same key, so tear it up! live well, vagrant signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Processing of debbindiff_27_amd64.changes
debbindiff_27_amd64.changes uploaded successfully to localhost along with the files: debbindiff_27.dsc debbindiff_27.tar.gz debbindiff_27_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Processing of debbindiff_27_amd64.changes
debbindiff_27_amd64.changes uploaded successfully to ftp-master.debian.org along with the files: debbindiff_27.dsc debbindiff_27.tar.gz debbindiff_27_all.deb Greetings, Your Debian queue daemon (running on host coccia.debian.org) ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#785777: marked as done (debbindiff: hexdump output when text encoding of file has changed)
Your message dated Fri, 31 Jul 2015 09:34:30 + with message-id e1zl6hy-0005yq...@franck.debian.org and subject line Bug#785777: fixed in debbindiff 27 has caused the Debian Bug report #785777, regarding debbindiff: hexdump output when text encoding of file has changed to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 785777: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785777 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: debbindiff Version: 20 Severity: minor When I debbindiff the attached HTML files, I get a diff of the hexdumps of the two files. This is less useful than what diff outputs. The two files have different encodings, which is probably the cause of this. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (860, 'testing-proposed-updates'), (850, 'buildd-testing-proposed-updates'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (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.27 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-7 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 genisoimage 9:1.1.11-3 ii gettext 0.19.3-2 ii ghc 7.6.3-21 ii gnupg 1.4.19-2 ii pdftk 2.02-2 ii poppler-utils 0.26.5-2 ii rpm2cpio4.11.3-1.1 ii sng 1.0.6-2 pn squashfs-tools none ii unzip 6.0-16 ii vim-common 2:7.4.712-2 ii xz-utils5.1.1alpha+20120614-2+b3 debbindiff suggests no packages. -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise Title: Philipp's Homepage: whohas whohas whohas 0.24 Description whohas is a command line tool that allows querying several package lists at once - currently supported are Arch, Debian, Fedora, Gentoo, Mandriva, openSUSE, Slackware (and linuxpackages.net), Source Mage, Ubuntu, FreeBSD, NetBSD, OpenBSD, Fink, MacPorts and Cygwin. whohas is written in Perl and was designed to help package maintainers find ebuilds, pkgbuilds and similar package definitions from other distributions to learn from. However, it can also be used by normal users who want to know: Which distribution provides packages on which the user depends. What version of a given package is in use in each distribution, or in each release of a distribution (implemented only for Debian). News There is now a "--no-threads" switch for those that need to suppress threading (not recommended, will be very slow). Tutorial It is suggested you use Unix command line tools to enhance your search results. whohas is optimised for fast execution. This is done by threading, and the order of results cannot be guaranteed. To nonetheless get a standardised output, alphabetically sorted by distribution, use the sort tool: whohas gimp | sort You can use grep to improve your search results. Depending on whether you want only packages whose names begin with your search term, end with your search term, or exactly match, you would use a space before, after or on both sides of your search term, respectively: whohas gimp | sort | grep " gimp" whohas vim | sort | grep "vim " whohas gimp | sort | grep " gimp " The spaces will ensure that only results for the package gimp are displayed, not for gimp-print etc. If you want results for a particular distribution only, do whohas arch | grep "^Arch" Output for each module will still be ordered, so you don't need to sort results in this case, although you may wish to do so for some distributions. Distribution names are abbreviated as "Arch", "Debian", "Fedora", "Gentoo", "Mandriva", "openSUSE", "Slackware", "Source Mage", "FreeBSD", "NetBSD", "OpenBSD", "Fink", "MacPorts", and "Cygwin". Output in version 0.1 looked like this. The first column is the name of the distribution, the second the name of the package, the third the version number, then the date, repository name and a url linking to more information about the package. Future versions will have package size information, too. Column lengths are fixed, so you can use
Re: [Reproducible-builds] b-d recommends
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. It's probably still worthwhile testing this, but IMO probably rather as a one time whole archive rebuild. btw, where are these fields defined? I couldn't find Build-Recommends: in https://www.debian.org/doc/debian-policy/ch-relationships.html ? cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] 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
[Reproducible-builds] Bug#789003: marked as done (debbindiff: should not try to create device files)
Your message dated Fri, 31 Jul 2015 11:53:17 +0200 with message-id 20150731095317.GA32590@loar and subject line Re: Bug#789003: debbindiff: should not try to create device files has caused the Debian Bug report #789003, regarding debbindiff: should not try to create device files to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 789003: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789003 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- package: debbindiff version: 22 User: reproducible-builds@lists.alioth.debian.org Usertags: infrastructure Hi, from https://jenkins.debian.net/view/reproducible/job/reproducible_openwrt/24/console Tue 16 Jun 23:30:09 UTC 2015 - debbindiff 22+test1 found issues, please investigate ar71xx/openwrt-ar71xx-generic-archer-c7-v2-squashfs-sysupgrade.bin create_inode: could not create character device /tmp/tmpq_LCg2debbindiff/dev/console, because you're not superuser! create_inode: could not create character device /tmp/tmpx7eb3fdebbindiff/dev/console, because you're not superuser! - debbindiff should not try to create device files when analyzing filesystem which contain device files... :) cheers, Holger signature.asc Description: This is a digitally signed message part. ---End Message--- ---BeginMessage--- Version: 27 Holger Levsen: Tue 16 Jun 23:30:09 UTC 2015 - debbindiff 22+test1 found issues, please investigate ar71xx/openwrt-ar71xx-generic-archer-c7-v2-squashfs-sysupgrade.bin create_inode: could not create character device /tmp/tmpq_LCg2debbindiff/dev/console, because you're not superuser! create_inode: could not create character device /tmp/tmpx7eb3fdebbindiff/dev/console, because you're not superuser! - debbindiff should not try to create device files when analyzing filesystem which contain device files... :) debbindiff 27 now knows how to handle device files. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature ---End Message--- ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [U-Boot] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
On 31/07/15 07:25, Chris Packham wrote:
The problem is that date -u implies UTC. So + is right if you do
want the time to be displayed in UTC (for me living at +12/+13 UTC
makes my head hurt because all the dates are yesterday).
One of the main problems with human-readable date/time is that it implies a
calendar, with all its exceptions like leap years, changing DST, etc. Many
RFCs, and the POSIX date functions, are highly flawed and conflate calendars
with absolute time, e.g. don't specify they mean the Gregorian calendar, and
don't specify what to do with dates before when the Gregorian calendar was
introduced.
If you want to be precise about these things (so as to not cause problems in
the future), then you need to specify all of that when dealing with
human-readable dates. This is why for now, the Reproducible Builds timestamps
proposal only defines SOURCE_DATE_EPOCH. We might extend it later, though.
The intent of f3f431a7 was to reflect the timezone that the build
machine was set to. Dropping the -u would probably be sufficient but
perhaps it would be better to make whole lot conditional on
SOURCE_DATE_EPOCH being set. Something like this (untested, apologies
gmail web interface)
ifneq ($(SOURCE_DATE_EPOCH),)
define filechk_timestamp.h
(SOURCE_DATE=$(SOURCE_DATE_EPOCH); \
LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_DATE %b
%d %C%y'; \
LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_TIME %T'; \
LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_TZ %z' )
endef
else
define filechk_timestamp.h
(LC_ALL=C date +'#define U_BOOT_DATE %b %d %C%y'; \
LC_ALL=C date +'#define U_BOOT_TIME %T'; \
LC_ALL=C date +'#define U_BOOT_TZ %z')
endef
endif
Yes, it is best to force the TZ as UTC for now, if SOURCE_DATE_EPOCH is set.
At some point later, we might add SOURCE_DATE_TZOFFSET, or other formats that
include a timezone offset, or something. (That would match Git's internal
timestamp format, which is $epochts $tzoffset, and can be translated
unambiguously into ISO8601 and RFC2822 formats). For now though, we decided to
keep things simple. But please say so, if you think that is something you (or
others who use timestamps in build systems) would really want.
BTW, you need to do @$${SOURCE_DATE_EPOCH} when giving timestamps to date(1):
$ date -d @143833 +%s
143833
$ date -d 143833 +%s
date: invalid date ‘143833’
1
X
--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
signature.asc
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
