On Sun, Jun 13, 2021 at 01:42:55AM +0100, Pete Batard wrote: > >Granted we also should have logged a bug for that issue as soon as we picked >it up, so we have to share part of the blame on this one. But the delays in >processing #985956, even though we tried to bring attention over and over >again to the fact that this very negatively affected one of the rare UEFI >installation of Bullseye on ARM64, on what has to be the current most >widespread system for that arch, was a bit concerning. Especially, it is not >the first time we've seen what I would qualify as extended delays in trying >to get showstopping UEFI patches looked into. As a matter of fact, I >eventually gave up trying to get the necessary Pi4 network patches backported >into Debian 10 (#950578), because even though we did submit a working patch >from the get go, it took 3 months (!) to actually get someone on the Debian >side to look into it, only to then tell us to just go re-do that patch, which >is not what I would qualify as a viable mode of operation.
So AFAICS what you're seeing is a severe lack of volunteer time to do some things in Debian. I've been one of the more active Debian arm porters in recent years, but I've moved on to other things and been swamped with things like shim and grub security work in my "spare" time for the last year or so. I'm also busy with a new job that (so far) has very little to do with the Arm world, so I've not been able to spend work time to pick up on some of these issues where prveiously I might have done. While this stuff is important for you and others, I'm afraid that doesn't necessarily make it top priority for volunteers already overloaded with other projects. That's not a lack of will to help, it's simple logistics. :-( We need to get more people involved to help, and that's often a struggle. >So, at the risk of being controversial, it doesn't seem to me like everybody >in the Debian world has been that willing to embrace UEFI. Or if they do, >then not everybody appears to have recognized the importance of being able to >provide Debian in UEFI mode on what has to account for the most popular ARM64 >platform. And I could point to further evidence of this when I also brought >the idea on this list that, maybe, it was time for Debian to start looking >into moving away from using good old uboot or similar for distributing >special installable images for platforms like the Pi not that we have a full >blown UEFI, as this very idea seemed to irk a few people (which, to be fair, >may not have been directly affiliated with Debian). As a Debian UEFI team person, I'm *really* happy that finally we have an affordable platform that might work sensibly like this. As Marcin says: if anything, our arm64 port has expected UEFI from the get-go. There are still remnants of this assumption in d-i if you go looking, where we don't work well enough on other platforms. However, one of our biggest issues has been the ridiculously, *appallingly* over-diverse Arm ecosystem with vendors continuing to push special-snowflake SBCs that all need special consideration just to do the simple basic things. It's batshit insane. On reflection, that mess was one of the reasons why I changed jobs. It was causing enough stress that I had to get away from it. >But regardless of this, my remark was aimed more at the topic at hand which >should be what feedback Debian may want to convey to the ARM community, and >especially the ARM platform manufacturers, and therefore goes beyond than >just the Raspberry Pi platform. > >In short, I would reiterate that, in light of the headaches caused by all the >other approaches, and especially a requirement that still seems to boil down >to providing custom images (in part because of custom boot methods as well as >proprietary blobs, which I don't realistically see as going away) the >feedback Debian should provide to ARM vendors is that, if the latter want >better cooperation with Linux distros, then they should put the onus on >releasing a working UEFI firmware for their platform, especially as it's been >demonstrated that, even for an SBC as quirky and as ill-suited for it as the >Raspberry Pi (and that was part of the point of the whole exercise), it is >not that difficult to achieve. +1000 -- Steve McIntyre, Cambridge, UK. st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead