Hi,
Here's an update regarding firmware packages vs. non-free-firmware. I'm
extending the list of recipients a little; feel free to let me know if
you spot packages/teams that I would have missed!
Cyril Brulebois <kibi@debian.org> (2023-01-17):
> 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.)
Different approach: downloading all non-free/binary-<ARCH>/Packages,
grepping for “firmware” or “microcode” in the package name, without
filtering on package contents.
- nvidia-tesla-470-kernel-support disappears, as it doesn't match the
package name pattern I selected, even if it ships /lib/firmware/;
- ixp4xx-microcode shows up, armel-only;
- midisport-firmware shows up, as it matches the package name pattern,
and didn't before because /usr/share/usb/maudio/ is where firmware
files are shipped.
To dot my i's and cross my t's, I iterated on non-free/Contents-<ARCH>,
looked for lib/firmware, and I found no other packages.
With some packages having moved to non-free-firmware migrating to testing,
users or developers have started noticing packages seemingly disappearing
from the archive. Thinking about the documentation aspect, I suppose it
would make sense to have *all* firmware packages move to non-free-firmware
which would be the place to find non-free firmware, regardless of the
list of packages that we determined to be interesting for the installer
(my initial mail).
Efforts to do that aren't much bigger than what's going on already:
- for debian-installer and debian-cd, that should only mean maintaining
a little list of packages that we want to allow/block on installation
images;
- ixp4xx-microcode could probably be removed entirely (#1029814);
- midisport-firmware now has a trivial MR:
https://salsa.debian.org/multimedia-team/midisport-firmware/-/merge_requests/1
> 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).
As long as library and firmware are shipped together, keeping packages
in non-free is probably best.
> - 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?
Regardless of the discussion below my initial mail, those packages can
move to non-free-firmware just like all the others.
Current state for the initial list of packages:
> - amd64-microcode
> - intel-microcode (and iucode-tool)
No changes. Those are not a blocker for the next d-i release though. See
#1029804 for a discussion about whether to install them automatically once
we have them there.
> - atmel-firmware
> - firmware-ast
> - firmware-sof
> - rtl8723bt-firmware
Moved to non-free-firmware, and migrated to testing.
Thank you, maintainers!
> - bluez-firmware
> - dahdi-firmware
> - firmware-nonfree
I've uploaded those a few hours ago, currently in NEW. firmware-nonfree
is a blocker for the next d-i release.
> - zd1211-firmware
This one looks like a weird state, I've added some comments in the MR:
https://salsa.debian.org/debian/zd1211-firmware/-/merge_requests/1
I don't plan on uploading it without learning more about it; I won't
consider it a blocker for the next d-i release.
Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature