On Fri, 13 Jun 2025 10:18:59 +0200 Johannes Schauer Marin Rodrigues <jo...@debian.org> wrote:
> 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 don't mean this in a mean way, but I wish you had spent the time to read the initial email all the way through or read through any of the first three links before suggesting this. I said no fewer than four times that I *want* to send a patch quite badly, and was waiting for there to be any kind of discussion, ACK, NACK, or sharing of concerns from the maintainer or anyone else with authority in the Raspberry Pi area of things. It's generally a universal rule in open-source that before implementing a large change in an open-source project, you discuss it with maintainers first, otherwise you end up with code that can't be used. I was unable to get that discussion started on my first attempt, thus why I emailed here. > 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. I'm more than motivated enough, and really if the first patch had to be discarded for whatever reasons and completely reworked, I'd be OK with that too. What I don't want is to send a patch and have it go as ignored as my attempts at reaching out to the maintainer, so if I'm going to implement it, I want to make sure there's a way forward to actually get it reviewed and merged (assuming of course the thing I'm trying to accomplish isn't fundamentally unacceptable to the reviewer(s)). > 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. That's neat! I like U-Boot in particular personally, but EDK2 sounds useful too. I haven't experimented with EDK2 since my workplace isn't interested in it, they want U-Boot to be used. (It also happens to be already used by Fedora and I *think* Ubuntu, so it's been tested and verified to work for this sort of thing.) Best regards, Aaron > Thanks! > > cheers, josch
pgpFf_AqwixcS.pgp
Description: OpenPGP digital signature
