Re: Review for the non-free-firmware template in apt-setup
Justin B Rye writes: > Cyril Brulebois wrote: ... >> _Description: Use non-free firmware? >> Some non-free firmware has been made to work with Debian. Though this > > The phrasing "made to work with" has always struck me as poor, since > there are two obvious misinterpretations - "created in order to work > on" or "forced to work on" Debian. All we mean is things are > organised so that it's made *available* for use on Debian. But is > there a better short way of saying that? At any rate I don't think > it's worth slowing down this update. How about "packaged alongside"? Some non-free firmware has been packaged alongside Debian. Though this >> firmware is not at all a part of Debian, standard Debian tools can be >> used >> to install it. This firmware has varying licenses which may prevent you >> from using, modifying, or sharing it. >> . >> Please choose whether you want to have it available anyway. which also ought to work for the contrib case. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Review for the non-free-firmware template in apt-setup
Philip Hands wrote: >>> _Description: Use non-free firmware? >>> Some non-free firmware has been made to work with Debian. Though this >> >> The phrasing "made to work with" has always struck me as poor, since >> there are two obvious misinterpretations - "created in order to work >> on" or "forced to work on" Debian. All we mean is things are >> organised so that it's made *available* for use on Debian. But is >> there a better short way of saying that? At any rate I don't think >> it's worth slowing down this update. > > How about "packaged alongside"? > > Some non-free firmware has been packaged alongside Debian. Though this > [...] That's is a more straightforward way of saying it if our audience is already familiar with all the terminology of developers "packaging" software for distributions, but the existing phrasing seems to be going to some lengths to avoid that jargon. If we're going to change that then the whole thing would need to be rethought. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Processing of netcfg_1.182_source.changes
netcfg_1.182_source.changes uploaded successfully to localhost along with the files: netcfg_1.182.dsc netcfg_1.182.tar.xz netcfg_1.182_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#1029352: marked as done (netcfg: broken ifupdown support for wireless interfaces)
Your message dated Tue, 24 Jan 2023 18:21:00 + with message-id and subject line Bug#1029352: fixed in netcfg 1.182 has caused the Debian Bug report #1029352, regarding netcfg: broken ifupdown support for wireless interfaces 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 ow...@bugs.debian.org immediately.) -- 1029352: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029352 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: netcfg Severity: serious Tags: patch Justification: no networking after installation X-Debbugs-Cc: ifupd...@packages.debian.org, w...@packages.debian.org Hi, I'm putting both ifupdown and wpa maintainers in the loop since I'd like to get some feedback of the proposed resolution for this major issue that's been annoying us for several releases: - wpa maintainers, you can jump to the second issue. - ifupdown maintainers, you can jump to the second and third issues. I know we have a few open bug reports about this already, but I thought I'd start a fresh bug, cutting to the chase. I've pushed three commits in the pu/ifupdown+wireless branch: https://salsa.debian.org/installer-team/netcfg/-/commits/pu/ifupdown+wireless Commit links: 1. https://salsa.debian.org/installer-team/netcfg/-/commit/9494d7ec02b32538db842d88c105db1ab2a6201b 2. https://salsa.debian.org/installer-team/netcfg/-/commit/247056dbb22e6eacbea6348c5c9a6951eab948bd 3. https://salsa.debian.org/installer-team/netcfg/-/commit/5ca665c6c26346e3c9c37c2df6366e8e5d718238 # First issue The first one explains why this could never work: we have a netcfg/target_network_config template that's preseedable, without a default value. The finish-install.d/55netcfg-copy-config script checks whether a value is preseeded, and sets it if it isn't: - if NM is installed, we use NM; - otherwise, if the connection is wired, we use ifupdown; - otherwise, the connection is wireless, and we use… loopback?! That means that at this point, /etc/network/interfaces contains entries for the wireless interface, but it's getting emptied to only contain the lo entry. The proposed fix is to stick to ifupdown for wired and wireless connections, with a small variation: if the connection is wireless and secured (WPA or WEP with a non-empty passphrase), we chmod 400 /e/n/i (in /target = the installed system); that used to be done a long while ago, in the early days of the patch series but that got scratched along the way. # Second issue Once that's fixed, if one gets both DHCP+SLAAC, the generated /e/n/i looks like this (± comments/newlines): allow-hotplug wlXXX iface wlXXX inet dhcp iface wlXXX inet6 auto wpa-ssid my-home-network wpa-psk my-very-secret-passphrase At best, we get SLAAC to work (IPv6 via RAs) but not DHCP: the first iface stanza is missing wpa-* parameters, and we get a huge delay at boot-up until dhclient finally times out. My first instinct was to replicate wpa-* settings in both stanzas: allow-hotplug wlXXX iface wlXXX inet dhcp wpa-ssid my-home-network wpa-psk my-very-secret-passphrase iface wlXXX inet6 auto wpa-ssid my-home-network wpa-psk my-very-secret-passphrase But that doesn't work either: when the DHCP is brought up, wpa-* are used by wpa_supplicant to do the authentication/association dance, DHCP works. But right afterwards, when the SLAAC entry is processed, the kernel and wpa_supplicant complain about being already associated, many errors are logged and deassociation ultimately happens. This leaves us with: an IPv4 address, no IPv6 address, and a DOWN interface. What seems to work in the DHCP+SLAAC case is writing just the DHCP entry, and let RAs bring up IPv6 connectivity on their own. I'm tempted to go with this solution for bookworm, as that cannot be worse than the current situation, but I'd be happy to get feedback from ifupdown and wpa maintainers about the best way to write /e/n/i for DHCP + SLAAC. As far as I can tell, ifupdown's interfaces manpage points at the many packages that can deal with extra options, and wpasupplicant's README.Debian is only about inet entries, inet6 is never mentioned. → ifupdown & wpa maintainers, comments welcome! # Third issue netcfg has some hotplug detection, which was last touched in 2005; it tries to identify interfaces that are hotpluggable, and lists them under /etc/network/devhotplug (in the installer's context), which is then used to determine whether interfaces should be declared “auto” or “allow-hotplug”. My rtl8192cu-based Wi-Fi USB dongle (shared from the host via libvirt) ends up as “allow-hotp
netcfg_1.182_source.changes ACCEPTED into unstable
Thank you for your contribution to Debian. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 24 Jan 2023 05:15:23 + Source: netcfg Architecture: source Version: 1.182 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Cyril Brulebois Closes: 1029352 Changes: netcfg (1.182) unstable; urgency=medium . * Fix ifupdown configuration for wireless connections (Closes: #1029352, issue #1): when NetworkManager isn't used, a wireless connection would result in the internal netcfg/target_network_config (if not preseeded) being set to “loopback”, resulting in a /etc/network/interfaces that's mostly empty in the installed system. Instead, use “ifupdown”, just like in the wired connection case, and keep /e/n/i as written by netcfg initially. Since secrets can be stored there (when using WPA or WEP with a non-empty passphrase), change its mode to 600 for secure connections. * Fix ifupdown configuration for wireless connections (Closes: #1029352, issue #2): when both DHCP and SLAAC stanzas are written for a wireless interface, the wireless options are only written for the second one (the SLAAC stanza, inet6 auto). This means that the first one (the DHCP stanza, inet dhcp) cannot establish a connection, leading to long delays until dhclient times out. Since duplicating wireless options in both stanzas wouldn't work, just write a DHCP stanza in that case, letting router advertisements (RAs) set up IPv6 automatically. Checksums-Sha1: 6b58976c9c13e2233a2e17bdbed1bf59764deb6b 1804 netcfg_1.182.dsc 35f0186d25f1310090f08fbd3ffbc3d13c9944a6 402580 netcfg_1.182.tar.xz 43177d5db91519135a8832e831307794df8c4eb7 5842 netcfg_1.182_source.buildinfo Checksums-Sha256: e8f8bfd44556a5a10ace9d39b34c76a67e21d4f4346125c1805d8013f6c6c743 1804 netcfg_1.182.dsc 094fa02c0fdea0e6401d1e5ae66bc86d6da958c7bab26c3cff436e5a4c631a8f 402580 netcfg_1.182.tar.xz ec6895046eba5f280849057941d187bfb81880058cc5b4a3c9ce562b681c1f24 5842 netcfg_1.182_source.buildinfo Files: 3a33a51fb5d3ce4eaa52ef14b0b9a922 1804 debian-installer optional netcfg_1.182.dsc 917a93dd8cffc745c45786efaec2eb01 402580 debian-installer optional netcfg_1.182.tar.xz 023554e39eb26783c77f672ec883c5ff 5842 debian-installer optional netcfg_1.182_source.buildinfo -BEGIN PGP SIGNATURE- iQJEBAEBCgAuFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmPPbFoQHGtpYmlAZGVi aWFuLm9yZwAKCRD/kUrwwrNVIN7sD/4h6Cx8oHft8Ee//AB5qu5g9BVzCWqRT8rx XlY0OKuvK5o1IzIoL39FQZ2IT1Kod9PhQjpU0HcN7lpYI9CWwIHevSkdCwZQj5cM Y4Tt4c7y0UgMBjBcr/ByzQ5zTuO1lhN2SpQdGaX8ORWJ/ox7HAVI1wzEoelIgEf5 vMOpdXjg3aPn4pwxVoLH62ngaHd1sp5rsHuG7VoUQVHRb2OvzJN1r3Yo6wM/P/FO TXonoP7i6vWenJrt1zSy7orm7iPft+jV/HvxaiG4rLFL5EvPx1pWRAqPwMMcTopa F6Fo0sC5noslzWIP7ChrcfGD4GlQX45FBgnl6h0QEZtE+W5Zb0UGzulKaYkqOTAb vo9JU7LFOBMw+4a/EsSrIaQjL9a3stqtNZABGEVt9wj9A8tOsYKuK0Q9r/bmbi7K qhhrXOErjAyIuA9H21lWWxkrg4EiwCTR8IEfmMV9qcCsUGHyHgyoebp/50HhACTe 6HtHy8oYQk9GVfd1M0h3zNotui0qk+NRRdEr+X4oIXcSMtxESMlfcuWaOackVaMh DmkJ7GQSe6ActXLQt9J82hhxLq7FxspjmmmsBSEsL9q39wARgqeVkUzSNoDB1xSE HNwpzwGb8JqJ2XaTb/9JLC0SmHTDmNR7XsA9i3cewxuFSGvQrtClS+ueTXt//ygt bEDLyX/lMA== =4X9A -END PGP SIGNATURE-
