Re: Storing build logs outside of .deb packages
On Mon, 2020-06-01 at 20:53 +0200, Mattia Rizzolo wrote: > But so, do you think the first step lies in pbuilder/sbuild to decide an > interface for the package maintainers to use, or for the buildd managers > (wanna-build/buildd and launchpad) to decide on an interface that > sbuild needs to provide (and I would guess pbuilder will try to copy it > for consistency). My initial thought was that none of the existing codebases should be doing this. Instead dsa-puppet should get sbuild post-build hooks that tar up a configurable set of build artefacts and transfer those to buildd.d.o to be displayed alongside build logs. The list of build artefact path patterns would be maintained in wanna-build/launchpad, transferred to each buildd before each build, matched after each build, the matches passed to tar and the tarball uploaded alongside the log. Since then I talked about this with aurel32/jcristau on #debian-buildd and they reached the conclusion that this should be a per-package thing left up to maintainers of packages rather than a global thing done by buildd management systems like wanna-build/launchpad. They thought the audience for this was mainly individual package maintainers rather than the porters, maintainers, RC bug fixers, NMUers and everyone else. All that said, I am not really one of the stakeholders in this discussion so I'll just follow along as a lurker from now on. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Storing build logs outside of .deb packages
On Mon, Jun 01, 2020 at 09:40:19PM +0800, Paul Wise wrote: > Re-reading the above thread, I now think that debhelper/dpkg-dev is the > wrong layer to be implementing this and that we want it in the hooks or > config for the build system in use; launchpad, sbuild, pbuilder etc. > […] > > So, I would suggest buildd.d.o folks and launchpad folks would be the > maintainers of the rules about artefacts to preserve and that the > artefacts be published in the same place as the build logs. Probably > for Debian, DSA would need to add to the buildd puppet module a way for > the buildd admins to specify a set of globs for files to preserve. But so, do you think the first step lies in pbuilder/sbuild to decide an interface for the package maintainers to use, or for the buildd managers (wanna-build/buildd and launchpad) to decide on an interface that sbuild needs to provide (and I would guess pbuilder will try to copy it for consistency). In the first case, it would mean me and Josh needs to think about something, probably including Neils in case debhelper can help maintainers do stuff (this is the reason I thought that the whole debian/.build thing was a good idea). I know I tried to catch Josh attention via IRC in the past, but he was also basically lost on how to tackle this matter. In the latter case, it would basically mean that Aurelien and Colin needs to think together instead. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Storing build logs outside of .deb packages
On Mon, 2020-06-01 at 11:12 +0200, Mattia Rizzolo wrote: > I know this has been linked in multiple places, but I'll link it > again: > https://bugs.launchpad.net/launchpad/+bug/1845159 > there has also been a relevant thread in debian-devel a few months > back, spawned off the debian/.build thread started by Niels Thykier. Here is the thread you have mentioned: https://lists.debian.org/msgid-search/5f47b00f-50f0-98b2-776a-28ead95ad...@thykier.net > I'm not quite clear what's the best way forward: I could go and > implement whatever feels best to me in pbuilder, and then hope the > rest of the tooling with catch up, copy my idea and adapt, but that > feels unlikely… Re-reading the above thread, I now think that debhelper/dpkg-dev is the wrong layer to be implementing this and that we want it in the hooks or config for the build system in use; launchpad, sbuild, pbuilder etc. The reason is that it needs to be able to evolve more rapidly than the codebases of any of the tools that the builds use, especially in response to maintainer requests after they notice new build failures. So, I would suggest buildd.d.o folks and launchpad folks would be the maintainers of the rules about artefacts to preserve and that the artefacts be published in the same place as the build logs. Probably for Debian, DSA would need to add to the buildd puppet module a way for the buildd admins to specify a set of globs for files to preserve. Sorry for getting side-tracked by BYHAND stuff. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Storing build logs outside of .deb packages
On Sun, May 31, 2020 at 02:49:46PM -0700, Vagrant Cascadian wrote: > On 2020-05-17, Paul Wise wrote: > > On Sat, 2020-05-16 at 22:58 +, Chris Lamb wrote: > >> My gut feeling is that this is the avenue we want to explore. Having a > >> separate mechanism to capture this build-specific metadata would be an > >> elegant solution and, as you imply, having the logs would have QA > >> advantages as well as permit reproducible builds. The system could be > >> generic enough for future use-cases that we cannot envisage too. > > > > Agreed that this is the best option. In order to standardise the > > naming, structure and organisation of the data in order to make it work > > across all Debian derivatives, probably a new conversation needs to be > > started between ftp-master and the dpkg maintainer. > > > >> We have taken great pains over the years that no special knowledge, > >> tools or tricks are required to compare the artifacts of a Debian > >> build with respect to reproducibility. > > > I'm guessing you just ignore all differences in buildinfo files and > > would have to add to that ignoring differences between build logs and > > other build metadata? > > That sounds likely, yes. I know this has been linked in multiple places, but I'll link it again: https://bugs.launchpad.net/launchpad/+bug/1845159 there has also been a relevant thread in debian-devel a few months back, spawned off the debian/.build thread started by Niels Thykier. I'm not quite clear what's the best way forward: I could go and implement whatever feels best to me in pbuilder, and then hope the rest of the tooling with catch up, copy my idea and adapt, but that feels unlikely… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Storing build logs outside of .deb packages
On 2020-05-17, Paul Wise wrote: > On Sat, 2020-05-16 at 22:58 +, Chris Lamb wrote: >> My gut feeling is that this is the avenue we want to explore. Having a >> separate mechanism to capture this build-specific metadata would be an >> elegant solution and, as you imply, having the logs would have QA >> advantages as well as permit reproducible builds. The system could be >> generic enough for future use-cases that we cannot envisage too. > > Agreed that this is the best option. In order to standardise the > naming, structure and organisation of the data in order to make it work > across all Debian derivatives, probably a new conversation needs to be > started between ftp-master and the dpkg maintainer. > >> We have taken great pains over the years that no special knowledge, >> tools or tricks are required to compare the artifacts of a Debian >> build with respect to reproducibility. > > I'm not involved in repro builds enough so your statement leads me to > wonder how you deal with ignoring the inevitable differences between > the buildinfo files, which would record the inevitable differences in > build environment between different builders. Thanks for diving in and nudging this conversation forward! The .buildinfo files aren't the build artifacts themselves, it's the vehicle by which data about the resulting artifacts and the environment used to produce them is recorded. So yes, they're not expected to be reproducible anymore. > I'm guessing you just ignore all differences in buildinfo files and > would have to add to that ignoring differences between build logs and > other build metadata? That sounds likely, yes. I'm not sure this belongs on the binutils bug anymore; dropped from CC. live well, vagrant signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
