Re: Bug#844431: Reproducibility in Policy

Hi, Quoting Russ Allbery (2017-08-12 09:57:44) > I think we need to add all environment variables starting with DEB_* to > the prerequisites. If you set DEB_BUILD_OPTIONS=nostrip or > DEB_BUILD_MAINT_OPTIONS=hardening=all, you'll definitely get a different > package, for instance. > > I feel

sbuild: please add the srebuild sbuild wrapper to reproduce builds

Hi, this bug has been listed in the "NMU campaign" email on d-devel. But I wonder how it ended up there. There are still open problems that are not answered, the fix for this is still blocked by another bug (#802241) which is not on the NMU list, and the code I wrote to fix the problem

Re: Reproducing packages in the archive

Hi, Quoting Holger Levsen (2017-02-01 11:56:03) > On Tue, Jan 31, 2017 at 07:35:35PM +, Daniel Shahaf wrote: > > That is: if I run dpkg-buildpackage and post the .deb and .buildinfo > > somewhere, do we have a script that takes the .buildinfo as input and > > reproduces the .deb? > > AIUI

Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups

Hi, Quoting Holger Levsen (2017-01-30 14:58:33) > On Mon, Jan 30, 2017 at 02:47:45PM +0100, Johannes Schauer wrote: > > > b.) if thats the case, shall we scan all packages in sid for files which > > > have the same timestamp+filename but different checksums and ask for &

Re: Some Debian package upgrades are corrupting rsync "quick check" backups

Hi Henrik & Holger, sbuild maintainer here. Quoting Holger Levsen (2017-01-30 14:25:51) > On Mon, Jan 30, 2017 at 01:10:12PM +0100, Mattia Rizzolo wrote: > > > Would reproducible-builds@lists.alioth.debian.org be the correct mailing > > > list to discuss this? > > the debian-buildd list or a

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

Hi, Quoting Holger Levsen (2016-12-19 10:35:53) > On Mon, Dec 19, 2016 at 10:02:58AM +0100, Johannes Schauer wrote: > > Other ways to solve this problem include: > > - only accept .buildinfo files that include the .dsc filename and checksum > > - accept .changes file

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

Hi, Quoting Johannes Schauer (2016-12-20 13:49:27) > Currently, a buildinfo file does not specify which artifacts were supposed to > be built (source,any,all). as guillem points out to me on #debian-dpkg, the Architecture field lists exactly that. It will contain "source" if th

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

Hi, Quoting Johannes Schauer (2016-12-19 10:02:58) > I also came up with another question: and as I'm implementing this, here yet another: Currently, a buildinfo file does not specify which artifacts were supposed to be built (source,any,all). What should happen if the buildinfo f

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

Hi, Quoting HW42 (2016-12-19 07:37:00) > So you (at least josch and ntyi) seem to prefer to have the user facing part > in sbuild/pbuilder and the common functionality in some kind of library. How > should the "library" interface look like for sbuild? pbuilder is written in bash, so a plain-text

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

Hi, Quoting Niko Tyni (2016-12-17 13:40:32) > On Thu, Dec 15, 2016 at 02:21:49PM +0100, Johannes Schauer wrote: > > Quoting Niko Tyni (2016-12-15 14:04:19) > > > In general, I like the concept of sbuild/pbuilder accepting .buildinfo > > > files > > > as

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

Hi, Quoting Niko Tyni (2016-12-15 14:04:19) > > But then on IRC, HW42 suggested to approach this problem differently. > > Instead of integrating the functionality of figuring out the right > > repositories to reproduce the contents of a buildinfo file into sbuild, > > write a tool that can drive

Bug#847805: reprotest: document/support simple reproducibility test with sbuild

Hi Sean, Quoting Sean Whitton (2016-12-12 00:44:05) > On Sun, Dec 11, 2016 at 03:12:57PM -0700, Sean Whitton wrote: > > I have sbuild properly set up on my machine, and I want to use it to > > test package reproducibility. Something like this, where PWD is an > > unpacked source package: > > >

