Re: [Reproducible-builds] using disorderfs to build packages

Chris Lamb: After reading the disorderfs manpage I wonder if it's really already suitable to build everything This is a little awkward for me as I raised these concerns a couple of times during the BoF but I did not want to temper anyone's enthusiasm in the room. I therefore did not labour

Re: [Reproducible-builds] using disorderfs to build packages

Andrew Ayer: On Wed, 26 Aug 2015 10:58:08 +0200 HW42 h...@ipsumj.de wrote: Errors from close are not properly reported. Probably don't hurt. Most programs ignore them anyway. I think close() only fails if there's a disk error or you run out of disk space/quota. Neither of these should

[Reproducible-builds] [PATCH] make suite list a bit more intuitive

Hi, I think the current suite/arch list is a bit unintuitive since it is not clear which suite/arch are built and which is currently shown. See attached patches for a proposal to make it a bit nicer. HW42 From be75eced896ff097ac68f510fd98be93aa5f8725 Mon Sep 17 00:00:00 2001 From: HW42 h

Re: [Reproducible-builds] using disorderfs to build packages

speculation (the only proper thing is probably a (partial) archive rebuild to see what happens) HW42 signature.asc Description: OpenPGP digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http

[Reproducible-builds] buildinfo patch breaks .changes

20160613T013823z-ff7bd155 The attached patch fixes this and should be stashed into the buildinfo patch. HW42 [0]: https://anonscm.debian.org/git/reproducible/dpkg.git/commit/?id=0774d0244c94733d1480f7c246085ef02196f71a [1]: https://anonscm.debian.org/git/reproducible/dpkg.git/tree/scripts/Dpkg

Re: [Reproducible-builds] Bug#825643: dash: please make the build reproducible

