On Tue, 17 Jan 2023 at 20:49, Cyril Brulebois <k...@debian.org> wrote: > > Hi folks, > > First off: sorry I haven't been able to work on this sooner. For some > context, you can check the notes for the meeting I had with Steve > after the GR result was published: > https://lists.debian.org/debian-boot/2022/10/msg00044.html > > This mail is about moving packages from non-free to non-free-firmware, > which will make it possible to install firmware packages (and configure > apt to keep them up-to-date) from non-free-firmware without enabling > non-free as a whole. > > For this first round, I've checked on amd64/unstable which packages > ship files under /lib/firmware, then excluded some of them, and worked > on the rest. (I'll need to check other archs for possible arch-specific > firmware packages, but I must confess our current thinking is making > the random joe/jane user experience on x86 systems as easy as possible, > then care about less obvious targets later.) > > So far I've excluded: > - libfishcamp1 and libsbig4 since those are library packages that > also happen to ship some hexdumps; I don't think they would qualify > for non-free-firmware (maybe if the hexdumps would be split out in > their own packages, but I'm not sure that's worth it). > - firmware-nvidia-gsp, firmware-nvidia-tesla-gsp, and > nvidia-tesla-470-kernel-support, from nvidia-graphics-drivers* > source packages; it's been a while since my X days, but I don't > think firmware packages would be useful on their own, one would > need to install/build X drivers from non-free as well? > > (but maintainers are in copy anyway, just in case I missed something.) > > The remaining source packages: > - amd64-microcode > - atmel-firmware > - bluez-firmware > - dahdi-firmware > - firmware-ast > - firmware-nonfree > - firmware-sof > - intel-microcode > - rtl8723bt-firmware > - zd1211-firmware > > I've filed merge requests on Salsa for 8 of them, and bug reports for > the remaining 2 (hosted on an external cgit for one, no VCS for the > other). > > I'd be happy for maintainers to tell me whether the merge requests are > sufficient, or whether they'd like bug reports filed as well. I'm happy > to take care of uploading and pushing commits/tags to the repository if > that helps getting packages quicker (in which case, just make sure to > grant “kibi” push access). > > I also plan on getting in touch with ftpmaster to get the whole lot > reviewed in a timely manner, and overrides adjusted. > > Please let us know if you have any questions. > > Thanks for your help! > > > Merge requests: > - amd64-microcode: > https://salsa.debian.org/hmh/amd64-microcode/-/merge_requests/3 > - atmel-firmware: > > https://salsa.debian.org/rfinnie/atmel-firmware-pkg-debian/-/merge_requests/1 > - bluez-firmware: > https://salsa.debian.org/bluetooth-team/bluez-firmware/-/merge_requests/3 > - dahdi-firmware: > https://salsa.debian.org/pkg-voip-team/dahdi-firmware/-/merge_requests/2 > - firmware-nonfree: > https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/48 > - firmware-sof: > https://salsa.debian.org/mpearson/firmware-sof/-/merge_requests/6 > - intel-microcode: > https://salsa.debian.org/hmh/intel-microcode/-/merge_requests/2 > - zd1211-firmware: > https://salsa.debian.org/debian/zd1211-firmware/-/merge_requests/1 > > Bug reports: > - firmware-ast: > https://bugs.debian.org/1029110 > - rtl8723bt-firmware > https://bugs.debian.org/1029111 > > > Cheers,
Hi, I think the open source nvidia kernel drivers need firmware-nvidia-gsp/firmware-nvidia-tesla-gsp. Also I think there are efforts in progress to use the nvidia firmwares with nouveau: https://lwn.net/Articles/910343/ I don't know if these are good enough reasons to include those for now - it would certainly not benefit end users at this stage, and mostly be for the benefit of developers and tinkerers. In case a future kernel version's nouveau can use the gsp though, being able to use it from bookworm-backports would be nice I think. Kind regards, Luca Boccassi