On Thu, Mar 20, 2025 at 7:14 AM Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > > On Thu, Mar 20, 2025 at 06:36:09AM -0400, Neal Gompa wrote: > > On Thu, Mar 20, 2025 at 6:33 AM Zbigniew Jędrzejewski-Szmek > > <zbys...@in.waw.pl> wrote: > > > > > > On Thu, Mar 20, 2025 at 06:23:53AM -0400, Neal Gompa wrote: > > > > On Thu, Mar 20, 2025 at 4:40 AM Zbigniew Jędrzejewski-Szmek > > > > <zbys...@in.waw.pl> wrote: > > > > > > > > > > On Thu, Mar 20, 2025 at 08:04:57AM +0100, Miroslav Suchý wrote: > > > > > > Dne 19. 03. 25 v 7:48 odp. Aoife Moloney via devel-announce > > > > > > napsal(a): > > > > > > > == Scope == > > > > > > > * Proposal owners: > > > > > > > ** Package [https://github.com/keszybz/fedora-repro-build > > > > > > > fedora-repro-build] to allow local rebuilds of historical koji > > > > > > > builds > > > > > > > > > > > > This > > > > > > > > > > > > https://rpm-software-management.github.io/mock/feature-hermetic-builds > > > > > > > > > > Yes, thanks for the link. I think this didn't exist when I started > > > > > working > > > > > on my script to do rebuilds, so I just gather the rpms reported by > > > > > koji > > > > > to have been used for the original build and call 'createrepo_c' on > > > > > the > > > > > directory and point mock to that. This works fine… But having support > > > > > for using a lockfile natively in mock is nice. > > > > > > > > > > Though, the process described in that link seems incomplete. > > > > > > # we want to build this package > > > > > > srpm=your-package.src.rpm > > > > > Where does the $srpm come from? The process of creating the srpm from > > > > > dist-git involves running the spec, i.e. already calling "untrusted" > > > > > code. How is that part handled? > > > > > > > > > > > > > It's also not *really* hermetic either. Hermetic builds require true > > > > isolation and there is no Mock backend that provides that right now. > > > > All it does is let you pre-download the build environment and replay > > > > it multiple times. Koji can do that too, and yet nobody calls it > > > > hermetic either because chroots/containers aren't good enough for that. > > > > > > OK, so what do you mean by "true isolation" then? > > > I'd say that once the build in a container with no network access, > > > that is good enough for me :) > > > > > > > A microvm, basically. Running as a VM prevents host characteristics > > from leaking into the build environment and messing things up. It also > > makes it so some test suites for packages will work correctly without > > breaking the builder. > > Meh. It's _a_ solution, but I don't think it's a great solution, > because I think the problem cannot be really solved in that way. > > If the package is taking into account stray characteristics of the > host, then this is a problem in the package build, something to be > fixed there. You can try to make the build environment more uniform, > but that only goes so far. The package can always start depending on > some little detail (number of CPUs, file system, µarch, amount of > memory, the list of devices, etc, etc, the possibilities are endless), > and then this pseudorandom characteristic would become locked and the > microvm cannot be changed. This is a race to the bottom that we cannot > win. > > Also, if "tests suite for packages […] break the builder" then this > is a problem to fix in the container environment. >
Well, the shared kernel puts a lot of limits on things. You can't fix anything as long as you can't make a whole new devfs for each build environment. And it screws up both package builds and image builds in weird ways. For example, two builds of fish cannot run at the same time in Koji because the test suite will lock up and fail due to shared devfs devices from the host into the container environment. And neither kiwi nor image-builder are able to produce disk images because nspawn doesn't let us do the right thing for loop devices. And the list goes on and on. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
