Bug#673727: License changed?
Gustavo Noronha Silva: On Qui, 2013-08-01 at 11:24 -0300, Rogério Brito wrote: It seems that the current JSHint is *not* licensed under the no evil license: https://github.com/jshint/jshint/blob/master/LICENSE It would be lovely to have JSHint and others in our repository. Unfortunately no: https://github.com/jshint/jshint/blob/master/src/jshint.js#L19 Grunt must be packaged after ripping any part of its code that needs JSHint. Upstream does not get it: […] Debian people will have to install JSHint through NPM or do some other workaround. To be honest, I'm getting tired of these not-true-open-source talks. Out of all things I need to do with JSHint this issue is probably the least important one. https://github.com/jshint/jshint/issues/1234#issuecomment-23185426 -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#719297: RFP: ruby-packetfu -- PacketFu is a mid-level packet manipulation library for Ruby
Control: retitle -1 ITP: ruby-packetfu -- PacketFu is a mid-level packet Control: owner -1 ! intrig...@debian.org: * Package name: ruby-packetfu Version : 1.1.8 Upstream Author : Tod Beardsley * URL or Web page : https://github.com/todb/packetfu https://rubygems.org/gems/packetfu * License : BSD Description : PacketFu is a mid-level packet manipulation library for Ruby I'm on it. :) -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#720709: ITP: ruby-pcaprub -- Ruby bindings for LBL Packet Capture library (libpcap)
Package: wnpp Severity: wishlist Owner: Jérémy Bobbio lu...@debian.org Control: block 719297 by -1 * Package name: ruby-pcaprub Version : 0.11.3-1 Upstream Author : shadowbq shado...@gmail.com * URL : https://github.com/shadowbq/pcaprub * License : LGPL-2 Programming Lang: Ruby Description : Ruby bindings for LBL Packet Capture library (libpcap) libpcap (Packet CAPture) provides a portable framework for low-level network monitoring. Applications include network statistics collection, security monitoring, network debugging, etc. pcaprub provide a consistent interface for using libcap in Ruby. It does not provide packet processing functionality, only the interface for capturing packets, and passing yielding those packets. The old binding (in ruby-pcap) is currently unmaintained and should be removed from the archive once ruby-pcaprub gets in. The former has currently no reverse dependencies. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#720709: ITP: ruby-pcaprub -- Ruby bindings for LBL Packet Capture library (libpcap)
Hi Paul, Paul van Tilburg: On Sat, Aug 24, 2013 at 06:49:05PM +0200, Jérémy Bobbio wrote: Package: wnpp Severity: wishlist Owner: Jérémy Bobbio lu...@debian.org Control: block 719297 by -1 * Package name: ruby-pcaprub Version : 0.11.3-1 Upstream Author : shadowbq shado...@gmail.com * URL : https://github.com/shadowbq/pcaprub [...] I have uploaded, maintained and also neglected ruby-pcap a bit in the archive. See also: http://packages.qa.debian.org/r/ruby-pcap.html If this is different upstream, better maintained or just a new version please feel welcome to take it over. I have not used it for a while also. Thanks for the “go ahead”. :) This is a different — active — upstream. Quoting pcaprub's README: This project was created because the currently available ruby-pcap library is poorly designed and has been unmaintained since 2000. As I've written in the initial ITP, ruby-pcap should probably be removed from the archive once pcaprub gets in: it has no rdeps. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#719315: ITP: taskwarrior-web -- A web interface for the Taskwarrior todo application
Ben Armstrong: lib/taskwarrior-web/public/css/bootstrap.min.css lib/taskwarrior-web/public/css/bootstrap-responsive.min.css lib/taskwarrior-web/public/js/bootstrap.js Copyright 2012 Twitter Inc, ASL 2.0 Packaged in libjs-twitter-bootstrap. lib/taskwarrior-web/public/css/datepicker.css lib/taskwarrior-web/public/js/bootstrap-datepicker.js Copyright 2012 Stefan Petre, ASL 2.0 Does not look packaged. lib/taskwarrior-web/public/js/jquery.dataTables.min.js Copyright 2008-2012 Allan Jardine, Dual GPLv2+BSD Does not look packaged. lib/taskwarrior-web/public/js/jquery.hotkeys.js Copyright 2010, John Resig, Dual MIT+GPLv2 Packaged in libjs-jquery-hotkeys. lib/taskwarrior-web/public/js/jquery.min.js MIT Packaged in libjs-jquery. lib/taskwarrior-web/public/js/tinycon.min.js Copyright (c) 2012 Tom Moor, MIT Does not look packaged. Hope that helps, -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#716916: [DRE-maint] Bug#716916: ruby-gettext: rxgettext doubles the backslashes in newline '\n' characters
Control: tag -1 + upstream Hi Francesco, Francesco Poli (wintermute): First of all, thanks a lot for fixing the bugs I have previously reported (#684182, #684184, and #692487)! And thanks for your reports! :) I noticed something new in rxgettext, and it looks like a newly introduced bug. […] Why all the newline '\n' characters are produced with doubled backslashes (as \\n)? I do not see this behavior, if I use xgettext (from the gettext package). After some bisection, it has been introduced in upstream commit ef467007b, first appeared in version 2.3.0. This looks intentional. I will ask upstream. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#719844: dpkg-source: Make compresing of {data,control}.tar.gz a deterministic process
Hi! Guillem Jover: I've been thinking about this, and I think you might be trying to solve the problem in the wrong place(s), and possibly there's a need to step back and ponder about what do you really want out of all this, to know where or how to best fix it. […] My ideal scenario is the following: 1. I retrieve the .changes file for a package. 2. I verify the signature on the .changes. 3. I give the .changes to a rebuild tool. 4. The checksum of the .deb listed in the original .changes file and the checksum of the .deb I've just built should match. I even would like to compare the rebuilt .deb not only by one source, but by several. I would rather avoid to have a `dpkg-deb --compare` as you suggested because comparing signed checksums is much easier that to transfer `.deb` all around between multiple independent builders. And then there's changing information that conveys important data. For example, in the generated data.tar the files will contain different modification times, some will come untouched from the source files if they just get copied, and others will be newer if the files got created at build time. Preserving these timestamps seems important to me, because you then know the possible staleness of the files. I disagree that this is important information. Most packages that I have seen so far do not propagate timestamps when copying a file from source. Could you give me an example of one that would do so? If you are set on this, then our only solution is to generalize the use of faketime. I found this more clumsy but we already encourage using fakeroot… The timestamp on the ar member let's you know when the package got built. I don't believe this add much value: we have this information in the .changes files already. Anyway, I was thinking of adding a `--timestamp=1377619307` option to `dpkg-deb`. The value would default to `time(NULL)` when the flag is missing. This could allow the rebuild tool to extract the timestamp from the .changes file in order to match the initial build. But this has extra complications given that different calls to dpkg-deb and dpkg-genchange will have different timestamps at the moment. Possible future ar members containing gpg signatures from the builder or the archive, would change and not be reproducible anyway. The recent switch of dpkg-deb default compressor. Or possible future .deb format revisions. Etc. Could you please elaborate? The idea is to record list of packages that has been initially able to build the package and to reinstall exactly the same set of packages (from snapshot.d.o) when performing rebuilds. I don't really understand how future changes in dpkg would affect any earlier versions that would get reinstalled to do the rebuild. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#719845: [PATCH] t-deterministic-file-order: new test case
In order to make the build reproducible, we ensure that the files are
written to the .deb in a deterministic file order.
---
Here is a test case for pkg-tests that should ensure that files are
always written in the same order in the control and data tarball,
despite what readdir() says.
t-deterministic-file-order/Makefile| 28 +
t-deterministic-file-order/hookdir.c | 110
.../pkg-file-order/DEBIAN/control |7 ++
.../pkg-file-order/DEBIAN/md5sums |2 +
4 files changed, 147 insertions(+)
create mode 100644 t-deterministic-file-order/Makefile
create mode 100644 t-deterministic-file-order/hookdir.c
create mode 100644 t-deterministic-file-order/pkg-file-order/DEBIAN/control
create mode 100644 t-deterministic-file-order/pkg-file-order/DEBIAN/md5sums
create mode 100644 t-deterministic-file-order/pkg-file-order/a
create mode 100644 t-deterministic-file-order/pkg-file-order/b
diff --git a/t-deterministic-file-order/Makefile
b/t-deterministic-file-order/Makefile
new file mode 100644
index 000..5ba11b0
--- /dev/null
+++ b/t-deterministic-file-order/Makefile
@@ -0,0 +1,28 @@
+include ../Test.mk
+
+test-case: libhookdir.so
+ rm -rf pkg-file-order-1 cp -a pkg-file-order pkg-file-order-1
+ rm -rf pkg-file-order-2 cp -a pkg-file-order pkg-file-order-2
+
+ $(DPKG_BUILD_DEB) pkg-file-order-1
+ LD_PRELOAD=$$(pwd)/libhookdir.so $(DPKG_BUILD_DEB) pkg-file-order-2
+
+ ar x pkg-file-order-1.deb
+ tar -ztf control.tar.gz content-control-1
+ tar -atf data.tar.* content-data-1
+ ar x pkg-file-order-2.deb
+ tar -ztf control.tar.gz content-control-2
+ tar -atf data.tar.* content-data-2
+ diff -u content-control-1 content-control-2
+ diff -u content-data-1 content-data-2
+
+test-clean:
+ rm -rf pkg-file-order-1 pkg-file-order-2
+ rm -f pkg-file-order-1.deb pkg-file-order-2.deb
+ rm -f data.tar.* control.tar.* debian-binary
+ rm -f content-control-1 content-control-2
+ rm -f content-data-1 content-data-2
+ rm -f libhookdir.so
+
+libhookdir.so: hookdir.c
+ gcc -Wall -shared -fPIC -o $@ $ -ldl
diff --git a/t-deterministic-file-order/hookdir.c
b/t-deterministic-file-order/hookdir.c
new file mode 100644
index 000..49c4bd1
--- /dev/null
+++ b/t-deterministic-file-order/hookdir.c
@@ -0,0 +1,110 @@
+/* libhookdir.c: LD_PRELOAD lib to return readdir() results in reverse order
+ * Code snippet from Niklas B. copied from http://stackoverflow.com/a/8866709
+ * Licensed under CC BY-SA 3.0
+ */
+
+#define _GNU_SOURCE 1
+#include stdio.h
+#include dirent.h
+#include dlfcn.h
+#include stdlib.h
+#include string.h
+
+struct __dirstream
+{
+ int __fd;
+ char *__data;
+ size_t __allocation;
+ size_t __offset;
+ size_t __size;
+ struct dirent __entry;
+};
+
+typedef struct _dirent_list {
+ struct dirent *value;
+ struct _dirent_list *next;
+} dirent_list;
+
+typedef struct _my_DIR {
+ struct __dirstream orig;
+ dirent_list *first_entry;
+ int first_readdir;
+} my_DIR;
+
+DIR *fdopendir(int fd) {
+ DIR *(*orig_fdopendir)(int) = dlsym(RTLD_NEXT, fdopendir);
+ DIR *dir = orig_fdopendir(fd);
+
+ // save additional information along with the
+ // original DIR structure
+ my_DIR *my_dir = calloc(1, sizeof(*my_dir));
+ my_dir-first_readdir = 1;
+ memcpy(my_dir, dir, sizeof(*dir));
+ return (DIR*)my_dir;
+}
+
+DIR *opendir(const char *name) {
+ DIR *(*orig_opendir)(const char*) = dlsym(RTLD_NEXT, opendir);
+ DIR *dir = orig_opendir(name);
+
+ // save additional information along with the
+ // original DIR structure
+ my_DIR *my_dir = calloc(1, sizeof(*my_dir));
+ my_dir-first_readdir = 1;
+ memcpy(my_dir, dir, sizeof(*dir));
+ return (DIR*)my_dir;
+}
+
+struct dirent *readdir(DIR *dir) {
+ struct dirent *(*orig_readdir)(DIR*) = dlsym(RTLD_NEXT, readdir);
+ my_DIR *my_dir = (my_DIR*)dir;
+ dirent_list *item;
+
+ if (my_dir-first_readdir) {
+struct dirent *entry;
+while ((entry = orig_readdir(dir))) {
+ item = calloc(1, sizeof(*item));
+ item-value = entry;
+ item-next = my_dir-first_entry;
+ my_dir-first_entry = item;
+}
+my_dir-first_readdir = 0;
+ }
+
+ if (!my_dir-first_entry)
+return NULL;
+
+ item = my_dir-first_entry;
+ struct dirent *result = item-value;
+ my_dir-first_entry = item-next;
+ free(item);
+
+ return result;
+}
+
+int closedir(DIR *dir) {
+ int (*orig_closedir)(DIR *) = dlsym(RTLD_NEXT, closedir);
+
+ return orig_closedir(dir);
+}
+
+long telldir(DIR *dir) {
+ long (*orig_telldir)(DIR *) = dlsym(RTLD_NEXT, telldir);
+
+ fprintf(stderr, telldir(%p): not properly implemented in libhookdir\n,
dir);
+ return orig_telldir(dir);
+}
+
+void seekdir(DIR *dir, long offset) {
+ void (*orig_seekdir)(DIR *, long) = dlsym(RTLD_NEXT, seekdir);
+
+ fprintf(stderr, seekdir(%p, %ld): not properly implemented in
libhookdir\n, dir, offset);
+
Bug#719845: [PATCH] t-deterministic-file-order: new test case
Guillem Jover: On Tue, 2013-08-27 at 23:12:34 +0200, Jérémy Bobbio wrote: In order to make the build reproducible, we ensure that the files are written to the .deb in a deterministic file order. --- Here is a test case for pkg-tests that should ensure that files are always written in the same order in the control and data tarball, despite what readdir() says. Thanks, this is very helpful. I've applied it locally, and done several simplifications. I've removed the libhookdir library, because it's really unneeded and it makes unportable assumptions on the internal structure of the DIR type (which in this case seems to be missing an off_t member). I'm just checking the .deb member tar output against a sorted tar output. How do you ensure that readdir() will not return files in sorted order? -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#719844: dpkg-source: Make compresing of {data,control}.tar.gz a deterministic process
Jérémy Bobbio:
Guillem Jover:
The timestamp on the ar member let's you know when the package got
built.
I don't believe this add much value: we have this information in the
.changes files already.
Anyway, I was thinking of adding a `--timestamp=1377619307` option to
`dpkg-deb`. The value would default to `time(NULL)` when the flag is
missing. This could allow the rebuild tool to extract the timestamp from
the .changes file in order to match the initial build. But this has
extra complications given that different calls to dpkg-deb and
dpkg-genchange will have different timestamps at the moment.
I have a test implementation of that idea ready. See the attached
patches (extracted from the `pu/reproducible_builds` branch available
from `git://anonscm.debian.org/users/lunar/dpkg.git`).
This makes the following work:
$ apt-get source hello
$ cd hello-2.8
$ dpkg-buildpackage
[…]
$ cp ../hello_2.8-4_amd64.deb ../hello_2.8-4_amd64.deb.orig
$ DEB_BUILD_TIMESTAMP=$(date +%s -d$(sed -n -e 's/^Date: //p'
../hello_2.8-4_amd64.changes)) dpkg-buildpackage
[…]
$ sha256sum ../hello_2.8-4_amd64.deb ../hello_2.8-4_amd64.deb.orig
1e944abfceac7e593f6706da971e0444e5cee9aab680de5292d52661940ee9c4
../hello_2.8-4_amd64.deb
1e944abfceac7e593f6706da971e0444e5cee9aab680de5292d52661940ee9c4
../hello_2.8-4_amd64.deb.orig
You probably will have several comments regarding the implementation,
but I was wondering how you felt with the overall approach.
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From 0275d0a656de921693f22c4b3dbd780670698829 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Tue, 27 Aug 2013 22:38:31 +0200
Subject: [PATCH 1/3] Use a single timestamp when building a .deb
In order to make build reproducible in the future, we now use a single
timestamp in all ar headers and for all members of the control.tar and data.tar
archives.
Previously, each ar header would have the current time of its creation.
This level of precision is not really needed and the time of the beginning of
the build is good enough.
The tar members were previously using the mtime of the files on the filesystem.
In almost all cases, the files are created/copied during the package build, so
again, using the time of the creation of the .deb does not make much of a
difference.
---
dpkg-deb/build.c | 40 +++-
dpkg-split/split.c |4 ++--
lib/dpkg/ar.c | 12 ++--
lib/dpkg/ar.h |6 +++---
4 files changed, 38 insertions(+), 24 deletions(-)
diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
index 99b014d..73e5bdd 100644
--- a/dpkg-deb/build.c
+++ b/dpkg-deb/build.c
@@ -38,6 +38,7 @@
#include stdint.h
#include stdlib.h
#include stdio.h
+#include time.h
#include dpkg/i18n.h
#include dpkg/dpkg.h
@@ -382,8 +383,9 @@ pkg_get_pathname(const char *dir, struct pkginfo *pkg)
return path;
}
+#define MTIME_ARG_LENGTH 30 /* length of --mtime=@18446744073709551616 + \0 */
static void
-create_control_tar(const char *dir, int gzfd)
+create_control_tar(const char *dir, int gzfd, time_t mtime)
{
int p1[2], p2[2], p3[2];
pid_t c1, c2, c3, c4;
@@ -394,13 +396,16 @@ create_control_tar(const char *dir, int gzfd)
m_pipe(p2);
c1 = subproc_fork();
if (!c1) {
+char mtime_arg[MTIME_ARG_LENGTH];
+
+snprintf(mtime_arg, MTIME_ARG_LENGTH, --mtime=@%lu, mtime);
m_dup2(p1[0], 0); close(p1[0]); close(p1[1]);
m_dup2(p2[1], 1); close(p2[0]); close(p2[1]);
if (chdir(dir))
ohshite(_(failed to chdir to `%.255s'), dir);
if (chdir(BUILDCONTROLDIR))
ohshite(_(failed to chdir to `%.255s'), .../DEBIAN);
-execlp(TAR, tar, -cf, -, --format=gnu, --null, -T, -, --no-recursion, NULL);
+execlp(TAR, tar, -cf, -, --format=gnu, --null, mtime_arg, -T, -, --no-recursion, NULL);
ohshite(_(unable to execute %s (%s)), tar -cf, TAR);
}
close(p1[0]);
@@ -456,6 +461,7 @@ create_control_tar(const char *dir, int gzfd)
subproc_wait_check(c2, gzip -9c, 0);
subproc_wait_check(c1, tar -cf, 0);
}
+#undef MTIME_ARG_LENGTH
static void
write_format_zero_deb_header(const char *debar, int arfd, int gzfd)
@@ -476,7 +482,7 @@ write_format_zero_deb_header(const char *debar, int arfd, int gzfd)
}
static void
-write_deb_header(const char *debar, int arfd, int gzfd)
+write_deb_header(const char *debar, int arfd, int gzfd, time_t time)
{
const char deb_magic[] = ARCHIVEVERSION \n;
@@ -490,8 +496,8 @@ write_deb_header(const char *debar, int arfd, int gzfd)
}
dpkg_ar_put_magic(debar, arfd);
- dpkg_ar_member_put_mem(debar, arfd, DEBMAGIC, deb_magic, strlen(deb_magic));
- dpkg_ar_member_put_file(debar, arfd, ADMINMEMBER, gzfd, -1);
+ dpkg_ar_member_put_mem(debar, arfd, DEBMAGIC, deb_magic, time, strlen(deb_magic
Bug#721179: lintian: Please update autopkgtest known restrictions
Package: lintian
Version: 2.5.17
Severity: minor
Tags: patch
Hi dear Lintian maintainers,
Could you please update the list of known restrictions for autopkgtest?
It looks like `allow-stderr` is missing.
I believe the attached patch written against the master branch will do
the trick.
Thanks!
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From 078ea14d610a480dceaee30c304708a84e661fce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Wed, 28 Aug 2013 20:38:45 +0200
Subject: [PATCH] Synchronize autopkgtest known restrictions with the
reference documentation
The `allow-stderr` flag was missing, and the order now match the documentation.
---
checks/testsuite.pm |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/checks/testsuite.pm b/checks/testsuite.pm
index 1cc98a3..a5d79f5 100644
--- a/checks/testsuite.pm
+++ b/checks/testsuite.pm
@@ -42,10 +42,11 @@ my %KNOWN_FIELDS = map { $_ = 1 } qw(
my %KNOWN_FEATURES = map { $_ = 1 } qw(
);
my %KNOWN_RESTRICTIONS = map { $_ = 1 } qw(
+ rw-build-tree
breaks-testbed
- build-needed
needs-root
- rw-build-tree
+ build-needed
+ allow-stderr
);
sub run {
--
1.7.10.4
signature.asc
Description: Digital signature
Bug#719844: dpkg-source: Make compresing of {data,control}.tar.gz a deterministic process
Jonathan Nieder: I disagree that this is important information. Most packages that I have seen so far do not propagate timestamps when copying a file from source. Could you give me an example of one that would do so? See http://www.debian.org/doc/debian-policy/ch-source.html#s-timestamps This got out of my mind. Thanks for the pointer. I still would like to be pointed at a package that does this, though. The idea is to record list of packages that has been initially able to build the package and to reinstall exactly the same set of packages (from snapshot.d.o) when performing rebuilds. That can be problematic when packages used during the build get security fixes, fixes for new hardware support, and so on. Problematic how? If it did build once, it should be rebuildable. Not to mention sources of randomness during the build, such as parallelism. A build system that produces an output that varies depending on the order of its computations should be fixed. Otherwise, it sounds like a great source of heisenbugs and other pains. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#719844: dpkg-source: Make compresing of {data,control}.tar.gz a deterministic process
Jérémy Bobbio: Jonathan Nieder: I disagree that this is important information. Most packages that I have seen so far do not propagate timestamps when copying a file from source. Could you give me an example of one that would do so? See http://www.debian.org/doc/debian-policy/ch-source.html#s-timestamps This got out of my mind. Thanks for the pointer. If dpkg is getting its own tar implementation, I think the following could work: If we record the time when the build starts, we know that any files created after that time are newly created files. So we can use a unique timestamp for all of them. (This could be done manually by touch'ing the files.) Together with the approach mentioned previously (using DEB_BUILD_TIMESTAMP), this could allow rebuilds with the aforementioned unique timestamp preset to the date of the initial build. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#721574: ruby-gettext: undefined method force_encoding... during apt-listbugs
Ivan Sergio Borgonovo: calling aptitude [] runs apt-listbugs that fails with /usr/lib/ruby/vendor_ruby/gettext/mo.rb:46: undefined method `force_encoding' for \225\004\022\336:String (NoMethodError) from /usr/lib/ruby/vendor_ruby/gettext/text_domain.rb:16:in `require' from /usr/lib/ruby/vendor_ruby/gettext/text_domain.rb:16 from /usr/lib/ruby/vendor_ruby/gettext/text_domain_manager.rb:14:in `require' from /usr/lib/ruby/vendor_ruby/gettext/text_domain_manager.rb:14 from /usr/lib/ruby/vendor_ruby/gettext.rb:19:in `require' from /usr/lib/ruby/vendor_ruby/gettext.rb:19 from /usr/sbin/apt-listbugs:274:in `require' from /usr/sbin/apt-listbugs:274 Oh crap… my bad. gettext 3.0 dropped support for Ruby 1.8. But given this is still our default interpreter, its reverse dependencies are likely to fail. Given the following: $ git grep 'respond_to?' upstream/2.3.9 | grep -v bindtextdomain upstream/2.3.9:lib/gettext/runtime/mo.rb:if .respond_to?(:force_encoding) upstream/2.3.9:lib/gettext/runtime/mo.rb:if .respond_to?(:encode) upstream/2.3.9:lib/gettext/tools/parser/erb.rb: if src.respond_to?(:encode) upstream/2.3.9:lib/gettext/tools/parser/ruby.rb: if source.respond_to?(:encode) upstream/2.3.9:lib/gettext/tools/parser/ruby.rb: return nil unless source.respond_to?(:force_encoding) upstream/2.3.9:lib/gettext/tools/xgettext.rb:if string.respond_to?(:encode) upstream/2.3.9:test/gettext-test-utils.rb:return unless string.respond_to?(:force_encoding) upstream/2.3.9:test/gettext-test-utils.rb:if string.respond_to?(:encode) upstream/2.3.9:test/run-test.rb:$KCODE = utf8 unless .respond_to?(:encoding) Trying to re-introduce compatibility with Ruby 1.8 is probably doable, but this might be a little flacky. Any opinions? -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#432200: Ruby 1.8 is going away
Control: severity -1 serious Hi! Ruby 1.8 is unsupported upstream and should not be part of Jessie. Please update apt-listbugs to make it works with newer Ruby versions. See also: http://release.debian.org/transitions/html/ruby1.8-removal.html Thanks! -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#721618: Ruby 1.8 is going away
Package: schleuder Version: 2.2.1-3 Severity: serious Justification: unsuitable for release Hi! schleuder currently depends on ruby1.8. Ruby 1.8 is unsupported upstream and unsuitable for release. We would like to remove it from the archive soon. See: http://release.debian.org/transitions/html/ruby1.8-removal.html Please update Schleuder to make it work with newer versions of Ruby. Thanks! -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#721703: RM: ruby-pcap -- ROM; dead upstream, alternative exists
Package: ftp.debian.org Hi! Please remove ruby-pcap from the archive. It has no reverse dependencies. Upstream is inactive for years. Other developers resumed work around a pcap binding for ruby in the pcaprub project. The later library entered the archive as ruby-pcaprub today. Thanks! -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#690572: localization takes $LANG into account, but ignores $LC_MESSAGES
Hleb Valoshka: The bug really lies in ruby-gettext which does not currently parse LC_MESSAGES at all. It should, just like GNU gettext. Are you sure? GNU gettext uses LC_MESSAGES only indirectly, calling _nl_locale_name (see intl/dcigettext.c), but it never checks its value by itself. [Now I understand that my «fix» for #520181 which introduced this bug was incorrect (and what even worse it's integrated by upstream now).] But as I said above the real problem is in ruby-locale because the latter does not distinguish between «language» and «locale», (may be) because its aim to be the GCD for the 4 different plaform, and, at least, in web there no difference between «language» and «locale». So to properly fix this (and #520181) we (or ruby-gettext/locale upstream team) should 1) change ruby-locale to better reflect POSIX locale; 2) patch ruby-gettet to use new ruby-locale's API. It seams to me that p.1 will cause a great breakage of ruby-locale internals. You seam to have better knowledge than me about the issues. I trust you on the correct path to fix this. (Jérémy, please, if you forward bugs to upstream report them to github https://github.com/ruby-gettext/locale/issues not to Kou's mail) I don't have a Github account. I'd rather not have to create one. :( But yes, now that gettext has a canonical home, it's probably a better place. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#716796: [Pkg-javascript-devel] Bug#716796: Bug#716796: jQuery needs updating
Hi Raphael, Raphael Hertzog: On Sun, 28 Jul 2013, Marcelo Jorge Vieira wrote: There is a big problem, Grunt depends on the JSHint and it is not DFSG-compatible (Crockford's license). Please read this: http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2013-February/004850.html What's non-free in https://github.com/jshint/jshint/blob/master/LICENSE ? It looks fine to me. It's really a problem to have an outdated jquery in Debian. :-| Take a look at the recent take of upstream on the question: https://github.com/jshint/jshint/issues/1234 -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#721811: Florence does not release keys when terminated
Control: forwaded -1 f.agr...@gmail.com Hi Michael, Michael Billington: If florence is killed/terminated, any keys which are down will remain down. I think that the program should release anything it's holding when it is closed. Thanks for your report. I have forwarded your suggestion to Florence's author. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#721910: xul-ext-torbutton: torbutton sets the wrong port number (8118) rather than the correct polipo port (8123)
Patrick Zanon: Package: xul-ext-torbutton Version: 1.2.5-3 Severity: grave Justification: renders package unusable As described in the object torbutton sets in iceweasel configuration of the proxy the wrong port number (8118) rather than the correct polipo port (8123), thus iceweasel says that the proxy does not answer to connection requests. Please, please do not use xul-ext-torbutton anymore. Quoting the NEWS file for unstable: torbutton (1.4.6.3-1) unstable; urgency=high Security fixes introduced in Iceweasel 10.0.8esr prevents Torbutton from hooking window properties. This means that using this package is no longer substantially different from disabling websockets, disabling plugins, and using Private Browsing Mode to prevent disk leaks. Due to the very strong risk of fingerprinting and the resulting reduction of the anonymity set, it is more than strongly advised to uninstall this package and use the TorBrowserBundle instead. The later can be downloaded at: https://www.torproject.org/projects/torbrowser.html.en The TorBrowser also includes several changes in Firefox itself that address other possible leaks and fingerprinting issues. -- Jérémy Bobbio lu...@debian.org Tue, 16 Oct 2012 20:33:40 +0200 (Note that this package is not in Wheezy for that reason.) -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#721909: tor does not set properly the polipo option socksParentProxy = localhost:9050
Patrick Zanon: It would be nice if tor installation scripts could ask the user if to change the polipo option socksParentProxy = localhost:9050 so that polipo would start using tor infrastructure... The Tor project recommends against polipo since Firefox finally implemented SOCKS properly. Software which needs to use HTTP over Tor but does not implement SOCKS usually works unmodified using torsocks. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#711720: [Pkg-roundcube-maintainers] Bug#711720: roundcube: Include -plugins-extra in 0.8.6 package set
Control: reassign -1 roundcube-plugins-extra Mihnea-Costin Grigore: The current version in experimental works fine (by the way, any chance of seeing this in sid any time soon? The version there is quite old) but it is lacking some important plugins -- the ones packaged in roundcube-plugins-extra: […] I am waiting for Roundcube 0.9 to land in unstable before updating roundcube-plugins-extra. Roundcube 0.9.1 is in the NEW queue right now: https://ftp-master.debian.org/new/roundcube_0.9.1-1.html -- Jérémy Bobbio.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#724340: e17: Please do not store timestamps in headers of gzipped documentation
Package: e17 Version: 0.17.3-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps Hi! As part of the effort to have byte-to-byte identical reproducible builds [1], I've noticed that e17 currently stores a timestamp in the gzip header of some of its documentation. Applying the attached patch should fix the issue. [1] http://wiki.debian.org/ReproducibleBuilds Thanks, -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- diff -Nur r2/e17-0.17.3/debian/rules r1/e17-0.17.3/debian/rules --- r2/e17-0.17.3/debian/rules 2013-08-03 10:15:11.0 + +++ r1/e17-0.17.3/debian/rules 2013-09-23 20:25:18.667042757 + @@ -9,7 +9,7 @@ ARCH_PATH=$(DEB_HOST_GNU_SYSTEM)-$(DEB_HOST_GNU_CPU)-$(SVN_RELEASE) install/e17-data:: - gzip -9 debian/tmp/usr/share/enlightenment/doc/*.txt + gzip -9n debian/tmp/usr/share/enlightenment/doc/*.txt rm debian/tmp/usr/share/enlightenment/COPYING install/e17:: signature.asc Description: Digital signature
Bug#724481: python-gnupg: Please package gnupg 1.2.2
Package: python-gnupg Severity: wishlist Hi! Would it be possible to package gnupg 1.2.2? The later comes from a new active upstream and is now gnupg on PyPI: https://pypi.python.org/pypi/gnupg Thanks, -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#724489: python-qrcode: missing dependency on python-six
Package: python-qrcode Version: 4.0.1-1 Severity: grave Hi! It looks like python-qrcode is missing a Depends on python-six. # apt-get install python-qrcode […] The following NEW packages will be installed: liblcms1 python-imaging python-qrcode […] $ echo 'bla' | qr Traceback (most recent call last): File /usr/bin/qr, line 10, in module import qrcode File /usr/lib/pymodules/python2.7/qrcode/__init__.py, line 1, in module from qrcode.main import QRCode, make File /usr/lib/pymodules/python2.7/qrcode/main.py, line 1, in module from qrcode import constants, exceptions, util File /usr/lib/pymodules/python2.7/qrcode/util.py, line 4, in module import six ImportError: No module named six # apt-get install python-six […] The following NEW packages will be installed: python-six […] $ echo 'bla' | qr insert QR code here -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#725675: ruby-packetfu: Should provide ruby2.0 compatibility
Package: ruby-packetfu Version: 1.1.8-2 Severity: wishlist Forwarded: https://github.com/todb/packetfu/issues/28 Hi! ruby-packetfu should be made compatible with ruby2.0. Hopefully, upstream will sort it out soon. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#722079: hello: Please provide a deterministic Build ID
Package: hello Version: 2.8-4 Severity: wishlist Tags: patch Hi! In the quest to get deterministic/reproducible builds [1], I have noticed that the result of building hello currently varies according to its build path. The attached patch use the debugedit tool to prevent such variation by relocating the source associated with the debug data to a deterministic path. It also adds `-fno-merge-debug-strings` to the CFLAGS, because the resulting .debug_str section will be different depending on the initial input strings. This behaviour should eventually be fixed at the compiler level. [1] http://wiki.debian.org/ReproducibleBuilds Thanks, -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- diff -Naur a/debian/control b/debian/control --- a/debian/control 2011-08-04 13:07:58.0 +0200 +++ b/debian/control 2013-09-07 15:18:45.29439 +0200 @@ -2,6 +2,7 @@ Section: devel Priority: optional Maintainer: Santiago Vila sanv...@debian.org +Build-Depends: debugedit | rpm (= 4.7.0-3) Standards-Version: 3.9.2 Homepage: http://www.gnu.org/software/hello/ diff -Naur a/debian/rules b/debian/rules --- a/debian/rules 2013-08-16 09:36:35.0 +0200 +++ b/debian/rules 2013-09-07 15:09:36.755619230 +0200 @@ -10,7 +10,7 @@ package = hello docdir = debian/tmp/usr/share/doc/$(package) -CFLAGS := `dpkg-buildflags --get CFLAGS` -Wall +CFLAGS := `dpkg-buildflags --get CFLAGS` -Wall -fno-merge-debug-strings LDFLAGS := `dpkg-buildflags --get LDFLAGS` CPPFLAGS := `dpkg-buildflags --get CPPFLAGS` @@ -34,6 +34,8 @@ STRIP = $(stripcmd) --remove-section=.comment --remove-section=.note endif +DEBUGEDIT = /usr/lib/rpm/debugedit + build: ./configure CFLAGS=$(CFLAGS) CPPFLAGS=$(CPPFLAGS) \ LDFLAGS=$(LDFLAGS) $(confflags) --prefix=/usr @@ -54,6 +56,7 @@ rm -rf debian/tmp install -d debian/tmp/DEBIAN $(docdir) $(MAKE) prefix=$$(pwd)/debian/tmp/usr install + $(DEBUGEDIT) -b $(dir $(realpath $(CURDIR))) -d /usr/src/debug -i debian/tmp/usr/bin/hello $(STRIP) debian/tmp/usr/bin/hello cp -a NEWS debian/copyright $(docdir) cp -a debian/changelog $(docdir)/changelog.Debian signature.asc Description: Digital signature
Bug#722079: hello: Please provide a deterministic Build ID
Hi! Santiago Vila: In the quest to get deterministic/reproducible builds [1], I have noticed that the result of building hello currently varies according to its build path. […] While I can agree that reproducible builds is a good thing (I added gzip -n recently), the proposed patch makes debugedit to be build-essential and it looks like an awfully horrible hack. This behaviour should eventually be fixed at the compiler level. Or maybe just s/eventually// Thanks for pushing me to look at other solutions. After poking some more at GCC and its documentation, I came up with the attached patch. It only adds two new switches to the CFLAGS: `-fdebug-prefix-map=` to adjust the source path and `-gno-record-gcc-switches` to prevent the difference in `-fdebug-prefix-map=` values from affecting the output. Does that sound more acceptable to you? -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- diff -Naur a/debian/rules b/debian/rules --- a/debian/rules 2013-08-16 09:36:35.0 +0200 +++ b/debian/rules 2013-09-07 15:09:36.755619230 +0200 @@ -10,7 +10,7 @@ package = hello docdir = debian/tmp/usr/share/doc/$(package) -CFLAGS := `dpkg-buildflags --get CFLAGS` -Wall +CFLAGS := `dpkg-buildflags --get CFLAGS` -Wall -fdebug-prefix-map=$(dir $(realpath $(CURDIR)))=/usr/src/debug/ -gno-record-gcc-switches LDFLAGS := `dpkg-buildflags --get LDFLAGS` CPPFLAGS := `dpkg-buildflags --get CPPFLAGS` signature.asc Description: Digital signature
Bug#722154: gem2deb: Please use dpkg-buildflags
Package: gem2deb Severity: wishlist Hi! gem2deb should ensure that Ruby extensions are built using the compilation flags available from dpkg-buildflags. Right now, this will enable hardening flags on Debian. In the future, it might help to have deterministic builds: http://wiki.debian.org/ReproducibleBuilds -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#722166: bobcat: Please do not write timestamps in gzip files
Package: bobcat Version: 3.15.00-1 Severity: wishlist Hi! In the effort of making Debian binary package build reproducible [1], I have noticed that your package currently ship gz compressed files with a timestamp. Adding the `-n` or `--no-name` flag to the various calls to `gzip` made in `icmake/install` would happily solve the problem. [1] http://wiki.debian.org/ReproducibleBuilds Thanks, -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#722166: bobcat: Please do not write timestamps in gzip files
Control: tags -1 + patch
tony mancill:
Thanks for the suggestion and for looking into the cause of the issue
with the bobcat build. I'm suspect that Frank, the upstream developer,
will be willing to address this in a future upstream release.
Great! Attached is a patch that indeed did the trick. :)
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
--- r2/bobcat-3.15.00/icmake/install 2012-02-08 20:56:04.0 +
+++ r1/bobcat-3.15.00/icmake/install 2013-09-08 17:32:26.867701666 +
@@ -10,7 +10,7 @@
for (idx = sizeof(man); idx--; )
{
file = element(idx, man);
-run(gzip -9 + src + file ++ dest + file + .gz);
+run(gzip -n -9 + src + file ++ dest + file + .gz);
}
}
@@ -26,7 +26,7 @@
for (idx = sizeof(files); idx--; )
{
file = element(idx, files);
-run(gzip -9 + file ++ dest + file + .gz);
+run(gzip -n -9 + file ++ dest + file + .gz);
}
}
@@ -59,7 +59,7 @@
rungzip9(tmp/man/man3/, dev + MAN + /man3/);
-run(gzip -9 tmp/man/man7/bobcat.7 +
+run(gzip -n -9 tmp/man/man7/bobcat.7 +
dev + MAN + /man7/bobcat.7.gz);
#endif
signature.asc
Description: Digital signature
Bug#722186: dh-buildinfo: Please produce stable output
Package: dh-buildinfo
Version: 0.9+nmu1
Severity: wishlist
Tags: patch
Hi!
It would really help the “reproducible efforts” [1] if dh-buildinfo
would produce a stable output each time it is called.
The attached patch do this by:
* calling gzip with the `-n` flag in order to prevent it to store
a timestamp;
* sorting the package lists by name.
The later might not be the nicest code, I don't really know Perl.
[1] http://wiki.debian.org/ReproducibleBuilds
Thanks!
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
diff -Nru dh-buildinfo-0.9+nmu1/debian/changelog dh-buildinfo-0.9+nmu2/debian/changelog
--- dh-buildinfo-0.9+nmu1/debian/changelog 2012-05-13 12:22:38.0 +0200
+++ dh-buildinfo-0.9+nmu2/debian/changelog 2013-09-08 23:22:26.0 +0200
@@ -1,3 +1,10 @@
+dh-buildinfo (0.9+nmu2) UNRELEASED; urgency=low
+
+ * Do not record timestamps when compressing buildinfo file.
+ * Output packages sorted by name.
+
+ -- Jérémy Bobbio lu...@debian.org Sun, 08 Sep 2013 20:59:23 +
+
dh-buildinfo (0.9+nmu1) unstable; urgency=low
* Non-maintainer upload.
diff -Nru dh-buildinfo-0.9+nmu1/dh_buildinfo dh-buildinfo-0.9+nmu2/dh_buildinfo
--- dh-buildinfo-0.9+nmu1/dh_buildinfo 2012-05-13 11:53:10.0 +0200
+++ dh-buildinfo-0.9+nmu2/dh_buildinfo 2013-09-08 23:28:36.0 +0200
@@ -161,12 +161,14 @@
while (shift @essentials ne '') {
}
;
+ @essentials = sort @essentials;
# get output in the same format as build-essential and explicit build-deps
#@essentials = BuildDeps::depends(join (', ', @essentials), @status);
# closure
my @essentialsclosure = deps_closure(\@essentials, \%depends, $excludes);
+ @essentialsclosure = sort @essentialsclosure;
add_to_closure(\@essentialsclosure, $excludes);
# record
@@ -201,9 +203,11 @@
# have the expression parsed
my @buildessentials = BuildDeps::depends($bestring, @status);
+ @buildessentials = sort @buildessentials;
# closure
my @buildessentialsclosure = deps_closure(\@buildessentials, \%depends, $excludes);
+ @buildessentialsclosure = sort @buildessentialsclosure;
add_to_closure (\@buildessentialsclosure, $excludes);
# record
@@ -222,16 +226,18 @@
my %fields = BuildDeps::parse_control ('debian/control');
if (defined $fields{'Build-Depends-Indep'}) {
@builddepsindep = BuildDeps::depends($fields{'Build-Depends-Indep'}, @status);
+@builddepsindep = sort @builddepsindep;
}
# closure
my @builddepsindepclosure = deps_closure(\@builddepsindep, \%depends, $excludes);
+ @builddepsindepclosure = sort @builddepsindepclosure;
add_to_closure (\@builddepsindepclosure, $excludes);
# record
$buildinfo .=
\n\n Declared Arch-indep Build-Dependencies:\n\n .
- pkgformat (\@builddepsindep, 0, @status) .
+ pkgformat (@builddepsindep, 0, @status) .
\n\n Arch-indep Build-Dependencies closure:\n\n .
pkgformat (\@builddepsindepclosure, 1, @status);
@@ -244,10 +250,12 @@
%fields = BuildDeps::parse_control ('debian/control');
if (defined $fields{'Build-Depends'}) {
@builddeps = BuildDeps::depends($fields{'Build-Depends'}, @status);
+@builddeps = sort @builddeps;
}
# closure
my @builddepsclosure = deps_closure(\@builddeps, \%depends, $excludes);
+ @builddepsclosure = sort @builddepsclosure;
#add_to_closure (\@builddepsclosure, $excludes);
# record
@@ -265,7 +273,7 @@
}
sub install_buildinfo {
- complex_doit(gzip -9f debian/buildinfo debian/buildinfo.gz);
+ complex_doit(gzip -9nf debian/buildinfo debian/buildinfo.gz);
foreach my $package (@{$dh{DOPACKAGES}}) {
my $tmp=tmpdir($package);
my $arch=package_arch($package);
signature.asc
Description: Digital signature
Bug#722166: bobcat: Please do not write timestamps in gzip files
Hi Frank, Frank B. Brokken: Of course I am. Could somebody please enlighten me what the problem actually is? This is the first time in my l-o-o-o-o-ng life that I learn about a thing called a `timestamp of a gzip file' and that it may cause problems. In Debian context, it currently can pause problem for multiarch: http://lintian.debian.org/tags/gzip-file-is-not-multi-arch-same-safe.html Some people are also working on having byte-by-byte reproducible builds [1]. This adds a way to verify that a given source produces the same binary. When done by multiple independent people, this would give Debian some resistance against targatted attacks on its developers. For the latter to work, we need to eliminate any variations coming from external factors, like timestamps. [1] http://wiki.debian.org/ReproducibleBuilds Hope that helps, -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#722528: Coquelicot: support subdirectories
Control: forwarded -1 https://coquelicot.potager.org/TODO Hi Shawn, Shawn Landden: I tried to install coquelicot under /images on my domain using nginx's rewrite directive, and the main page shows up, but I cannot upload as it goes to /upload. There should be an easy way to tell coquelicot it is operating under a subdirectory. This is already on the radar. :) In the meantime you can manually patch the source, see: https://listes.potager.org/pipermail/coquelicot/2013-July/11.html -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#734622: Please package GeoLiteCity.dat and GeoIPASNum.dat
Source: geoip-database Severity: wishlist Hi! ooni-probe [1] which I am trying to package requires GeoLiteCity.dat and GeoIPASNum.dat for some tests to work. They are respectively available at: http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz and: http://download.maxmind.com/download/geoip/database/asnum/GeoIPASNum.dat.gz Both databases are licensed as CC BY-SA 3.0 according to http://dev.maxmind.com/geoip/legacy/geolite/ Do you think these files could be included in the geoip-database package or maybe in a new packages (e.g. geoip-database-extra)? [1] https://ooni.torproject.org/ Thank you, -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#719845: [PATCH] Deterministic file order for control and data archives
Control: tags -1 + patch
Hi!
Here are four patches based on the current master (1e059955) that will
write files in deterministic order in the control and data archives.
File names are sorted by forking `sort` before being piped to `tar`.
They have been tested with the test case previously sent and on bigger
packages.
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From fd525d04c230d5bc85dcf544467dc5de8cab053c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Tue, 27 Aug 2013 18:10:15 +0200
Subject: [PATCH 1/4] Ensure deterministic file order in data.tar.* files
---
dpkg-deb/build.c | 42 ++
lib/dpkg/dpkg.h |1 +
2 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
index 2871234..01b625b 100644
--- a/dpkg-deb/build.c
+++ b/dpkg-deb/build.c
@@ -170,19 +170,36 @@ file_info_list_free(struct file_info *fi)
static void
file_treewalk_feed(const char *dir, int fd_out)
{
- int pipefd[2];
- pid_t pid;
+ int sort_pipefd[2], find_pipefd[2];
+ pid_t sort_pid, find_pid;
struct file_info *fi;
struct file_info *symlist = NULL;
struct file_info *symlist_end = NULL;
- m_pipe(pipefd);
+ m_pipe(find_pipefd);
+ m_pipe(sort_pipefd);
+
+ sort_pid = subproc_fork();
+ if (sort_pid == 0) {
+m_dup2(find_pipefd[0], 0);
+close(find_pipefd[0]);
+close(find_pipefd[1]);
+m_dup2(sort_pipefd[1], 1);
+close(sort_pipefd[0]);
+close(sort_pipefd[1]);
+if (setenv(LC_ALL, C, 1 /* overwrite */))
+ohshite(_(unable to setenv));
+execlp(SORT, sort, --zero-terminated, NULL);
+ohshite(_(unable to execute %s (%s)), sort, SORT);
+ }
+ close(find_pipefd[0]);
+ close(sort_pipefd[1]);
- pid = subproc_fork();
- if (pid == 0) {
-m_dup2(pipefd[1], 1);
-close(pipefd[0]);
-close(pipefd[1]);
+ find_pid = subproc_fork();
+ if (find_pid == 0) {
+m_dup2(find_pipefd[1], 1);
+close(find_pipefd[0]);
+close(find_pipefd[1]);
if (chdir(dir))
ohshite(_(failed to chdir to `%.255s'), dir);
@@ -191,11 +208,11 @@ file_treewalk_feed(const char *dir, int fd_out)
-print0, NULL);
ohshite(_(unable to execute %s (%s)), find, FIND);
}
- close(pipefd[1]);
+ close(find_pipefd[1]);
/* We need to reorder the files so we can make sure that symlinks
* will not appear before their target. */
- while ((fi = file_info_get(dir, pipefd[0])) != NULL) {
+ while ((fi = file_info_get(dir, sort_pipefd[0])) != NULL) {
if (S_ISLNK(fi-st.st_mode)) {
file_info_list_append(symlist, symlist_end, fi);
} else {
@@ -206,8 +223,9 @@ file_treewalk_feed(const char *dir, int fd_out)
}
}
- close(pipefd[0]);
- subproc_wait_check(pid, find, 0);
+ close(sort_pipefd[0]);
+ subproc_wait_check(find_pid, find, 0);
+ subproc_wait_check(sort_pid, sort, 0);
for (fi = symlist; fi; fi = fi-next)
if (fd_write(fd_out, fi-fn, strlen(fi-fn) + 1) 0)
diff --git a/lib/dpkg/dpkg.h b/lib/dpkg/dpkg.h
index fbdc73e..f816aa2 100644
--- a/lib/dpkg/dpkg.h
+++ b/lib/dpkg/dpkg.h
@@ -113,6 +113,7 @@ DPKG_BEGIN_DECLS
#define CAT cat
#define FIND find
#define DIFF diff
+#define SORT sort
#define FIND_EXPRSTARTCHARS -(),!
--
1.7.10.4
From 6190a30b1d8fef99801f1da8263a937884ce2fba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Fri, 17 Jan 2014 12:56:13 +0100
Subject: [PATCH 2/4] Extract the creation of the control tarball to a
dedicated function
---
dpkg-deb/build.c | 73 --
1 file changed, 43 insertions(+), 30 deletions(-)
diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
index 01b625b..ebc0572 100644
--- a/dpkg-deb/build.c
+++ b/dpkg-deb/build.c
@@ -234,6 +234,40 @@ file_treewalk_feed(const char *dir, int fd_out)
file_info_list_free(symlist);
}
+static void
+create_control_tar(const char *dir, struct compress_params *control_compress_params,
+ int gzfd)
+{
+ int p1[2];
+ pid_t c1, c2;
+
+ /* Fork a tar to package the control-section of the package. */
+ unsetenv(TAR_OPTIONS);
+ m_pipe(p1);
+ c1 = subproc_fork();
+ if (!c1) {
+m_dup2(p1[1],1); close(p1[0]); close(p1[1]);
+if (chdir(dir))
+ ohshite(_(failed to chdir to `%.255s'), dir);
+if (chdir(BUILDCONTROLDIR))
+ ohshite(_(failed to chdir to `%.255s'), .../DEBIAN);
+execlp(TAR, tar, -cf, -, --format=gnu, ., NULL);
+ohshite(_(unable to execute %s (%s)), tar -cf, TAR);
+ }
+ close(p1[1]);
+
+ /* And run the compressor on our control archive. */
+
+ c2 = subproc_fork();
+ if (!c2) {
+compress_filter(control_compress_params, p1[0], gzfd, _(compressing control member));
+exit(0);
+ }
+ close(p1[0]);
+
Bug#735919: florence: Shouldn't this be in 'x11' section, not 'web'?
Control: tags -1 + pending Dylan Thurston: What's the justification for putting florence in the web category? Surely 'x11' would be a better fit? It doesn't seem specific to web browsing at all. Indeed! Thanks for spotting the mistake. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#736126: /dev/random entropy depletion on a fresh install
Control: reassign -1 tasksel Jeffrey Walton: It would probably be very beneficial to install an entropy gatherer by default. I am unconvinced that haveged is the answer here, but reassigning to the proper package. -- Jérémy Bobbio.''`. jeremy.bob...@irq7.fr : : : lu...@debian.org `. `'` lu...@torproject.org `- signature.asc Description: Digital signature
Bug#736239: python-sphinx: 'sphinx/pycode' not installed
Stephan Sürken: Maybe 'sphinx/pycode' is new in 1.2.1, but just not installed? # dpkg -L python-sphinx | grep Grammar-py2.txt /usr/share/pyshared/sphinx/pycode/Grammar-py2.txt The file is right there but the code is not properly looking for it. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#712954: [DRE-maint] Bug#712954: 1.4.3
Axel Wagner: It has been quite a while since jekyll has been updated. Some releases also contain security fixes. Since I would like to use jekyll in $dayjob, I am quite interested in a good health of this package. So if the delay in uploading new versions is for a lack of manpower, I would gladly commit some time to this. Please do! :) The Debian Ruby team gladly accept new members. You can know more about the innerworkings on https://wiki.debian.org/Teams/Ruby and https://wiki.debian.org/Teams/Ruby/Packaging for the packaging side. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#660759: xul-ext-torbutton: torbrowser firefox patches
Hi Robert, Robert Millan: I just wanted to step in and give my point of view, which I think is quite similar to that of the Tor project. […] In the meantime, I believe that providing torbutton does more harm than good, because it provides the *illusion* of security rather than security itself. Please, I urge you to reconsider. I don't understand what you want me to reconsider. See #706881. The package is still in the archive because I wanted to give users a chance to see the debian/NEWS on their next upgrade: http://anonscm.debian.org/gitweb/?p=pkg-mozext/torbutton.git;a=blob_plain;f=debian/NEWS;hb=HEAD Feel free to ask the removal of the package, if you think enough users had that chance by now. Or suggest any other course of actions. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#738591: lintian: Add checker for timestamped gzip files
Tomasz Buchert: +Severity: normal It think it should be at most wishlist, perhaps even pedantic. Let's make it pedantic, but hopefully one day it will be normal. Could we go for “wishlist” instead? I know that switching to reproducible builds sounds like a major shift in Debian's current practices but we already have way more packages reproducible that one might expect. The following wiki page describe the last large scale experiment that was done: https://wiki.debian.org/ReproducibleBuilds/Rebuild20140126 67% out of the 6887 packages that were tested were reproducible. 103 of them failed due to one or more timestamp in gzip files. I think “wishlist” is more appropriate because we are trying to get the the archive reproducible and asking interested maintainers for help. I don't think this fall under a “particular Debian packaging style” as worded in the man page about `--pedantic`. In any cases, my dear Lintian maintainers, I trust you to sort things out appropriately. :) -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#721618: Fix schleuder somehow
Ondřej Surý: Christian Hofstaedtler: Please, if anyhow possible, fix schleuder so it no longer depends on ruby-tmail or ruby-actionmailer (2.3), so we can go ahead with the removal of ruby1.8. It's not in testing, so it doesn't block the removal. Otherwise fill the removal bug, the package can be reintroduced later when fixed. You should proceed of the removal of ruby1.8. schleuder will be broken but it is already the case. Schleuder needs upstream work and unfortunately every regular contributor to Schleuder (me included) is super busy with other things. *sigh* -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#738591: lintian: Add checker for timestamped gzip files
Tomasz Buchert: The reason I did it is that I wanted to keep backwards compatibility. Another solution is to drop gzip-file-is-not-multi-arch-same-safe altogether, of course. The latter is severity “important”. “Multi-Arch: Same” packages for different architecture will be uninstallable if they do not contain identical data files. That's a serious problem. Reproducibility issues do not affect users in the same way. It could make sense to emit either “gzip-file-is-not-multi-arch-same-safe” or “package-contains-timestamped-gzip” instead of emitting both as they should be fixed by the same changes. -- Jérémy Bobbio.''`. jeremy.bob...@irq7.fr : : : lu...@debian.org `. `'` lu...@torproject.org `- signature.asc Description: Digital signature
Bug#739284: obfsproxy: Please include an AppArmor profile for confining obfsproxy
intrig...@debian.org: once the tor package is able to run obfsproxy even when AppArmor is enabled (#739279), it will be running obfsproxy unconfined. Adding an AppArmor profile for obfsproxy should be pretty easy. https://trac.torproject.org/projects/tor/ticket/6996#comment:22 has a draft one. I'll probably take care of this some day. That would be lovely. Thank you! :) -- Jérémy Bobbio.''`. jeremy.bob...@irq7.fr : : : lu...@debian.org `. `'` lu...@torproject.org `- signature.asc Description: Digital signature
Bug#739609: ITP: ooniprobe -- probe for the Open Observatory of Network Interference (OONI)
Package: wnpp Severity: wishlist Owner: Jérémy Bobbio lu...@debian.org * Package name: ooniprobe Version : 1.0.0-rc7 Upstream Author : Open Observatory of Network Interference ooni-...@torproject.org * URL : https://ooni.torproject.org/ * License : BSD-2-clause Programming Lang: Python Description : probe for the Open Observatory of Network Interference (OONI) OONI, the Open Observatory of Network Interference, is a global observation network which aims is to collect high quality data using open methodologies and free software to share observations and data about the various types, methods, and amounts of network tampering in the world. ooniprobe is a program to probe a network and collect data for the OONI project. It will test the current network for signs of surveillance and censorship. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#700048: Log for attempted build of haveged_1.4-4 on m68k (dist=unstable)
Control: tags -1 + moreinfo Thorsten Glaser: Source: haveged Version: 1.4-4 Justification: fails to build from source (but built successfully in the past) Severity: important Please try again with 1.9.1-1. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#740117: haveged: spinning
Control: severity -1 740117 important Control: tags -1 + moreinfo Cristian Ionescu-Idbohrn: Severity: grave Justification: renders package unusable Sorry, but haveged works just fine for many users so lowering the severity to important. Haveged is just spinning and not comming anywhere :( Been watching it for hours doing that. Uses one CPU at 100%. Upstream version 1.9.0 promisses improvements, although I have no idea if those address the problem I'm reporting. I have just uploaded 1.9.1-1. Please try it. -- Jérémy Bobbio.''`. jeremy.bob...@irq7.fr : : : lu...@debian.org `. `'` lu...@torproject.org `- signature.asc Description: Digital signature
Bug#740575: typo in README.Debian
Control: tags -1 + pending Antoine Beaupré: README.Debian says: Coquelicot should be ready to be tested out of the box. Point a browser at http://127.0.0.1:5116/ to make sure of it. The default password is test. After failing at following those instructions, and looking at lsof, I found that the port is actually 51161. Thanks for noticing! It'll be fixed in the next upload. :) -- Jérémy Bobbio.''`. jeremy.bob...@irq7.fr : : : lu...@debian.org `. `'` lu...@torproject.org `- signature.asc Description: Digital signature
Bug#684021: ruby-sinatra: shouldn't break error processing if error logging is failed
Aliaksandr Barouski: When error logging in sinatra fails (with exception), it can't process exception in right way. Example: Our code handles Errno:EROFS: error Errno:EROFS do #some processing end If standard logger (rack.error) starts failing (e.g. filesystem become read only), our handlers stop working and default error page appears. For fix this problem, Sinatra should ignore exceptions Is the problem still reproducible with ruby-sinatra/1.4.5-1 that has just been uploaded to unstable? -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#744975: xul-ext-https-everywhere: all rules lost?
Hi Christoph, Christoph Anton Mitterer: It seems that apart form loosing some security due to the campaign of the anti-CAcert fraction (I wonder why it is better to have e.g. rules for cacert.org removed, I mean... if people go to that site they WILL have the certs installed manually and will want that security)... The CACert rules are still there, just disabled by default. Anyway...as the screenshot shows basically all but a few other rules seem to be gone as well... o.O The rules are there. If you visit http://www.debian.org/ you will notice that HTTPS Everywhere will rewrite the URL… and the URL will be shown in the rule list. I agree this is a major inconvenience though, especially if you wish to renable CACert-supported rules. -- Jérémy Bobbio.''`. jeremy.bob...@irq7.fr : : : lu...@debian.org `. `'` lu...@torproject.org `- signature.asc Description: Digital signature
Bug#741421: coquelicot: Debug-style Net::IMAP::NoResponseError output in browser on bad user
Rowan Thorpe: Just adding that this bug seems not to be limited to the IMAP authentication, but is a general behaviour when receiving an exception from any of the authentication modules. I know this because I just implemented LDAP authentication, and any failed authentication from that spills the debug trace the same way (outputs source in the dialog framed rather than rendering it in the main frame). Thanks for the report. I really hope I'll be able to dedicate some time to Coquelicot in the upcoming weeks. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#723532: ruby-pcaprub link with -L/usr/lib
Control: tags -1 + moreinfo YunQiang Su: This package has one or more -L/usr/lib in its build system, which will make it ftbfs if there is libraries under /usr/lib, while is not the default architecture, mips* for example. Is the problem still present in sid? -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#718218: coquelicot: fails to start due to invalid byte sequence error in fast_gettext
Control: reassign -1 ruby-fast-gettext Johannes Schauer: Result: poparser.ry:162:in `===': invalid byte sequence in US-ASCII (ArgumentError) from poparser.ry:162:in `parse' from /usr/lib/ruby/vendor_ruby/fast_gettext/po_file.rb:16:in `to_mo_file' That line says: parser.parse(File.read(file), mo_file) PoParser already contains a `parse_file` method that will deal with the encoding of the PO file. The following makes the issue disappear: parser.parse_file(file, mo_file) -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#752904: ooniprobe: Cannot run ooniprobe in armhf
Control: tags -1 + unreproducible Luser: I installed the ooniprobe package using 'apt-get install ooniprobe'. * Run '/usr/bin/ooniprobe' output: Illegal instruction I can't reproduce the problem on harris.debian.org. 0xb6ae824c in ?? () from /usr/lib/python2.7/dist-packages/_yaml.so (gdb) where #0 0xb6ae824c in ?? () from /usr/lib/python2.7/dist-packages/_yaml.so #1 0xb6fe8254 in ?? () from /lib/ld-linux-armhf.so.3 #2 0xb6fff094 in _rtld_global () from /lib/ld-linux-armhf.so.3 #3 0xb6fff094 in _rtld_global () from /lib/ld-linux-armhf.so.3 The problem hardly looks in ooniprobe itself from the stacktrace. Could you please try to play with the yaml module or run other software which depends on python-yaml? I'm enclined to think the problem is on your hardware given the amount of armhf users and the fact that no one reported an issue. -- Jérémy Bobbio.''`. jeremy.bob...@irq7.fr : : : lu...@debian.org `. `'` lu...@torproject.org `- signature.asc Description: Digital signature
Bug#759231: dh-python: Please output dependencies in a stable order
Package: dh-python
Version: 1.20140511-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain
Hi!
It would help the “reproducible efforts” [1] if dh-python would output
dependencies in a stable order. Right now they are likely to be
different each time a package is built.
The attached patch will make the order stable by sorting the
dependencies.
[1]: https://wiki.debian.org/ReproducibleBuilds
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From 8c892fde3d9009072f48cd5a6a8c9a19549b6480 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Sun, 24 Aug 2014 20:47:50 +
Subject: [PATCH] Ensure that Depends and the likes are written in a stable
order
This is needed for reproducible builds.
---
dhpython/depends.py | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/dhpython/depends.py b/dhpython/depends.py
index e406fb7..935ddc6 100644
--- a/dhpython/depends.py
+++ b/dhpython/depends.py
@@ -61,17 +61,17 @@ class Dependencies:
def export_to(self, dh):
Fill in debhelper's substvars.
prefix = PKG_PREFIX_MAP.get(self.impl, 'misc')
-for i in self.depends:
+for i in sorted(self.depends):
dh.addsubstvar(self.package, '{}:Depends'.format(prefix), i)
-for i in self.recommends:
+for i in sorted(self.recommends):
dh.addsubstvar(self.package, '{}:Recommends'.format(prefix), i)
-for i in self.suggests:
+for i in sorted(self.suggests):
dh.addsubstvar(self.package, '{}:Suggests'.format(prefix), i)
-for i in self.enhances:
+for i in sorted(self.enhances):
dh.addsubstvar(self.package, '{}:Enhances'.format(prefix), i)
-for i in self.breaks:
+for i in sorted(self.breaks):
dh.addsubstvar(self.package, '{}:Breaks'.format(prefix), i)
-for i in self.rtscripts:
+for i in sorted(self.rtscripts):
dh.add_rtupdate(self.package, i)
def __str__(self):
--
1.7.10.4
signature.asc
Description: Digital signature
Bug#719845: [PATCH] Deterministic file order for control and data archives
Hi!
Jérémy Bobbio:
Here are four patches based on the current master (1e059955) that will
write files in deterministic order in the control and data archives.
File names are sorted by forking `sort` before being piped to `tar`.
Attached are the same patches rebased on the current master (29422bfd).
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From 5d80504af3d8855f4fb584cd839ff9153ca76453 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Tue, 27 Aug 2013 18:10:15 +0200
Subject: [PATCH 1/4] Ensure deterministic file order in data.tar.* files
---
dpkg-deb/build.c | 42 ++
lib/dpkg/dpkg.h |1 +
2 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
index 0b9cfb6..bbd0c79 100644
--- a/dpkg-deb/build.c
+++ b/dpkg-deb/build.c
@@ -170,19 +170,36 @@ file_info_list_free(struct file_info *fi)
static void
file_treewalk_feed(const char *dir, int fd_out)
{
- int pipefd[2];
- pid_t pid;
+ int sort_pipefd[2], find_pipefd[2];
+ pid_t sort_pid, find_pid;
struct file_info *fi;
struct file_info *symlist = NULL;
struct file_info *symlist_end = NULL;
- m_pipe(pipefd);
+ m_pipe(find_pipefd);
+ m_pipe(sort_pipefd);
+
+ sort_pid = subproc_fork();
+ if (sort_pid == 0) {
+m_dup2(find_pipefd[0], 0);
+close(find_pipefd[0]);
+close(find_pipefd[1]);
+m_dup2(sort_pipefd[1], 1);
+close(sort_pipefd[0]);
+close(sort_pipefd[1]);
+if (setenv(LC_ALL, C, 1 /* overwrite */))
+ohshite(_(unable to setenv));
+execlp(SORT, sort, --zero-terminated, NULL);
+ohshite(_(unable to execute %s (%s)), sort, SORT);
+ }
+ close(find_pipefd[0]);
+ close(sort_pipefd[1]);
- pid = subproc_fork();
- if (pid == 0) {
-m_dup2(pipefd[1], 1);
-close(pipefd[0]);
-close(pipefd[1]);
+ find_pid = subproc_fork();
+ if (find_pid == 0) {
+m_dup2(find_pipefd[1], 1);
+close(find_pipefd[0]);
+close(find_pipefd[1]);
if (chdir(dir))
ohshite(_(failed to chdir to `%.255s'), dir);
@@ -191,11 +208,11 @@ file_treewalk_feed(const char *dir, int fd_out)
-print0, NULL);
ohshite(_(unable to execute %s (%s)), find, FIND);
}
- close(pipefd[1]);
+ close(find_pipefd[1]);
/* We need to reorder the files so we can make sure that symlinks
* will not appear before their target. */
- while ((fi = file_info_get(dir, pipefd[0])) != NULL) {
+ while ((fi = file_info_get(dir, sort_pipefd[0])) != NULL) {
if (S_ISLNK(fi-st.st_mode)) {
file_info_list_append(symlist, symlist_end, fi);
} else {
@@ -206,8 +223,9 @@ file_treewalk_feed(const char *dir, int fd_out)
}
}
- close(pipefd[0]);
- subproc_wait_check(pid, find, 0);
+ close(sort_pipefd[0]);
+ subproc_wait_check(find_pid, find, 0);
+ subproc_wait_check(sort_pid, sort, 0);
for (fi = symlist; fi; fi = fi-next)
if (fd_write(fd_out, fi-fn, strlen(fi-fn) + 1) 0)
diff --git a/lib/dpkg/dpkg.h b/lib/dpkg/dpkg.h
index 1dfef96..8bbad67 100644
--- a/lib/dpkg/dpkg.h
+++ b/lib/dpkg/dpkg.h
@@ -112,6 +112,7 @@ DPKG_BEGIN_DECLS
#define CAT cat
#define FIND find
#define DIFF diff
+#define SORT sort
#define FIND_EXPRSTARTCHARS -(),!
--
1.7.10.4
From 753454b4062e3d4c1f7d87057b8e9b1d80eb32f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Fri, 17 Jan 2014 12:56:13 +0100
Subject: [PATCH 2/4] Extract the creation of the control tarball to a
dedicated function
---
dpkg-deb/build.c | 73 --
1 file changed, 43 insertions(+), 30 deletions(-)
diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
index bbd0c79..9dff37f 100644
--- a/dpkg-deb/build.c
+++ b/dpkg-deb/build.c
@@ -234,6 +234,40 @@ file_treewalk_feed(const char *dir, int fd_out)
file_info_list_free(symlist);
}
+static void
+create_control_tar(const char *dir, struct compress_params *control_compress_params,
+ int gzfd)
+{
+ int p1[2];
+ pid_t c1, c2;
+
+ /* Fork a tar to package the control-section of the package. */
+ unsetenv(TAR_OPTIONS);
+ m_pipe(p1);
+ c1 = subproc_fork();
+ if (!c1) {
+m_dup2(p1[1],1); close(p1[0]); close(p1[1]);
+if (chdir(dir))
+ ohshite(_(failed to chdir to `%.255s'), dir);
+if (chdir(BUILDCONTROLDIR))
+ ohshite(_(failed to chdir to `%.255s'), .../DEBIAN);
+execlp(TAR, tar, -cf, -, --format=gnu, ., NULL);
+ohshite(_(unable to execute %s (%s)), tar -cf, TAR);
+ }
+ close(p1[1]);
+
+ /* And run the compressor on our control archive. */
+
+ c2 = subproc_fork();
+ if (!c2) {
+compress_filter(control_compress_params, p1[0], gzfd, _(compressing control member));
+exit(0);
+ }
+ close(p1[0]);
+ subproc_wait_check(c2, gzip -9c, 0
Bug#757234: xul-ext-https-everywhere: update Debian rules from master and my patches
Paul Wise: I've been submitting changes to the rules for debian.org/debian.net as DSA add more SSL-enabled domains[1]. I'm not sure if upstream will make a release containing them in time for the jessie release so I thought I would submit a diff against 3.5.3 so we can at least have recent Debian rules. My most recent patch hasn't yet been accepted but I guess it will since previous ones were accepted. The attached patch includes the patch that hasn't yet been accepted upstream, hopefully that is OK. Thanks for the patch. Upstream is going to release 4.0.0 real soon, so I'll make sure Debian rules are right when updating the package. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#756935: proot: cwd is not changed when target is bind mounted and matching proot cwd
Package: proot Version: 4.0.0-1 Severity: normal User: reproducible-bui...@lists.alioth.debian.org Usertags: toolchain Hi! Some lines of shells are sometimes better than lengthly explainations: $ mkdir -p /tmp/a $ cd /tmp/a $ proot -b /tmp/a:/test -w /test bash -c 'pwd' /tmp/a This should output `/test`. It seems that the directory change is not done is this particular case. It indeed does if the current working directory is different than the one being bind-mounted: $ mkdir -p /tmp/a $ cd /tmp $ proot -b /tmp/a:/test -w /test bash -c 'pwd' /test -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#759886: debhelper: please make mtimes of packaged files deterministic
Package: debhelper Version: 9.20140817 User: reproducible-bui...@lists.alioth.debian.org Usertags: toolchain, timestamps X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi! As part of the “reproducible builds” project [1], it would be great to get the files shipped in the Debian package have deterministic mtimes. The attached patch will add a new helper `dh_fixmtimes`, largely inspired by `dh_fixperms`, that will change the modification time of any file that has been created later than the time of the latest debian/changelog entry to the time of the latest debian/changelog entry. This helper is set to run right before `dh_builddeb` in the `dh` process. [1]: https://wiki.debian.org/ReproducibleBuilds -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#759886: debhelper: please make mtimes of packaged files deterministic
Control: tags -1 + patch
Lunar:
The attached patch will add a new helper `dh_fixmtimes`, largely
inspired by `dh_fixperms`, that will change the modification time of any
file that has been created later than the time of the latest
debian/changelog entry to the time of the latest debian/changelog entry.
This time with the patch. *sigh*
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From 7a61549b6313d31c5a97fff46367cd5188804f92 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Fri, 29 Aug 2014 03:46:09 +
Subject: [PATCH] dh_fixmtimes: introduce new helper to fix mtimes for
reproducibility
To enable reproducible builds, file modification times written in binary
packages should be the same accross multiple builds of the same source
package. This helper will change the modification time of any file that
has been created later than the time of the latest debian/changelog
entry to the time of the latest debian/changelog entry.
See https://wiki.debian.org/ReproducibleBuilds for more information on
reproducible builds in Debian.
---
Debian/Debhelper/Dh_Lib.pm |4 ++-
dh |1 +
dh_fixmtimes | 76
man/po4a/po4a.cfg |1 +
4 files changed, 81 insertions(+), 1 deletion(-)
create mode 100755 dh_fixmtimes
diff --git a/Debian/Debhelper/Dh_Lib.pm b/Debian/Debhelper/Dh_Lib.pm
index 6a79c9c..44c3ced 100644
--- a/Debian/Debhelper/Dh_Lib.pm
+++ b/Debian/Debhelper/Dh_Lib.pm
@@ -477,7 +477,8 @@ sub pkgfilename {
}
# Returns 1 if the package is a native debian package, null otherwise.
-# As a side effect, sets $dh{VERSION} to the version of this package.
+# As a side effect, sets $dh{VERSION} to the version of this package,
+# and $dh{DATE} to the date of the latest changelog entry.
{
# Caches return code so it only needs to run dpkg-parsechangelog once.
my %isnative_cache;
@@ -499,6 +500,7 @@ sub pkgfilename {
if (! defined $dh{VERSION}) {
error(changelog parse failure);
}
+ ($dh{DATE})=$version=~m/Date:\s*(.*)/m;
# Is this a native Debian package?
if ($dh{VERSION}=~m/.*-/) {
diff --git a/dh b/dh
index f3bd321..fc300b8 100755
--- a/dh
+++ b/dh
@@ -408,6 +408,7 @@ my @b=qw{
dh_installdeb
dh_gencontrol
dh_md5sums
+ dh_fixmtimes
dh_builddeb
};
$sequences{clean} = [qw{
diff --git a/dh_fixmtimes b/dh_fixmtimes
new file mode 100755
index 000..28122c7
--- /dev/null
+++ b/dh_fixmtimes
@@ -0,0 +1,76 @@
+#!/usr/bin/perl -w
+
+=encoding utf-8
+
+=head1 NAME
+
+dh_fixperms - fix mtimes of files in package build directories
+
+=cut
+
+use strict;
+use Config;
+use Debian::Debhelper::Dh_Lib;
+
+=head1 SYNOPSIS
+
+Bdh_fixmtimes [SIdebhelper options] [B-XIitem]
+
+=head1 DESCRIPTION
+
+Bdh_fixmtimes is a debhelper program that is responsible for setting the
+modification times of files and directories in package build directories to
+a state easily reproducible accross multiple builds.
+
+Bdh_fixperms will examine the modification time of all files in the package
+build directory. If the file is newer than the date of the latest
+debian/changelog entry, we assume the file is a result of a build, and its
+modification time will be set to the date of the latest debian/changelog entry.
+
+This removes unneeded variations accross builds of the same package.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B-XIitem, B--exclude Iitem
+
+Exclude files that contain Iitem anywhere in their filename from having
+their modification times changed. You may use this option multiple times to
+build up a list of things to exclude.
+
+=back
+
+=cut
+
+init();
+
+foreach my $package (@{$dh{DOPACKAGES}}) {
+ my $tmp=tmpdir($package);
+
+ # XXX: not nice, we only run this for the side effect of getting $dh{DATE} set
+ isnative($package);
+
+ my $timestamp=`date -d'$dh{DATE}' +%s`;
+ chomp $timestamp;
+
+ my $find_options='';
+ if (defined($dh{EXCLUDE_FIND}) $dh{EXCLUDE_FIND} ne '') {
+ $find_options=! \\( $dh{EXCLUDE_FIND} \\);
+ }
+
+ complex_doit(find $tmp -newermt '$dh{DATE}' $find_options -print0,
+ 2/dev/null | xargs -0r touch --no-dereference --date='$dh{DATE}');
+}
+
+=head1 SEE ALSO
+
+Ldebhelper(7)
+
+This program is a part of debhelper.
+
+=head1 AUTHOR
+
+Jérémy Bobbio lu...@debian.org
+
+=cut
diff --git a/man/po4a/po4a.cfg b/man/po4a/po4a.cfg
index 311762f..39e3876 100644
--- a/man/po4a/po4a.cfg
+++ b/man/po4a/po4a.cfg
@@ -17,6 +17,7 @@
[type: pod] dh_compress $lang:man/$lang/dh_compress.pod add_fr:man/po4a/add.fr add_es:man/po4a/add1.es add_de:man/po4a/add.de add_pt:man/po4a/add.pt
[type: pod] dh_desktop $lang:man/$lang/dh_desktop.pod add_fr:man/po4a/add.fr add_es:man/po4a/add1.es add_de:man/po4a/add.de add_pt:man/po4a/add.pt
[type: pod] dh_fixperms $lang:man/$lang/dh_fixperms.pod
Bug#759895: debhelper: please strip non-deterministic data from static libraries
Package: debhelper
Version: 9.20140817
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain, timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi!
Currently, static libraries shipped in Debian package capture the time
when the package is built. As part of the “reproducible builds”
project [1], it would be great to have static libriaries normalized.
The attached patch will make `dh_strip` replace non-deterministic data
in static libraries. The replacement data is the same as the one put by
`ar` from binutils when used with the `D` option (deterministic mode).
[1]: https://wiki.debian.org/ReproducibleBuilds
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From 99adaf58da5f63065076d21818ce03ac3c7537a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Sat, 30 Aug 2014 02:24:57 +
Subject: [PATCH] dh_strip: normalize ar file headers for reproducible builds
User id, group id, timestamps and file modes can get captured when creating
static libraries. While this information is not useful while building software,
it prevents build to be reproducible. Let's replace the data by what is
written when `ar` is used in deterministic mode.
Thanks to Niko Tyni for the Perl code.
---
dh_strip | 61 +
1 file changed, 61 insertions(+)
diff --git a/dh_strip b/dh_strip
index 516b6f2..c55f10f 100755
--- a/dh_strip
+++ b/dh_strip
@@ -8,6 +8,7 @@ dh_strip - strip executables, shared libraries, and some static libraries
use strict;
use File::Find;
+use Fcntl q/SEEK_SET/;
use Debian::Debhelper::Dh_Lib;
=head1 SYNOPSIS
@@ -28,6 +29,9 @@ strips each as much as is possible. (Which is not at all for debugging
libraries.) In general it seems to make very good guesses, and will do the
right thing in almost all cases.
+For static libraries, it will also normalize user id, group id, timestamp and
+file mode of the archive members to enable build reproducibility.
+
Since it is very hard to automatically guess if a file is a
module, and hard to determine how to strip a module, Bdh_strip does not
currently deal with stripping binary modules such as F.o files.
@@ -190,6 +194,61 @@ sub attach_debug {
doit($objcopy, --add-gnu-debuglink, $debug_path, $file);
}
+sub normalize_ar {
+ my $file=shift;
+
+ my $GLOBAL_HEADER= !arch\n;
+ my $GLOBAL_HEADER_LENGTH=length $GLOBAL_HEADER;
+
+ my $FILE_HEADER_LENGTH=60;
+ my $FILE_MAGIC=`\n;
+
+ my $buf;
+
+ open(F, '+', $file)
+ or die(failed to open $file for read+write: $!);
+
+ read F, $buf, $GLOBAL_HEADER_LENGTH;
+ die(Unable to find global header) if $buf ne $GLOBAL_HEADER;
+
+ while (1) {
+ my $file_header_start=tell F;
+ my $count=read F, $buf, $FILE_HEADER_LENGTH;
+ die reading $file failed: $! if !defined $count;
+ last if $count == 0;
+
+ # http://en.wikipedia.org/wiki/Ar_(Unix)
+ #from to Name Format
+ #0 15 File name ASCII
+ #16 27 File modification dateDecimal
+ #28 33 Owner ID Decimal
+ #34 39 Group ID Decimal
+ #40 47 File mode Octal
+ #48 57 File size in bytesDecimal
+ #58 59 File magic\140\012
+
+ die Incorrect header length
+ if length $buf != $FILE_HEADER_LENGTH;
+ die Incorrect file magic
+ if substr($buf, 58, length($FILE_MAGIC)) ne $FILE_MAGIC;
+
+ my $file_size = substr($buf, 48, 10);
+ seek F, $file_header_start + 16, SEEK_SET;
+
+ # mtime
+ syswrite F, sprintf(%-12d, 0);
+ # owner
+ syswrite F, sprintf(%-6d, 0);
+ # group
+ syswrite F, sprintf(%-6d, 0);
+ # file mode
+ syswrite F, sprintf(%-8o, 0644);
+
+ # move to next member
+ seek F, $file_header_start + $FILE_HEADER_LENGTH + $file_size, SEEK_SET;
+ }
+}
+
foreach my $package (@{$dh{DOPACKAGES}}) {
my $tmp=tmpdir($package);
@@ -236,6 +295,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
foreach (@static_libs) {
doit($strip,--strip-debug,$_);
+ normalize_ar($_);
}
}
@@ -248,5 +308,6 @@ This program is a part of debhelper.
=head1 AUTHOR
Joey Hess jo...@debian.org
+Niko Tyni nt...@debian.org
=cut
--
1.7.10.4
signature.asc
Description: Digital signature
Bug#759999: dpkg: please set reproducible timestamps in .deb ar file headers
Package: dpkg
Version: 1.17.14
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain, timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi!
`.deb` are ar archives. The archive internal headers currently capture
the time when the build was made. As part of the reproducible builds
project [1], it would be great if these timestamps could be made
easily reproducible.
Guillem Jover already expressed [2] that he preferred to keep these
timestamps meaningful. The attached patches will set them to be the date
of the latest changelog entry when a package is built using
`dpkg-buildpackage`. During the discussions at DebConf14, there was a
consensus that it was the most meaningful time reference to use.
The first patch will modify `dpkg-deb` to use the same timestamp for
every member of the ar archive.
The second patch will:
1. Make `dpkg-deb` try to look for a timestamp to use in the
DEB_BUILD_TIMESTAMP environment variable in epoch format.
If not set or not parseable, it will default to use the current
time.
2. Change `dpkg-buildpackage` to parse `debian/changelog` and preset
DEB_BUILD_TIMESTAMP to the value of its latest entry. Unless
DEB_BUILD_TIMESTAMP was already set in order to allow arbitrary
dates to be reproduced.
[1]: https://wiki.debian.org/ReproducibleBuilds
[2]: https://bugs.debian.org/719844#10
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From fe1543722750a71ed7d7110291a917fc12bbc7ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Tue, 27 Aug 2013 22:38:31 +0200
Subject: [PATCH 1/2] Use a single timestamp for ar headers when building a
.deb
In order to make build reproducible in the future, we now use a single
timestamp in all ar headers when creating a .deb.
Previously, each ar header would have the current time of its creation.
This level of precision is not really needed and the time of the beginning of
the build is good enough.
---
dpkg-deb/build.c | 10 +++---
dpkg-split/split.c |4 ++--
lib/dpkg/ar.c | 13 +++--
lib/dpkg/ar.h |4 ++--
4 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
index 0b9cfb6..5384776 100644
--- a/dpkg-deb/build.c
+++ b/dpkg-deb/build.c
@@ -38,6 +38,7 @@
#include stdint.h
#include stdlib.h
#include stdio.h
+#include time.h
#include dpkg/i18n.h
#include dpkg/dpkg.h
@@ -440,6 +441,7 @@ do_build(const char *const *argv)
int arfd;
int p1[2], p2[2], gzfd;
pid_t c1, c2;
+ time_t build_timestamp;
/* Decode our arguments. */
dir = *argv++;
@@ -486,6 +488,8 @@ do_build(const char *const *argv)
}
m_output(stdout, _(standard output));
+ build_timestamp = time(NULL);
+
/* Now that we have verified everything its time to actually
* build something. Let's start by making the ar-wrapper. */
arfd = creat(debar, 0644);
@@ -561,8 +565,8 @@ do_build(const char *const *argv)
compressor_get_extension(control_compress_params.type));
dpkg_ar_put_magic(debar, arfd);
-dpkg_ar_member_put_mem(debar, arfd, DEBMAGIC, deb_magic, strlen(deb_magic));
-dpkg_ar_member_put_file(debar, arfd, adminmember, gzfd, -1);
+dpkg_ar_member_put_mem(debar, arfd, DEBMAGIC, deb_magic, build_timestamp, strlen(deb_magic));
+dpkg_ar_member_put_file(debar, arfd, adminmember, gzfd, build_timestamp, -1);
} else {
internerr(unknown deb format version %d.%d, deb_format.major, deb_format.minor);
}
@@ -632,7 +636,7 @@ do_build(const char *const *argv)
if (lseek(gzfd, 0, SEEK_SET))
ohshite(_(failed to rewind temporary file (%s)), _(data member));
-dpkg_ar_member_put_file(debar, arfd, datamember, gzfd, -1);
+dpkg_ar_member_put_file(debar, arfd, datamember, gzfd, build_timestamp, -1);
close(gzfd);
}
diff --git a/dpkg-split/split.c b/dpkg-split/split.c
index 37cbb93..b2da62b 100644
--- a/dpkg-split/split.c
+++ b/dpkg-split/split.c
@@ -216,13 +216,13 @@ mksplit(const char *file_src, const char *prefix, off_t maxpartsize,
(intmax_t)st.st_size, (intmax_t)partsize,
curpart, nparts, arch);
dpkg_ar_member_put_mem(file_dst.buf, fd_dst, PARTMAGIC,
- partmagic.buf, partmagic.used);
+ partmagic.buf, time(NULL), partmagic.used);
varbuf_reset(partmagic);
/* Write the data part. */
varbuf_printf(partname, data.%d, curpart);
dpkg_ar_member_put_file(file_dst.buf, fd_dst, partname.buf,
- fd_src, cur_partsize);
+ fd_src, time(NULL), cur_partsize);
varbuf_reset(partname);
close(fd_dst);
diff --git a/lib/dpkg/ar.c b/lib/dpkg/ar.c
index cf540a0..8613310 100644
--- a/lib/dpkg/ar.c
+++
Bug#760075: torsocks: SIGSEGV with torsocks 2.0.0 on some browsers, failure to anonimize others
js: I upgraded torsocks from the 1.3.3 to 2.0.0 and it either SIGSEV on some browsers or else fails to anonimize others (in other words, running under tor they cannot access sites blocked by my firewall) Please be aware that browsing the web with anything else than the Tor Browser is not going to provide anonymity. These browsers have many identifying factors themselves, the anonymity set is going to be super small. TTBOMK, they also will not prevent linkability attacks using cross-domain cookies, fonts, HTML5 storage, window resolution and other means. I'm not saying that there's not a bug in torsocks. But everyone reading this bug report should be aware that running web browsers through torsocks is likely to give a false sense of security. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#759895: [debhelper-devel] Bug#759895: debhelper: please strip non-deterministic data from static libraries
Joey Hess:
Jérémy Bobbio wrote:
Currently, static libraries shipped in Debian package capture the time
when the package is built. As part of the “reproducible builds”
project [1], it would be great to have static libriaries normalized.
The attached patch will make `dh_strip` replace non-deterministic data
in static libraries. The replacement data is the same as the one put by
`ar` from binutils when used with the `D` option (deterministic mode).
I think this is awesome! However, I am uncomfortable putting this big
block of code into debhelper.
+sub normalize_ar {
...
+}
Could it be moved to a utility that could
a) be maintained by someone else, perhaps in a package such as binutils
and b) could be used by non-debhelper users inside and outside of
debian.
Andrew Ayer has been working on a `dh_strip_nondeterminism` helper:
http://anonscm.debian.org/cgit/reproducible/strip-nondeterminism.git/
We can move that chunk of code to it, alongside normalizers for gzip,
zip, and jar files.
But we were kinda hoping to get that helper as part of debhelper in
order to not have to modify every packages to add a new Build-Depends.
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
signature.asc
Description: Digital signature
Bug#759886: [debhelper-devel] Bug#759886: debhelper: please make mtimes of packaged files deterministic
Joey Hess: Do you have a plan to get packages not using dh or cdbs to use this new command? Its heart is a single find+xargs+touch command. I had in mind that packages not using dh or cdbs could have their own way on how to make the mtimes deterministic. Possibly by adding such a find command in their debian/rules at the right location, but there might be other solutions. I can think of 2 ways.. one is to add it to some existing command, perhaps renaming the command. I thought maybe dh_fixperms could be renamed to dh_fixmetadata. But, I think some will use dh_fixperms -X to exclude certian files from being fixed, and we would not want that to apply to mtime fixing. dh_fixmtimes must be run right before building the .deb, or it's likely that some other command will change the newly set mtimes. dh_fixperms is currently run at an earlier step of the build process. My other idea is to make dh_fixmtimes set something that a later command (eg, dh_builddeb) could use and warn if it was not run. Maybe it should be integrated to dh_builddeb, then? -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#760594: ITP: golang-siphash-dev -- Go implementation of SipHash-2-4
Package: wnpp Severity: wishlist Owner: Jérémy Bobbio lu...@debian.org X-Debbugs-Cc: pkg-anonymity-to...@lists.alioth.debian.org * Package name: golang-siphash-dev Version : 1.0.0 Upstream Author : Dmitry Chestnykh dmi...@codingrobots.com * URL : https://github.com/dchest/siphash * License : CC0 Programming Lang: Go Description : Go implementation of SipHash-2-4 SipHash-2-4 is a fast short-input pseudorandom function (a.k.a. keyed hash functions) optimized for speed on short messages. This package is a required dependency for obfs4proxy, the latest implementation of obfsucation protocols from the Tor Project. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#760595: ITP: golang-ed25519-dev -- Go implementation of Ed25519 signature algorithm
Package: wnpp Severity: wishlist Owner: Jérémy Bobbio lu...@debian.org X-Debbugs-Cc: pkg-anonymity-to...@lists.alioth.debian.org * Package name: golang-ed25519-dev Version : HEAD Upstream Author : Adam Langley a...@imperialviolet.org * URL : https://github.com/agl/ed25519 * License : BSD-3-clause Programming Lang: Go Description : Go implementation of the Ed25519 signature algorithm Ed25519 is a public-key signature system based on elliptic-curve cryptography, carefully engineered at several levels of design and implementation to achieve very high speeds without compromising security. This package is a required dependency for obfs4proxy, the latest implementation of obfsucation protocols from the Tor Project. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#760596: ITP: obfs4proxy -- pluggable transport proxy for Tor, implementing obfs4
Package: wnpp Severity: wishlist Owner: Jérémy Bobbio lu...@debian.org X-Debbugs-Cc: pkg-anonymity-to...@lists.alioth.debian.org * Package name: obfs4proxy Version : 0.0.1 Upstream Author : Yawning Angel yawn...@torproject.org * URL : https://gitweb.torproject.org/pluggable-transports/obfs4.git * License : BSD-2-clause Programming Lang: Go Description : pluggable transport proxy for Tor, implementing obfs4 obfs4proxy is a tool that attempts to circumvent censorship by transforming the Tor traffic between the client and the bridge. This way censors, who usually monitor traffic between the client and the bridge, will see innocent-looking transformed traffic instead of the actual Tor traffic. obfs4proxy implements the obfsucation protocols obfs2, obfs3, and obfs4. It is written in Go and is compliant with the Tor pluggable transports specification, and its modular architecture allows it to support multiple pluggable transports. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#766384: debhelper: please register conffiles in a stable order
Package: debhelper
Version: 9.20141010
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain fileordering
Hi!
As part of the “reproducible builds” effort [1], we have noticed that
dh_installdeb is registering conffiles depending on the file system
order. This prevents some package from building reproducibly.
Attached is a patch that will sort the list of files, giving a stable
output.
[1]: https://wiki.debian.org/ReproducibleBuilds
Thanks,
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From 4cd40ffc4e64eabb82ce712351324b7356c0105d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Sun, 19 Oct 2014 13:35:46 +0200
Subject: [PATCH] dh_installdeb: register conffiles in a stable order
conffiles were automatically registered by dh_installdeb depending on
the order they were found on the filesystem. For build reproducibility,
we now sort them in order to have a stable order accross multiple
builds.
---
dh_installdeb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dh_installdeb b/dh_installdeb
index 1f02edf..3fc802c 100755
--- a/dh_installdeb
+++ b/dh_installdeb
@@ -128,7 +128,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
# Automatic conffiles registration: If it is in /etc, it is a
# conffile.
if (! compat(2) -d $tmp/etc) {
- complex_doit(find $tmp/etc -type f -printf '/etc/%P\n' $tmp/DEBIAN/conffiles);
+ complex_doit(find $tmp/etc -type f -printf '/etc/%P\n' | LC_ALL=C sort $tmp/DEBIAN/conffiles);
# Anything found?
if (-z $tmp/DEBIAN/conffiles) {
doit(rm, -f, $tmp/DEBIAN/conffiles);
--
1.9.1
signature.asc
Description: Digital signature
Bug#766736: geoip-database: outdated license information; more databases could be in main!
Package: geoip-database Hi! According to http://dev.maxmind.com/geoip/legacy/geolite/, “The GeoLite databases are distributed under the Creative Commons Attribution-ShareAlike 3.0 Unported License”. This probably means that debian/copyright should be updated. But this also means that all GeoLite databases could be in geoip-database and that geoip-database-contrib could be removed from the archive. Sounds like a good news, or? Thanks! -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#764550: ooniprobe: ooniresources fails with ImportError: No module named processors
Control: tags -1 + fixed-upstream Matt Kraai: As described in the ooniprobe README, I ran sudo ooniresources --update-inputs --update-geoip which failed with the following error message: Traceback (most recent call last): File /usr/bin/ooniresources, line 11, in module from ooni.resources import cli File /usr/lib/python2.7/dist-packages/ooni/resources/__init__.py, line 4, in module from ooni.deckgen.processors import citizenlab_test_lists ImportError: No module named processors I expected ooniresources to run successfully. Upstream has pushed a fix: https://gitweb.torproject.org/ooni-probe.git/commit/1f918109b8d7458a629f59dc8e2e0ef5797e0792 I'll make a new package as soon as the new release is out. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#764721: dpkg-dev: dpkg-shlibdeps does not output the minimum dependency when a package does not use any symbols
Package: dpkg-dev
Version: 1.17.16
Severity: minor
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain randomness
Hi!
As part of the “reproducible builds” effort [1], I came to investigate a
couple of failures related to dpkg-shlibdeps.
An example is visible in the output of debbindiff for gemanx-gtk2:
https://jenkins.debian.net//userContent/dbd/gemanx-gtk2_0.1.0.3-2.debbindiff.html
In the Depends field of the control file of libgemanx-core0, one build
has `libglib2.0-0 (= 2.12.0)` while the other has
`libglib2.0-0 (= 2.16.0)`.
dpkg-shlibdeps outputs a warning, as it is actually a useless
dependency. So the issue is probably a minor one. Here's my analysis and
possible solution:
The minimal version numbers differ from one run to another because when
the .symbols file is loaded, the order of the entries in the `libfiles`
hash are random. Only the minimal required version for the first
encountered shared library of a package will be currently used.
libglib2.0-0 exhibits the problem because libgio-2.0.so.0 has a minimal
required version of 2.16.0, while all other shared libraries contained
in the same package have a minimal required version of 2.12.0.
The attached patch uses `update_dependency_version` in order to raise
the initial minimum required version for each shared libraries provided
by the same package.
[1]: https://wiki.debian.org/ReproducibleBuilds
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
diff --git a/scripts/dpkg-shlibdeps.pl b/scripts/dpkg-shlibdeps.pl
index bda1e09..6caa6d8 100755
--- a/scripts/dpkg-shlibdeps.pl
+++ b/scripts/dpkg-shlibdeps.pl
@@ -255,13 +255,9 @@ foreach my $file (keys %exec) {
# package and we really need it)
my $dep = $symfile-get_dependency($soname);
my $minver = $symfile-get_smallest_version($soname) || '';
- foreach my $subdep (split /\s*,\s*/, $dep) {
- if (not exists $dependencies{$cur_field}{$subdep}) {
- $dependencies{$cur_field}{$subdep} = Dpkg::Version-new($minver);
-print Initialize dependency ($subdep) with minimal .
- version ($minver)\n if $debug 1;
- }
- }
+ update_dependency_version($dep, $minver);
+ print Initialize dependencies ($dep) with minimal .
+ version ($minver)\n if $debug 1;
} else {
# No symbol file found, fall back to standard shlibs
print Using shlibs+objdump for $soname (file $lib)\n if $debug;
signature.asc
Description: Digital signature
Bug#765343: systemd: localed wrote a /etc/default/keyboard withouth XKBMODEL
Package: systemd Version: 215-5+b1 Hi! What happened: 1. Install Debian with GNOME desktop using Jessie d-i beta 2. 2. Upgrade to sid. 3. Add new layouts in Input Sources through the Region Language interface. 4. Install Plymouth. 5. Restart. 6. Be unable to enter disk passphrase. I hadn't notice when installing Plymouth that `update-initramfs` actually issue an error about not being able to save a boottime keymap… After more investigation, it seems that `/etc/default/keyboard` only had entries for XKBLAYOUT, XKBVARIANT and BACKSPACE. This was prevent the boot keymap from being generated as `setupcon` will exit unless `XKBMODEL` is set. Adding back XKBMODEL to `/etc/default/keyboard` and issuing `update-initramfs -u` restored a working keymap. I am not sure what made localed unable to get the keyboard model, but maybe that situation is bad enough to make it have a fallback value? -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#762388: ifupdown: please make method order deterministic when generating C code
Source: ifupdown
Version: 0.7.48.2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
Hi!
As part of the “reproducible builds” effort, we have detected that
`ifupdown` did not build reproducibly.
This is caused by the fact that Perl orders its hashes randomly by
default. This, in turn, results in a random order in which the methods
are written when generating C code. Resulting in different binaries for
each builds.
The attached patch will sort the methods to produce a stable order.
`ifupdown` can then build reproducibly. :)
[1]: https://wiki.debian.org/ReproducibleBuilds
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
diff -Nru ifupdown-0.7.48.1/debian/changelog ifupdown-0.7.48.2~reproducible1/debian/changelog
--- ifupdown-0.7.48.1/debian/changelog 2014-03-23 17:50:11.0 +
+++ ifupdown-0.7.48.2~reproducible1/debian/changelog 2014-09-21 18:20:37.0 +
@@ -1,3 +1,10 @@
+ifupdown (0.7.48.2~reproducible1) UNRELEASED; urgency=low
+
+ * Output methods in stable order when generating C code to make
+builds reproducible.
+
+ -- Jérémy Bobbio lu...@debian.org Sun, 21 Sep 2014 18:19:56 +
+
ifupdown (0.7.48.1) unstable; urgency=low
* Add --ignore-errors option.
diff -Nru ifupdown-0.7.48.1/defn2c.pl ifupdown-0.7.48.2~reproducible1/defn2c.pl
--- ifupdown-0.7.48.1/defn2c.pl 2014-03-23 17:27:30.0 +
+++ ifupdown-0.7.48.2~reproducible1/defn2c.pl 2014-09-21 18:18:00.0 +
@@ -211,7 +211,7 @@
print static method methods[] = {\n;
%ourmethods = %methods if (our_arch());
my $method;
-foreach $method (keys %ourmethods) {
+foreach $method (sort keys %ourmethods) {
print EOF;
{
$method,
signature.asc
Description: Digital signature
Bug#762397: libgpg-error: please do not capture the current time during the build process
Source: libgpg-error
Version: 1.16-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertag: timestamps
Hi!
As part of the “reproducible builds” effort [1], it was detected that
libgpg-error could not be built reproducibly.
The build process capture the time of the build. This piece of
information is not really helpful to anyone and prevents the build
process from being deterministic.
The attached patch will instead use the time of the latest
debian/changelog entry. Once applied, libgpg-error can be built
reproducibly! :)
[1]: https://wiki.debian.org/ReproducibleBuilds
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
diff -Nru libgpg-error-1.16/debian/changelog libgpg-error-1.16/debian/changelog
--- libgpg-error-1.16/debian/changelog 2014-09-18 16:57:20.0 +0200
+++ libgpg-error-1.16/debian/changelog 2014-09-21 22:37:47.0 +0200
@@ -1,3 +1,10 @@
+libgpg-error (1.16-1.0~reproducible1) UNRELEASED; urgency=low
+
+ * Use latest entry of debian/changelog as build timestamp in order
+to get reproducible builds.
+
+ -- Jérémy Bobbio lu...@debian.org Sun, 21 Sep 2014 20:37:15 +
+
libgpg-error (1.16-1) unstable; urgency=medium
* New upstream release
diff -Nru libgpg-error-1.16/debian/patches/series libgpg-error-1.16/debian/patches/series
--- libgpg-error-1.16/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ libgpg-error-1.16/debian/patches/series 2014-09-21 22:36:52.0 +0200
@@ -0,0 +1 @@
+use-debian-changelog-date-as-timestamp.diff
diff -Nru libgpg-error-1.16/debian/patches/use-debian-changelog-date-as-timestamp.diff libgpg-error-1.16/debian/patches/use-debian-changelog-date-as-timestamp.diff
--- libgpg-error-1.16/debian/patches/use-debian-changelog-date-as-timestamp.diff 1970-01-01 01:00:00.0 +0100
+++ libgpg-error-1.16/debian/patches/use-debian-changelog-date-as-timestamp.diff 2014-09-21 22:36:29.0 +0200
@@ -0,0 +1,17 @@
+Description: Use latest entry of debian/changelog as build timestamp
+ In order to make the build reproducible, we use the time of the latest
+ entry in debian/changelog as the build timestamp.
+Author: Jérémy Bobbio lu...@debian.org
+Last-Update: 2014-09-21
+
+--- libgpg-error-1.16.orig/configure.ac
libgpg-error-1.16/configure.ac
+@@ -484,7 +484,7 @@ changequote([,])dnl
+ BUILD_FILEVERSION=${BUILD_FILEVERSION}0,mym4_revision_dec
+ AC_SUBST(BUILD_FILEVERSION)
+
+-BUILD_TIMESTAMP=`date -u +%Y-%m-%dT%H:%M+ 2/dev/null || date`
++BUILD_TIMESTAMP=`date --date=$(dpkg-parsechangelog -SDate) -u +%Y-%m-%dT%H:%M+ 2/dev/null || date`
+ AC_SUBST(BUILD_TIMESTAMP)
+ AC_DEFINE_UNQUOTED(BUILD_TIMESTAMP, $BUILD_TIMESTAMP,
+[The time this package was configured for a build])
signature.asc
Description: Digital signature
Bug#762433: lsof: please stop capturing environment information during the build process
Source: lsof
Version: 4.86+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps username hostname uname
Hi!
As part of the “reproducible builds” project, we have identified that
lsof build process captured too much information about its build
environment. This unfortunately prevents lsof from building
reproducibly.
The attached patch will make lsof builds reproducible by preventing
username, hostname, kernel version, and build time from being captured
as part of the build process. For build time, a patch over upstream code
is added to allow LSOF_CCDATE to be preset by an environment variable,
just like LSOF_HOST and others.
[1]: https://wiki.debian.org/ReproducibleBuilds
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
diff -Nru lsof-4.86+dfsg/debian/changelog lsof-4.86+dfsg/debian/changelog
--- lsof-4.86+dfsg/debian/changelog 2012-04-25 08:11:26.0 +0200
+++ lsof-4.86+dfsg/debian/changelog 2014-09-22 11:31:24.0 +0200
@@ -1,3 +1,11 @@
+lsof (4.86+dfsg-1.0reproducible1) UNRELEASED; urgency=medium
+
+ * Allow LSOF_CCDATE to be overriden by an environment variable.
+ * Ensure build reproducibility by preventing Configure to capture
+username, hostname, kernel version, and build time.
+
+ -- Jérémy Bobbio lu...@debian.org Mon, 22 Sep 2014 09:13:54 +
+
lsof (4.86+dfsg-1) unstable; urgency=low
[ Nicholas Bamber ]
diff -Nru lsof-4.86+dfsg/debian/patches/preset-ccdate lsof-4.86+dfsg/debian/patches/preset-ccdate
--- lsof-4.86+dfsg/debian/patches/preset-ccdate 1970-01-01 01:00:00.0 +0100
+++ lsof-4.86+dfsg/debian/patches/preset-ccdate 2014-09-22 11:35:59.0 +0200
@@ -0,0 +1,235 @@
+Description: Allow LSOF_CCDATE to be overriden by an environment variable
+ Capturing the current time as part of the build process does not make it
+ deterministic. By allowing the LSOF_CCDATE to be externally set, the current
+ time can be removed or preset.
+Author: Jérémy Bobbio lu...@debian.org
+Last-Update: 2014-09-22
+
+--- lsof-4.86+dfsg.orig/dialects/aix/Makefile
lsof-4.86+dfsg/dialects/aix/Makefile
+@@ -84,7 +84,15 @@ version.h: FRC
+ @echo '#define LSOF_BLDCMT ${LSOF_BLDCMT}' version.h;
+ @echo '#define LSOF_CC ${CC}' version.h
+ @echo '#define LSOF_CCV ${CCV}' version.h
+- @echo '#define LSOF_CCDATE '`date`'' version.h
++ @if [ X${LSOF_CCDATE} = X ]; then \
++ echo '#define LSOF_CCDATE '`date`'' version.h; \
++ else \
++ if [ ${LSOF_CCDATE} = none ]; then \
++ echo '#define LSOF_CCDATE ' version.h; \
++ else \
++ echo '#define LSOF_CCDATE ${LSOF_CCDATE}' version.h; \
++ fi \
++ fi
+ @echo '#define LSOF_CCFLAGS '`echo ${CFLAGS} | sed 's/(/\\(/g' | sed 's/)/\\)/g' | sed 's///g'`'' version.h
+ @echo '#define LSOF_CINFO ${CINFO}' version.h
+ @if [ X${LSOF_HOST} = X ]; then \
+--- lsof-4.86+dfsg.orig/dialects/darwin/kmem/Makefile
lsof-4.86+dfsg/dialects/darwin/kmem/Makefile
+@@ -88,7 +88,15 @@ version.h: FRC
+ @echo '#define LSOF_BLDCMT ${LSOF_BLDCMT}' version.h;
+ @echo '#define LSOF_CC ${CC}' version.h
+ @echo '#define LSOF_CCV ${CCV}' version.h
+- @echo '#define LSOF_CCDATE '`date`'' version.h
++ @if [ X${LSOF_CCDATE} = X ]; then \
++ echo '#define LSOF_CCDATE '`date`'' version.h; \
++ else \
++ if [ ${LSOF_CCDATE} = none ]; then \
++ echo '#define LSOF_CCDATE ' version.h; \
++ else \
++ echo '#define LSOF_CCDATE ${LSOF_CCDATE}' version.h; \
++ fi \
++ fi
+ @echo '#define LSOF_CCFLAGS '`echo ${CFLAGS} | sed 's/(/\\(/g' | sed 's/)/\\)/g' | sed 's///g'`'' version.h
+ @echo '#define LSOF_CINFO ${CINFO}' version.h
+ @if [ X${LSOF_HOST} = X ]; then \
+--- lsof-4.86+dfsg.orig/dialects/darwin/libproc/Makefile
lsof-4.86+dfsg/dialects/darwin/libproc/Makefile
+@@ -92,7 +92,15 @@ version.h: FRC
+ @echo '#define LSOF_BLDCMT ${LSOF_BLDCMT}' version.h;
+ @echo '#define LSOF_CC ${CC}' version.h
+ @echo '#define LSOF_CCV ${CCV}' version.h
+- @echo '#define LSOF_CCDATE '`date`'' version.h
++ @if [ X${LSOF_CCDATE} = X ]; then \
++ echo '#define LSOF_CCDATE '`date`'' version.h; \
++ else \
++ if [ ${LSOF_CCDATE} = none ]; then \
++ echo '#define LSOF_CCDATE ' version.h; \
++ else \
++ echo '#define LSOF_CCDATE ${LSOF_CCDATE}' version.h; \
++ fi \
++ fi
+ @echo '#define LSOF_CCFLAGS '`echo ${CFLAGS} | sed 's/(/\\(/g' | sed 's/)/\\)/g' | sed 's///g'`'' version.h
+ @echo '#define LSOF_CINFO ${CINFO}' version.h
+ @if [ X${LSOF_HOST} = X ]; then \
+--- lsof-4.86+dfsg.orig/dialects/du/Makefile
lsof-4.86+dfsg/dialects/du/Makefile
+@@ -76,7 +76,15 @@ version.h: FRC
+ @echo '#define LSOF_BLDCMT ${LSOF_BLDCMT}' version.h;
+ @echo '#define LSOF_CC ${CC}' version.h
+ @echo '#define LSOF_CCV ${CCV}' version.h
+- @echo '#define
Bug#762397: [Reproducible-builds] Bug#762397: libgpg-error: please do not capture the current time during the build process
Jeroen Dekkers: Jérémy actually already wrote a patch for dpkg-buildpackage to export DEB_BUILD_TIMESTAMP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=75 But if we want to push these things upstream, wouldn't it be better to remove the DEB_ prefix from the name of the environment variable? This is unrelated. DEB_BUILD_TIMESTAMP is meant to be consumed by dpkg. If libgpg-error build system needs to be fed with a timestamp, it would need to be through another environment variable. In that case, debian/rules should probably take care of feeding the right value. But, sincerely, I believe the right move for upstream would be to get rid of the embedded timestamp entirely. Embedding a Git commit id would make much more sense (and mabye its date) than embedding the time of the build. PS: Please call me Lunar. PPS: If we start bikeshedding on every patch, there's not even the slightest chance we will get to the point where build reproducibility is actually a Debian feature. We need to trust maintainers to do the right things. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#762622: discount: please mangle email addresses deterministically
Package: discount Version: 2.1.7-1 Severity: wishlist Tags: patches Forwarded: https://github.com/Orc/discount/pull/112 User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness Hi! As part of the “reproducible builds” project [1], we have identified that currently discount output was not deterministic when the Markdown source contained email addresses. Some Debian packages use discount to generate their documentation. This causes different builds of these packages to be different. We assume that the current behavior of randomly choosing between hex and decimal encoding for email addresses is intended to defeat email scrapers that understand one encoding but not the other. Could discount instead alternate every other character between hex and decimal? This would accomplish the same effect but in a deterministic manner. The attached patch changes the `mangle()` function accordingly. It has already been submitted upstream. [1]: https://wiki.debian.org/ReproducibleBuilds -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#762622: [Reproducible-builds] Bug#762622: discount: please mangle email addresses deterministically
Control: tags -1 + patch
Jérémy Bobbio:
The attached patch changes the `mangle()` function accordingly.
For real, this time.
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From 503fb7de2fe26eaf126ce7698931434517a3d418 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Tue, 23 Sep 2014 16:56:46 +
Subject: [PATCH] Provide a stable output for email address accross runs
Email adresses were previously mangled randomly. This prevented two runs of
discount from providing the same output. This is problematic for software
using discount and compare its output to some reference, or for software which
wants to generate documentation in a reproducible manner.
We can assume that the current code is trying to defeat an email address
scraper that supports one encoding but not the other. Simply alternating
between the two encodings would accomplish the same effect.
We thus change the behaviour of the `mangle()` function to alternate the
encoding based on the position in the string instead of randomly. As there is
no other users of the `COINTOSS()` macro, we can remove its definition from the
configure script.
---
configure.sh | 8
generate.c | 2 +-
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/configure.sh b/configure.sh
index 44c8986..8d009f4 100755
--- a/configure.sh
+++ b/configure.sh
@@ -105,14 +105,6 @@ else
AC_FAIL $TARGET requires bzero or memset
fi
-if AC_CHECK_FUNCS random; then
-AC_DEFINE 'COINTOSS()' '(random()1)'
-elif AC_CHECK_FUNCS rand; then
-AC_DEFINE 'COINTOSS()' '(rand()1)'
-else
-AC_DEFINE 'COINTOSS()' '1'
-fi
-
if AC_CHECK_FUNCS strcasecmp; then
:
elif AC_CHECK_FUNCS stricmp; then
diff --git a/generate.c b/generate.c
index 7180a1e..0935f78 100644
--- a/generate.c
+++ b/generate.c
@@ -775,7 +775,7 @@ mangle(char *s, int len, MMIOT *f)
{
while ( len-- 0 ) {
Qstring(#, f);
- Qprintf(f, COINTOSS() ? x%02x; : %02d;, *((unsigned char*)(s++)) );
+ Qprintf(f, (len % 2 == 0) ? x%02x; : %02d;, *((unsigned char*)(s++)) );
}
}
--
2.1.0
signature.asc
Description: Digital signature
Bug#762666: cwidget: please stop writing timestamps in Doxygen generated documentation
Source: cwidget Version: 0.5.17-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps Hi! As part of the “reproducible builds” project [1], we have discovered that the documentation generated by Doxygen during cwidget build process contained timestamps. Together with #762622, this prevents cwidget builds to be reproducible. We believe that these timestamps in the documentation are not really useful, so the attached patch simply setup Doxygen to avoid writing them. [1]: https://wiki.debian.org/ReproducibleBuilds -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- diff -Nru cwidget-0.5.17/debian/changelog cwidget-0.5.17/debian/changelog --- cwidget-0.5.17/debian/changelog 2014-02-27 20:41:11.0 +0100 +++ cwidget-0.5.17/debian/changelog 2014-09-24 11:05:58.0 +0200 @@ -1,3 +1,10 @@ +cwidget (0.5.17-1.0reproducible1) UNRELEASED; urgency=medium + + * Add a patch to have Doxygen not write timestamps in the generated +documentation to allow package builds to be reproducible. + + -- Jérémy Bobbio lu...@debian.org Wed, 24 Sep 2014 09:05:52 + + cwidget (0.5.17-1) unstable; urgency=medium * New upstream release diff -Nru cwidget-0.5.17/debian/patches/do-not-write-timestamps-in-documentation cwidget-0.5.17/debian/patches/do-not-write-timestamps-in-documentation --- cwidget-0.5.17/debian/patches/do-not-write-timestamps-in-documentation 1970-01-01 01:00:00.0 +0100 +++ cwidget-0.5.17/debian/patches/do-not-write-timestamps-in-documentation 2014-09-24 11:04:48.0 +0200 @@ -0,0 +1,24 @@ +Description: Do not write timestamps in documentation generated by Doxygen + In order to make the build reproducible, we configure Doxygen to skip + writing timestamps in the HTML documentation it generates. +Author: Jérémy Bobbio lu...@debian.org +Last-Update: 2014-09-24 + +--- cwidget-0.5.17.orig/Doxyfile.in cwidget-0.5.17/Doxyfile.in +@@ -699,6 +699,15 @@ HTML_HEADER= + + HTML_FOOTER= + ++# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML ++# page will contain the date and time when the page was generated. Setting this ++# to NO can help when comparing the output of multiple runs. ++# The default value is: YES. ++# This tag requires that the tag GENERATE_HTML is set to YES. ++ ++HTML_TIMESTAMP = NO ++ ++ + # The HTML_STYLESHEET tag can be used to specify a user-defined cascading + # style sheet that is used by each HTML page. It can be used to + # fine-tune the look of the HTML output. If the tag is left blank doxygen diff -Nru cwidget-0.5.17/debian/patches/series cwidget-0.5.17/debian/patches/series --- cwidget-0.5.17/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ cwidget-0.5.17/debian/patches/series 2014-09-24 10:56:13.0 +0200 @@ -0,0 +1 @@ +do-not-write-timestamps-in-documentation signature.asc Description: Digital signature
Bug#762674: python-apt: please don't embed the date and time of the build in apt_pkg
Source: python-apt Version: 0.9.3.10 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps Hi! As part of the “reproducible builds” projects [1], we have discovered that the apt_pkg module provided by python-apt embeds the date and time of the build. This makes the build process unreproducible. We don't believe such timestamps to be useful. In the case of apt_pkg, it's even a little bit confusing because the values of VERSION and LIB_VERSION are actually coming from apt, but DATE and TIME will depend solely on the build time of python-apt. The attached patch simply removes the DATE and TIME apt_pkg members. This is the only modification needed to make the package build reproducible. The sole known user of these members in the Debian archive in the example script in python-apt, according to codesearch: http://codesearch.debian.net/search?q=apt_pkg\.DATE http://codesearch.debian.net/search?q=apt_pkg\.TIME If the API change is not acceptable, another solution would be to generate their value from the latest entry of debian/changelog. [1]: https://wiki.debian.org/ReproducibleBuilds -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- diff -Nru python-apt-0.9.3.10/debian/changelog python-apt-0.9.3.10.0reproducible1/debian/changelog --- python-apt-0.9.3.10/debian/changelog 2014-09-04 18:08:55.0 +0200 +++ python-apt-0.9.3.10.0reproducible1/debian/changelog 2014-09-24 12:09:21.0 +0200 @@ -1,3 +1,10 @@ +python-apt (0.9.3.10.0reproducible1) UNRELEASED; urgency=medium + + * Stop providing apt_pkg.DATE and apt_pkg.TIME as they make the build +unreproducible. + + -- Jérémy Bobbio lu...@debian.org Wed, 24 Sep 2014 10:08:36 + + python-apt (0.9.3.10) unstable; urgency=medium * python/tag.cc: ensure that the final \n is there when diff -Nru python-apt-0.9.3.10/python/apt_pkgmodule.cc python-apt-0.9.3.10.0reproducible1/python/apt_pkgmodule.cc --- python-apt-0.9.3.10/python/apt_pkgmodule.cc 2014-09-04 18:08:55.0 +0200 +++ python-apt-0.9.3.10.0reproducible1/python/apt_pkgmodule.cc 2014-09-24 12:08:34.0 +0200 @@ -880,8 +880,6 @@ // Version.. PyModule_AddStringConstant(Module,VERSION,(char *)pkgVersion); PyModule_AddStringConstant(Module,LIB_VERSION,(char *)pkgLibVersion); - PyModule_AddStringConstant(Module,DATE,__DATE__); - PyModule_AddStringConstant(Module,TIME,__TIME__); // My constants PyModule_AddIntConstant(Module,PRI_IMPORTANT,pkgCache::State::Important); diff -Nru python-apt-0.9.3.10/doc/examples/config.py python-apt-0.9.3.10.0reproducible1/doc/examples/config.py --- python-apt-0.9.3.10/doc/examples/config.py 2014-09-04 16:08:55.0 + +++ python-apt-0.9.3.10.0reproducible1/doc/examples/config.py 2014-09-24 10:21:34.0 + @@ -45,8 +45,7 @@ print Version selected - 1.1 if Cnf.find_b(help, 0) == 1: -print python-apt, apt_pkg.VERSION, \ - compiled on, apt_pkg.DATE, apt_pkg.TIME +print python-apt, apt_pkg.VERSION print Hi, I am the help text for this program sys.exit(0) signature.asc Description: Digital signature
Bug#762732: libdebian-installer: please do not write timestamps in Doxygen generated documentation
Source: libdebian-installer Version: 0.96 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps Hi! As part of the “reproducible builds” project [1], we have identified that libdebian-installer writes the current date and time in the documentation generated by Doxygen. This prevents libdebian-installer to be built reproducibly. The attached patch tells Doxygen to skip writing timestamps in its output. libdebian-installer build process can then be reproduced just fine. [1]: https://wiki.debian.org/ReproducibleBuilds -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- diff -Nru libdebian-installer-0.96/debian/changelog libdebian-installer-0.96.0~reproducible1/debian/changelog --- libdebian-installer-0.96/debian/changelog 2014-09-04 22:28:21.0 +0200 +++ libdebian-installer-0.96.0~reproducible1/debian/changelog 2014-09-24 21:10:37.0 +0200 @@ -1,3 +1,10 @@ +libdebian-installer (0.96.0~reproducible1) UNRELEASED; urgency=low + + * Do not write timesamps in Doxygen generated documentation for +reproducibility of the build process. + + -- Jérémy Bobbio lu...@debian.org Wed, 24 Sep 2014 19:08:26 + + libdebian-installer (0.96) unstable; urgency=medium * arm64: Detect UEFI based systems as efi subarch. diff -Nru libdebian-installer-0.96/doc/Doxyfile.in libdebian-installer-0.96.0~reproducible1/doc/Doxyfile.in --- libdebian-installer-0.96/doc/Doxyfile.in 2014-09-04 22:28:21.0 +0200 +++ libdebian-installer-0.96.0~reproducible1/doc/Doxyfile.in 2014-09-24 21:08:19.0 +0200 @@ -1119,7 +1119,7 @@ # The default value is: YES. # This tag requires that the tag GENERATE_HTML is set to YES. -HTML_TIMESTAMP = YES +HTML_TIMESTAMP = NO # If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML # documentation will contain sections that can be hidden and shown after the signature.asc Description: Digital signature
Bug#762854: groff: please provide a way to specify a creation date
Package: groff Version: 1.22.2-8 Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: toolchain timestamps Hi! For the reasons outlined in https://lists.gnu.org/archive/html/groff/2014-08/msg00112.html, it would be great if groff could be given a creation date instead of always taking the current date and time. Thanks, -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#762666: cwidget: please stop writing timestamps in Doxygen generated documentation
Manuel A. Fernandez Montecelo: As part of the “reproducible builds” project [1], we have discovered that the documentation generated by Doxygen during cwidget build process contained timestamps. Together with #762622, this prevents cwidget builds to be reproducible. We believe that these timestamps in the documentation are not really useful, so the attached patch simply setup Doxygen to avoid writing them. [1]: https://wiki.debian.org/ReproducibleBuilds Thanks for the suggestion. Is this needed for some particular date, e.g. before Jessie's freeze? Or is it an ongoing thing that can be left for a bit later? It's a very small change. But please postpone it after Jessie if you feel it's best. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#763328: [Reproducible-builds] Bug#763328: RFP: reproducible/misc.git
Control: retitle -1 RFP: debbindiff Holger Levsen: please package git.debian.org/git/reproducible/misc.git - I mostly care about having the diffp tool installable via apt-get, so maybe move this into an existing package instead? But then I believe the other stuff is also useful, hence this RFP for a reproducible-tools package or such. I believe having /usr/bin/diffp easily installable will also be important for wider developer adoption during jessie+1s development cycle. Let's package debbindiff [1] instead. It's way less of a hack than diffp and produces more readable output. [1]: https://anonscm.debian.org/cgit/reproducible/debbindiff.git/ -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#763699: keepassx: please use source mtime as creation date when generating icons
Source: keepassx Version: 0.4.3+dfsg-0.1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps Hi! As part of the “reproducible builds” project [1], we have detected that keepassx embeds the current date and time when it generates the software icon in multiple sizes. This prevents keepassx build from being reproducible: https://jenkins.debian.net//userContent/diffp/keepassx_0.4.3+dfsg-0.1.diffp.html The attached patch will set the `date:create` and `date:modify` fields according to the mtime of the source files. keepassx then builds reproducibly. [1]: https://wiki.debian.org/ReproducibleBuilds -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- diff -Nru keepassx-0.4.3+dfsg/debian/changelog keepassx-0.4.3+dfsg/debian/changelog --- keepassx-0.4.3+dfsg/debian/changelog 2013-03-20 17:03:52.0 + +++ keepassx-0.4.3+dfsg/debian/changelog 2014-10-01 21:55:54.0 + @@ -1,3 +1,11 @@ +keepassx (0.4.3+dfsg-0.2~reproducible1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Use source file mtime as creation and modfication time while converting +icons for build reproducibility. + + -- Jérémy Bobbio lu...@debian.org Wed, 01 Oct 2014 21:54:51 + + keepassx (0.4.3+dfsg-0.1) unstable; urgency=high * Non-maintainer upload. diff -Nru keepassx-0.4.3+dfsg/debian/rules keepassx-0.4.3+dfsg/debian/rules --- keepassx-0.4.3+dfsg/debian/rules 2012-04-07 16:14:51.0 + +++ keepassx-0.4.3+dfsg/debian/rules 2014-10-01 21:54:44.0 + @@ -4,6 +4,11 @@ %: dh $@ --parallel --buildsystem=qmake_qt4 +MEDIUM_ICON = share/keepassx/icons/keepassx.png +MEDIUM_ICON_DATE = $(shell date '+%Y-%m-%dT%H:%M:%S%:z' --reference='$(MEDIUM_ICON)') +LARGE_ICON = debian/keepassx.svg +LARGE_ICON_DATE = $(shell date '+%Y-%m-%dT%H:%M:%S%:z' --reference='$(LARGE_ICON)') + override_dh_auto_install: dh_auto_install @@ -17,15 +22,27 @@ cp share/keepassx/icons/keepassx_small.png \ debian/keepassx/usr/share/icons/hicolor/16x16/apps/keepassx.png - convert share/keepassx/icons/keepassx.png -resize 24x24 \ + convert -resize 24x24 \ + -set date:create $(MEDIUM_ICON_DATE) \ + -set date:modify $(MEDIUM_ICON_DATE) \ + $(MEDIUM_ICON) \ debian/keepassx/usr/share/icons/hicolor/24x24/apps/keepassx.png cp share/keepassx/icons/keepassx.png \ debian/keepassx/usr/share/icons/hicolor/32x32/apps/keepassx.png - convert -density 72 -background none debian/keepassx.svg \ + convert -density 72 -background none \ + -set date:create $(LARGE_ICON_DATE) \ + -set date:modify $(LARGE_ICON_DATE) \ + $(LARGE_ICON) \ debian/keepassx/usr/share/icons/hicolor/48x48/apps/keepassx.png - convert -density 96 -background none debian/keepassx.svg \ + convert -density 96 -background none \ + -set date:create $(LARGE_ICON_DATE) \ + -set date:modify $(LARGE_ICON_DATE) \ + $(LARGE_ICON) \ debian/keepassx/usr/share/icons/hicolor/64x64/apps/keepassx.png - convert -density 192 -background none debian/keepassx.svg \ + convert -density 192 -background none \ + -set date:create $(LARGE_ICON_DATE) \ + -set date:modify $(LARGE_ICON_DATE) \ + $(LARGE_ICON) \ debian/keepassx/usr/share/icons/hicolor/128x128/apps/keepassx.png cp debian/keepassx.svg \ debian/keepassx/usr/share/icons/hicolor/scalable/apps/keepassx.svg signature.asc Description: Digital signature
Bug#763822: ftp.debian.org: please include .buildinfo file in the archive
Package: ftp.debian.org Severity: wishlist User: ftp.debian@packages.debian.org Usertags: archive Hi! As part of the “reproducible builds” effort [1], we came up with the idea of a new control file, currently named “.buildinfo” .buildinfo files would capture from the build environment as much information as needed to reproduce the build. The file format and how it could be included in the archive is described on the wiki [2]. An exercise in summarizing the key points: * A .buildinfo file is generated for each build, and is considered unique for a source package, version, and architecture. A rebuild should always generate the same .buildinfo as the original build. * A .buildinfo contains many fields similar to .changes, and the list of all packages forming the build environment (build-deps, their deps, Essential:yes, build-essential, etc.) * .buildinfo would be distributed in the archive together with source and binary packages. * They would be accompanied by detached GnuPG signatures, so multiple parties (e.g. DD and buildd) could assert the production of similar binary packages from the same source and same environment. * The latter information can then be shown in the Packages index for each binary packages. * A tool will allow independent parties to rebuild binary packages from .buildinfo files in the archive. We wish .buildinfo files could become part of the Debian archive. For that to happen, we highly welcome your comments on the current specification, and advices regarding the next steps we could make. During our experiments, adding .buildinfo files to .changes had one unforeseen consequence. Packages that used to be “Architecture: all” are now “Architecture: all amd64” as .buildinfo are tied to a given build architecture. Except that it breaks lintian test suite, it is unclear if that's a problem at all, or if some changes should be made. Again, your input would be most welcome. [1]: https://wiki.debian.org/ReproducibleBuilds [2]: https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#719845: [PATCH] Deterministic file order for control and data archives
Jérémy Bobbio:
Here are four patches based on the current master (1e059955) that will
write files in deterministic order in the control and data archives.
File names are sorted by forking `sort` before being piped to `tar`.
Attached are the patch based on current master (36eda4c1bc).
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From 05791de26a9cc119aa4742bbb61c58d19348b176 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Tue, 27 Aug 2013 18:10:15 +0200
Subject: [PATCH 1/4] Ensure deterministic file order in data.tar.* files
Address: #719845
---
dpkg-deb/build.c | 42 ++
lib/dpkg/dpkg.h |1 +
2 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
index 442298d..eccc27f 100644
--- a/dpkg-deb/build.c
+++ b/dpkg-deb/build.c
@@ -168,19 +168,36 @@ file_info_list_free(struct file_info *fi)
static void
file_treewalk_feed(const char *dir, int fd_out)
{
- int pipefd[2];
- pid_t pid;
+ int sort_pipefd[2], find_pipefd[2];
+ pid_t sort_pid, find_pid;
struct file_info *fi;
struct file_info *symlist = NULL;
struct file_info *symlist_end = NULL;
- m_pipe(pipefd);
+ m_pipe(find_pipefd);
+ m_pipe(sort_pipefd);
+
+ sort_pid = subproc_fork();
+ if (sort_pid == 0) {
+m_dup2(find_pipefd[0], 0);
+close(find_pipefd[0]);
+close(find_pipefd[1]);
+m_dup2(sort_pipefd[1], 1);
+close(sort_pipefd[0]);
+close(sort_pipefd[1]);
+if (setenv(LC_ALL, C, 1 /* overwrite */))
+ohshite(_(unable to setenv));
+execlp(SORT, sort, --zero-terminated, NULL);
+ohshite(_(unable to execute %s (%s)), sort, SORT);
+ }
+ close(find_pipefd[0]);
+ close(sort_pipefd[1]);
- pid = subproc_fork();
- if (pid == 0) {
-m_dup2(pipefd[1], 1);
-close(pipefd[0]);
-close(pipefd[1]);
+ find_pid = subproc_fork();
+ if (find_pid == 0) {
+m_dup2(find_pipefd[1], 1);
+close(find_pipefd[0]);
+close(find_pipefd[1]);
if (chdir(dir))
ohshite(_(failed to chdir to `%.255s'), dir);
@@ -189,11 +206,11 @@ file_treewalk_feed(const char *dir, int fd_out)
-print0, NULL);
ohshite(_(unable to execute %s (%s)), find, FIND);
}
- close(pipefd[1]);
+ close(find_pipefd[1]);
/* We need to reorder the files so we can make sure that symlinks
* will not appear before their target. */
- while ((fi = file_info_get(dir, pipefd[0])) != NULL) {
+ while ((fi = file_info_get(dir, sort_pipefd[0])) != NULL) {
if (S_ISLNK(fi-st.st_mode)) {
file_info_list_append(symlist, symlist_end, fi);
} else {
@@ -204,8 +221,9 @@ file_treewalk_feed(const char *dir, int fd_out)
}
}
- close(pipefd[0]);
- subproc_reap(pid, find, 0);
+ close(sort_pipefd[0]);
+ subproc_reap(find_pid, find, 0);
+ subproc_reap(sort_pid, sort, 0);
for (fi = symlist; fi; fi = fi-next)
if (fd_write(fd_out, fi-fn, strlen(fi-fn) + 1) 0)
diff --git a/lib/dpkg/dpkg.h b/lib/dpkg/dpkg.h
index 1dfef96..8bbad67 100644
--- a/lib/dpkg/dpkg.h
+++ b/lib/dpkg/dpkg.h
@@ -112,6 +112,7 @@ DPKG_BEGIN_DECLS
#define CAT cat
#define FIND find
#define DIFF diff
+#define SORT sort
#define FIND_EXPRSTARTCHARS -(),!
--
1.7.10.4
From e27bef15519d4641cc37553660d39eb830b76daa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Fri, 17 Jan 2014 12:56:13 +0100
Subject: [PATCH 2/4] Extract the creation of the control tarball to a
dedicated function
---
dpkg-deb/build.c | 73 --
1 file changed, 43 insertions(+), 30 deletions(-)
diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
index eccc27f..3059954 100644
--- a/dpkg-deb/build.c
+++ b/dpkg-deb/build.c
@@ -232,6 +232,40 @@ file_treewalk_feed(const char *dir, int fd_out)
file_info_list_free(symlist);
}
+static void
+create_control_tar(const char *dir, struct compress_params *control_compress_params,
+ int gzfd)
+{
+ int p1[2];
+ pid_t c1, c2;
+
+ /* Fork a tar to package the control-section of the package. */
+ unsetenv(TAR_OPTIONS);
+ m_pipe(p1);
+ c1 = subproc_fork();
+ if (!c1) {
+m_dup2(p1[1],1); close(p1[0]); close(p1[1]);
+if (chdir(dir))
+ ohshite(_(failed to chdir to `%.255s'), dir);
+if (chdir(BUILDCONTROLDIR))
+ ohshite(_(failed to chdir to `%.255s'), .../DEBIAN);
+execlp(TAR, tar, -cf, -, --format=gnu, ., NULL);
+ohshite(_(unable to execute %s (%s)), tar -cf, TAR);
+ }
+ close(p1[1]);
+
+ /* And run the compressor on our control archive. */
+
+ c2 = subproc_fork();
+ if (!c2) {
+compress_filter(control_compress_params, p1[0], gzfd, _(compressing control member));
+exit(0);
+ }
+ close(p1[0]);
+ subproc_reap(c2, gzip -9c, 0);
+ subproc_reap(c1, tar
Bug#759999: dpkg: please set reproducible timestamps in .deb ar file headers
Jérémy Bobbio:
The first patch will modify `dpkg-deb` to use the same timestamp for
every member of the ar archive.
The second patch will:
1. Make `dpkg-deb` try to look for a timestamp to use in the
DEB_BUILD_TIMESTAMP environment variable in epoch format.
If not set or not parseable, it will default to use the current
time.
2. Change `dpkg-buildpackage` to parse `debian/changelog` and preset
DEB_BUILD_TIMESTAMP to the value of its latest entry. Unless
DEB_BUILD_TIMESTAMP was already set in order to allow arbitrary
dates to be reproduced.
The patches rebased on current master are attached (36eda4c1bc).
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From 075bc4fd3d83604f0b38819179f559165bc75779 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Tue, 27 Aug 2013 22:38:31 +0200
Subject: [PATCH 1/2] Use a single timestamp for ar headers when building a
.deb
In order to make build reproducible in the future, we now use a single
timestamp in all ar headers when creating a .deb.
Previously, each ar header would have the current time of its creation.
This level of precision is not really needed and the time of the beginning of
the build is good enough.
Address: #75
---
dpkg-deb/build.c | 10 +++---
dpkg-split/split.c |4 ++--
lib/dpkg/ar.c | 13 +++--
lib/dpkg/ar.h |4 ++--
4 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
index e48b4bf..6406493 100644
--- a/dpkg-deb/build.c
+++ b/dpkg-deb/build.c
@@ -38,6 +38,7 @@
#include stdint.h
#include stdlib.h
#include stdio.h
+#include time.h
#include dpkg/i18n.h
#include dpkg/dpkg.h
@@ -500,6 +501,7 @@ do_build(const char *const *argv)
int arfd;
int p1[2], p2[2], gzfd;
pid_t c1, c2;
+ time_t build_timestamp;
/* Decode our arguments. */
dir = *argv++;
@@ -546,6 +548,8 @@ do_build(const char *const *argv)
}
m_output(stdout, _(standard output));
+ build_timestamp = time(NULL);
+
/* Now that we have verified everything its time to actually
* build something. Let's start by making the ar-wrapper. */
arfd = creat(debar, 0644);
@@ -600,8 +604,8 @@ do_build(const char *const *argv)
compressor_get_extension(control_compress_params.type));
dpkg_ar_put_magic(debar, arfd);
-dpkg_ar_member_put_mem(debar, arfd, DEBMAGIC, deb_magic, strlen(deb_magic));
-dpkg_ar_member_put_file(debar, arfd, adminmember, gzfd, -1);
+dpkg_ar_member_put_mem(debar, arfd, DEBMAGIC, deb_magic, build_timestamp, strlen(deb_magic));
+dpkg_ar_member_put_file(debar, arfd, adminmember, gzfd, build_timestamp, -1);
} else {
internerr(unknown deb format version %d.%d, deb_format.major, deb_format.minor);
}
@@ -671,7 +675,7 @@ do_build(const char *const *argv)
if (lseek(gzfd, 0, SEEK_SET))
ohshite(_(failed to rewind temporary file (%s)), _(data member));
-dpkg_ar_member_put_file(debar, arfd, datamember, gzfd, -1);
+dpkg_ar_member_put_file(debar, arfd, datamember, gzfd, build_timestamp, -1);
close(gzfd);
}
diff --git a/dpkg-split/split.c b/dpkg-split/split.c
index fe4b60e..68109dc 100644
--- a/dpkg-split/split.c
+++ b/dpkg-split/split.c
@@ -216,13 +216,13 @@ mksplit(const char *file_src, const char *prefix, off_t maxpartsize,
(intmax_t)st.st_size, (intmax_t)partsize,
curpart, nparts, arch);
dpkg_ar_member_put_mem(file_dst.buf, fd_dst, PARTMAGIC,
- partmagic.buf, partmagic.used);
+ partmagic.buf, time(NULL), partmagic.used);
varbuf_reset(partmagic);
/* Write the data part. */
varbuf_printf(partname, data.%d, curpart);
dpkg_ar_member_put_file(file_dst.buf, fd_dst, partname.buf,
- fd_src, cur_partsize);
+ fd_src, time(NULL), cur_partsize);
varbuf_reset(partname);
close(fd_dst);
diff --git a/lib/dpkg/ar.c b/lib/dpkg/ar.c
index cf540a0..8613310 100644
--- a/lib/dpkg/ar.c
+++ b/lib/dpkg/ar.c
@@ -36,11 +36,12 @@
#include dpkg/ar.h
static void
-dpkg_ar_member_init(struct dpkg_ar_member *member, const char *name, off_t size)
+dpkg_ar_member_init(struct dpkg_ar_member *member, const char *name,
+time_t timestamp, off_t size)
{
member-name = name;
member-size = size;
- member-time = time(NULL);
+ member-time = timestamp;
member-mode = 0100644;
member-uid = 0;
member-gid = 0;
@@ -124,11 +125,11 @@ dpkg_ar_member_put_header(const char *ar_name, int ar_fd,
void
dpkg_ar_member_put_mem(const char *ar_name, int ar_fd,
- const char *name, const void *data, size_t size)
+ const char *name, const void *data, time_t timestamp, size_t size
Bug#764251: socat: please set the build timestamp to a deterministic time
Source: socat Version: 1.7.2.4-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps Hi! As part of the “reproducible builds” effort, we have discovered that socat is using the __DATE__ and __TIME__ C pre-processor macro to record the time of the build. This prevent socat build to be reproducible. The attached patch will instead set the value of the `timestamp` variable to the date of the latest debian/changelog entry. In order to do so, it will patch the build system to allow the build timestamp to be externally set through the BUILD_DATE variable. Once applied, socat can be built reproducibly. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- diff -Nru socat-1.7.2.4/debian/changelog socat-1.7.2.4/debian/changelog --- socat-1.7.2.4/debian/changelog 2014-06-24 21:20:21.0 +0200 +++ socat-1.7.2.4/debian/changelog 2014-10-06 17:56:32.0 +0200 @@ -1,3 +1,10 @@ +socat (1.7.2.4-1.0~reproducible1) UNRELEASED; urgency=medium + + * Patch build system to allow the build date to be set externally, +and set it to the latest debian/changelog entry for reproducibility. + + -- Jérémy Bobbio lu...@debian.org Mon, 06 Oct 2014 17:55:47 +0200 + socat (1.7.2.4-1) unstable; urgency=low * New upstream release, update patches. diff -Nru socat-1.7.2.4/debian/control socat-1.7.2.4/debian/control --- socat-1.7.2.4/debian/control 2014-06-24 19:15:04.0 +0200 +++ socat-1.7.2.4/debian/control 2014-10-06 17:51:02.0 +0200 @@ -3,7 +3,7 @@ Priority: extra Maintainer: Laszlo Boszormenyi (GCS) g...@debian.org Homepage: http://www.dest-unreach.org/socat/ -Build-Depends: debhelper (= 9), libssl-dev, libwrap0-dev +Build-Depends: debhelper (= 9), dh-autoreconf, libssl-dev, libwrap0-dev Standards-Version: 3.9.5 Package: socat diff -Nru socat-1.7.2.4/debian/patches/04-Set-build-date socat-1.7.2.4/debian/patches/04-Set-build-date --- socat-1.7.2.4/debian/patches/04-Set-build-date 1970-01-01 01:00:00.0 +0100 +++ socat-1.7.2.4/debian/patches/04-Set-build-date 2014-10-06 18:55:35.0 +0200 @@ -0,0 +1,41 @@ +Description: allow time of the build to be set externally + When running the configure script, the time of the build + will be set to the environment variable BUILD_DATE if the + latr is set. This is needed to make builds reproducible. +Author: Jérémy Bobbio lu...@debian.org +Last-Update: 2014-10-06 + +--- socat-1.7.2.4.orig/configure.in socat-1.7.2.4/configure.in +@@ -1844,4 +1844,11 @@ if test -n $WITH_FIPS; then + fi + AC_SUBST(FIPSLD_CC) + ++# allow BUILD_DATE to be externally set for build reproducibility ++if test $BUILD_DATE; then ++ AC_DEFINE_UNQUOTED(BUILD_DATE, [$BUILD_DATE]) ++else ++ AC_DEFINE(BUILD_DATE, [__DATE__ __TIME__]) ++fi ++ + AC_OUTPUT(Makefile) +--- socat-1.7.2.4.orig/socat.c socat-1.7.2.4/socat.c +@@ -70,7 +70,7 @@ static int socat_newchild(void); + static const char socatversion[] = + #include ./VERSION + ; +-static const char timestamp[] = __DATE__ __TIME__; ++static const char timestamp[] = BUILD_DATE; + + const char copyright_socat[] = socat by Gerhard Rieger - see www.dest-unreach.org; + #if WITH_OPENSSL +--- socat-1.7.2.4.orig/config.h.in socat-1.7.2.4/config.h.in +@@ -550,4 +550,6 @@ + + #undef WITH_MSGLEVEL + ++#define BUILD_DATE __DATE__ __TIME__ ++ + #endif /* !defined(__config_h_included) */ diff -Nru socat-1.7.2.4/debian/patches/series socat-1.7.2.4/debian/patches/series --- socat-1.7.2.4/debian/patches/series 2014-06-24 21:11:46.0 +0200 +++ socat-1.7.2.4/debian/patches/series 2014-10-06 18:55:59.0 +0200 @@ -2,3 +2,4 @@ 01-Index 02-Manpage-slashes 03-Truncate +04-Set-build-date diff -Nru socat-1.7.2.4/debian/rules socat-1.7.2.4/debian/rules --- socat-1.7.2.4/debian/rules 2013-07-03 20:12:23.0 +0200 +++ socat-1.7.2.4/debian/rules 2014-10-06 18:47:18.0 +0200 @@ -1,7 +1,12 @@ #!/usr/bin/make -f +export BUILD_DATE = $(shell LC_ALL=C date -u --date=`dpkg-parsechangelog -SDate` +'%b %e %Y %H:%M:%S') + +# upsteram maintains config.h.in manually +export AUTOHEADER = true + %: - dh $@ + dh $@ --with=autoreconf override_dh_auto_configure: dh_auto_configure -- --disable-readline signature.asc Description: Digital signature
Bug#764251: socat: please set the build timestamp to a deterministic time
Ian Jackson: Jérémy Bobbio writes (Bug#764251: socat: please set the build timestamp to a deterministic time): As part of the “reproducible builds” effort, we have discovered that socat is using the __DATE__ and __TIME__ C pre-processor macro to record the time of the build. This prevent socat build to be reproducible. The attached patch will instead set the value of the `timestamp` variable to the date of the latest debian/changelog entry. In order to do so, it will patch the build system to allow the build timestamp to be externally set through the BUILD_DATE variable. Once applied, socat can be built reproducibly. Thanks. I have reviewed the patch and it looks good to me. Have you considered sending something like this upstream ? I've designed the patch so it would have a chance to be accepted upstream. I was hoping the package maintainers would push it there if it was deemed good enough. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#769844: linux: please make linux build reproducibly
Source: linux Version: 3.16.7-2 Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps randomness Control: block -1 by 759886 Hi! I have been doing some experimentation on making linux build reproducibly [1]. With the attached patches, we are down to three binary packages with differences on amd64. The kernel itself and its module can be built reproducibly with our current framework. The first patch adds call to `dh_strip_nondeterminism` and `dh_fixmtimes`, both being part of the custom toolchain currently used for reproducible builds. Hence not tagging the bug with “patch” until they are integrated in debhelper. The second patch changes the value of KBUILD_BUILD_TIMESTAMP to a timestamp parseable by `date`. Otherwise, a timestamp of the current time gets stored in usr/initramfs_data.cpio.gz because `scripts/gen_initramfs_list.sh` will not pass the value of KBUILD_BUILD_TIMESTAMP to `usr/gen_init_cpio`. http://sources.debian.net/src/linux/3.16.7-2/scripts/gen_initramfs_list.sh/?hl302:308#L302 Another solution would be to patch `scripts/gen_initramfs_list.sh` to parse the Debian format of KBUILD_BUILD_TIMESTAMP. An unclear aspect is where to add a call to `dh_genbuildinfo` which generates the .buildinfo [2]. It should be called after all binary packages have been created. For the remaining differences: * linux-doc: many variations due to ids generated in HTML documentation by XSLT processor. This needs to be addressed at that level. * linux-manual: see attached debbindiff output. I don't have good ideas. * linux-source: mtimes of many files differ. Would it be ok to just create the tarball with a single timestamp (`tar --mtime=`)? [1]: https://wiki.debian.org/ReproducibleBuilds [2]: https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- --- linux-3.16.7/debian/rules.real 2014-11-04 04:41:34.0 + +++ b1/linux-3.16.7/debian/rules.real 2014-11-14 22:07:20.272662604 + @@ -173,12 +173,14 @@ dh_installdocs $(INSTALLDOCS_ARGS) dh_installchangelogs dh_strip + dh_strip_nondeterminism dh_compress dh_fixperms dh_installdeb dh_gencontrol -- $(GENCONTROL_ARGS) dh_md5sums + dh_fixmtimes dh_builddeb -- -Zxz $(BUILDDEB_ARGS) install-dummy: dh_testdir @@ -427,8 +430,10 @@ dh_prep kernel-wedge install-files $(ABINAME) kernel-wedge check $(PACKAGE_NAMES) + dh_strip_nondeterminism dh_fixperms dh_gencontrol + dh_fixmtimes dh_builddeb install-source: PACKAGE_NAME = linux-source-$(VERSION) --- linux-3.16.7/debian/rules.real 2014-11-04 04:41:34.0 + +++ b1/linux-3.16.7/debian/rules.real 2014-11-14 22:07:20.272662604 + @@ -39,7 +39,7 @@ stamp = [ -d $(dir $@) ] || mkdir $(dir $@); touch $@ setup_env := env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u LOCALVERSION -setup_env += DISTRIBUTION_OFFICIAL_BUILD=1 DISTRIBUTOR=$(DISTRIBUTOR) DISTRIBUTION_VERSION=$(SOURCEVERSION) KBUILD_BUILD_TIMESTAMP=$(DISTRIBUTOR) $(SOURCEVERSION) ($(SOURCE_DATE_UTC_ISO)) KBUILD_BUILD_USER=$(word 1,$(subst @, ,$(MAINTAINER))) KBUILD_BUILD_HOST=$(word 2,$(subst @, ,$(MAINTAINER))) +setup_env += DISTRIBUTION_OFFICIAL_BUILD=1 DISTRIBUTOR=$(DISTRIBUTOR) DISTRIBUTION_VERSION=$(SOURCEVERSION) KBUILD_BUILD_TIMESTAMP=$(SOURCE_DATE_UTC_ISO) KBUILD_BUILD_USER=$(word 1,$(subst @, ,$(MAINTAINER))) KBUILD_BUILD_HOST=$(word 2,$(subst @, ,$(MAINTAINER))) MAKE_CLEAN = $(setup_env) $(MAKE) MAKE_SELF := $(MAKE) -f debian/rules.real $(MAKEOVERRIDES) Title: /usr/bin/debbindiff --debug --html debbindiff-manual.html b1/linux-manual-3.16_3.16.7-2.0~reproducible1_all.deb b2/linux-manual-3.16_3.16.7-2.0~reproducible1_all.deb linux-manual-3.16_3.16.7-2.0~reproducible1_all.deb control.tar.gz control.tar md5sums Files in package differs data.tar.xz data.tar kthread_create_on_node.9.gz kthread_create_on_node.9 1 +-- 63 lines: '\ t- 64 This helper function creates and names a kernel thread\. The thread will be stopped: use 65 \fBwake_up_process\fR 66 to start it\. See also 67 \fBkthread_run\fR\. 68 .PP 69 If thread is going to be bound on a particular cpu, give its node in 70 \fInode\fR, to get NUMA affinity for kthread stack, or else give \-1\. When woken, the thread will run 71 \fIthreadfn\fR() with 72 \fIdata\fR 73 as its argument\. 74 \fIthreadfn\fR() can either call 75 \fBdo_exit\fR 76 directly if it is a standalone thread for which no one will call 77 \fBkthread_stop\fR, or return when \*(Aq\fBkthread_should_stop\fR\*(Aq is true (which means 78 \fBkthread_stop\fR 79 has been
Bug#769844: linux: please make linux build reproducibly
Bastian Blank: On Mon, Nov 17, 2014 at 12:46:45AM +0100, Jérémy Bobbio wrote: The first patch adds call to `dh_strip_nondeterminism` and `dh_fixmtimes`, both being part of the custom toolchain currently used for reproducible builds. Hence not tagging the bug with “patch” until they are integrated in debhelper. Why does this need new tool instead of being integrated into the existing ones? I am not sure which ones you specifically have in mind, but the whole project is still at the experimental stage. We try to work in unintrusive ways. The second patch changes the value of KBUILD_BUILD_TIMESTAMP to a timestamp parseable by `date`. Well, no. The string is this way for a reason. Would a patch against `scripts/gen_initramfs_list.sh` to make it parse Debian's KBUILD_BUILD_TIMESTAMP be acceptable then? Any other suggestions? An unclear aspect is where to add a call to `dh_genbuildinfo` which generates the .buildinfo [2]. It should be called after all binary packages have been created. Not possible, dh_* acts on single binary packages. Mh… I'm not sure we had realized that. It makes a case to move the generation of the .buildinfo closer to dpkg-genchanges. * linux-source: mtimes of many files differ. Would it be ok to just create the tarball with a single timestamp (`tar --mtime=`)? Looks like a way. Good. :) I will experiment with this approach and probably add another patch to this bug report. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#769893: ghc: Make compilation deterministic
user reproducible-bui...@lists.alioth.debian.org usertags 769893 + toolchain randomness Joachim Breitner: It'd be much appreciated if this was applied to 7.6.3, which would affect 300 Haskell packages that are currently not reproducible. glad to hear this! Very good news! :) So either get a pre-approval from the release team, or ping us again after the release. This can definitely wait for the release, no hurry. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#770213: jenkins.d.n: please create a milestone page for build reproducibility of core packages
Package: qa.debian.org Severity: wishlist Control: user qa.debian@packages.debian.org Control: usertags -1 jenkins Control: user reproducible-bui...@lists.alioth.debian.org Control: usertags -1 infrastructure Hi! As part of the reproducible build pages on jenkins.d.n, it would be great to have a dedicate pages tracking progress for core packages. Some kind of progress bar and a status list of the packages would be great. A list of core packages can be optained from UDD: https://wiki.debian.org/ReproducibleBuilds#Archive_wide_rebuilds Thanks, -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#770365: debsources: 403 on /src/beignet/1.0.0-1/README.md/
Package: qa.debian.org Severity: normal User: qa.debian@packages.debian.org Usertags: debsources Hi! When visiting https://sources.debian.net/src/beignet/1.0.0-1/README.md/ I'm told “403 Permission Denied”. This is a bit annoying as the file is listed on https://sources.debian.net/src/beignet/1.0.0-1/ Thanks, -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#772029: [Reproducible-builds] Bug#772029: debbindiff: please avoid hardcoded use of VIm
Control: severity -1 wishlist Jonas Smedegaard: I am not a VIm user, however, and its hardcoded use of that editor is strongly discouraging for me (no, I do not use emacs either). Please consider recoding¹ to not rely on VIm-specific features, to appeal also to users of other interactive editors. Feel free to provide another way to generate HTML diffs in a reasonable amount of time (Python html diff is out of the picture) which are readable. I've looked a bit before hacking the current solution and nothing worked out. Users of debbindiff don't need to know anything about vim. Vim is not used as an editor at all. I don't see why it would be problematic to depend on vim as an external tool, and how it would differ from msgunfmt (gettext package) which is needed to process .mo files. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#773916: libical: Ship different constant values accross builds
Package: libical-dev Version: 1.0-1.1 Severity: critical User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness Hi! While working on the “reproducible builds” effort [1], we have noticed that libical could not be built reproducibly: https://jenkins.debian.net/userContent/dbd/libical_1.0-1.1.debbindiff.html The debbindiff output linked above show that two builds of libical will output different values for the constant defined in the icalvalue_kind enum in ical.h and icalderivedvalue.h. This is bad. It means that any software using these values will break when libical is updated. After a quick look at the report, this might be the cause for #766454. The problem highly likely lies in the following code: https://sources.debian.net/src/libical/1.0-1.1/scripts/mkderivedvalues.pl/?hl=66:74#L66 Sorting the keys before using them should make the output stable accross builds. Ideally this should be done in all similar constructs to enable the package to build reproducibly. Packages having a Build-Depends on libical-dev should probably be binNMU'ed once this is fixed. That should be: agenda.app, asterisk, bluez, cairo-dock-plug-ins, citadel, cyrus-imapd-2.4, evolution, evolution-data-server, evolution-ews, gnokii, goldencheetah, ical2html, kdepimlibs, kmymoney, libsynthesis, openchange, orage, osmo, syncevolution, webcit. [1]: https://wiki.debian.org/ReproducibleBuilds -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
