On Wed, 2022-04-27 at 11:48 -0400, Neal Gompa wrote: > On Wed, Apr 27, 2022 at 11:46 AM Luca Boccassi <bluca@xxxxxxxxxx> wrote: > > > > On Wed, 2022-04-27 at 11:26 -0400, Neal Gompa wrote: > > > On Wed, Apr 27, 2022 at 11:13 AM Zbigniew Jędrzejewski-Szmek > > > <zbyszek@xxxxxxxxx> wrote: > > > > > > > > On Wed, Apr 27, 2022 at 09:31:10AM -0400, Neal Gompa wrote: > > > > > On Wed, Apr 27, 2022 at 7:41 AM Lennart Poettering > > > > > > > Realistically, I think if we want to make movement on making > > > > > > > systemd-boot fully supported in Fedora, the systemd-boot boot manager > > > > > > > code itself should be split out into its own repository with its own > > > > > > > release cadence, while bootctl(1) and related infrastructure remains > > > > > > > in the systemd source tree and evolves to be able to manage arbitrary > > > > > > > BLS-conformant boot managers. > > > > > > > > > > > > Why though? I don't follow? as long as we provide you with a tarball > > > > > > you can build your stuff from it shouldn't really matter if there's > > > > > > more stuff in it you are not immediately interested in. > > > > > > > > > > > > I mean, if you like I could do a "cp systemd-251.tar.gz > > > > > > systemd-boot-251.tar.gz" for you if you want two tarballs instead of > > > > > > one, but I don't see the point? > > > > > > > > > > > > > > > > As I illustrated in another email[5], decoupling the lifecycle of the > > > > > EFI boot manager code from the rest of systemd would be ideal to not > > > > > make the constraints around building sd-boot with secure boot support > > > > > painful. > > > > > > > > > > [5]: https://lists.freedesktop.org/archives/systemd-devel/2022-April/047801.html > > > > > > > > Apart from the constraint who can build official packages, is there > > > > anything else? If it's just that, that doesn't seem onerous. > > > > > > It also means Fedora CI, pull requests from contributors, and > > > releng auto-rebuilds will no longer work. Maintainers basically > > > sign-on to do all of those things manually and have to be responsive > > > for doing it. You will get FTBFS tickets every cycle because of it, > > > for example. > > > > > > Koji doesn't conceptually know the difference because there is no > > > namespacing for builders, only who is approved to build. > > > > > > (In contrast, in the Open Build Service like what Luca Boccassi was > > > talking about, packagers don't control the builds at all, so OBS only > > > has to trust itself to sign it, so everything works properly.) > > > > You could simply have a separate source RPM, no? That should be pretty > > simple, and limit the impact on team maintenance of the main source > > package? > > > > Yep. I was hoping we could have the upstream sources split too, but if > we can't, then that's definitely the preferred way to go. With this PR https://github.com/systemd/systemd/pull/23204 you'll be able to do this, which takes a fraction of a second to complete, as opposed to the full build: $ ninja src/boot/efi/linuxx64.efi.stub [21/21] Generating src/boot/efi/linuxx64.efi.stub with a custom command $ ninja src/boot/efi/systemd-bootx64.efi [10/10] Generating src/boot/efi/systemd-bootx64.efi with a custom command $ DESTDIR=/tmp/foo meson install --tags sd-boot,sd-stub --no-rebuild Installing src/boot/efi/systemd-bootx64.efi to /tmp/foo/usr/lib/systemd/boot/efi Installing src/boot/efi/linuxx64.elf.stub to /tmp/foo/usr/lib/systemd/boot/efi Installing src/boot/efi/linuxx64.efi.stub to /tmp/foo/usr/lib/systemd/boot/efi It should make it easier and more manageable I hope? > > (OBS is awesome :-) ) > > > > Indeed. I run an OBS instance for my workplace, and I've contributed > to OBS over the years. It has its warts, but I think it got more > right than wrong in the philosophy of a build system. Same at $previous_job, and miss it dearly at $current_job. The way they've integrated signing EFI binaries for packages is quite nice too - I contributed some bits and pieces to enable EFI binary signing for Debian builds too, as it was supported only for RPM before, PoC with shim + grub + kernel = secure bootable Debian image: https://build.opensuse.org/project/show/home:bluca:debian_secure_boot -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part
