Hi David, On 4/13/22 21:27, David Cantrell wrote: > On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote: >> Hi, >> >> On 4/13/22 18:07, David Cantrell wrote: >>> On Wed, Apr 13, 2022 at 10:39:23AM -0500, Michael Catanzaro wrote: >>>> On Wed, Apr 13 2022 at 10:54:01 AM -0400, David Cantrell >>>> <dcantrell@xxxxxxxxxx> wrote: >>>>> The core issue still comes down to having resources to continue >>>>> maintaining >>>>> BIOS boot support in Fedora and so far no one has come forward to work >>>>> on >>>>> that. >>>> >>>> It's not true, although you can be forgiven for missing it in such a massive >>>> thread. Hans proposed to start a BIOS SIG to handle this. This seems like a >>>> very credible proposal. >>> >>> Ah, yes. I do remember the post from Hans, but thought he was more outlining >>> how a Legacy BIOS SIG could work and what would need to happen rather than >>> volunteering to set one up and do that. But I went back and reread that post >>> and yes, he did volunteer to do just that. >> >> Correct. >> >>> If a video call happens to discuss this feature proposal, ensure Hans can >>> attend. >> >> FWIW, ATM I think everything which can be said about >> this has been said and I'm not sure if having a video >> call about this will add anything new. > > Agreed. > >> As for setting up the SIG if necessary, my plan is to >> try to keep the SIG lite weight on the process side >> and focus on the practical things. >> >> What I envision for the SIG is: >> >> 1. I'm not sure if it is possible to setup group ownership >> of pkgs in pagure? So to keep things simple the few packages which >> are only necessary for BIOS boot can be handed over to me and then >> I'll just add other people willing to help out as co-maintainers. >> >> 2. Setup a mailinglist for this and have that in bugzilla + PR >> Cc for all the relevant packages. >> >> 3. Have people from the SIG regularly test Fedora N and >> Fedora N + 1 (after branching) on machines which only support >> BIOS booting and file bugs (if any) + report the results to >> the mailinglist. >> >> 4. Have people from the SIG try to regularly do bugzilla >> triage of relevant packages. >> >> And I would also like to have a discussion about splitting >> the BIOS boot grub bits out into a separate src.rpm >> (using the same Source0 as the main grub) so that this can >> be build by the SIG without needing help from the bootloader >> team (the main grub package can only be built by a few people >> because of secureboot signing). The idea is to avoiding >> bottlenecking on the bootloader team when some BIOS boot bugs >> in grub need to be fixed, quoting from my original email about >> this: >> >> """ >> I've been thinking about how this could be done for grub; also >> because of the issue that the EFI builds of grub need to be >> signed with Fedora's secure boot keys, which means only a few >> people can do grub2 builds atm. >> >> One option which I think we should consider is sticking with >> a single downstream git fork (until we have managed to get >> everything we need upstream), so stick with: >> >> https://github.com/rhboot/grub2/ >> >> As the Source0 provider for the packages and then next to: >> >> https://src.fedoraproject.org/rpms/grub2 >> >> Add a: >> >> https://src.fedoraproject.org/rpms/grub2-bios >> >> And moving the build of all sub-packages which are >> only necessary for BIOS support to the second src.rpm. >> >> This way the Legacy BIOS SIG could maintain >> the grub2-bios src.rpm (and binary pkgs it builds). >> The SIG _must_ then of course still submit pull-reqs to: >> https://github.com/rhboot/grub2/ for any changes. >> >> But in case of e.g. a beta blocking BIOS only bug they >> could solve that with a patch in the src.rpm and kickof >> a build right away without blocking on the bootloader >> team and thus without causing a spike in >> work-pressure/load for the bootloader team. >> >> And then once the pull-req is merged (possibly >> a revised version of it) the next build of >> the grub2-bios src.rpm can pull in the new Source0 >> and drop its local changes (IOW grub2-bios _must_ >> not become a separate fork). >> """ > > OK, given this proposal, I'd like the original change proposal amended to > essentially say "transfer legacy BIOS boot support to newly formed Legacy BIOS > SIG" or something like that. The logistics at that point can be sorted out as > the SIG sees fit. I'd like to see the original proposal advance forward and > this gives a plan for the legacy BIOS piece. TBH I'm not sure if that is the direction in which the proposal owner (Robbie) wants to go, Robbie ? > Can you followup with the proposal owners to make that amendment? I've send Robbie an offlist email asking him to weigh in here. Regards, Hans _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
