Hi Mark, On Tuesday, 7 May 2024 19:30:59 CEST Mark Pearson wrote: > > 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.
Cheers :) > 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. As it has to go through NEW, the uploader must be a DD (not a DM). AFAIK, it's not the upload that's the blocker (that should be rather quick), but the *review* of MR 85. And those reviews are VERY important (more on that later). > And, thinking about the comment previously about funding - is this something > where somebody needs some paid time to do the exercise? IIF that's an option then I'd guess they'd contact you, most likely privately. The most likely scenario, as is the case for 99% (just a guess) of the software packaged for Debian, is that someone needs to find the time (and motivation) to do that 'work' in their FREE time. > - 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. My guess is that it'll take a couple (probably <4) of hours a 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. Debian is often described as a do-ocracy so I did what was in my power and that was making a MR which would/could fix the problem I was seeing. It wasn't the most enjoyable thing I've done, but someone needed to do the 'work', so why not me? > 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? I haven't added my procedure to a MR because I wanted to have a review first. As I've learned over time, there tends to be very good reasons why things are done (and described in README.source) a certain way. I didn't manage to find the reason why the described update procedure was as written down. It could be that 'my' procedure does something wrong or is incomplete or not the best/appropriate way, which I expect will be pointed out in the review. If the reviewer thinks my procedure is actually better, then I'll write it down and submit that as MR too. That shouldn't take much time. > 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? Generally the best way to learn something is by doing 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. https://gitlab.com/kernel-firmware/linux-firmware/ is now the place where upstream changes are merged. When a release is tagged, their CI now produces a deb (and rpm) package. So on https://gitlab.com/kernel-firmware/linux-firmware/-/tags you'll see a (hopefully green) checkmark indicating the success of the pipeline run. https://gitlab.com/kernel-firmware/linux-firmware/-/pipelines/1247368343 would be the one for the 20240410 tag/release and if you click through to the 'deb- release' job and then you can download or browse through to the artifact(s), which in this case is a 347 MiB deb package with all the firmware. > >> 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 - When you submit a MR you are (generally) expected to have verified it works as intended. While I did build a 6.8 kernel, I tend to use the 'nodoc' profile. The review of that MR (in this case by Ben) turned out that it actually contained an error ... in building the documentation. So while using the 'nodoc' is generally fine for my use case, next time I really should also make a build with the 'doc' profile (which is the default). That's why those reviews are so important! > I have a number of platforms running Debian that I usually use for testing > the firmware-sof package updates. What you can do is *verify* whether the Debian kernel package build from (current) 'master' does indeed make the devices for which you need the 6.8 kernel, work correctly and fully. At https://kernel-team.pages.debian.net/kernel-handbook/ you should find all the information/instructions on how to build your own Debian kernel. It could be (f.e.) that you actually need one or more kernel modules enabled, which aren't currently enabled in the Debian kernel config. If not everything works properly, then you can find out which additional modules you need and which changes to the Debian kernel config are needed for everything to work properly. That's how I got started (with Pine64's Rock64 SBC) ... It could also turn out that there's a bug in the upstream kernel (and not in the Debian package of it), in which case you can immediately start to get that fixed upstream. Once you have verified that your self-build Debian kernel now does work as you want, you can file a bug report requesting those changes ... and/or create a MR to get your changes into the Debian kernel (repo). You could also build the Debian firmware packages from one of my branches/MRs or indeed make one yourself for the 20240410 version to verify if it does what you expect it will do. And take appropriate action if it does not. So there's plenty you (and/or your team) can do to make sure that when the (official) Debian kernel gets released, it functions optimal for your use cases. Good luck and have fun :) Cheers, Diederik
signature.asc
Description: This is a digitally signed message part.
