| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 26 |
| Nodes: | 6 (1 / 5) |
| Uptime: | 64:49:43 |
| Calls: | 482 |
| Calls today: | 1 |
| Files: | 1,072 |
| Messages: | 96,344 |
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?
On Thu, Jun 12, 2025 at 02:31:02PM -0500, Aaron Rainbolt wrote:
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?
Salvage or hijack, basically.
On Thursday, June 12, 2025 1:36:50 PM Mountain Standard Time Andrey Rakhmatullin wrote:
On Thu, Jun 12, 2025 at 02:31:02PM -0500, Aaron Rainbolt wrote:
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?
Salvage or hijack, basically.
I would recommend you first create a bug and an associated MR. Then,
if you get no response (which is obviously different than a NACK),
you can choose if you would like to salvage the package or if you
would like to leave the MR there for someone else who to to come
along and salvage the package.
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.
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
I would recommend you first create a bug and an associated MR. Then, if you get no response (which is obviously different than a NACK), you can choose if
you would like to salvage the package or if you would like to leave the MR there for someone else who to to come along and salvage the package.
I would recommend you first create a bug and an associated MR. Then, if you get no response (which is obviously different than a NACK), you can choose if you would like to salvage the package or if you would like to leave the MR there for someone else who to to come along and salvage the package.
https://tracker.debian.org/pkg/raspi-firmware doesnt give any indication
to me that the package is ripe for salvaging it. Hijacking it you could,
but you should not.
Please don´t give bad advice on -devel.
(The bug in question is wishlist and merely asks for a new way to boot raspis giving some hints how this could be implemented but does not contain
a patch, but rather explains how there are two unsolved problems with that suggestion and finally the bug is from end of April 2025 when the freeze
was already quite far advanced, so no wonder there was no reply.)
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?
With all of the above in mind, how likely would it be that U-Boot +
GRUB support for the Raspberry Pi could be upstreamed into Debian,
perhaps even as the default boot flow for the Raspberry Pi 4? We'd be interested in helping out in this regard if this is something others
here would be interested in having.
I would like to suggest (and if acceptable, contribute) the following
two features: [...]
Is this a feature for which you would welcome a merge request here,
either as an option or even as the default?
On Thu, Jun 12, 2025 at 02:42:33PM -0700, Soren Stoutner wrote:
I would recommend you first create a bug and an associated MR.
Then, if you get no response (which is obviously different than a
NACK), you can choose if you would like to salvage the package or
if you would like to leave the MR there for someone else who to to
come along and salvage the package.
https://tracker.debian.org/pkg/raspi-firmware doesnt give any
indication to me that the package is ripe for salvaging it. Hijacking
it you could, but you should not.
Please don´t give bad advice on -devel.
(The bug in question is wishlist and merely asks for a new way to
boot raspis giving some hints how this could be implemented but does
not contain a patch, but rather explains how there are two unsolved
problems with that suggestion
and finally the bug is from end of April 2025 when the freeze was
already quite far advanced, so no wonder there was no reply.)
I forgot another important reason why suggesting to salvage was a
really bad advice here: there was only one single mail to the bug,
not even just two, but just one. So it´s really premature to suggest anything except please mail the bug again, probably with more info.
On Thu, 12 Jun 2025 14:31:02 -0500, Aaron Rainbolt
<arraybolt3@ubuntu.com> wrote:
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.
If you had written that two weeks ago I would have saved myself a few
days of work. I spent some time with u-boot on the Raspberry Pi 4 and
am just in the middle of preparing a blog post.
Did you publish your work? Would you mind linking that publication on
the Debian Wiki Raspberry Pi 4 page? I believe that page already has a
place that says that booting grub through u-boot is possible. That
would be the right place to publish your work. You don't need any team
to cooperate to write about your results there.
Does your solution mean that the regular Debian ARM64 installer just
works on the Raspi?
Does the resulting system enumerate the hardware via ACPI or is
there a Device Tree?
How about having accelerated Graphics?
What did you do to keep the raspi-firmware package from messing
around with /boot/firmware?
Thanks for caring about Debian on the Raspberry Pi!
Greetings
Marc
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
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.)
Hi Aaron,
Quoting Aaron Rainbolt (2025-06-13 15:51:50)
thank you for your work! I see that the mails, the issue and theI don't mean this in a mean way, but I wish you had spent the time
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?
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.
you are right. I apologize, I should've paid more attention when
reading your messages. I think you picked the correct approach and I
would like to retract the part from my last mail where I implied that
you would not be willing to do the work. I'm sorry for the noise.
I suppose (but understand if you are not motivated enough to doI'm more than motivated enough, and really if the first patch had
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.
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)).
I think your approach is sound. Thank you for offering to contribute
and thank you for sticking around instead of giving up.
Incidentally, I just enabled EFI booting for the MNT ReformThat's neat! I like U-Boot in particular personally, but EDK2
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.
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.)
Thank you for your work and sorry again for my accusation in my
earlier mail.
cheers, josch