Re: Firmware GR result - what happens next?
> I think it's ironic Apologies, on second thought this was poor wording. It's not ironic, merely an oversight. We all believe in the success of free software, and I don't mean to question anyone's values or allegiance for wanting to serve users by tackling the most evident problems. signature.asc Description: This is a digitally signed message part
Re: Firmware GR result - what happens next?
I concede I'm biased as its maintainer, but I think it's ironic that non-free firmware is about to have better support than the flagship libre wireless firmware. I'm referring to open-ath9k-htc-firmware, which if you're not familiar, is the firmware for the most prominent USB wireless adapters that work with exclusively free software, including all of the recent Respects Your Freedom-certified ones. I specifically have two grievances: * Unlike all other free firmware, firmware-ath9k-htc is not installed on systems by default. The only reason it's segregated is because it gets built from source, unlike the other free firmware. * The ath9k_htc firmware should also be in the installer so users can install over Wi-Fi. Fortunately the live images already include it, so I usually recommend users wanting to install over Wi-Fi use that. Note that downstream distros that are more free software-centric, like Trisquel and PureOS, have already addressed the foregoing by choosing to install firmware-ath9k-htc by default as a downstream change. I'm not a new Debian Contributor; I know how things work around here. But it would be nice if I could get some help from folks who already know the ins and outs of the Debian Installer, and I thought this thread would be a good opportunity to bring awareness to these issues affecting firmware-ath9k-htc. P.S. I'm aware that open-ath9k-htc-firmware may be FTBFS right now, I plan to have a fix shortly. P.P.S. I plan to split carl9170fw (the other 802.11n USB wireless firmware) out into its own source package in the style of firmware- ath9k-htc so we can build it from source too. Even though it's already in firmware-linux-free, carl9170 currently doesn't work with the installer either. Thanks for your consideration. signature.asc Description: This is a digitally signed message part
Re: Naming convention for udebs: -udeb/-installer suffix
> We don't ship udebs for firmware. So please discuss first how this > s[h]ould work I presumed a udeb was necessary for it to be usable during installation. If it's not needed, that's good to hear and I guess I'll hold off. If that's because the ordinary .deb is suitable (it conforms to udeb requirements), I wonder what my next steps are to see it incorporated in the installation images. signature.asc Description: This is a digitally signed message part.
Naming convention for udebs: -udeb/-installer suffix
It's going to take a while for me to figure out how to incorporate it into the installer for Bookworm, but just because it's otherwise ready I'm thinking of doing an upload of firmware-ath9k-htc adding a udeb. I've seen in some places the docs mention adding a -udeb suffix, but other places the udeb package name being the same as the regular package. Does it matter? In this case the packages will provide the same core files and will not be co- installable. signature.asc Description: This is a digitally signed message part.
Re: Pulling free firmware-ath9k-htc into the CD images
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. signature.asc Description: This is a digitally signed message part.
Re: Pulling free firmware-ath9k-htc into the CD images
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. signature.asc Description: This is a digitally signed message part.
Re: Pulling free firmware-ath9k-htc into the CD images
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.
Bug#934822: debian-installer: include free firmware-ath9k-htc
Ping :). AR9271 dominates modern free-software-friendly wireless dongles and I would love to see their support in Bullseye. Please let me know if I can help. signature.asc Description: This is a digitally signed message part.
Bug#934822: debian-installer: include free firmware-ath9k-htc
Package: debian-installer Severity: normal Tags: d-i Control: block -1 by 900171 931283 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 firmware-ath9k-htc includes firmware for some of the few Wi-Fi USB dongles that work without non-free software. In particular, all dongles supporting 802.11n that are Respects Your Freedom certified require this. Its inclusion would make installing Debian easier for me. - -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iHUEARMIAB0WIQQd3xxna2VescxVfdXYKFckL7guMwUCXVVKkAAKCRDYKFckL7gu M1MLAP4tJhGfxnvjshgTCxNMqnX1S9z3LTRo8sNypjKrM3+JnwD6A8WnB5rsueDL dFecnQzTxMLH1tAP4ARiOEWSRJSv2Hs= =yU+o -END PGP SIGNATURE-
