Re: Making schleuder build reproducibly

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

Re: Question about strip-nondeterminism in bsh

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

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

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 >

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

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

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

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

Re: Reproducibility in Policy

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

Bug#871244: diffoscope: support keybox files with kbxutil

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

Bug#871244: diffoscope: support keybox files with kbxutil

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

Re: source-only builds and .buildinfo

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

Re: source-only builds and .buildinfo

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

Re: source-only builds and .buildinfo

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

Re: Making schleuder build reproducibly

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

Bug#858867: diffoscope: please support pcap files

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

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,

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

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

Re: Buildinfo in the Debian archive, updates

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

Re: Buildinfo in the Debian archive, updates

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`) >

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

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

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

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

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

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

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

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

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

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

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

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

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

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 :/ >> "hostname -

Re: [PATCH] Make use of gpg more flexible

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

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

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

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

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

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

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

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

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

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

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

Re: opi2a back! init system variations?

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

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

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

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

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'

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 &g

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

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'

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.

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:

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

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 as gnupg (&

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

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 >

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

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 >

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

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"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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: >

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

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:

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

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:

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

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

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

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] Bug#787793: libisoburn: new upstream version 1.4.0 available

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

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

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] Bug#787444: help2man: support externally-supplied --date for reproducibility

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 that

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

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 it's

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

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 variable

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

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

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

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 will

[Reproducible-builds] generating reproducible ISOs with xorriso

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

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

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

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

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

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

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

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 the

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

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] don't panic? or: inform d-d-a

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 in favor of

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

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

Re: [Reproducible-builds] Bug#762397: libgpg-error: please do not capture the current time during the build process

On 09/21/2014 04:58 PM, Dominic Hargreaves wrote: On Sun, Sep 21, 2014 at 10:45:14PM +0200, Jérémy Bobbio wrote: 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