Hi Aaron, Quoting Aaron Rainbolt (2025-06-12 21:31:02) > Some time ago, I did a lot of work on getting a U-Boot + grub-efi-arm64 > boot flow to work on the Raspberry Pi 4 with Debian. I was able to get > a proof-of-concept implementation to work correctly, and was interested > in upstreaming my work to Debian if it was welcome. To that end, I > attempted to reach the team taking care of Raspberry Pi support > maintenance in Debian in a few different ways. [1] [2] [3] [4] So far I > haven't gotten much of a response on any platform. > > Obviously, I would like to see this feature in upstream Debian at some > point, which is why I did the work to see if it could be done. I'd like > to send patches to implement the feature. However, since I haven't > gotten any response (no explicit "this would be good, send a patch and > let's see what you have", no criticism or discussion, etc.), I don't > know how to proceed. I don't want to submit a patch and have it ignored > similar to the research and feature requests up to now. I also don't > want to just wait indefinitely before implementing patches. > > I know that for bugfixes, the NMU process can be used to work around an > unresponsive maintainer, while still giving the maintainer time to take > a look and fix things if they'd like to. But for this kind of a feature > addition, I don't know if this is the right approach. As the Debian > Developer's Reference [5] says, "Using NMUs to make changes that are > likely to be non-consensual is discouraged." > > What's a good way forward here? Am I trying to do something that > fundamentally shouldn't be done, or is there a good way for me to > contribute this feature? > > [1] https://lists.debian.org/debian-arm/2025/04/msg00012.html > [2] https://salsa.debian.org/raspi-team/image-specs/-/issues/78 > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102607 > [4] Also reached out via IRC, didn't get much of a response except one > person let me know about the existence of another UEFI > implementation for Raspberry Pi devices. > [5] > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-and-how-to-do-an-nmu
thank you for your work! I see that the mails, the issue and the bug report you opened did not get much of a reply and I agree that that's not ideal. On the other hand, you also did not send a patch. I realize that you linked instructions you created to implement what you propose but you actually didn't implement it, no? So maybe (and i can only guess) your bugs and issues did not result in much of a reply because even though you showed a proof-of-concept, it still requires somebody to actually do the work. And if that's the case, your issues are just asking others to carry out that work. I realize that this is frustrating for you but the maintainers are volunteers just as you, so maybe they have not yet found time to look into your instructions, implement and test your work? I suppose (but understand if you are not motivated enough to do this after being "ignored" like this) that you would get more of a reply if you actually can show a patch which implements your work on top of the Debian packaging. Incidentally, I just enabled EFI booting for the MNT Reform images I maintain using systemd-boot. The MNT Reform also uses u-boot by default but the RK3588 supports EDK2 and we are currently performing experiments with it. Maybe we switch away from u-boot to some efi-based solution in the future. Thanks! cheers, josch
signature.asc
Description: signature
