Hi Didier & Ben,
I hope all is well.
I wanted to check in with you guys, as with the new 2024 platforms
coming out there are some updates to linux-firmware - for CPU, GPU,
Wifi, Bluetooth, etc devices
I checked and it looked like firmware-nonfree and it hadn't been
updated since last year - and I wondered if that is something I can
help with? I'd like to make sure the Debian experience on this years platforms is good out-of-the-box.
Let me know if that would be helpful, and any pointers on how best to contribute and be useful
Thanks
Mark
PS - in case anyone notices, I've mothballed my old
markpearson@lenovo.com address because the Lenovo outlook servers there became horribly unusable. I am using my personal domain for open source collaboration instead.
I still have access to that address (if anybody wants to check I am who
I say I am) and am still employed at Lenovo (if that makes any
difference to anything)
Hi Didier & Ben,
I hope all is well.
I wanted to check in with you guys, as with the new 2024 platforms coming
out there are some updates to linux-firmware - for CPU, GPU, Wifi,
Bluetooth, etc devices
I checked and it looked like firmware-nonfree and it hadn't been updated since last year - and I wondered if that is something I can help with? I'd like to make sure the Debian experience on this years platforms is good out-of-the-box.
Let me know if that would be helpful, and any pointers on how best to contribute and be useful
Thanks
Mark
PS - in case anyone notices, I've mothballed my old markpearson@lenovo.com address because the Lenovo outlook servers there became horribly unusable.
I am using my personal domain for open source collaboration instead. I
still have access to that address (if anybody wants to check I am who I say
I am) and am still employed at Lenovo (if that makes any difference to anything)
What I did back then to try to help getting the firmware package in better shape was to dive in the (complex) packaging and try to produce "ready-to- merge" merge-requests for new upstream releases, fixes, etc, then pinging
Ben at (what I considered) reasonable intervals. I see that Diederik
(CC'ed) has started to do the same for recent versions.
The package is complex and a mined land of legal concerns,
the upstream repo needs repacking,
and the (upstream & debian/) repositories are split;
I have not found this a very pleasant experience, sadly.
And again; no-one to blame here: there _is_ tooling to help, and immense
work has been put towards making this manageable! I'm merely saying it's not a matter of running "debian/rules get-new-upstream" at all.
Hello there Mark,
thanks for your email, and for the followup ping; weeks are well-filled with $job, baby and other involvements.
Regarding firmware-nonfree updates, I have related my last-years' experience on d-devel: https://lists.debian.org/msgid-search/2390124.3VsfAaAtOV@turnagra
I insist: I am absolutely not implying that Ben is doing anything wrong; I just observed that he was mostly alone in a bottleneck position for that package.
What I did back then to try to help getting the firmware package in better shape was to dive in the (complex) packaging and try to produce "ready-to- merge" merge-requests for new upstream releases, fixes, etc, then pinging Ben at (what I considered) reasonable intervals. I see that Diederik (CC'ed) has started to do the same for recent versions.
The package is complex and a mined land of legal concerns, the upstream repo needs repacking, and the (upstream & debian/) repositories are split; I have not found this a very pleasant experience, sadly. And again; no-one to blame here: there _is_ tooling to help, and immense work has been put towards making
this manageable! I'm merely saying it's not a matter of running "debian/rules get-new-upstream" at all.
From where I sit (that is: I only modestly contributed in the past, and cannot
commit to much these days), there are two angles to address:
A) lift the bottleneck: there needs to be more Debian Developers confident to comment and merge MRs, and then upload.
B) regular commitment: I feel it would be easier to get regular updates merged, rather than doing the huge batch shortly before release; that would also appease the tensions that many probably feel when they get new hardware but no available package.
As to how I can get involved in any of the above; I can't reasonably add this to my plate these days (and would rather _not do_, than commit to do and fail).
But I wonder if some financial sponsorship (if Lenovo and others would be open
to something like that) could help, via Freexian for example (disclaimer: not for me to do it; I'm not a Freexian person). I'd be concerned that this would only solve B above though. It would feel like a 1-2 hours job / week.
I hope the above helps you navigate that question, and that it helps the situation in general.
On Tuesday, 7 May 2024 08:25:23 CEST Didier 'OdyX' Raboud wrote:
What I did back then to try to help getting the firmware package in better >> shape was to dive in the (complex) packaging and try to produce "ready-to- >> merge" merge-requests for new upstream releases, fixes, etc, then pinging
Ben at (what I considered) reasonable intervals. I see that Diederik
(CC'ed) has started to do the same for recent versions.
What I did was indeed my effort to get things into better shape with the hope/
goal that it would be easier to do going forward. Which in turn hopefully means that it would be done more regularly which would not make it a monumental task ... which no-one is looking forward to do or has the capacity (time/motivation/etc) to do.
The package is complex and a mined land of legal concerns,
It was a HUGE amount of work, partly because I wanted to get things into what I consider a better shape. Another part which made it *look* complex, were inconsistencies. In one of my commits I determined in which sequence the control fields were going to get placed and then fixed all the config files to
conform to that sequence. I also ordered the entries alphabetically.
I haven't documented it (yet), but I followed a different procedure
then 'the
official one', which I think makes it easier and better ... lowering
the barrier
for future contributions/MRs.
It was basically the following:
1) Have the upstream repo locally and checkout the next tag/release and open
that with gitk
2) Start a new branch in your local Debian firmware-nonfree repo
3) Go through each commit and decide what to do with it
- Upstream merge commit: ignore it
- Upstream working on their own infra: ignore it. Unless it has an effect on
(future) Debian packaging, then add it to d/changelog. And use the
secondary commit message to properly document it.
- Updated version of firmware files: if it has a(n explicit) version number,
update the version in the appropriate ``defines`` file.
- New links (documented in WHENCE): Add that entry to the ``files:`` section
of the Debian ``defines`` file.
- New files: Add an entry to the `files:` section and add a Stanza for it with
its 'ID'/Name, description and if available the version number
- Check whether d/copyright covers any new files and if it doesn't expand the
'regex' so that it does if the license is already known. Otherwise add an
entry and the license text to d/copyright*
With updated versions or new links or new files, add an entry to d/changelog which is mostly or fully upstream's primary commit message, prepended by the Debian package name. This way there's an almost 1-on-1 match between the Debian and upstream's commit (message). This should also make reviews easier.
I ordered the entries by Debian package name, so that if someone only has AMD graphics firmware, it doesn't have to read the full changelog, only the part which is about amd-graphics. Upstream's git commit log sequence is rather random, which isn't useful or helpful to our users (IMO ofc)
*) I did improve d/copyright too, but not fully. All the license texts have been moved to the bottom, but I didn't fix the sequencing of all the stanzas.
the upstream repo needs repacking,
Upstream now also produces a deb package per tag/release, but that's 350MB in size ... and growing. And it includes firmware which isn't DFSG compliant and therefor we shouldn't ship or f.e. can only be shipped as part of the kernel, so we can't distribute them.
and the (upstream & debian/) repositories are split;
I think the split is very useful, especially for our users. Some users only need one or a few small firmware files. Not having to download >350MB for that
for every upstream/Debian release/version is quite useful. Not everyone has unmetered GbE internet connection ... or wants to waste 300+MB for files for which they have no need/use.
I have not found this a very pleasant experience, sadly.
I didn't find it pleasant either, but I hope/expect that with my updates and restructuring it shouldn't be that bad either.
When things are kept up-to-date it's quite doable, but when you have to work through months of 'backlog' the 'fun' quickly diminishes.
And again; no-one to blame here: there _is_ tooling to help, and immense
work has been put towards making this manageable! I'm merely saying it's not >> a matter of running "debian/rules get-new-upstream" at all.
The tooling is mostly great.
*I* do think that the script which imports upstream's changelog should go though as it makes 'you' think you're quickly done. But if you want to do things right, you should still go through all the commits to actually update the versions and add the new links and new files.
If you don't, and the temptations is IMO rather high, then you'd create another monumental task like the one I went through.
And that REALLY did not make me happy or considered fun. At all.
As I see it, the primary problem is the lack of people actively contributing to the Debian kernel team's work. In general.
The amount of open *kernel* bugs is usually around 800. And that's mostly due to periodic mass closing of bugs. I have been triaging (kernel) bugs in the last say 2 years, but it was mostly me and Salvatore doing that work.
I asked for assistance but I didn't see anyone step up. And I plan to shift (part of) my time/focus to other things and my worry is that that means that bug reports get completely unanswered. Like before.
And having 800+ kernel bugs open isn't helping motivation to spend time on non-free stuff like firmware.
Most of the time triaging (kernel) bugs isn't that hard . It usually boils down to finding when the issue surfaced (last working version vs first non- working version), possibly/ideally bisected to a specific commit and then finding the appropriate upstream maintainers and let the bug reporter and the upstream maintainer take it from there.
It's just time consuming.
FTR: Offering to help: great.
Creating NEW bugs with vague/non-actionable descriptions basically asking for new upstream versions ... of which there are already several open in the BTS: not so great. It just makes the mountain (of work) higher.
As I see it, the primary problem is the lack of people actively contributing to the Debian kernel team's work. In general.
Interesting read, and combined with my notes to Didier - is this something where I and some in my team could maybe help? If you think it would be worthwhile, does it make sense to setup a training session to walk me
through the steps so I can attempt a first pass, and then review where the problems are and which bits are useful/not-useful. If the review/link updating/etc was all done - would it make it easier for a DM to look at it and go "yeah, that's solid" and release?
I can't highlight all patches needed for Meteorlake/Hawkpoint support - that would be huge. I can highlight that a 6.8 kernel is needed; and which FW packages are needed.
On Tuesday, 7 May 2024 15:49:45 CEST Mark Pearson wrote:
As I see it, the primary problem is the lack of people actively
contributing to the Debian kernel team's work. In general.
Interesting read, and combined with my notes to Didier - is this something >> where I and some in my team could maybe help? If you think it would be
worthwhile, does it make sense to setup a training session to walk me
through the steps so I can attempt a first pass, and then review where the >> problems are and which bits are useful/not-useful. If the review/link
updating/etc was all done - would it make it easier for a DM to look at it >> and go "yeah, that's solid" and release?
*I* don't see where you/your team could help now. At least not for this particular issue. General help with f.e. bug triaging would still be welcomed I presume.
At https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/ you
can find the MRs I made to make the firmware-nonfree packages all up to date. MR 85 is 'the BIG one' and in there I also mentioned that I also have an update to 20240312 in my fork which I can submit as MR too.
MR 85 is also reviewed by a DD, but while they are *allowed* to make uploads for any package, they choose not to. And FWIW: I agree with that.
I already mentioned that MR 85 is a BIG one (but the only one which needs to go through NEW), which in turn means that reviewing takes more then 10 minutes
(to put it mildly).
The update to 20230804 is also larger then average as some changes needed to be 'postponed' due to needing a new upstream version.
The updates after that are indicative of what I suspect/hope future updates will look like. Unless a kernel-team member thinks that I didn't do it correctly. While I did my best, that's surely a possibility.
So if you want to know what's generally involved into updating the firmware- nonfree packages, I suggest to look into my MRs.
I have a tendency to be verbose in my commit messages, which may help.
And the procedure I described earlier should match what you'll see in the updates after 20230804.
I can't highlight all patches needed for Meteorlake/Hawkpoint support - that >> would be huge. I can highlight that a 6.8 kernel is needed; and which FW
packages are needed.
While firmware package updates have lagged before, the kernel packages are normally quite up-to-date. But sometimes there are other factors which cause delays which normally aren't there. The time64 transition f.e. caused 'some' disruptions.
But (my) update-to-6.8 MR has now been merged into master, so an update to the
6.8 kernel is in the works.
I already mentioned that MR 85 is a BIG one (but the only one which needs to go through NEW), which in turn means that reviewing takes more then 10 minutes (to put it mildly).
The updates after that are indicative of what I suspect/hope future
updates will look like. Unless a kernel-team member thinks that I didn't
do it correctly. While I did my best, that's surely a possibility.
Cool - I have taken a very quick look and kudos - amazing job.
A few follow on questions:
- It looks like it is stuck on someone doing the upload (guessing nobody
has time to do that). Unfortunately I can't help with that bit - not a DM
and nowhere near enough experience.
And, thinking about the comment previously about funding - is this something where somebody needs some paid time to do the exercise?
- I love what you've done with the monthly cadence of updates, that seems smart to me but I appreciate it's a chunk of work every month.
I also noted in one of the commits you mentioned "I don't particularly care about this package, but just wanted to do something about the (big) backlog AND make it easier to prevent a backlog from appearing again in the future (by making it easier for everyone to make an update)", so I'm assuming you'd like done with it ASAP.
You noted earlier that it wasn't documented and added some useful notes. Would it be helpful to work through that process with an idiot (aka...me) to get an initial document down as a starting point?
With the last MR being a few months old now, would it be reasonable
for me to take a stab at doing an update and (worst-case) learning from it?
- Previously you noted "Upstream now also produces a deb package per tag/release" - I had a look for those but couldn't find it. Do you have a location I can check those out? Figured it would be interesting to have a look.
I can't highlight all patches needed for Meteorlake/Hawkpoint support -
that would be huge. I can highlight that a 6.8 kernel is needed; and
which FW packages are needed.
But (my) update-to-6.8 MR has now been merged into master, so an update to the 6.8 kernel is in the works.
That's awesome. If you want any sanity checks run on it, let me know -
I have a number of platforms running Debian that I usually use for testing the firmware-sof package updates.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 60:27:09 |
| Calls: | 6,915 |
| Calls today: | 5 |
| Files: | 12,379 |
| Messages: | 5,431,244 |