Your message dated Mon, 30 Jan 2023 02:41:59 +0000 with message-id <[email protected]> and subject line Bug#1029848: fixed in hw-detect 1.154 has caused the Debian Bug report #1029848, regarding hw-detect: decide how to configure firmware support to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1029848: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029848 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: hw-detect Severity: important Hi, # Context Quoting the text that was agreed to via the 2022 General Resolution about non-free firmware: We will include non-free firmware packages from the "non-free-firmware" section of the Debian archive on our official media (installer images and live images). This means that images built by debian-cd (like netinst) will have main and non-free-firmware packages available under /firmware, with metadata under /firmware/dep11, making it easy for hw-detect to: - Resolve firmware files (spotted as missing by looking at dmesg) into firmware packages (if available), deploy those packages in the installer environment, tweak apt-setup's default configuration, and install those packages in the target environment. → Implemented by check-missing-firmware (detection & deployment in the installer environment) and install-firmware hooks (enabling apt-setup/non-free-firmware if relevant, installing in target environment). - Detect firmware packages based on modalias information (in case missing firmware didn't trigger lines in dmesg), not deploying them in the installer environment, but queuing them for installation in the target environment (also tweaking apt-setup's default config). → Implemented by install-firmware hooks. (Implementation detail: There are two install-firmware hooks, one after base-installer, one before pkgsel.) # Allowing for main-only The next sentence of the text that was agreed to is: The included firmware binaries will normally be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.). I'd like us to determine the following things: - the best name for an internal-only template for hw-detect; - the best alias for it, to be used e.g. on the Linux command line, to save some typing; - what values it should support; - what semantics should be attached to those values. Even before working on non-free-firmware integration, there were many possible combinations. With the ongoing work, we aim at making it easy for most users to just get a successful installation, and I've proposed to streamline alternate use cases (see #1029543), so that we can focus on supporting maybe fewer things, but supporting them well. hw-detect already has a loop, the concept of searching for firmware on external media, the concept of asking, etc. It really doesn't make sense to me to have any kind of per-file, per-module, or per-package granularity. This would mean many prompts, possibly with way too many lines (see how many files iwlwifi can request), and wouldn't really help users make an informed decision. Extra templates would also mean more work for translators… Therefore, my current approach would be not to try and implement some yes/ask/no trichoice as originally envisioned, but to provide users wanting to avoid firmware altogether a way to do so. I'm proposing: - “hw-detect/firmware” as template for hw-detect; - “firmware” or “fw” as an alias for shorter typing (“fw” feels like extremely short); - “never” value to skip firmware handling altogether, meaning skipping both mechanisms mentioned above. That would leave us a rather important flexibility regarding other behaviours that we might want to implement, depending on the use cases that might get identified (#1029543), without having to make a decision about those (names and associated semantic) right now. Implementing this (and documenting it in the installation guide) would make us comply with what was agreed to. Swift feedback would be appreciated, thanks! Cheers, -- Cyril Brulebois ([email protected]) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
--- End Message ---
--- Begin Message ---Source: hw-detect Source-Version: 1.154 Done: Cyril Brulebois <[email protected]> We believe that the bug you reported is fixed in the latest version of hw-detect, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [email protected], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Cyril Brulebois <[email protected]> (supplier of updated hw-detect package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [email protected]) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Mon, 30 Jan 2023 02:36:59 +0100 Source: hw-detect Architecture: source Version: 1.154 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team <[email protected]> Changed-By: Cyril Brulebois <[email protected]> Closes: 1029848 Changes: hw-detect (1.154) unstable; urgency=medium . * Implement support for the hw-detect/firmware-lookup=never setting (Closes: #1029848): - It can be set on the kernel command line or via preseed. - It can be set via the firmware=never alias. - It changes check-missing-firmware's behaviour: + It will still scan kernel logs for missing firmware files, and generate log lines accordingly. + It will not try to load firmware packages from the installation image, even if firmware packages are included (as that's the case for official installation images starting with Bookworm). + It will not ask whether to load firmware from removable media. - It changes install-firmware's behaviour: + It will not copy any firmware files into the installed system. + It will not try to install firmware packages based on modalias information. * Reinstate “mountmedia” and “mountmedia driver” calls, even if use cases haven't been clarified yet (See: #1029543); but skip them during the first iteration: - The “Load missing firmware from removable media?” question hasn't been asked yet, so that seems better consistency-wise. - If firmware is found in /firmware or /cdrom/firmware, which is likely now that installation images include packages from non-free-firmware, the first iteration might be sufficient and skipping those calls means an improved user experience (less waiting). Checksums-Sha1: 5c92776621523ef81063e647f843c6e97f1a9aa3 1990 hw-detect_1.154.dsc 0128d884f1d5d442e52529c89ce58bbdb209c321 193940 hw-detect_1.154.tar.xz fa3ccedcd09476f7201fa3828e8d1a916aafe410 6491 hw-detect_1.154_source.buildinfo Checksums-Sha256: 3123e52331cf88a4db2b29331ab31b1d44c43127235402dc4950ee07176c2302 1990 hw-detect_1.154.dsc 07664f61f5c0a3fbc5e77abe5094eb8c74e032d299eaf047af80abb0a7147fb2 193940 hw-detect_1.154.tar.xz 6ba9bc2ae817c32b1cfc2aebb045118452465facdd46fe4a58f51e15beb7a0da 6491 hw-detect_1.154_source.buildinfo Files: f353c989e9c5fa1e303a222622b3ca7e 1990 debian-installer standard hw-detect_1.154.dsc dc98b32393a77885ff6542b142ee23c7 193940 debian-installer standard hw-detect_1.154.tar.xz 53633a4cbd68e5768e740e84fbb60747 6491 debian-installer standard hw-detect_1.154_source.buildinfo -----BEGIN PGP SIGNATURE----- iQJEBAEBCgAuFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmPXIvcQHGtpYmlAZGVi aWFuLm9yZwAKCRD/kUrwwrNVIEghD/97KrRGIN58Fcy/gXS8x7PTEGixRf47vrOA 3VX6kvt1uCMnb5i5HWog0lzEJ/DFUhHOtJHmO+uZp6mxvZauJmNzEjoQ6yKgmJc8 rc9Eyof75rST/bw4h2uNEZSagzxfV88JY5dyzy6xaHPtFpomcnOMwooSV7p2de88 h/pSg5jCsae6oFl3TyQjRyTEIaNRBEmQwgEz05napmhjYFJVu+TdsjhWbgsTV9Aj ubdKTZ2ZkUOcjBlrICvytsaSDbYPQOoZamVsYtdP6NQK1udoO3VWiFJFAEFwhYXO QPtsoGXvO1xziAMnJo20Y7giD2CYg/LY86bXk+viCf3ZP0fodA2UCTs32Je2KDc2 uMk5S5CmKsOruQjtjsBBqi9E9ju2ScAHwjgVwnvKMl2cIJrf5dzAtSu1kKeICO3d AFd6qFP0qnzYzJ2pOgg2aIITz5BsJRh1Yf2dEVxrMIMgGdF2au+ePFBtACIIHvyR 94AqyFvFhtZ0f89lRn5pbHEq+D3a0UWyE1QYGeF18Evref9sFeIugIjIlBIpJM3l FSnpPgvmM4WFzdDakKNQbNae2/vkpGEzm0NiV/knHVUHlZbhRmD2Xq/2yNZv6Kx2 GWeGfcEf48gcs9Nc2ASlvGItrWFwmzCbXhiEit+XvDSx0x+ShkujdxWd/ST6dq1U 4tyNKW61SA== =LLa4 -----END PGP SIGNATURE-----
--- End Message ---
