Re: Making schleuder build reproducibly

2017-11-09 Thread Daniel Kahn Gillmor
On Tue 2017-11-07 17:02:02 +0100, Georg Faerber wrote: > On 17-11-04 16:01:43, Holger Levsen wrote: >> On Mon, Oct 30, 2017 at 06:21:39PM +0100, Georg Faerber wrote: >> > @dkg: It seems, there is still a bug / race in dirmngr, which leads to >> > errors like "can't connect to '127.0.0.1': no IP ad

Re: Question about strip-nondeterminism in bsh

2017-10-12 Thread Daniel Kahn Gillmor
On Thu 2017-10-12 03:02:49 +0100, Chris Lamb wrote: > The GitHub repositories are read-only mirrors. If you are checking out > the code as a member of the Reproducible Builds team, then it makes more > sense to get it from Alioth, for example: > > $ git clone git.debian.org:/git/reproducible/str

Bug#877418: dh-strip-nondeterminism: kills clojure performance

2017-10-06 Thread Daniel Kahn Gillmor
On Fri 2017-10-06 10:00:27 +0100, Chris Lamb wrote: > If it were hardcoded into the filenames, one wouldn't need to do > anything onerous, eg. > > -rw-r--r-- 1 0 Oct 6 09:56 > helloworld.adc83b19e793491b1c6ea0fd8b46cd9f32e592fc.class > -rw-r--r-- 1 0 Oct 6 09:56 > helloworld.adc83b19e793491

Bug#877418: dh-strip-nondeterminism: kills clojure performance

2017-10-05 Thread Daniel Kahn Gillmor
On Thu 2017-10-05 10:56:46 +0100, Chris Lamb wrote: > I'd also be curious to know why you think *more* than one second could > ever be needed here. I think I'm mising something. some filesystems have a resolution > 1s :( http://www.ntfs.com/exfat-comparison.htm shows that FAT32 has a 2s granul

Bug#877418: dh-strip-nondeterminism: kills clojure performance

2017-10-05 Thread Daniel Kahn Gillmor
On Wed 2017-10-04 19:45:49 +0100, Chris Lamb wrote: > *Very* quick thoughts here: could some variant of a) be merged > upstream…? Perhaps upstream could move to a hash-based system instead > of using timestamps? eg. encoding the SHA1 of the file in the filename. I'm thinking about this problem mor

Re: Bug#873937: dpkg: should include information about the used kernel in .buildinfo files

2017-09-06 Thread Daniel Kahn Gillmor
Over on 873...@bugs.debian.org, Holger Levsen wrote: > on reflection I agree that the privacy implications are too bad. > > On Fri, Sep 01, 2017 at 04:51:55PM +0200, Guillem Jover wrote: > [more insightful stuff I cannot disagree with removed.] > >> Given all the above, I'm inclined to just close

Re: [rb-general] GCC build-path patch getting blocked

2017-08-16 Thread Daniel Kahn Gillmor
On Wed 2017-08-16 15:40:00 +, Ximin Luo wrote: > This idea is similar to hardening-wrapper. That is now deprecated, but > was useful as a stepping-stone to more "proper" fixes. Likewise, this > shouldn't be thought of as "the proper fix", but will give us some > useful data on how many packages

Re: Reproducibility in Policy

2017-08-11 Thread Daniel Kahn Gillmor
Thanks for the proposal. I like it! A few nit-picks below: On Fri 2017-08-11 16:08:47 -0700, Sean Whitton wrote: > - a version of a source package unpacked at a given path; I don't like the idea of hard-coding a fixed build path requirement into debian policy. We're over 80% with variable

Bug#871244: diffoscope: support keybox files with kbxutil

2017-08-07 Thread Daniel Kahn Gillmor
On Mon 2017-08-07 13:33:00 +0200, Mattia Rizzolo wrote: > As you know we/I regularly backport diffoscope to Debian stable, so we > care about having those tools available there as well. > So, do you plan on making gnupg-utils available in stretch-backports > (with all the ongoing maintenance that s

Bug#871244: diffoscope: support keybox files with kbxutil

2017-08-06 Thread Daniel Kahn Gillmor
Package: diffoscope Version: 84 Severity: wishlist keybox files are a file format specific to the GnuPG project. The gnupg-utils package (currently only in experimental, but hopefully soon to be moved to unstable) ships kbxutil, which should provide sufficient textual diffs to get a better hint a

Re: source-only builds and .buildinfo

2017-06-21 Thread Daniel Kahn Gillmor
On Wed 2017-06-21 15:42:07 +0100, Ian Jackson wrote: > This is a very useful concept but I suggest you give it a new name. > "binaries-attested upload" perhaps ? I like the idea that we should name this thing, but i'd call it something like a "source-only upload with .buildinfo" or "source+buildin

Re: source-only builds and .buildinfo

2017-06-21 Thread Daniel Kahn Gillmor
On Wed 2017-06-21 13:38:42 +0100, Ian Jackson wrote: > This is an interesting use case which dgit should support. cool! > But I think this is not what dgit push-source should do. Sean's > proposed dgit push-source does not do any kind of binary package > build. I think this is correct. But thi

Re: source-only builds and .buildinfo

2017-06-21 Thread Daniel Kahn Gillmor
On Wed 2017-06-21 14:16:00 +0300, Adrian Bunk wrote: > On Wed, Jun 21, 2017 at 09:30:14AM +, Holger Levsen wrote: >> Hi, >> >> trigger warning: nitpicking. >> >> On Wed, Jun 21, 2017 at 11:34:17AM +0300, Adrian Bunk wrote: >> > > I do source-only uploads because i don't want the binaries buil

Re: source-only builds and .buildinfo

2017-06-20 Thread Daniel Kahn Gillmor
Hi Ian-- On Tue 2017-06-20 18:10:49 +0100, Ian Jackson wrote: > A .buildinfo file is not useful for a source-only upload which is > veried to be identical to the intended source as present in the > uploader's version control (eg, by the use of dgit). > > Therefore, dgit should not include .buildin

Re: Making schleuder build reproducibly

2017-06-15 Thread Daniel Kahn Gillmor
Hi Georg-- On Thu 2017-06-15 21:19:12 +0200, Georg Faerber wrote: > I really would like to make the build of schleuder, a gpg enabled > mailing list, reproducible. However, I'm a bit lost on my own, that's > why I'm searching for input with this mail: > > Some of the upstream provided tests check

Bug#858867: diffoscope: please support pcap files

2017-03-28 Thread Daniel Kahn Gillmor
On Tue 2017-03-28 03:39:18 -0500, Chris Lamb wrote: > tags 858867 + pending > thanks > > Implemented in Git: > > > https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=c5d01341055d0aa0552d08725a6b8e44255b0374 woo, thanks! in my testing before i saw this, i ended up using diff

Bug#858867: diffoscope: please support pcap files

2017-03-27 Thread Daniel Kahn Gillmor
Package: diffoscope Version: 78 Severity: wishlist i want to be able to do "diffoscope capture-1.pcap capture-2.cap" and get something meaningful. --dkg -- System Information: Debian Release: 9.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unst

Re: Moving towards a deb-buildinfo(5) Format 1.0

2017-02-20 Thread Daniel Kahn Gillmor
On Sun 2017-02-19 16:34:45 -0500, Guillem Jover wrote: > On Sun, 2017-02-19 at 11:39:28 -0800, Vagrant Cascadian wrote: >> On 2017-02-19, Guillem Jover wrote: >> >> * .buildinfo files are not generated when creating source-only uploads >> > >> > Fixed. Now always generated. >> >> On a related note

Re: Buildinfo in the Debian archive, updates

2016-12-07 Thread Daniel Kahn Gillmor
On Wed 2016-12-07 06:31:00 -0500, Ximin Luo wrote: > Separately regarding the ECC point, I don't think we can assume that > at this time because DDs still have non-ECC signatures, and are still > doing binary uploads with buildinfo files that we want to store. sure, but that's just one buildinfo f

Re: Buildinfo in the Debian archive, updates

2016-12-06 Thread Daniel Kahn Gillmor
On Tue 2016-12-06 17:41:34 -0500, Jonathan McDowell wrote: > The storage of the hashes of the signed buildinfo files in Packages.gz > seems to be in order to deal with the fact that the signature is not > available elsewhere. If dkg's suggestion of using ECC signatures is > followed then some quick

Re: Buildinfo in the Debian archive, updates

2016-11-18 Thread Daniel Kahn Gillmor
Hi all-- On Mon 2016-11-14 12:13:00 -0500, Ximin Luo wrote: > A GPG signature with a 4096-bit key is about 800 bytes in base 64: > > http://ftp.debian.org/debian/dists/sid/ (has 2 signatures, if you use `gpg > --list-packets`) > http://ppa.launchpad.net/infinity0/rust-nightly/ubuntu/dists/yakkety

Re: Moving towards a deb-buildinfo(5) Format 1.0

2016-11-13 Thread Daniel Kahn Gillmor
On Sun 2016-11-13 22:33:29 +0900, Chris Lamb wrote: >> Multiple builds of the same source package will set SOURCE_DATE_EPOCH to >> the same value but will result in a different Build-Date. > > … but that would mean that a reproducible build will result in .buildinfo > files with different contents

Re: [PATCH] reproducible Debian: filter Environment section from buildinfo files

2016-11-07 Thread Daniel Kahn Gillmor
On Mon 2016-11-07 09:14:00 -0500, HW42 wrote: > 1) Currently the diff contains only stuff which should be fixed. If we >include .buildinfo differences it will include stuff which should not >be "fixed" (and can't be by the package maintainer). What if we only included the .buildinfo differ

Re: [PATCH] submit signed .buildinfo files to buildinfo.debian.net

2016-11-01 Thread Daniel Kahn Gillmor
On Tue 2016-11-01 11:49:42 -0400, Daniel Shahaf wrote: > Mattia Rizzolo wrote on Tue, Nov 01, 2016 at 11:18:37 +: >> On Tue, Nov 01, 2016 at 11:12:44AM +, Chris Lamb wrote: >> > Feel free to change to -f >> >> Holger changed that to ${HOSTNAME}, a variable that I've never >> understood whe

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-11-01 Thread Daniel Kahn Gillmor
On Tue 2016-11-01 11:56:00 -0400, Ximin Luo wrote: > But the TIMESTAMP patch is for __TIMESTAMP__ whereas our > currently-existing Debian patches are only for __DATE__ and __TIME__. ah, right. sorry i totally missed that, and of course it makes sense. Perhaps you could call that out explicitly in

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-11-01 Thread Daniel Kahn Gillmor
Hi Ximin-- On Tue 2016-11-01 09:52:00 -0400, Ximin Luo wrote: > Updated patches here: > > https://gist.github.com/infinity0/72aba22411a2e8baaae4649329f96643 > > Everyone please feel free to comment / review before I soon send them off to > GCC. This looks great, thank you! I have not tried runn

Re: [PATCH] submit signed .buildinfo files to buildinfo.debian.net

2016-10-31 Thread Daniel Kahn Gillmor
On Mon 2016-10-31 20:46:14 -0400, Holger Levsen wrote: > On Mon, Oct 31, 2016 at 08:42:28PM -0400, Daniel Kahn Gillmor wrote: >> This is not a glitch at all, these are instructions that will make it >> work well with gpg 2.1.x, and are harmless in 1.4.x. Please keep it >> int

Re: [PATCH] submit signed .buildinfo files to buildinfo.debian.net

2016-10-31 Thread Daniel Kahn Gillmor
On Mon 2016-10-31 19:52:13 -0400, Holger Levsen wrote: > still, there is this glitch: > > gpg: skipping control `%no-ask-passphrase' () > gpg: skipping control `%no-protection' () > > Is that harmless? This is not a glitch at all, these are instructions that will make it work well with gpg 2.1.x,

Re: [PATCH] submit signed .buildinfo files to buildinfo.debian.net

2016-10-31 Thread Daniel Kahn Gillmor
On Mon 2016-10-31 19:00:18 -0400, Chris Lamb wrote: > Daniel Kahn Gillmor wrote: > >> > we might use gpg signing for other purposes, so I removed that >> > constraint… fwiw, i didn't say this ↑↑ but it looks like you're attributing it to me :/ >> "

Re: [PATCH] submit signed .buildinfo files to buildinfo.debian.net

2016-10-31 Thread Daniel Kahn Gillmor
On Mon 2016-10-31 17:43:16 -0400, Holger Levsen wrote: > On Sat, Oct 29, 2016 at 11:28:46AM +0100, Chris Lamb wrote: >> Updated sign-buildinfo-submissions-with-gpg-key. I didn't squash & >> force push so that dkg's contribution is correctly attributed. :) > > cool! > >> (I *think* I'm understanding

Re: [PATCH] Make use of gpg more flexible

2016-10-29 Thread Daniel Kahn Gillmor
On Fri 2016-10-28 17:17:10 -0400, Holger Levsen wrote: > thanks for chiming in…! > > On Fri, Oct 28, 2016 at 01:51:30PM -0400, Daniel Kahn Gillmor wrote: >> This set of commands should work with modern versions of gpg (2.1.x) >> as well, and should be independent of potent

[PATCH] Make use of gpg more flexible

2016-10-28 Thread Daniel Kahn Gillmor
This set of commands should work with modern versions of gpg (2.1.x) as well, and should be independent of potentially variable output. Additionally, we want the key to be signing-capable, but nothing else. We also have no need to generate an encryption-capable subkey, so just drop that part. ---

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-10-27 Thread Daniel Kahn Gillmor
On Thu 2016-10-27 11:18:00 -0400, Ximin Luo wrote: > So, I can implement option B fairly easily, but there is one ugly fact > about the syntax that we should think about. The way that GCC does it, > it means you can't strip a prefix that itself contains the "=" > character. > > Now this is not goin

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-10-25 Thread Daniel Kahn Gillmor
On Tue 2016-10-25 08:29:00 -0400, Ximin Luo wrote: > Option A > > oldprefix = getenv("SOURCE_ROOT_DIR") > newprefix = getenv("SOURCE_ROOT_PREFIX") or "." > > Pros: Simple, easy to understand. Works almost exactly as debug-prefix-map > which has already existed for ages in GCC. > Cons: Uses two en

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-10-24 Thread Daniel Kahn Gillmor
On Mon 2016-10-24 16:18:00 -0400, Ximin Luo wrote: > Almost, with two minor corrections: > > I picked SOURCE_ROOT_DIR; SOURCE_ROOT has 6395 pages of results in > sources.debian.net and I didn't want to check that none of these are > environment variables. fair enough. > SOURCE_ROOT_PREFIX would o

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-10-24 Thread Daniel Kahn Gillmor
On Mon 2016-10-24 15:33:00 -0400, Ximin Luo wrote: > HW42: >> Btw: Do you know why currently debug-prefix-map maps the source dir to >> '.'? (My guess is because that's the easiest in dpkg-buildflags) I think >> for debugging between package boundaries '${srcpkg}-${srcver}' would be >> much better.

Re: [rb-general] Scheduling a regular time for IRC meetings (#2)

2016-10-18 Thread Daniel Kahn Gillmor
On Tue 2016-10-18 07:47:00 -0400, Chris Lamb wrote: > The consensus was that we want to try polling again including more range of > times. I will close this poll in one week from today and then send out a mail > scheduling the first one. Just to clarify: these times represent times for a regular

Re: opi2a back! init system variations?

2016-10-07 Thread Daniel Kahn Gillmor
On Wed 2016-10-05 23:42:17 -0400, Vagrant Cascadian wrote: > The whole ordeal did trigger a thought about adding init system > variations to the builds... at least could do systemd and sysvinit at > the moment without a *huge* amount of trouble, unless we're relying on > some init-specific features

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-09-09 Thread Daniel Kahn Gillmor
On Fri 2016-09-09 01:33:00 +0200, HW42 wrote: > According to codesearch.d.n it seems only SOURCE_DIR_ROOT isn't taken > yet. (Google finds at least one case). thanks for looking, that's what i should have done in the first place. > also bikeshedding: I dislike SOURCE_DIR_ROOT because the name is

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-09-07 Thread Daniel Kahn Gillmor
On Tue 2016-09-06 16:02:00 -0400, Ximin Luo wrote: > Thanks, I did see this a while ago and forgot about it. However it > does differ from the current proposal in an important way. > > Current proposal (2): GCC should, if SOURCE_ROOT is set and > debug-prefix-map is not given, *automatically* use t

Re: [Reproducible-builds] Minimising work needed for this build-path issue

2016-09-06 Thread Daniel Kahn Gillmor
On Wed 2016-08-24 07:20:00 -0400, Ximin Luo wrote: > 2. Define another variable SOURCE_ROOT to be set to the top-level > source dir, and patch GCC to use this as the default value for > debug-prefix-map (and the analogue for other languages / tools). > > This would have the same concrete behaviour

Re: Bug#835465: [Reproducible-builds] Bug#835465: python-apt: FTBFS: AptKeyError: recv from 'hkp://localhost:19191' failed for '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'

2016-08-30 Thread Daniel Kahn Gillmor
On Tue 2016-08-30 10:31:50 -0400, Julian Andres Klode wrote: > On Tue, Aug 30, 2016 at 10:18:33AM -0400, Daniel Kahn Gillmor wrote: >> Can you point me to a report about that? I'm not seeing it in my scan >> of the bts at https://bugs.debian.org/src:software-properties >

Re: Bug#835465: [Reproducible-builds] Bug#835465: python-apt: FTBFS: AptKeyError: recv from 'hkp://localhost:19191' failed for '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'

2016-08-30 Thread Daniel Kahn Gillmor
On Tue 2016-08-30 09:47:34 -0400, Julian Andres Klode wrote: > On Tue, Aug 30, 2016 at 09:32:15AM -0400, Daniel Kahn Gillmor wrote: >> On Tue 2016-08-30 08:49:20 -0400, Julian Andres Klode wrote: >> >> apt/auth.py appears to want to force gnupg to store its secret key >>

Re: Bug#835465: [Reproducible-builds] Bug#835465: python-apt: FTBFS: AptKeyError: recv from 'hkp://localhost:19191' failed for '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'

2016-08-30 Thread Daniel Kahn Gillmor
On Tue 2016-08-30 08:49:20 -0400, Julian Andres Klode wrote: >> apt/auth.py appears to want to force gnupg to store its secret key >> material in secring.gpg. This isn't a best practice, and modern >> versions of gpg do not do so by default. I'd recommend dropping >> tmp_secret_keyring entirely.

Re: [Reproducible-builds] Bug#835075: libmail-gnupg-perl: FTBFS: Failed 1/10 test programs. 0/4 subtests failed.

2016-08-30 Thread Daniel Kahn Gillmor
Control: affects 835075 src:gnupg2 On Mon 2016-08-22 03:20:05 -0400, Chris Lamb wrote: > Source: libmail-gnupg-perl > Version: 0.22-1 > Severity: serious > Justification: fails to build from source > User: reproducible-builds@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-b

Re: Bug#835592: php-crypt-gpg: FTBFS: Tests: 286, Assertions: 514, Errors: 77, Failures: 8, Skipped: 8

2016-08-30 Thread Daniel Kahn Gillmor
On Tue 2016-08-30 06:49:30 -0400, Axel Beckert wrote: > Daniel Kahn Gillmor wrote: >> However, if your next upload of php-crypt-gpg can't be built or run >> against modern versions of GnuPG, then you probably need to state this >> package's dependency on gnupg a

Re: [Reproducible-builds] Bug#835465: python-apt: FTBFS: AptKeyError: recv from 'hkp://localhost:19191' failed for '0xa1bD8E9D78F7FE5C3E65D8AF8B48AD6246925553'

2016-08-30 Thread Daniel Kahn Gillmor
Control: affects 835465 + gnupg2 Hi python-apt folks-- On Thu 2016-08-25 20:55:27 -0400, Chris Lamb wrote: > Source: python-apt > Version: 1.1.0~beta4 > Severity: serious > Justification: fails to build from source > User: reproducible-builds@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-

Re: Bug#835592: php-crypt-gpg: FTBFS: Tests: 286, Assertions: 514, Errors: 77, Failures: 8, Skipped: 8

2016-08-30 Thread Daniel Kahn Gillmor
Control: affects 835592 src:gnupg2 Hi php maintainers-- over on https://bugs.debian.org/835592 , Chris Lamb wrote: > Source: php-crypt-gpg > Version: 1.4.1-1 > Severity: serious > Justification: fails to build from source > User: reproducible-builds@lists.alioth.debian.org > Usertags: ftbfs > X-D

Re: [Reproducible-builds] Reproducible patches for libisoburn and libisofs

2016-08-12 Thread Daniel Kahn Gillmor
On Fri 2016-08-12 15:27:40 -0400, Thomas Schmitt wrote: > Although grub-mkrescue probably can live with poor GPT GUIDs, i meanwhile > found a use case in xorriso where user defined modification-date does not > express the desire for reproducibile GUIDs: xorriso command > -boot_image "any" "replay".

[Reproducible-builds] Bug#833282: reprotest: please add a manpage for reprotest

2016-08-02 Thread Daniel Kahn Gillmor
Package: reprotest Version: 0.2 Severity: normal Thanks for writing reprotest! it would be great to have a manual page for the executable, since that's where many users look for documentation. it would also clear up this lintian warning: W: reprotest: binary-without-manpage usr/bin/reprotest

[Reproducible-builds] Bug#833284: reprotest: please add a "buildpath" variation to reprotest

2016-08-02 Thread Daniel Kahn Gillmor
Package: reprotest Version: 0.2 Severity: normal The list of variations supported by reprotest doesn't appear to include changing the build path. We should be able to generate identical output regardless of where in the filesystem the build takes place, so supporting this variation would be a use

Re: [Reproducible-builds] Bug#827155: dpkg-buildflags: reproducible/fixdebugpath doesn't escape build path

2016-06-30 Thread Daniel Kahn Gillmor
On Sun 2016-06-12 23:25:33 -0400, HW42 wrote: > as Mattia noticed dpkg-buildflags doesn't escape the build path in the > -fdebug-prefix-map CC argument when enabling the 'fixdebugpath' option. > > What assumptions does dpkg make about the build path? I think there are a > lot of build scripts which

Re: [Reproducible-builds] Bug#828178: afl: FTBFS: clang error unknown argument -fdebug-prefix-map=/build/afl-2.16b=.'

2016-06-27 Thread Daniel Kahn Gillmor
Hi Daniel-- On Sat 2016-06-25 16:09:08 -0400, Daniel Stender wrote: > AFL fails to build from source in reproducible builds test build > environments like this (log from 2.16b-1 build): > > > lang-3.7 -g -O2 -fdebug-prefix-map=/build/afl-2.16b=. -fPIE > -fstack-protector-strong -Wformat -Werror=

Re: [Reproducible-builds] [Groff] Reproducible dates in HTML/PDF/PS output files?

2016-06-13 Thread Daniel Kahn Gillmor
On Mon 2016-06-13 09:20:46 -0400, Ximin Luo wrote: > Ximin Luo: >> Hi all, was this ever committed? I don't see it in the commit archives... >> > > Hey, any news on this? The original thread I'm referring to is this one: > > https://lists.gnu.org/archive/html/groff/2015-11/msg00013.html Werner LE

Re: [Reproducible-builds] Bug#819194: dpkg-buildflags: please add normalizedebugpath to reproducible feature set

2016-03-29 Thread Daniel Kahn Gillmor
On Tue 2016-03-29 21:52:53 -0400, Holger Levsen wrote: > it's surely progress on the gcc/clang side of things but dropping the > build path from the .buildinfo files would be a huge step *backwards* > for reproducibility… No one is arguing for dropping the build path from .buildinfo files. As we

Re: [Reproducible-builds] Bug#819194: dpkg-buildflags: please add normalizedebugpath to reproducible feature set

2016-03-29 Thread Daniel Kahn Gillmor
On Tue 2016-03-29 20:58:32 -0400, Holger Levsen wrote: > not wanting to spoil the fun, but… > > On Mon, Mar 28, 2016 at 06:33:49PM -0400, Daniel Kahn Gillmor wrote: >> > Ah great! And one less way to leak local information. >> yep :) > > I *believe* it's not

[Reproducible-builds] Bug#819194: dpkg-buildflags: please add normalizedebugpath to reproducible feature set

2016-03-24 Thread Daniel Kahn Gillmor
f-show failed >From 638a575180174df9bd1e60a8856609ba72d52849 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Thu, 24 Mar 2016 13:19:28 -0400 Subject: [PATCH] add normalizedebugpath to reproducible featureset This feature normalizes the path stored in debug symbols, so that these symb

Re: [Reproducible-builds] Bug#812428: libgcrypt20: please make the build reproducible (timestamps)

2016-01-24 Thread Daniel Kahn Gillmor
On Sat 2016-01-23 16:52:09 -0500, Jérémy Bobbio wrote: > While working on the “reproducible builds” effort [1], we have noticed > that libgcrypt20 could not be built reproducibly. > > The attached patch adds support for SOURCE_DATE_EPOCH to set the value > of BUILD_TIMESTAMP defined in the configur

Re: [Reproducible-builds] build paths and debug info for generated C objects

2015-12-10 Thread Daniel Kahn Gillmor
On Thu 2015-12-10 12:38:56 -0500, Niels Thykier wrote: > Given no one has voiced their concerns, I think you should go ahead and > push it upstream. :) I've done so, and it's on https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01168.html (also forwarded to rb-gene...@reproducible-builds.org, since th

[Reproducible-builds] build paths and debug info for generated C objects

2015-12-04 Thread Daniel Kahn Gillmor
Hey all-- Niels, anthraxx and i were just commiserating about the fact that we're punting on reproducibility of the build path. We think we might have found a way to make progress on this. Problem Statement - One of the main concerns about the build path is that it gets included

Re: [Reproducible-builds] Bug#763822: ftp.debian.org: please include .buildinfo file in the archive

2015-12-03 Thread Daniel Kahn Gillmor
Hi there! In https://bugs.debian.org/763822, lunar asked ftp.debian.org to accept .buildinfo files when they are uploaded with a .changes file. This is a followup to make the request concrete by specifying how we hope the archive will sanity-check the included .buildinfo files, and with a suggest

[Reproducible-builds] [R-B WEBSITE PATCH] native en_US speaker website tweaks

2015-11-10 Thread Daniel Kahn Gillmor
Signed-off-by: Daniel Kahn Gillmor --- index.html | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index c3808c9..b361343 100644 --- a/index.html +++ b/index.html @@ -37,13 +37,13 @@ layout: home - Most aspect of software

Re: [Reproducible-builds] Bug#802528: valac: make the generated C files reproducible

2015-10-20 Thread Daniel Kahn Gillmor
On Tue 2015-10-20 15:53:43 -0400, Niko Tyni wrote: > Package: valac > Version: 0.30.0-2 > Severity: wishlist > Tags: patch > User: reproducible-builds@lists.alioth.debian.org > Usertags: toolchain randomness > X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org > > While working on the "repro

Re: [Reproducible-builds] [Debian Wiki] Update of "ReproducibleBuilds/TimestampsProposal" by BenBoeckel

2015-09-16 Thread Daniel Kahn Gillmor
On Wed 2015-09-16 21:19:59 -0400, Debian Wiki wrote: > Dear Wiki user, > > You have subscribed to a wiki page or wiki category on "Debian Wiki" for > change notification. > > The "ReproducibleBuilds/TimestampsProposal" page has been changed by > BenBoeckel: > https://wiki.debian.org/ReproducibleB

Re: [Reproducible-builds] [PATCH 2/2] DocBook: Use a fixed encoding for output

2015-09-11 Thread Daniel Kahn Gillmor
On Fri 2015-09-11 15:30:59 -0400, Jonathan Corbet wrote: > On Tue, 01 Sep 2015 23:49:19 +0100 > Ben Hutchings wrote: > >> Currently the encoding of documents generated by DocBook depends on >> the current locale. Make the output reproducible independently of >> the locale, by setting the encoding

[Reproducible-builds] Bug#793813: medicalterms: /usr/share/hunspell/de_med.dic is not reproducible (collation order based on build environment)

2015-07-27 Thread Daniel Kahn Gillmor
Source: medicalterms Version: 20110608-1 Severity: wishlist User: reproducible-builds@lists.alioth.debian.org Usertags: locale Hi medicalterms maintainers-- Today i noticed that usr/share/hunspell/de_med.dic gets created differently depending on the locale of the build environment: https://repro

[Reproducible-builds] comparing PE executables and assemblies in debbindiff

2015-07-12 Thread Daniel Kahn Gillmor
hi folks-- I just pushed git commit 3d0af25 to the debbindiff repository: commit 3d0af25e8d046b9ae08405cdbf243dc38ae543b4 Author: Daniel Kahn Gillmor Date: Sun Jul 12 17:10:13 2015 -0400 add test for PE assemblies and executables This works at least for those assemblies

[Reproducible-builds] Bug#791673: doc-debian: please make .txt files UTF-8 independently of the locale of the build system

2015-07-07 Thread Daniel Kahn Gillmor
Package: doc-debian Version: 6.3 Severity: wishlist Tags: patch User: reproducible-builds@lists.alioth.debian.org currently, lynx produces text output on the basis of the locale. this means that as the locale differs, the generated .txt files change. Please see: https://reproducible.debian.net/d

Re: [Reproducible-builds] Storing .deb checksums in ADMINDIR/status?

2015-06-23 Thread Daniel Kahn Gillmor
On Tue 2015-06-23 03:31:05 -0400, Jérémy Bobbio wrote: > Some people suggested that we should record a checksum of the `.deb` > installed as a way to unambiguously referring to a specific package. > The main benefit that I can think of is that it would allow to directly > retrieve the file from sn

[Reproducible-builds] Bug#788536: icont embeds some entropy in produced files -- please provide a reproducible mode

2015-06-12 Thread Daniel Kahn Gillmor
Package: icon Version: 9.4.3-4.2 X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org User: reproducible-builds@lists.alioth.debian.org Usertags: toolchain Severity: wishlist Control: affects -1 noweb I'm working on the reproducible-builds project [0] the noweb package uses icont to create

[Reproducible-builds] cheers to ikiwiki

2015-06-11 Thread Daniel Kahn Gillmor
hey Reproducible Build folks-- Just wanted to give a shout out to Simon McVittie (cc'ed here), who did a bunch of work getting ikiwiki to support a deterministic option. In ikiwiki version 3.20150610, we see the following reproducibility-oriented changes (in addition to a small fix i supplied for

Re: [Reproducible-builds] Bug#787444: Bug#787444: help2man: support externally-supplied --date for reproducibility

2015-06-05 Thread Daniel Kahn Gillmor
On Fri 2015-06-05 10:55:34 -0400, Brendan O'Dea wrote: > Any of UTC_SOURCE_DATE, SOURCE_DATE_UTC My vote is for SOURCE_DATE_UTC, and i agree with Brendan that we should take the opportunity to define this as strictly and narrowly as possible (i.e. end in a 'Z', none of the other offsets), so that

Re: [Reproducible-builds] generating reproducible ISOs with xorriso

2015-06-05 Thread Daniel Kahn Gillmor
Hi Thomas-- Thanks for all your work looking into this! On Fri 2015-06-05 10:57:38 -0400, Thomas Schmitt wrote: > About the --sort-weight-list approach which is possible with > already released xorriso versions: > >> (find . -type f -print0 | xargs -0 md5sum | sort | cut -f2- -d/ ; find . >> -min

Re: [Reproducible-builds] Bug#787793: libisoburn: new upstream version 1.4.0 available

2015-06-05 Thread Daniel Kahn Gillmor
On Fri 2015-06-05 02:06:40 -0400, Daniel Kahn Gillmor wrote: > For reproducibility alone, the two relevant changes to apply if > libisoburn debian packaging is rebuilding the docs from the texinfo > would just be: > > > http://libburnia-project.org/changeset/5190/libiso

[Reproducible-builds] Bug#787795: grub: please build rescue ISO and floppy reproducibly

2015-06-04 Thread Daniel Kahn Gillmor
Source: grub Version: 2.02~beta2-23 Severity: wishlist User: reproducible-builds@lists.alioth.debian.org Usertags: timestamps Control: block -1 with 787793 The ISOs (/usr/lib/grub-rescue/grub-rescue-cdrom.iso and /usr/lib/grub-rescue/grub-rescue-floppy.iso) that are created by the grub build proce

[Reproducible-builds] Bug#787793: libisoburn: new upstream version 1.4.0 available

2015-06-04 Thread Daniel Kahn Gillmor
Source: libisoburn Version: 1.3.2-1.1 Severity: wishlist User: reproducible-builds@lists.alioth.debian.org Usertags: timestamps toolchain libisoburn 1.4.0 is available upstream as of 2015-05-17. This update in particular includes the following changeset that allows for setting of ctime in the gen

Re: [Reproducible-builds] Bug#787444: help2man: support externally-supplied --date for reproducibility

2015-06-04 Thread Daniel Kahn Gillmor
On Thu 2015-06-04 21:51:37 -0400, Brendan O'Dea wrote: > Local times, and daylight savings are just too much of a PITA. Just > use UTC and if builds on the first of the month are possibly different > to the changelog, so be it. I agree with Brendan here. If there are no objections to the idea th

Re: [Reproducible-builds] generating reproducible ISOs with xorriso

2015-06-04 Thread Daniel Kahn Gillmor
On Thu 2015-06-04 14:08:36 -0400, Thomas Schmitt wrote: > The syntax would have to be different and probably a more > comprehensive name will come to us when we know what xorriso > features in particular shall be bundled with the new command. That seems like a reasonable approach. > The users wil

Re: [Reproducible-builds] Bug#787444: help2man: support externally-supplied --date for reproducibility

2015-06-04 Thread Daniel Kahn Gillmor
On Thu 2015-06-04 10:38:53 -0400, Ximin Luo wrote: > A few months ago I had an idea for this that would be more generalisable. See > > https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150330/001317.html > > for details. TL;DR is to have SOURCEDATE as an environment variab

Re: [Reproducible-builds] generating reproducible ISOs with xorriso

2015-06-04 Thread Daniel Kahn Gillmor
On Thu 2015-06-04 09:53:11 -0400, Thomas Schmitt wrote: > I saw some sin-list page about packages shortly after > xorriso-1.4.0 was released. > It complained about libburn's doc/doxygen.conf.in which i hope to > have fixed by > http://libburnia-project.org/changeset/5446 Thanks! We don't think

Re: [Reproducible-builds] Bug#787444: help2man: support externally-supplied --date for reproducibility

2015-06-04 Thread Daniel Kahn Gillmor
On Thu 2015-06-04 08:17:59 -0400, Brendan O'Dea wrote: > The idea was that unless that environment variable was set, the > behaviour would be unchanged: the current date would be used. It > seems unlikely that DEB_BUILD_CHANGELOG would be set accidentally. right, but this wouldn't be terribly use

[Reproducible-builds] generating reproducible ISOs with xorriso

2015-06-04 Thread Daniel Kahn Gillmor
Hi libburnia/xorriso folks-- I participate in the Debian Reproducible Builds project [0] (cc'ed here). Our goal is to ensure that free software can be built from source in a way that the binary outcome is byte-for-byte identical, so that compromised build infrastructure can be detected. One of t

Re: [Reproducible-builds] [PATCH] provide anchors to target sections of the front page

2015-06-04 Thread Daniel Kahn Gillmor
On Thu 2015-06-04 05:07:51 -0400, Holger Levsen wrote: > Cool! Thanks, merged + deployed your patch! great, thank you, Holger! > Will you be providing links to these anchors too? ;-) Yes, but they'll probably be external, like https://www.debian-administration.org/users/dkg/weblog/115 If folks

Re: [Reproducible-builds] Bug#787444: help2man: support externally-supplied --date for reproducibility

2015-06-03 Thread Daniel Kahn Gillmor
Hi Brendan-- Thanks for the quick followup! (cc'ing the r-b list) On Wed 2015-06-03 08:24:51 -0400, Brendan O'Dea wrote: > On 2 June 2015 at 04:49, Daniel Kahn Gillmor wrote: >> Please consider the attached patch as a step on the way toward allowing >> packages t

[Reproducible-builds] python-support umask affects reproducibility of built packages

2015-05-11 Thread Daniel Kahn Gillmor
Control: user reproducible-builds@lists.alioth.debian.org Control: usertags 588746 + umask Control: affects 588746 xtalk Fixing the python-support umask issue for .private files would make more packages build reproducibly. For example, consider the xtalk package, which builds reproducibly *except

[Reproducible-builds] [PATCH] Bug #777753: GCC variation with link-time optimization (LTO)

2015-04-15 Thread Daniel Kahn Gillmor
When GCC does link-time optimizations, it embeds some randomness in the generated object. This is https://bugs.debian.org/53, and it affects several packages. it may be the underlying cause of several instances of build_id_variation_requiring_further_investigation, but i haven't removed those

Re: [Reproducible-builds] sbuild: predictible build location for reproducible builds

2015-04-03 Thread Daniel Kahn Gillmor
On Fri 2015-04-03 06:46:07 -0400, Holger Levsen wrote: > I like /usr/src/debian/$packagename-$random where $random are 4 or 8 > alphanumberic characters, as there might be situations where one wants to > build the same package (+version+suite) simultaneously on the same host. > > Thinking further

Re: [Reproducible-builds] Variation in day

2015-02-24 Thread Daniel Kahn Gillmor
On Tue 2015-02-24 16:48:44 -0500, Jérémy Bobbio wrote: > Reiner Herrmann: >> after Faux found a package with a variation not in time, but only >> in the date [1] because it was built around midnight, I had an idea >> about how to get a variation in the day, without having to change >> the clock of

Re: [Reproducible-builds] Doxygen issue with reproducible builds

2015-02-22 Thread Daniel Kahn Gillmor
On Sun 2015-02-22 03:37:41 -0500, marivalen wrote: > On 02/16/2015 02:43 PM, marivalen wrote: >> Furthermore the Doxyfile configuration file embedded in each package >> using doxygen is often copied from the upstream defaults and thus >> enables HTML_TIMESTAMP. The following query on codesearch.d.

Re: [Reproducible-builds] [Mono-dev] making mono builds reproducible (xamarin bz #26842)

2015-02-16 Thread Daniel Kahn Gillmor
On Mon 2015-02-16 18:17:53 -0500, Michael McGlothlin wrote: > I'd always store time in epochs. Seconds since 1/1/1970 GMT. > > The use of textual date strings instead of a epochs is one of the > worst things I've seen from the C# way of doing things. I had often > wondered why so many programs coul

[Reproducible-builds] making mono builds reproducible (xamarin bz #26842)

2015-02-16 Thread Daniel Kahn Gillmor
Hi Mono folks-- some good discussion has come up on the xamarin bugtracker about being able to make builds using the mono toolchain reproducible: https://bugzilla.xamarin.com/show_bug.cgi?id=26842 Jo Shields offered a one-liner fix to PEWriter.cs to allow the use of an environment variable to

Re: [Reproducible-builds] Preliminary review of dpkg-genbuildinfo

2015-02-16 Thread Daniel Kahn Gillmor
On Mon 2015-02-16 04:39:32 -0500, Hans-Christoph Steiner wrote: > I think this topic is far too vast with far too many dependencies to really > have a useful discussion on without a full time, dedicated team. Since that > seems highly unlikely in the near future, we need to break it down into chun

Re: [Reproducible-builds] Reproducible Builds — proof of concept successful for 83% of all sources in main

2015-02-13 Thread Daniel Kahn Gillmor
On Fri 2015-02-13 14:33:12 -0500, Paul Gevers wrote: > On 13-02-15 18:28, Reproducible builds folks wrote: >> If you want to help, a first step is to check the reproducibility of >> your packages [DDLIST]. Feel free to ask for help on the >> mailing list or in >> #debian-reproducible on irc.debian

Re: [Reproducible-builds] [Reproducible-commits] [notes] 01/01: add new issue, randomness_in_gnu_build_id and, so far, two packages affected by it: encfs and bacula

2015-02-13 Thread Daniel Kahn Gillmor
On Fri 2015-02-13 11:10:31 -0500, Holger Levsen wrote: > Hi, > > On Samstag, 7. Februar 2015, Jérémy Bobbio wrote: >> I think it really is not helpful. It's like having a category >> “needs_more_work_to_understand_the_problem”. > > actually I think such a category, or even such categories, would be

Re: [Reproducible-builds] Preliminary review of dpkg-genbuildinfo

2015-02-13 Thread Daniel Kahn Gillmor
On Fri 2015-02-13 03:36:20 -0500, Hans-Christoph Steiner wrote: > I think it would be much simpler to just have the single package signature > that is embedded in the package file itself, like Android APKs and Java JARs. > Since the package is built reproducibly, anyone who builds it can just copy

Re: [Reproducible-builds] Preliminary review of dpkg-genbuildinfo

2015-02-12 Thread Daniel Kahn Gillmor
On Fri 2015-02-06 01:13:18 -0500, Guillem Jover wrote: > Take the example I gave previously of a binary package detached from > an archive, just a .deb package laying around, either from an old > download or passed to you by someone. You have to *know* the origin of > the binary, otherwise you need

Re: [Reproducible-builds] don't panic? or: inform d-d-a

2015-02-10 Thread Daniel Kahn Gillmor
On Mon 2015-02-09 21:01:46 -0500, Jérémy Bobbio wrote: > Mattia Rizzolo: >> I added a lot of stuff to the pad. Not sure if everything is relevant, >> but yet, imho is nice to have. > > And I've trimmed a lot of it. ;) > > > I'm quite happy with the content as of 2015-02-10 02:00 UTC. I would be > i

Re: [Reproducible-builds] don't panic? or: inform d-d-a

2015-02-08 Thread Daniel Kahn Gillmor
On Sun 2015-02-08 06:58:37 -0500, Mattia Rizzolo wrote: > On Sun, Feb 8, 2015 at 12:48 PM, Holger Levsen wrote: >> The following is a suggestion which I'm not entirely happy with, feedback >> much >> welcome. I think we should probably move this to etherpad/gobby and >> fisnih/rewrite it collabor

Re: [Reproducible-builds] Bug#774422: perl: please make perl builds reproducible

2015-01-23 Thread Daniel Kahn Gillmor
On Fri 2015-01-23 06:03:25 -0500, Holger Levsen wrote: > Hi Niko, > > On Freitag, 23. Januar 2015, Niko Tyni wrote: >> A quick search indicates that there's no separate namespace for other >> uname(2) information than the host name and domain name. This suggests >> that something like http://www.b

Re: [Reproducible-builds] Recording build path in .buildinfo

2014-11-20 Thread Daniel Kahn Gillmor
On 11/19/2014 07:42 AM, Jérémy Bobbio wrote: > While I still think it would be a good idea to write these patches and > push for a canonical build location, I am now thinking that there's a > way to be a bit more flexible. If we would record the build path as part > of the environment in the .build

  1   2   >