Moving firmware packages from non-free to non-free-firmware

Cyril Brulebois kibi at debian.org
Tue Jan 17 20:49:10 GMT 2023


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,
-- 
Cyril Brulebois (kibi at debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-nvidia-devel/attachments/20230117/d1026b34/attachment.sig>


More information about the pkg-nvidia-devel mailing list