Re: [Reproducible-builds] ARM build machines
Hi, On Montag, 3. August 2015, Vagrant Cascadian wrote: Oops. Accidentally dropped it on one of the debian.net updates. Re-added just now, got the ack that it was added, now just need to wait for DNS propagation... thanks! (as you may notice, they're all CNAMEs with a consistant pattern, so you could try accessing them directly in a pinch...) yes, I knew the IP, but prefered to get this fixed instead of working around it :) cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] diffoscope_29_amd64.changes is NEW
binary:diffoscope is NEW. source:diffoscope is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will recieve an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#793460: marked as done (debbindiff: please consider backport to Jessie)
Your message dated Mon, 3 Aug 2015 23:20:50 + with message-id 20150803232050.ga32...@chase.mapreri.org and subject line debbindiff landed in jessie-backports has caused the Debian Bug report #793460, regarding debbindiff: please consider backport to Jessie to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 793460: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793460 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: debbindiff Version: 26 Severity: wishlist In devscripts/stable, debbindiff is mentioned both in the long package description as well as in debdiff(1). However, debbindiff does not exist in stable. A backport to Jessie would be nice. ---End Message--- ---BeginMessage--- debbindiff landed in backports yesterday, thus closing this bug. fyi: yes, uploads to backports does not interact with the back tracker i no way. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: Digital signature ---End Message--- ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [PATCH] Makefile: Use correct timezone for U_BOOT_TZ
Le vendredi 31 juillet 2015 à 22:04 +1200, Chris Packham a écrit :
When building with SOURCE_DATE_EPOCH the timezone is in UTC. When
building normally the timezone is taken from the build machine's locale
setting.
Thanks a lot for introducing this, I thought it might disturb a few
people.
Fixes: f3f431a71272 (Reproducible U-Boot build support, using
SOURCE_DATE_EPOCH)
It is incorrect to say that your patch fixes my commit, because my
commit didn't introduce anything unexpected or faulty.
If anything, it was merged before people gave their opinion about
whether UTC should be default. I was also going to introduce a patch
like yours later. For the record, UTC is default for Coreboot's
timestamps.
Thus, please remove that line.
Otherwise, this is:
Tested-By: Paul Kocialkowski cont...@paulk.fr
Signed-off-by: Chris Packham judge.pack...@gmail.com
---
Hopefully this will suit everyone. I've done a quick sanity test with
sandbox and the date shown in the version output looks to be what I
expect with/without SOURCE_DATE_EPOCH.
Makefile | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 394ed09..f75c730 100644
--- a/Makefile
+++ b/Makefile
@@ -1230,10 +1230,16 @@ define filechk_version.h
endef
define filechk_timestamp.h
- (SOURCE_DATE=$${SOURCE_DATE_EPOCH:+@$$SOURCE_DATE_EPOCH}; \
- LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_DATE %b %d
%C%y'; \
- LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_TIME %T';
\
- LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_TZ %z' )
+ (if test -n $${SOURCE_DATE_EPOCH}; then \
+ SOURCE_DATE=@$${SOURCE_DATE_EPOCH}; \
+ LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_DATE %b
%d %C%y'; \
+ LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_TIME
%T'; \
+ LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_TZ
%z'; \
+ else \
+ LC_ALL=C date +'#define U_BOOT_DATE %b %d %C%y'; \
+ LC_ALL=C date +'#define U_BOOT_TIME %T'; \
+ LC_ALL=C date +'#define U_BOOT_TZ %z'; \
+ fi)
endef
$(version_h): include/config/uboot.release FORCE
signature.asc
Description: This is a digitally signed message part
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Reproducibility vs signatures
On Mon, 2015-08-03 at 10:27 +0200, Jérémy Bobbio wrote: Ben Hutchings: At some point we're hopefully going to support Secure Boot on amd64. That means there will be a signed kernel image (separate from the current linux-image packages) and a signed GRUB image. The kernel modules in the linux-image packages will also be signed, probably with an ephemeral key. All these signatures will all be embedded within binaries and will of course not be reproducible. The locations of differences will however be predictable. How should we deal with this limited variability? Could source packages or buildinfo describe the expected variations somehow? One way to solve this, although a bit wasteful on resource, is to use the clean rule to perform a first build and create a signature to be added to the source package. That sort of works as long as there's only one architecture we want to do this for. But the ability to verify modules is useful in general so I would like to turn that on for all architectures. See my suggest patch for wireless-regdb which implements this idea: https://bugs.debian.org/725803#29 Would that be a good fit for Linux or GRUB? Not really; they both take a long time to build. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Reproducibility vs signatures
Hi, On Montag, 3. August 2015, Ben Hutchings wrote: See https://lists.debian.org/debian-kernel/2013/08/msg00267.html. Thanks. That seems to say that a.) only the kernel team can sign kernels, so no user signed kernels?? and b.) only amd64, while I believe uefi arm mainboards are there already or will be soon? cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Reproducibility vs signatures
On Mon, 2015-08-03 at 12:46 +0200, Holger Levsen wrote: Hi, On Montag, 3. August 2015, Ben Hutchings wrote: See https://lists.debian.org/debian-kernel/2013/08/msg00267.html. Thanks. That seems to say that a.) only the kernel team can sign kernels, so no user signed kernels?? Only the FTP team will be able to get shim signed by the Microsoft CA. Only the FTP team will be able to sign GRUB and the kernel using the private key for which the public part is embedded in shim. Users can add further trusted keys at boot time through the BIOS setup program or shim; then they can use their own signed kernels. and b.) only amd64, while I believe uefi arm mainboards are there already or will be soon? I don't think they support Secure Boot though. If they do, and if they allow users to change the trusted keys, then we should sign for arm64 as well. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [RFC PATCH] Makefile: Add SOURCE_DATE_TZ
On 01/08/15 20:47, Paul Kocialkowski wrote: Le samedi 01 août 2015 à 22:32 +1200, Chris Packham a écrit : Along with SOURCE_DATE_EPOCH SOURCE_DATE_TZ can be used to recreate a build with a specific date timestamp. This allows the verification of source supplied with a pre-compiled binary. If SOURCE_DATE_EPOCH is supplied SOURCE_DATE_TZ can be used to specify what will appear in the output of the version command. If SOURCE_DATE_TZ is not specified UTC will be used. SOURCE_DATE_TZ on it's own will not have an affect. Well, I worked with the assumption that SOURCE_DATE_EPOCH would always be provided in UTC, but I see no harm in providing SOURCE_DATE_TZ as well, provided that it falls back to UTC when not set, as is the current behaviour of tour patch. To clarify, SOURCE_DATE_EPOCH is a unix timestamp which is defined as the number of seconds (excluding leap seconds) since Jan 1 1970 UTC. There is no way to specify this in another timezone; there is no ambiguity here. However, I am not sure that us at Reproducible Builds will actually adopt this variable. We haven't talked about it beyond my previous email [1], it was just me quickly skimming off my thoughts and firing off quick ideas. My personal concern about SOURCE_DATE_TZ is that it implies that it could take actual named time zones, like EST or Europe/London; it is **extremely unlikely** that we will do anything like this soon, because this would involve timezone databases and complex things like that. This is why in my previous email I suggested the SOURCE_DATE_TZOFFSET variable. Also, the TZ variable as specified by POSIX specifies the offset in the *opposite* direction to what ISO8601 and RFC2822 displays. The git internal timestamp format only supports timezone offsets in the common direction, opposite to TZ, i.e. positive for east of Greenwich and negative for west. I'd suggest to leave out SOURCE_DATE_TZ for now, until we come up with a more precisely defined *meaning* for this variable. It is meant to be a standard across all tools, so some time to think through the issues is necessary. Otherwise we risk leaving a clusterfuck of a legacy, like the POSIX time functions. X [1] https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150727/002562.html or http://lists.denx.de/pipermail/u-boot/2015-July/221301.html -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [PATCH] Makefile: Use correct timezone for U_BOOT_TZ
On Fri, Jul 31, 2015 at 6:04 PM, Chris Packham judge.pack...@gmail.com wrote:
When building with SOURCE_DATE_EPOCH the timezone is in UTC. When
building normally the timezone is taken from the build machine's locale
setting.
Fixes: f3f431a71272 (Reproducible U-Boot build support, using
SOURCE_DATE_EPOCH)
Signed-off-by: Chris Packham judge.pack...@gmail.com
---
Hopefully this will suit everyone. I've done a quick sanity test with
sandbox and the date shown in the version output looks to be what I
expect with/without SOURCE_DATE_EPOCH.
Makefile | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 394ed09..f75c730 100644
--- a/Makefile
+++ b/Makefile
@@ -1230,10 +1230,16 @@ define filechk_version.h
endef
define filechk_timestamp.h
- (SOURCE_DATE=$${SOURCE_DATE_EPOCH:+@$$SOURCE_DATE_EPOCH}; \
- LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_DATE %b
%d %C%y'; \
- LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_TIME
%T'; \
- LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_TZ %z' )
+ (if test -n $${SOURCE_DATE_EPOCH}; then \
+ SOURCE_DATE=@$${SOURCE_DATE_EPOCH}; \
+ LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_DATE
%b %d %C%y'; \
+ LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_TIME
%T'; \
+ LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_TZ
%z'; \
+ else \
+ LC_ALL=C date +'#define U_BOOT_DATE %b %d %C%y'; \
+ LC_ALL=C date +'#define U_BOOT_TIME %T'; \
+ LC_ALL=C date +'#define U_BOOT_TZ %z'; \
+ fi)
endef
$(version_h): include/config/uboot.release FORCE
--
Tested-by: Bin Meng bmeng...@gmail.com
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [PATCH] Makefile: Use correct timezone for U_BOOT_TZ
(note I had some patman config that erroneously included extra people
on the original Cc list, I've now dropped them)
On Sat, Aug 1, 2015 at 5:05 AM, Paul Kocialkowski cont...@paulk.fr wrote:
Le vendredi 31 juillet 2015 à 22:04 +1200, Chris Packham a écrit :
When building with SOURCE_DATE_EPOCH the timezone is in UTC. When
building normally the timezone is taken from the build machine's locale
setting.
Thanks a lot for introducing this, I thought it might disturb a few
people.
Fixes: f3f431a71272 (Reproducible U-Boot build support, using
SOURCE_DATE_EPOCH)
It is incorrect to say that your patch fixes my commit, because my
commit didn't introduce anything unexpected or faulty.
If anything, it was merged before people gave their opinion about
whether UTC should be default. I was also going to introduce a patch
like yours later. For the record, UTC is default for Coreboot's
timestamps.
Thus, please remove that line.
Done. v2 on it's way.
The other mailing list thread also talked about the possibility of
having SOURCE_DATE_TZOFFSET I'll look at a proof of concept for that.
Otherwise, this is:
Tested-By: Paul Kocialkowski cont...@paulk.fr
Signed-off-by: Chris Packham judge.pack...@gmail.com
---
Hopefully this will suit everyone. I've done a quick sanity test with
sandbox and the date shown in the version output looks to be what I
expect with/without SOURCE_DATE_EPOCH.
Makefile | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 394ed09..f75c730 100644
--- a/Makefile
+++ b/Makefile
@@ -1230,10 +1230,16 @@ define filechk_version.h
endef
define filechk_timestamp.h
- (SOURCE_DATE=$${SOURCE_DATE_EPOCH:+@$$SOURCE_DATE_EPOCH}; \
- LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_DATE %b
%d %C%y'; \
- LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_TIME
%T'; \
- LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_TZ %z' )
+ (if test -n $${SOURCE_DATE_EPOCH}; then \
+ SOURCE_DATE=@$${SOURCE_DATE_EPOCH}; \
+ LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_DATE
%b %d %C%y'; \
+ LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_TIME
%T'; \
+ LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_TZ
%z'; \
+ else \
+ LC_ALL=C date +'#define U_BOOT_DATE %b %d %C%y'; \
+ LC_ALL=C date +'#define U_BOOT_TIME %T'; \
+ LC_ALL=C date +'#define U_BOOT_TZ %z'; \
+ fi)
endef
$(version_h): include/config/uboot.release FORCE
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] [PATCH] Makefile: Use correct timezone for U_BOOT_TZ
When building with SOURCE_DATE_EPOCH the timezone is in UTC. When
building normally the timezone is taken from the build machine's locale
setting.
Fixes: f3f431a71272 (Reproducible U-Boot build support, using
SOURCE_DATE_EPOCH)
Signed-off-by: Chris Packham judge.pack...@gmail.com
---
Hopefully this will suit everyone. I've done a quick sanity test with
sandbox and the date shown in the version output looks to be what I
expect with/without SOURCE_DATE_EPOCH.
Makefile | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 394ed09..f75c730 100644
--- a/Makefile
+++ b/Makefile
@@ -1230,10 +1230,16 @@ define filechk_version.h
endef
define filechk_timestamp.h
- (SOURCE_DATE=$${SOURCE_DATE_EPOCH:+@$$SOURCE_DATE_EPOCH}; \
- LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_DATE %b %d
%C%y'; \
- LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_TIME %T';
\
- LC_ALL=C date -u -d $${SOURCE_DATE:-now} +'#define U_BOOT_TZ %z' )
+ (if test -n $${SOURCE_DATE_EPOCH}; then \
+ SOURCE_DATE=@$${SOURCE_DATE_EPOCH}; \
+ LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_DATE %b
%d %C%y'; \
+ LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_TIME
%T'; \
+ LC_ALL=C date -u -d $${SOURCE_DATE} +'#define U_BOOT_TZ
%z'; \
+ else \
+ LC_ALL=C date +'#define U_BOOT_DATE %b %d %C%y'; \
+ LC_ALL=C date +'#define U_BOOT_TIME %T'; \
+ LC_ALL=C date +'#define U_BOOT_TZ %z'; \
+ fi)
endef
$(version_h): include/config/uboot.release FORCE
--
2.5.0.rc0
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] [RFC PATCH] Makefile: Add SOURCE_DATE_TZ
On 02/08/15 00:02, Ximin Luo wrote: However, I am not sure that us at Reproducible Builds will actually adopt this variable. We haven't talked about it beyond my previous email [1], it was just me quickly skimming off my thoughts and firing off quick ideas. Whoops, I mean the _TZ variable. The _EPOCH variable has been decided and we're trying to get tools to support this. -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Reproducibility vs signatures
Hi, On Montag, 3. August 2015, Ben Hutchings wrote: That sort of works as long as there's only one architecture we want to do this for. But the ability to verify modules is useful in general so I would like to turn that on for all architectures. how is this going to work for builds on buildds anyway? I suppose you are not planning to build+sign all arch manually? And who can sign those kernels anyway? I suppose anybody should stil be able to build+sign+boot kernels, or? cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] debbindiff_26~bpo8+1_amd64.changes ACCEPTED into jessie-backports, jessie-backports
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 28 Jul 2015 11:36:25 +0200 Source: debbindiff Binary: debbindiff Architecture: source all Version: 26~bpo8+1 Distribution: jessie-backports Urgency: medium Maintainer: Reproducible builds folks reproducible-builds@lists.alioth.debian.org Changed-By: Holger Levsen hol...@debian.org Description: debbindiff - highlight differences between two builds of Debian packages Closes: 763328 764131 764140 764254 764420 764470 772029 773573 774983 778423 778537 778641 779391 779474 779475 779476 780863 781280 781373 781374 782253 782551 783792 784891 785288 793460 Changes: debbindiff (26~bpo8+1) jessie-backports; urgency=medium . * Rebuild for jessie-backports. (Closes: #793460) * Add myself to uploaders. . debbindiff (26) unstable; urgency=low . * Declare the package autopkgtestable. * Fix comparator for unknown files. * Add tests for unknown files comparator. . debbindiff (25) unstable; urgency=low . * Comparators now have a test suite with 93% code coverage. * Support autopkgtest to run the test suite. * Properly strip path from javap output even when they are relative. * Also remove 'Last modified' and 'MD5 checksum' lines from javap output. * Factorize readelf commands. * Filter archive name from readelf output. * Filter archive name from objdump output. * Fix charset handling of .mo files. * Don't be quadratic when parsing .mo header. * Skip archive name in zipinfo output. * Fix destination path when decompressing gzip files not ending in .gz. * Filter image name from squashfs superblock information. * Fix comparison of files in cpio archives. * Change how we handle a missing RPM module. * Don't add empty Difference when comparing files with equal metadata in directories. * Filter access time from stat output. * Rename .changes comparator. * Rework .changes comparator. * Comparators now return a single Difference instead of a list of Difference. . debbindiff (24) unstable; urgency=medium . * Fix for undefined variables introduced in last release. . debbindiff (23) unstable; urgency=medium . [ Helmut Grohne ] * Speed up diff collection. * Read lines in larger chunks. . [ Reiner Herrmann ] * Don't follow symlinks, but print their targets. . debbindiff (22) unstable; urgency=low . * Add myself to uploaders * Swap JDK dependencies, so openjdk is preferred (thanks mapreri) . debbindiff (21) unstable; urgency=low . * Non-maintainer upload. * Add support for Java .class files. * Add support for .ipk package files. . debbindiff (20) unstable; urgency=low . [ Reiner Herrmann ] * info files can contain numbers in the extension . [ Jérémy Bobbio ] * Fix diff parser when skipping until the end of a file without a newline. * Use same encoding as stdin when output is not a TTY. (Closes: #785288) . debbindiff (19) unstable; urgency=low . [ Reiner Herrmann ] * Fix info files comparator by specifying the correct parameter name for the text comparator. (Closes: #784891) . debbindiff (18) unstable; urgency=low . [ Reiner Herrmann ] * Use zip comparator for pk3 files. * Use text comparator for info files. * Drop mime type for info files. * Remove limit of diff output again. . [ Jérémy Bobbio ] * Assume tar member names are UTF-8 encoded. This allows debbindiff to process drmips. * Write a text report on stdout as default behavior. * Allow both --html and --text to produce output in one run. . debbindiff (17) unstable; urgency=low . [ Jérémy Bobbio ] * Add support for ISO9660 images. * Catch a few more initrds as such. * Reimplement are_same_binaries() using cmp. . [ Reiner Herrmann ] * Use gzip comparator for .dz (dictzip) files. * Added isoinfo to list of tool providers. . [ Yasushi SHOJI ] * Disable 'Device' section diff in stat output. (Closes: #783792) . debbindiff (16) unstable; urgency=low . [ Reiner Herrmann ] * Remove temporary directory when exception is raised. (Closes: #782253) * Fix extraction when Zip member contain ../ in their path. . [ Jérémy Bobbio ] * Fail with a better error message when unable to create a Queue. (Closes: #782551) . debbindiff (15) unstable; urgency=low . * Terminate xxd if its output was too long. * Handle broken zip files by falling back on binary comparison. * Fix an over-matching jar/war filename regexp. * Fix .hi comparator. * Fix some file descriptor leaks. . debbindiff (14) unstable; urgency=low . * Remove diffutils from Recommends as it is Essential:yes. * Fallback to Python hexlify if xxd is not available. * Decode msgunfmt output using the actual PO charset. * Stop buffering output of most external commands and send it to diff as it comes. (Closes: #781373) * Stop feeding input to diff after a certain amount
Re: [Reproducible-builds] Reproducibility vs signatures
On Mon, 2015-08-03 at 12:27 +0200, Holger Levsen wrote: Hi, On Montag, 3. August 2015, Ben Hutchings wrote: That sort of works as long as there's only one architecture we want to do this for. But the ability to verify modules is useful in general so I would like to turn that on for all architectures. how is this going to work for builds on buildds anyway? I suppose you are not planning to build+sign all arch manually? And who can sign those kernels anyway? I suppose anybody should stil be able to build+sign+boot kernels, or? See https://lists.debian.org/debian-kernel/2013/08/msg00267.html. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Reproducibility vs signatures
Ben Hutchings: At some point we're hopefully going to support Secure Boot on amd64. That means there will be a signed kernel image (separate from the current linux-image packages) and a signed GRUB image. The kernel modules in the linux-image packages will also be signed, probably with an ephemeral key. All these signatures will all be embedded within binaries and will of course not be reproducible. The locations of differences will however be predictable. How should we deal with this limited variability? Could source packages or buildinfo describe the expected variations somehow? One way to solve this, although a bit wasteful on resource, is to use the clean rule to perform a first build and create a signature to be added to the source package. See my suggest patch for wireless-regdb which implements this idea: https://bugs.debian.org/725803#29 Would that be a good fit for Linux or GRUB? -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] ARM build machines
On 2015-08-03, Holger Levsen wrote: On Samstag, 1. August 2015, Vagrant Cascadian wrote: wbq0-armhf-rb.debian.net: $ host wbq0-armhf-rb.debian.net Host wbq0-armhf-rb.debian.net not found: 3(NXDOMAIN) Oops. Accidentally dropped it on one of the debian.net updates. Re-added just now, got the ack that it was added, now just need to wait for DNS propagation... (as you may notice, they're all CNAMEs with a consistant pattern, so you could try accessing them directly in a pinch...) live well, vagrant signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] GSoC 2015 Week 10: Move forward reproducible builds
Hello, This week I have been working on the following problems: 1- Packages which are marked as affected by timestamps_in_manpages_generated_by_doxygen [1]: Patches were submitted for the following packages: - Package: libsyncml https://bugs.debian.org/794225 - Package: zipios++ https://bugs.debian.org/794239 30 out of the 35 unreproducible packages that suffer from timestamps_in_manpages_generated_by_doxygen belong to the same maintainer who has been contacted before proceeding to open bugs against those packages: http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150727/002513.html 2- I added the issue different_encoding [2] for the following package: - Package: confused 3- I also submitted a patch for cdbs. The patch exports the environment variable SOURCE_DATE_EPOCH which was proposed by the Debian reproducible builds team as a way to have deterministic timestamps [3]. Package: cdbs https://bugs.debian.org/794241 I have updated the section in the experimental toolchain about cdbs [4] and uploaded a version of cdbs with this patch to the reproducible builds git repository. 4- squashfs-tools was patched to have an additional option which allows to print user and group id instead of mapping them to the user and group name on the current system (like: ls -n) - Package: squashfs-tools https://bugs.debian.org/794096 Kind Regards, akira [1] https://reproducible.debian.net/issues/unstable/timestamps_in_manpages_generated_by_doxygen_issue.html [2] https://reproducible.debian.net/issues/unstable/different_encoding_issue.html [3] https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal [4] https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain#cdbs signature.asc Description: OpenPGP digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] ARM build machines
Hi Vagrant, On Samstag, 1. August 2015, Vagrant Cascadian wrote: wbq0-armhf-rb.debian.net: $ host wbq0-armhf-rb.debian.net Host wbq0-armhf-rb.debian.net not found: 3(NXDOMAIN) The others resolve just fine. cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Processing of diffoscope_29_amd64.changes
diffoscope_29_amd64.changes uploaded successfully to localhost along with the files: diffoscope_29.dsc diffoscope_29.tar.gz debbindiff_29_all.deb diffoscope_29_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Processing of diffoscope_29_amd64.changes
/diffoscope_29_amd64.changes is already present on target host: diffoscope_29_all.deb Either you already uploaded it, or someone else came first. Job diffoscope_29_amd64.changes removed. Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
