Processed: Re: Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
Processing commands for cont...@bugs.debian.org: > tags 1068705 + pending Bug #1068705 [diffoscope] diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 1068705: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068705 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
tags 1068705 + pending thanks Fay Stegerman wrote: > The attached patch avoids the crash in this case, FWIW. […] Applied in Git with attribution taken from your email. > I would still recommend catching the error for other cases. Fixed as well. And it adds a nice comment displaying the issue. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
On Thu, Apr 11, 2024 at 11:28:19AM +0100, Chris Lamb wrote: [...] > Applied in Git with attribution taken from your email. [...] > Fixed as well. And it adds a nice comment displaying the issue. awesome, thank you both! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make facts great again. 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: Bug#1068483: Bug#882511: dpkg-buildpackage: should allow caller to force inclusion of source in buildinfo
Hi! On Wed, 2024-04-10 at 15:22:45 -0700, Vagrant Cascadian wrote: > On 2024-04-09, Guillem Jover wrote: > > I've now finished the change I had in that branch, which implements > > support so that dpkg-buildpackage can be passed a .dsc or a source-dir, > > and in the former will first extract it, and for both then it will > > change directory to the source tree. If it got passed a .dsc then it > > will instruct dpkg-genbuildinfo to include a ref to it. > > > > Which I think accomplishes the requested behavior in a safe way? I've > > attached what I've got, which I'm planning on merging for 1.22.7. I'll > > probably split that into two commits though before merging. > > Had a chance to take this for a test run, and it appears to work, though > with a few surprises... Ah, thanks for the testing, that was very helpful! :) > dpkg-buildpackage -- hello_2.10-3.dsc > > Ends up regenerating the .dsc, as --build=any,all,source by default > ... which may end up with a different .dsc checksum in the .buildinfo > than .dsc that was passed on the commandline. Which makes some sense, > but maybe would be better to error out? I would not expect to regenerate > the .dsc if you're passing dpkg-buildpackage a .dsc! Hmm, right I think I had documented that locally in the manual page, but I can see how this can be surprising. I've for now switched the code to not regenerate the .dsc when that is being passed, but the problem is that I think the three options are potentially correct: * regen: If you built the source on a stable/unstable system, then you'd want to regenerate it on the target one (for unstable or a backport or stable update), otherwise we might get compatibility issues or missed updates. It is also what is being requested when calling dpkg-buildpackage (as in "please build source and binaries" :). * no-regen: If we rebuild then we might end up with inconsistent sources if these are tracked in different places, and if you pass it the sources then it seems logical to expect them not to be regenerated. * error: This is the safe option of "both options are correct, let's do none :D", of deferring the interface behavior. Even though I changed it to no-regen for now, I'm thinking, though, that the regen behavior is the more correct one. > dpkg-buildpackage --build=any,all -- /path/to/hello_2.10-3.dsc > > Fails to find the .dsc file, as it appears to extract the sources to > hello-2.10 and then expects to find ../hello_2.10-3.dsc Ah, right, this is expected to be a filename not a pathname. (Placing the source elsewhere is not currently feasible, see #657401; I mean I guess dpkg-buildpackage could copy the source but…). I've now added a check, although I'll be reworking it a bit before merging, because it will emit confusing output if you specify «./filename.dsc» as not being in the current directory. :) > All that said ... this seemed to work for me: > > dpkg-buildpackage --build=any,all -- hello_2.10-3.dsc > > So yay, progress! Thanks! Great, thanks! > All of the above cases do not clean up the hello-2.10 extracted from the > .dsc file, so re-running any of the above need to manually clean that or > run from a clean directory or experience various failure modes with the > existing hellp-2.10 directory. I've also added an explicit check, and dpkg-buildpackage now will error out if the directory already exists. I don't think removing a pre-existing directory would be safe (at least w/o an explicit option to do so). But perhaps, as you hinted, removing the source tree (for a successful build) after finishing would indeed be an option, hmm. > So a few little glitches, but overall this seems close to something we > have really wanted for reproducible builds! And just for good measure, > thanks! I force-pushed the reworked code into: https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=pu/dpkg-buildpackage-dsc Thanks, Guillem ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068809: dh-buildinfo: consider deprecating and removing the package
Package: dh-buildinfo Version: 0.11+nmu3 X-Debbugs-Cc: hol...@debian.org Hi, dh-buildinfo much predates the reproducible builds effort and the .buildinfo file and probably laid ground to it. I am now raising the question whether it is time to get rid of dh-buildinfo in Debian. Essentially I am arguing that the use case of dh-buildinfo is now served by dpkg-genbuildinfo and the generated .buildinfo files on every package build. Besides the difference in formatting, the main difference is that dh-buildinfo embeds this information into the binary package rather than next to it (where it can be lost). I argue that all of the uses of dh-buildinfo can now be met with examining .buildinfo files. At the same time, dh-genbuildinfo reduces reproducibility. When cross building a package, we necessarily install different packages from a native build. This difference manifests in the embedded buildinfo files and thus comparing a natively built package with a cross built package needs to ignore the embedded buildinfo file where we would like cross builds to exactly reproduce native builds where possible. As such I am proposing to call dh-buildinfo deprecated, then to actively remove dependencies on it and finally remove it from Debian. If you agree with this vision, please tag this bug confirmed. If you disagree with this vision, please tag it wontfix and explain the added value that I fail to see. Thank you Helmut ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: Please review the draft for March's report
Chris Lamb wrote: > Please review the draft for March's Reproducible Builds report: This has now been published — thanks to all who contributed. If possible, please share the following link: https://reproducible-builds.org/reports/2024-03/ .. and also consider retweeting: https://twitter.com/ReproBuilds/status/1778496263027093713 Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org 💠 ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
* Holger Levsen [2024-04-11 12:54]: > On Thu, Apr 11, 2024 at 11:28:19AM +0100, Chris Lamb wrote: > [...] > > Applied in Git with attribution taken from your email. > [...] > > Fixed as well. And it adds a nice comment displaying the issue. > > awesome, thank you both! The promised cpython issue: https://github.com/python/cpython/issues/117779 And a small follow-up: https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/140 - Fay ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#847805: reprotest: document/support simple reproducibility test with sbuild
On 2016-12-11, Sean Whitton wrote: > 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: >> >> 1) sbuild >> 2) record .deb checksums from .changes file >> 3) sbuild >> 4) compare .deb checksums in new .changes file >> 5) run diffoscope if the checksums differ > > Thanks to #debian-reproducible, this is mostly what I wanted: > > reprotest auto . -- schroot unstable-amd64-sbuild > > This doesn't actually invoke sbuild, but it does perform the builds > inside the schroot I already have set up, and compare the results. > > This is useful, but it would also be good if reprotest could invoke > sbuild(1) itself. That is because sbuild has lots of useful options. > > For example, suppose that foo depends on dh_bar, and I am hacking on > dh_bar in the hope of making foo reproducible. Then I want to build foo > against my local version of dh_bar. With sbuild, I can do this using > --extra-package and --add-depends. reprotest with a pure schroot > backend can't do that kind of thing, so far as I can tell. A while back I did work on a simple wrapper for sbuild that calls reprotest as part of a --finished-build-commands hook: https://salsa.debian.org/reproducible-builds/sbuild-unshare-reprotest It is definitely quite rough around the edges and there are some caveats that limit the functionality, but can do some of what you were looking for. 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
Processing of reprotest_0.7.27_source.changes
reprotest_0.7.27_source.changes uploaded successfully to localhost along with the files: reprotest_0.7.27.dsc reprotest_0.7.27.tar.xz reprotest_0.7.27_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org) ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Bug#1034311: reprotest: make it easier to compare against an existing build (eg from ftp.d.o)
On 2024-03-08, Vagrant Cascadian wrote: > On 2023-04-12, Holger Levsen wrote: >> i guess reprotest maybe should grow an option to do >> --control-build /path/to/packages/ >> --vary=build_path=/use/this/build/path ... >>to make it easier to use reprotest to compare against an existing >> build >>YES >> e.g. there is no way to disable buidl path variations when >> comparing >> against an arbitrary build >>i'm reporting this as a bug to the bts, quoting your words here. >> (ok?) >> reprotest can control it's own builds ... but if i want to use >> reprotest >>against the archive packages or an sbuild >>or pbuilder build package ... it will always have a different >> build path > > Forgot about this bug, but I have since implemented a proof-of-concept > of this: > > > https://salsa.debian.org/reproducible-builds/reprotest/-/commits/wip-specify-build-path?ref_type=heads And merged in 0.7.27 ... which resolves the one specific issue mentioned ... are there any other must-haves we need to consider this bug closed? Better documentation of how to actually do this? :) 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
reprotest_0.7.27_source.changes ACCEPTED into unstable
Thank you for your contribution to Debian. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 11 Apr 2024 15:45:44 -0700 Source: reprotest Architecture: source Version: 0.7.27 Distribution: unstable Urgency: medium Maintainer: Reproducible builds folks Changed-By: Vagrant Cascadian Changes: reprotest (0.7.27) unstable; urgency=medium . * Enable specifying the build path with --vary=build_path.path=/X/Y/Z * Consistently use 398 days for time variation rather than choosing randomly. * Enable specific number of cpus using --vary=num_cpus.cpus=X. * Update signing key with currently active team members. Checksums-Sha1: 40436c8a2fe539ffe62426af444cbe5d7e456a2e 1710 reprotest_0.7.27.dsc c90b345a776c32e3ade6743536943bb9729a3d9e 112544 reprotest_0.7.27.tar.xz 3959e5df4b5ed8a164f95e24aeb41953c93c9f6b 11960 reprotest_0.7.27_amd64.buildinfo Checksums-Sha256: 0c50b28611b7cd833d659537892128d3b95a257b74c3c7bd4a36e0b8b18e6e58 1710 reprotest_0.7.27.dsc b0deaa7690a0c96c667dee9111c9b7d40710b08291e62214197c052268b83f0a 112544 reprotest_0.7.27.tar.xz 5986bf9ed5e2eb4c1e660c75398671323f09c18fb8e313768a872a4c77251aa4 11960 reprotest_0.7.27_amd64.buildinfo Files: b87ac29ef772b5bcda6ceadc99f0ccb0 1710 devel optional reprotest_0.7.27.dsc f862d1b767c0e9fd50d5491356c4d09a 112544 devel optional reprotest_0.7.27.tar.xz e54558933ae8444a317ca80e5b7d0656 11960 devel optional reprotest_0.7.27_amd64.buildinfo -BEGIN PGP SIGNATURE- iJYEARYKAD4WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZhhpsCAcdmFncmFudEBy ZXByb2R1Y2libGUtYnVpbGRzLm9yZwAKCRDcUY/If5cWqlVnAQD8VIHLXLwdr8t0 WM07monojDqCTlq/ij9QDL+ejGuUewEAx61+X0h4IVlMPlEW/7w6/SfUTG9JJQKE gqO99hJm/AQ= =hSoW -END PGP SIGNATURE- pgpYZkk3rPtYK.pgp Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
