Re: Pulling free firmware-ath9k-htc into the CD images

2020-12-23 Thread Steve McIntyre
[ Adding a CC to the debian-boot list too ]

Hi John!

On Sun, Dec 20, 2020 at 01:31:15AM -0500, John Scott wrote:
>
>I'm not subscribed, please CC me. Also I've already sent a mail like this one 
>to the kernel list; I hope this is the right place (as an outsider I don't 
>know if I need to be reaching the d-i team instead).
>
>I'm adopting the firmware-ath9k-htc package, which has been FTBFS for a while 
>but I've already found a sponsor (Paul Wise) and expect my fixes will be 
>uploaded shortly [1].

Yay!

>These are some of the flagship chipsets for free wireless adapters, and 
>although it's good that the firmware gets built from source in a separate 
>package, until now it's been segregated from the installer and Debian 
>installations. I've sent a MR for the latter [2], so I'd like to know how to 
>best tackle the former.
>
>I think I can build a udeb of my package before the freeze, but I wasn't sure 
>if it would be easiest for you to do something else, such as copy the firmware 
>into your udeb. I'm not familiar at all with the firmware/d-i aspects of the 
>kernel packages, which doesn't appear well documented to me in code comments 
>or the manual, but I'm willing to put in the work to make Debian more usable 
>with free software and hardware.

Cool. I would suggest making a udeb of your own. That way we can add
it to the list of free firmware packages in various places. I'd expect
d-i and debian-cd will both want updates, the former to attempt to
install it when needed and the latter to add it to our media by
default. Is this just going to be for x86 machines, or is it likely to
be useful for ~everybody?

>One hiccup though is that the firmware is included in firmware-nonfree; to 
>avoid 
>a filename clash I rename mine to 'htc_*-1.dev.0.fw' and set the kernel option 
>to use the "development" firmware. This option would probably need to be set 
>outright, or else the module needs to be reloaded. If it's appropriate, I'd be 
>good to do a migration where it can be removed from firmware-nonfree and 
>firmware-ath9k-htc can take back the file name.

OK. You'll need to work with the kernel team to work through things
there then. Oh, also... IIRC d-i uses kernel messages to work out what
firmware to use. Is the kernel driver still going to be looking for
the older (non-free) firmware still? If so, that should probably be
changed.

>I would appreciate your advice on how I can proceed.
>
>Sincerely,
>John
>
>P.S. The reporter of [3] pointed out that, even if we're not building it from 
>source, some of the firmware may be GPL and the Debian source packages do not 
>ship the source code. Although I understand how meritocracy works, this does 
>seem like a very serious problem which I'd like to mention in case you haven't 
>considered.

Ah... It would be more *normal* to ship the source. Is there a reason
not to?

>[1] https://mentors.debian.net/package/open-ath9k-htc-firmware/
>[2] https://salsa.debian.org/kernel-team/firmware-free/-/merge_requests/1
>[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890601#15


-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.



Re: Pulling free firmware-ath9k-htc into the CD images

2020-12-23 Thread John Scott
On Wednesday, December 23, 2020 9:52:16 AM EST Steve McIntyre wrote:
> Is this just going to be for x86 machines, or is it likely to be useful for 
> ~everybody?
It will be useful for all architectures, except I don't think there are
FreeBSD and Hurd drivers yet, but it's an arch:all package regardless.

>  IIRC d-i uses kernel messages to work out what firmware to use. Is the 
>  kernel driver still going to be looking for the older (non-free) firmware 
>  still? If so, that should probably be changed.
Well, the "nonfree" (quotes because I suspect it's built from the same
free source, but by definition we can't be sure without an identical binary)
firmware currently hijacks the proper name of the firmware. I'd love for
my package to take it over, but if not a hack could be to set the kernel
option to look for the "development" firmware.

> Ah... It would be more *normal* to ship the source. Is there a reason
> not to?
Sorry, should've revised my footnote from the mail to the kernel team. None
of the firmware in firmware-free is built from source, and that's what I was
expressing concern to. To the best of my knowledge, this package is the
first to be built as such. (Given the recent Lenovo discussion on -devel
about having to ship that firmware in non-free, I suspect this is
little-known.)

signature.asc
Description: This is a digitally signed message part.