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

2023-01-27 Thread Cyril Brulebois 
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  (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-/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-,
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 (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

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

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

2023-01-17 Thread Cyril Brulebois 
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 (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature