On Thu, Mar 20, 2025 at 08:18:15AM +0000, Daniel P. Berrangé wrote: > On Wed, Mar 19, 2025 at 06:48:21PM +0000, Aoife Moloney via devel-announce > wrote: > > > > == Scope == > > * Proposal owners: > > ** Package [https://github.com/keszybz/fedora-repro-build > > fedora-repro-build] to allow local rebuilds of historical koji builds > > ** Make [https://github.com/kpcyrd/rebuilderd/ rebuilderd] work with > > Fedora packages and repos > > What is rebuilderd using to actually perform the builds ? Can > it just be using the regular koji, so that maintainers don't > have to learn yet another build tool.
Currently it's using my script to do rebuilds (https://github.com/keszybz/fedora-repro-build/blob/main/koji_rebuild.py). It queries koji for the buildroot contents of the (historic) build, downloads all listed rpms into a temporary directory, calls createrepo_c on this directory, and calls mock with that directory as the only repo. Using koji to do the build is an interesting idea. koji has createBuildTarget(name, build_tag, dest_tag) and build(src, target), where the build_tag contents specify the rpms that are visible. It also get getBuildrootListing(id), which returns a list of nvra's. What we'd actually want is to connect the two, i.e. do a build using the specified buildroot id. Maybe koji could be taught to do that for us. That said, as I wrote in a reply about copr, we also want our rebuilds to be as independent as possible. So using koji to do rebuilds would be nice for test packager rebuilds, we'd still want to have rebuilderd doing the rebuilds _not_ through koji. > > ** Stand up a public rebuilderd instance for Fedora rawhide > > ** Adjust `add-determinism` to handle new cases, if widespread issues > > are found and it's possible to handle them in the cleanup phase > > ** Open bugs against packages when irreproducibilities are detected, > > initially as a manual process > > Can we have this run as part of the post-build gating tests, so > that we have a single place to look for test results, along with > the option for maintainers to waive reproducibility issues ? > > I'm pretty unethusiastic about dealing with yet another standalone > web service providing post-build testing. Yes, I understand this. The same question was asked previously in the other thread and I wrote [1] the following: > Theoretically — yes. In practice — no such plans at this point. Right > now, we expect some percentage of the rebuilds to fail, so it’d be too > early to gate on this. After some time, once those bugs have been > fixed, theoretically we try could try. But this always means a second > build, which can be quite slow. (That said, the rebuilds can be done > without tests, which are often the slowest part.) > > The problem is that if we just rebuild the package a second time in > the same build environment, we are not testing much. We really want to > build it on a different variant of the same architecture, with a > different file system, on a different date, etc. But I don’t think we > want to set up two variants of our build environment internally. > > Dunno, this could be something to consider in the future, depending on > how this initial stage goes. [1] https://discussion.fedoraproject.org/t/f43-change-proposal-package-builds-are-expected-to-be-reproducible-system-wide/147320/7 Zbyszek -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
