Irregular status update about reproducible live-build ISO images
Hello lists, here is the 23th update of the status for reproducible live-build ISO images [1]. Single line summary: 97.7% reproducible live images Reproducible status: * All major desktops build reproducibly with bullseye, bookworm, trixie and sid ... ** ... provided they are built for a second time within the same DAK run (i.e. 6 hours) * All major desktops built reproducibly for the official Debian live images for bookworm (12.5.0) at any later moment ... ** ... except for KDE, which has only 1 issue left in 12.5.0 * Last month a question was raised, whether the distributed sources are sufficient to rebuild the images. The answer is: probably yes, but I haven't tried. The chain is: source code --compiler--> executable files --debian packaging--> .deb archives --live-build--> live images I've focused on the last section of this chain; the installation of the .deb archives into the live images. My activities in February: * Rebuilding all images for 12.5.0 * The KDE image in 12.4.0 had 2 sources of non-reproducibility ** Issue 1: order in the filesystem for vlc, has been worked-around for 12.5.0 [3]. An upstream fix would need sorting of the output of `readdir`, which would be some copy of the code from disorderfs ** Issue 2: unstable sort in install-info, was fixed upstream [4] for trixie and worked-around [5] for the (future) 12.6.0 bookworm release, which is planned for April * The MR for better udeb handling [2] is now merged, the installer for the trixie images uses DHCP again. * Some bug triaging, closing old bug reports * The official weekly live images are now regularly fed to openQA for functionality tests (in addition to the images generated by Jenkins) * Unfinished: support for cross-builds to arm64 in the helper script (including documentation) * Unfinished: pre-release work-around for #1051607 (Calamares installation on UEFI Secure Boot systems fails to boot after installation) Work to be done: * Visit to the MiniDebCamp in Hamburg [6] * See the TODO page [7] With kind regards, Roland Clobus [1] https://wiki.debian.org/ReproducibleInstalls/LiveImages [2] https://salsa.debian.org/live-team/live-build/-/merge_requests/337 [3] https://salsa.debian.org/live-team/live-build/-/merge_requests/338 [4] https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=01b5a4b9c33bef08feae041c221f820a1c76749f [5] https://salsa.debian.org/live-team/live-build/-/merge_requests/339 [6] https://wiki.debian.org/DebianEvents/de/2024/MiniDebCampHamburg [7] https://wiki.debian.org/DebianLive/TODO 97.7%: based on 4 versions x 9 variants + 8 variants OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Two questions about build-path reproducibility in Debian
On 2024-02-15, James Addison via rb-general wrote: > A quick recap: in July 2023, Debian's package build infrastructure > (buildd) intentionally began using a fixed directory path during > package builds (bug #1034424). Previously, some string randomness > existed within each source build directory path. > > I've two questions related to buildpaths - one relevant to the > Salsa-CI team, and the other a RB-team housekeeping question: > > 1. [Salsa] Recently Debian's CI pipeline was reconfigured[1] to > enable more variance in builds. However: I think that change also > (inadvertently?) enabled buildpath variation. Is that useful and/or > aligned with Debian package migration incentives[2] -- or should we > disable that buildpath variance? I think it might be worth disabling build path variations by default in salsa-ci, although making it possible for people to override. > 2. [RB] Housekeeping: we use Debian's bugtracker to record packages > with buildpath-related build problems[3]. Do we want to keep those > bugs open, or should we close them? I think the bugs should remain open, but perhaps downgraded to minor or wishlist? While buildd.debian.org does now use a predictible path, sbuild does not by default and requires slightly tricky manual intervention to get the right path; many people still may perform local builds in their home directory; I am not sure if pbuilder now defaults to matching buildd.debian.org, though it is possible to specify the build path (as seen on tests.reproducible-builds.org!); reprotest still uses randomized build paths, although a WIP branch exists: https://salsa.debian.org/reproducible-builds/reprotest/-/merge_requests/22 There are real-world build path issues, and while it is possible to work around them in various ways, I think they are still issues worth fixing to make it easier to debug other issues, although deprioritizing them makes sense, given buildd.debian.org now normalizes them. live well, vagrant signature.asc Description: PGP signature
Re: reprotest: inadvertent misconfiguration in salsa-ci config
On 2024-02-27, Chris Lamb wrote: >> * Update reprotest to handle a single-disabled-varations-value as a >> special case - treating it as vary and/or emitting a warning. Well, I would broaden this to include an arbitrary number of negating options: --variations=-time,-build_path That seems just as invalid. The one special case I could see is "--variations=-all" where you might want to be normalizing as much as possible. > On whether to magically/transparently fix this, needless to say, it's > considered bad practice to change the behaviour of software that has > already been released — I would, as a rule, subscribe to that idea. > However, we should bear in mind that this idea revolves around what > users are *expecting*, not necessarily what the software actually > does. > > I say that because I hazard that all 400 usages are indeed expecting > that `--variations=-foo` functions the same as `--variations=all,-foo` > (or `--vary=-foo`), and so this proposed change would merely be > modifying reprotest to reflect their existing expectations. It would > not therefore be a violation of the "don't break existing > functionality" dictum. > > (Saying that, the addition of a warning that we are doing so would > definitely not go amiss.) Hrm. Less inclined toward this approach; expectations can shift with time and context and culture and whatnot. That said, I agree the current behavior is confusing, and we should change something explicitly, rather than implicitly... >> * Treat removal of a variance factor from an already-empty-context >> as an error. > > I'm also tempted by this as well. :) How would this be experienced by > most DDs? Would their new pushes to Salsa now suddenly fail in the > reprotest job of the pipeline? If so, that's not too awful, given that > the prominent error message would presumably let them know precisely > how to fix it. I would much prefer an error message if we can correctly identify this. Some possible expected behaviors to consider treating as invalid, and issue an error: --variations=-build_path --variations=-time,-build_path This almost makes me want to entirely deprecate --variations, and switch to recommending "--vary=-all,+whatever" or "--vary=-all --vary=+whatever" instead of ever using --variations. I'm not sure the variations syntax enables much that cannot be more unambiguously expressed with --vary. That said, the reprotest code is a bit hairy, and I am not sure what sort of refactoring will be needed to make this possible. In particular, how --auto-build is implemented, where it systematically tests each variation one at a time. That said, Refactoring might be needed regardless. :) live well, vagrant signature.asc Description: PGP signature
Re: reprotest: inadvertent misconfiguration in salsa-ci config
Hi James, Great post, thank you. So, I'm in two minds re. the way forward: > * Update reprotest to handle a single-disabled-varations-value as a > special case - treating it as vary and/or emitting a warning. On whether to magically/transparently fix this, needless to say, it's considered bad practice to change the behaviour of software that has already been released — I would, as a rule, subscribe to that idea. However, we should bear in mind that this idea revolves around what users are *expecting*, not necessarily what the software actually does. I say that because I hazard that all 400 usages are indeed expecting that `--variations=-foo` functions the same as `--variations=all,-foo` (or `--vary=-foo`), and so this proposed change would merely be modifying reprotest to reflect their existing expectations. It would not therefore be a violation of the "don't break existing functionality" dictum. (Saying that, the addition of a warning that we are doing so would definitely not go amiss.) > * Treat removal of a variance factor from an already-empty-context > as an error. I'm also tempted by this as well. :) How would this be experienced by most DDs? Would their new pushes to Salsa now suddenly fail in the reprotest job of the pipeline? If so, that's not too awful, given that the prominent error message would presumably let them know precisely how to fix it. Best wishes, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org 💠 ⬊ ⬋ o
