[Debian-astro-maintainers] Moving firmware packages from non-free to non-free-firmware

Luca Boccassi luca.boccassi at gmail.com
Tue Jan 17 21:02:24 GMT 2023


On Tue, 17 Jan 2023 at 20:49, Cyril Brulebois <kibi at 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



More information about the Debian-astro-maintainers mailing list