, HW42 diff -urN a/debian/rules b/debian/rules --- a/debian/rules 2016-06-13 01:27:12.0 +0200 +++ b/debian/rules 2016-06-13 01:20:28.447939088 +0200 @@ -46,7 +46,7 @@ touch configure (cd build-tmp && CC='$(CC)' \ CFLAGS='$(CFLAGS)' CPPFLAGS='$(CPPFLAGS)' LDFLAGS='$

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

in different languages (shell, Makefile). So if we want to support spaces in buildpaths this need to be changed to an array. What do you think? HW42 signature.asc Description: OpenPGP digital signature ___ Reproducible-builds mailing list Reproducible-builds

Re: [Reproducible-builds] u-boot locale variations with it_*.UTF-8

image format which embeds timestamps which aren't set to SOURCE_DATE_EPOCH [2]. See attached patch to fix this (might need some cleanup before upstreaming). [2]: https://sources.debian.net/src/u-boot/2016.07~rc1%2Bdfsg1-1/tools/fit_image.c/#L55 HW42 --- a/tools/default_image.c +++ b/tools/defau

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

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 ab

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

Thomas Schmitt: > A new source of irreproducibility appeared: Future xorriso versions. > [...] > > I will of course try to keep such changes as rare as possible. But it > cannot be totally guaranteed that the same input data and options will > yield the same ISO with future versions of xorriso.

Re: [Reproducible-builds] enable build path variation when testing unstable & experimental?

Chris Lamb: > Holger wrote: > >> I think regarding Debian releases, I'd recommend that we aim for >> partially reproducible packages given known build paths > > I agree. We should, regrettably, define a fixed build path for stretch > at this point in the release cycle. I want to note that this

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

Ximin Luo: > However the question is, do we want to do this every time an upstream > saves CFLAGS somewhere? [...] > 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

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

Ximin Luo: > HW42: >> Ximin Luo: >>> [..] >>> >>> 1. Patch GCC to set debug-prefix-map to "$pwd=." by default (and the >>> analogue for other languages / tools). >>> >>> This behaviour is concretely different

Re: Bug#836732: strip-nd: FTBFS when locale is not English

Chris Lamb: > tag 836732 + pending > thanks > >> Not sure how much related they are, but I guess it means something given >> that it's not in the English build. > > I don't really understand why that would be causing an error but we follow > your assumption that the "return" that is causing the

Re: Build path variation and __FILE__

Sascha Steinbiss: > Hi all, > > I’d like to contribute to the build path discussion as well with a few > observations I made when trying to fix reproducibility problems > related to that in my packages. In addition to the problem already > raised by Ximin concerning upstream storing CFLAGS in

Bug#837681: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs

Since guestfs works by running a modified kernel in an VM to parse the file system, I think it fails to start the VM (nested virt disabled, OOM, ...). So I think you should first try if guestfs works at all (without diffoscope) and/or enable the debug loggin like suggested in the error message.

Re: strip-nd FTBFS in reproducible infra

Chris Lamb: >> Then I'd have expected it to fail also in the buildds... > > Oh, it *doesn't* fail in the buildds? Weird. > > Still, given that it's *this* particular test that fails it's almost > certainly something along the lines I previously suggested (this test > is deliberately designed to

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

Ximin Luo: > 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 ha

Bug#837681: debug output (Re: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs)

Holger Levsen: > On Thu, Sep 15, 2016 at 02:58:00PM +0000, HW42 wrote: >> It fails to find a kernel for the VM image it creates on the fly: > > ah, wow. > >> diffoscope-qubes-debug: >>> supermin: failed to find a suitable kernel (host_cpu=x86_64). >

Bug#837681: debug output (Re: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs)

Holger Levsen: > On Tue, Sep 13, 2016 at 03:35:58PM +0200, Holger Levsen wrote: >> so I build an Qubes ISO, twice and ran diffoscope against it: > > just now I enabled debugging like this: > >> To see full error messages you may need to enable debugging. >> Do: >> export LIBGUESTFS_DEBUG=1

Bug#837681: debug output (Re: diffoscope: 'ERROR guestfs can't be launched' when trying to compare to qubes ISOs)

Holger Levsen: > On Thu, Sep 15, 2016 at 04:38:00PM +0000, HW42 wrote: >>> 3.16.0-4-amd64 is the kernel (so jessie standard), and the host this is >>> running on is a profitbricks VM, so running on kvm. >> I assume you have this kernel only installed on the VM not the c

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

Ximin Luo: > HW42: >>> I preferred the ${x}dir style instead of dir_${x} or ${x}_dir because >>> of some existing conventions like >>> >>> https://www.gnu.org/prep/standards/html_node/Directory-Variables.html >> >> Well, OTOH, freedesktop.org uses

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

Ximin Luo: > Ximin Luo: >> I'm going to suggest SOURCE_ROOT_DIR [..] > > OTOH, taking into account dkg's earlier point about overloading > "root", perhaps SOURCE_BASE_DIR would be better. > > It is used quite heavily: > > https://codesearch.debian.net/search?q=\bSOURCE_BASE_DIR\b > > but only

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

Ximin Luo: > Hi all, > > I'm thinking of ways to minimise the work needed to fix the build path > issues that we're having. > > The present method is that dpkg-buildflags sets > "-fdebug-prefix-map=$PWD=." into various *FLAGS envvars, and Make (or > another build tool) will pass this to gcc.

Bug#839538: diffoscope: json: detect order-only differences

Daniel Shahaf: > It would be better to report "json files are equal up to order of > elements in an object (= hash, dictionary, associative array)", and to > print the difference in a more readable way than a hex dump. (For > example, a linewise diff of pretty-printed json.) While at it, it

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

Chris Lamb: > HW42 wrote: [...] >>> +Subkey-Type: ELG-E >>> +Subkey-Length: 1024 >> >> Huh? > > Suggestions welcome. I cribbed it from the internet. [...] > Just to re-iterate — and I hope this comes across the right way! — but > the current state

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

> +sign_buildinfo() { > + # Greate GPG key if it does not already exist > + if ! gpg --list-secret-keys | grep -qs '^sec' >/dev/null 2>&1 Is this ever called concurrently? > +Subkey-Type: ELG-E > +Subkey-Length: 1024 Huh? > mail -s "buildinfo from $NODE1"

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

Mattia Rizzolo: > On Sun, Nov 06, 2016 at 10:04:00PM +0000, HW42 wrote: >> (As I wrote an hour ago on irc,) See last 3 commit at >> https://anonscm.debian.org/git/users/hw42-guest/jenkins.debian.net.git/ > > >> commit fdb7a50073ef9e3b8d22176b63817a78c928d73c >&g

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

Mattia Rizzolo: > On Mon, Nov 07, 2016 at 01:41:00PM +0000, HW42 wrote: >> I removed the filter from Reiner and replaced it with a 'sed' filtering >> out the .buildinfo entries from the .changes file. So diffoscope should >> not compare the .buildinfos (and the files re

Re: From srebuild sbuild-wrapper to debrebuild

Johannes Schauer: > Hi, > > On Thu, 10 Nov 2016 05:54:13 -0200 Johannes Schauer <jo...@debian.org> wrote: >> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer <jo...@debian.org> wrote: >>> But then on IRC, HW42 suggested to approach this problem dif

Bug#841146: diffoscope: Failure of test_superblock

Leo Famulari: > On Fri, Oct 21, 2016 at 04:23:51PM +, Mattia Rizzolo wrote: >> Though I'm using pytest 3.0.3. >> That test is skipped by using pytest.mark.skip(), which I don't see in >> the docs of pytest for 2.7. >> The changelog of pytest tells me pytest.mark.skip() is recognized as a >>

Re: From srebuild sbuild-wrapper to debrebuild

the source package now depends on >>the exact right package versions and let the resolver figure out the rest >>(thanks Benjamin for that idea) >> - check whether the generated binaries produce the same checksum as given in >>the supplied buildinfo f

Re: From srebuild sbuild-wrapper to debrebuild

Johannes Schauer: > Hi, > > On Thu, 10 Nov 2016 05:54:13 -0200 Johannes Schauer <jo...@debian.org> wrote: >> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer <jo...@debian.org> wrote: >>> But then on IRC, HW42 suggested to approach this problem dif

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

Chris Lamb: > Hey Johannes, > >> 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 (varying on

Re: accessibility of the reproducible builds page

Sebastian Humenda: > Hi all > > I'd like to report and discuss with you an issue that I'm having with the > reproducible builds page, linked from the QA page of a package of mine. > My package, freedict, is affected by "unstable" builds. I suppose that's > because > the build time stamp is

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

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

Re: Bug#774415: From srebuild sbuild-wrapper to debrebuild

builder or >>> sbuild/pbuilder use a common tool to figure out the right lines for the >>> sources.list inside the chroot. I just want to have .buildinfo support for >>> sbuild in Stretch and if either solution is not in unstable soon, then my >>> plan is to just ad