Re: From srebuild sbuild-wrapper to debrebuild

Hi, Quoting HW42 (2016-11-17 05:10:00) > After discussing this in the irc meeting yesterday I propose that: > > - we keep it as a separate tool. > - put it in a git repo under >https://anonscm.debian.org/git/reproducible/ > - We have more than enough DDs who are willing to sponsor

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

Hi, Quoting Daniel Kahn Gillmor (2016-11-13 21:44:22) > It is definitely not what most of us initially expected, but it is > actually what we want. > > i look at it this way: > > * Ideally, the generated binary packages are reproducible *even when >the build environment changes*. For

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

Hi, Quoting Chris Lamb (2016-11-13 12:25:07) > > move the build date inside the .buildinfofile in a Build-Date field or > > similar > Hrm. Are we sure about this? My gut tells me that the external definition of > the build should not include the Build-Date. (At the very least, this is just > a

Re: From srebuild sbuild-wrapper to debrebuild

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 differently. > > Instead of integrating the fu

Re: misleading timestamps in binnmus

Hi, Quoiting Holger Levsen (2016-11-10 07:48:33) > On Thu, Nov 10, 2016 at 10:38:45AM +0100, Emilio Pozuelo Monfort wrote: > > > I see. And this changelog.$arch is neither part of the source package, > > > the .changes file nor the .buildinfo file, it's just included in the > > > binary packages?

Re: sbuild should use build date as binnmu changelog date

Hi Ian and reproducible-builds folks, On Wed, 9 Nov 2016 12:03:48 + Ian Jackson wrote: > Currently, when adding a changelog stanza for a binnmu (or when appending to > the version number is requested for another reason), sbuild uses the existing > source

Re: Build dependency list

Hi mike, welcome to the bootstrapping problem! Quoting james michael dupont (2016-11-02 12:12:57) > Here is a question, if you were to compile an entire Debian system from > scratch with no root access, and first get all the developer packages > compiled and then use those newly built tools to

Re: [Reproducible-builds] Moving towards buildinfo on the archive network

Hi Jonathan, Quoting Jonathan McDowell (2016-07-25 22:29:39) > Having been impressed by the current status of reproducible builds and > the fact it looks like we're close to having the important pieces in > Debian proper, I have started to have a look at how I could help out > with this bug. I've

[Reproducible-builds] From srebuild sbuild-wrapper to debrebuild

Hi, On Mon, 09 May 2016 21:07:40 +0200 Johannes Schauer <jo...@debian.org> wrote: > The main disadvantage of the current srebuild implementation is, that it will > only make use of a single snapshot.d.o timestamp. This makes it impossible to > reproduce situations where package

[Reproducible-builds] repro-test (was: Re: Projects and mentors wanted for our participation in upcoming outreach programmes)

Hi, Quoting Holger Levsen (2016-02-17 11:57:03) > And then I was thinking to add another project, "develop reprotest tool", > what > other ideas do you have? I have some more random thoughts about this: - unfortunately I failed to take part in that discussion in Athens but I assume you

Re: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

Hi, Quoting Holger Levsen (2016-02-04 11:31:32) > (AFAIK transitive build-depends are all possible build depends, no, that would be the build dependency closure ;) > so if a package build depends on python2 || python3 both python versions will > be part of the transitive build depends. (Is

Re: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

Hi, Quoting Guillem Jover (2016-02-04 09:44:13) > On Sun, 2016-01-31 at 14:43:08 +0100, Jérémy Bobbio wrote: > > and “Installed-Build-Depends” for the list of packages? > > I asked for more suggestions on #debian-dpkg, and Johannes Schauer > suggested Transitive-Build-Depends,

Re: [Reproducible-builds] Building packages in the *past* (!!)

Hi, Quoting Chris Lamb (2015-09-30 11:57:20) > > There is a minimum of sanity that we should assume on the autobuilders, > > Agree in principle.. > > > namely, that packages are built on a date which is later than the one > > in the last changelog entry. > > .. but why should this matter? In

[Reproducible-builds] binNMU detection for generating Changes field in buildinfo (was: Re: binNMU or reproducible builds (choose only one))

Hi Lunar, Quoting Jérémy Bobbio (2015-09-19 16:46:36) > Simon McVittie: > > BinNMUs don't upload any source at all. They instruct the autobuilders > > to run sbuild with some non-default options ("sbuild --binNMU=2 > > --make-binNMU "Rebuild with foo 3" foo_1.2-3" will result in > >

Re: [Reproducible-builds] .buildinfo should contain source hashes (as well as binary hashes)

Hi, Quoting Ximin Luo (2015-09-20 18:49:16) > Currently, to run a DDC test, we would have to read the buildinfo file, find > the hashes of the binary build-deps, lookup the source packages that > corresponds to these hashes, find a different binary build-deps for these > hashes, and run our

[Reproducible-builds] package uploaded to our repo

debhelper_9.20150811.0~reproducible1.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org

Re: [Reproducible-builds] Bug#794792: freeipmi: please make the build reproducible

Hi, just some (hopefully helpful) comments about your freeipmi patch. Not CC-ing the bug so that it's completely up to you whether you want to address my comments or not. Quoting Dhole (2015-08-06 19:13:22) The attached patch replaces the timestamp in the docs with the latest debian/changelog

Re: [Reproducible-builds] Bug#791815: libxslt: please support timestamps from environment

Control: block -1 by 791823 On Wed, 08 Jul 2015 20:01:57 +0200 Dhole dh...@openmailbox.org wrote: The submitted bug for the mentioned feature in debhelper can be found at: https://bugs.debian.org/791823 and added some bug metadata :) signature.asc Description: signature

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

Hi, Quoting Guillem Jover (2015-06-26 06:30:39) On Tue, 2015-06-23 at 09:31:05 +0200, 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. In principle the tuple pkgname-version-arch

Re: [Reproducible-builds] Patches for sbuild reproducible builds

Hi, Quoting Holger Levsen (2015-02-17 09:27:22) On Dienstag, 17. Februar 2015, Johannes Schauer wrote: Also, pbuilder and sbuild would need to ensure the same exact package set from build dependencies; [...] this has been taken care of by the srebuild wrapper which will take

Re: [Reproducible-builds] Patches for sbuild reproducible builds

Hi, Quoting Vagrant Cascadian (2015-02-16 21:01:18) Also, pbuilder and sbuild would need to ensure the same exact package set from build dependencies; there are various different dependency resolvers which might result in differences that could cause unreproducibility... this has been taken

Re: [Reproducible-builds] Bug#778423: support a plain text output mode

Hi, Quoting Helmut Grohne (2015-02-14 21:14:41) A limitation of rebootstrap currently is that it can only output a build log. Thus I embed the debbindiffs into the log. This is cumbersome to read, since they are unrendered html. Having a plain text output mode would make reading these logs

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

Hi, Quoting Holger Levsen (2015-02-13 17:10:31) 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 helpful. I

[Reproducible-builds] Bug#774554: dcmd: please support .buildinfo files

Package: devscripts Version: 2.14.11 Severity: wishlist Tags: patch User: reproducible-builds@lists.alioth.debian.org Usertags: toolchain Hi, the attached patch enables dcmd to parse .buildinfo files as well. They are generated as part of the ReproducibleBuilds effort:

[Reproducible-builds] introducing srebuild (was: Re: introducing buildinfo2snapshot)

Hi, Quoting Johannes Schauer (2014-12-31 16:42:04) today I skimmed the ReproducibleBuilds wiki page and read that A build tool that would reproduce a build environment using packages from snapshot.debian.org is still missing.. As I understand it, this task mainly boils down to finding

[Reproducible-builds] introducing buildinfo2snapshot

Hi, today I skimmed the ReproducibleBuilds wiki page and read that A build tool that would reproduce a build environment using packages from snapshot.debian.org is still missing.. As I understand it, this task mainly boils down to finding a snapshot that all package versions in the .buildinfo