Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel.cd > #6532 > unrolled thread

Pulling free firmware-ath9k-htc into the CD images

Back to article view | Back to linux.debian.devel.cd

Contents

  Pulling free firmware-ath9k-htc into the CD images John Scott <jscott@posteo.net> - 2020-12-20 20:10 +0100
    Re: Pulling free firmware-ath9k-htc into the CD images Steve McIntyre <steve@einval.com> - 2020-12-23 16:00 +0100
      Re: Pulling free firmware-ath9k-htc into the CD images John Scott <jscott@posteo.net> - 2020-12-23 19:00 +0100
        Re: Pulling free firmware-ath9k-htc into the CD images John Scott <jscott@posteo.net> - 2020-12-29 01:10 +0100
        Re: Pulling free firmware-ath9k-htc into the CD images Steve McIntyre <steve@einval.com> - 2020-12-31 17:00 +0100
          Re: Pulling free firmware-ath9k-htc into the CD images John Scott <jscott@posteo.net> - 2021-01-01 01:50 +0100

#6532 — Pulling free firmware-ath9k-htc into the CD images

[Multipart message — attachments visible in raw view] — view raw

Hi,

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].

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.

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.

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.

[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

[toc] | [next] | [standalone]

#6533

[ 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.                                steve@einval.com
Welcome my son, welcome to the machine.

[toc] | [prev] | [next] | [standalone]

#6534

[Multipart message — attachments visible in raw view] — view raw

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.)

[toc] | [prev] | [next] | [standalone]

#6538

[Multipart message — attachments visible in raw view] — view raw

I've committed a rudimentary udeb in Git at
https://salsa.debian.org/jscott/open-ath9k-htc-firmware.git

for which I would appreciate feedback. Does the d-i freeze coming up in a
couple weeks mean this may not clear NEW in time for Bullseye?

If so, no biggie. Here's the gist of what it installs:
/etc/modprobe.d/ath9k_htc.conf
/lib/firmware/ath9k_htc/htc_7010-1.dev.0.fw
/lib/firmware/ath9k_htc/htc_9271-1.dev.0.fw

The 1.dev.0 file names make it so that firmware-nonfree can be coinstalled
without any changes. The modprobe options, which should hopefully be honored
by the installer image, just sets
	options ath9k_htc use_dev_fw=1
so it finds the firmware with the alternate filename.

A release of the firmware package (no udeb) was released a couple days ago
and should land in Bullseye shortly, so just let me know if the udeb looks
suitable for upload; sponsorship would be appreciated.

[toc] | [prev] | [next] | [standalone]

#6542

Hey John,

I hope you had a good Christmas!

On Wed, Dec 23, 2020 at 12:57:09PM -0500, John Scott wrote:
>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.

Right. I'm more asking whether it's useful to try and pull this in for
all arches, or just for amd64 / i386 for now.

>>  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.

Hmmm. In that case you'll need to talk to the kernel maintainers here,
surely? There's not much point having the firmware available if the
kernel isn't going to look for it AFAICS?

>> 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.)

OK.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Yes, of course duct tape works in a near-vacuum. Duct tape works
 anywhere. Duct tape is magic and should be worshipped."
   -― Andy Weir, "The Martian"

[toc] | [prev] | [next] | [standalone]

#6543

[Multipart message — attachments visible in raw view] — view raw

On Thursday, December 31, 2020 10:53:30 AM EST Steve McIntyre wrote:
> Right. I'm more asking whether it's useful to try and pull this in for
> all arches, or just for amd64 / i386 for now.
I guess the majority of users are on amd64/i386 systems, but as the firmware
is for USB devices it would be useful for all of them, including, say,
Raspberry Pi users wanting to minimize use of proprietary firmware.

> There's not much point having the firmware available if the
> kernel isn't going to look for it AFAICS?
Actually with my draft udeb, it just uses the same workaround to find
the firmware as it does on the installed system, by setting the appropriate
option via a modprobe configuration file. It really should be as simple as
pulling in the udeb into the images:
https://salsa.debian.org/jscott/open-ath9k-htc-firmware

Assuming the freeze doesn't get in the way, this will probably need to go
through NEW and might be able to be merged in that way.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel.cd

csiph-web