Bug#919619: [Pkg-utopia-maintainers] Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend
Quoting Andreas Henriksson (2020-07-12 18:40:57) > On Sun, Jul 12, 2020 at 05:39:19PM +0200, Jonas Smedegaard wrote: > > I understand that neither you nor Andreas consider current release of > > IWD a _recommended_ alternative for wpa-supplicant. That is a good > > reason to not depend on or recommend iwd. > > I think iwd itself (since >= 1.2, so not the version in buster) has > reached production quality. The problem here is the iwd backend in > *NM* which is not production quality and actively discuraged by NM > upstream! Thanks for the clarification: Yes, I meant iwd used with network-manager which this bugreport is about (not IWD in general). > Please note that the iwd backend is not even *compiled* by default! Ok, but doesn't really change my point: You and network-manager upstream really REALLY not recommending iwd as alternative for wpa-supplicant does not change that network-manager is usable without wpa-supplicant. > > I do not understand, however, why you will not relax relationship on > > wpa-supplicant to recommend it instead of depending on it. > > Because there's no benefit in doing it, while there's a massive > support burden. There's a massive amount of clueless users who > blatantly configure recommends to not be installed and any application > that has as many users as NM will be hit with a floodwave of support > requests over it. From being involved in the GNOME team we know it's > simply not possible. You haven't offered to do the work, but if you're > willing then start out by triaging the existing bug reports! Talk is > cheap, etc, etc. Ok, so the reason is that (unlike me) network-manager maintainers see no benefit in doing it and expect a massive support burden by doing it. Thanks. I think I understand now. Sorry if that was explained already and I failed to understand it previously. > > There are use-cases of network-manager without wpa-supplicant, when > > either wifi is not used, or when IWD is used instead. > > Nothing prevents you from using iwd (while having wpasupplicant > installed). > > If you feel you must get rid of wpasupplicant (why?), then here are a > few options: > * use equivs to create a dummy replacement > * recompile NM packaging with wpasupplicant dependency changed > (You could even contribute a patch which does this using > build-profiles so you can rebuild without any changes to the source > package!) > * use dpkg exclude features to get wpasupplicant packages files not > unpacked on your system while the package gets installed. Above are options to deviate slightly from Debian. > * realize that wpasupplicant is small and useful to have as a fallback > if something ever goes wrong. Obviously there is the option of changing my mind to no longer want what I wanted. :-) > You seem to just argue over a theoretical supremacy idea, while not > even trying to describe which practical problem you're trying to > solve. Sorry, I thought it would confuse rather than help to dive into my specific use-case. I am more than happy to share that: I want to offer system installation profiles for others than myself (where non-Debian deviation is not an option: I want to offer Debian not a fork of Debian), with a minimal core setup that includes wifi but excludes network-manager (due to its size), optionally adding a GUI (which then introduces network-manager but should do so without breaking the already established networking setup of a core system. Current prototype is here: http://box.redpill.dk/ > > Again, I do understand that such use-cases are not _recommended_ but > > they are still _possible_ and _wanted_ for some unusual situations. > > Yes, it's still possible. So go do it! > FFS I'm using it myself right now! It is certainly possible. My point is that unlike "a theoretical supremacy idea", possible use-cases are "unusual installations" as per Debian Policy 4.5 § 7.2. Debian Policy 4.5 § 7.2 does not say that if you want to do something unusual then fork debian using equivs or recompiled packages, or delete the files getting in the way, or disable the daemons blocking your other daemons. Debian Policy 4.5 § 7.2 says that if you want to do something unusual then overrride specific recommendations of packages you want to use in an unusual way. Debian Policy 4.5 § 7.2 says that a package relationship declared a dependency is required to provide a significant amount of functionality. > Better yet start improving the NM iwd backend so that it becomes > better. Thanks for the encouragement. I am not a C programmer, however. > Maybe some day NM upstream will even reconsider and have it compiled by > default (it comes with zero new build-time dependencies after all). > After that they might even automatically fall back on using iwd without > requiring manual configuration. Improving network-manager so that IWD can be recommended is obviously better than discussing how to deal with not-rec
Bug#919619: [Pkg-utopia-maintainers] Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend
Hello, On Sun, Jul 12, 2020 at 05:39:19PM +0200, Jonas Smedegaard wrote: > I understand that neither you nor Andreas consider current release of > IWD a _recommended_ alternative for wpa-supplicant. That is a good > reason to not depend on or recommend iwd. I think iwd itself (since >= 1.2, so not the version in buster) has reached production quality. The problem here is the iwd backend in *NM* which is not production quality and actively discuraged by NM upstream! Please note that the iwd backend is not even *compiled* by default! (This is a debian deviation and I'm sure if you give Michael enough grief about this he'll reconsider and go back to upstream recommendations of not even building the IWD backend.) > > I do not understand, however, why you will not relax relationship on > wpa-supplicant to recommend it instead of depending on it. Because there's no benefit in doing it, while there's a massive support burden. There's a massive amount of clueless users who blatantly configure recommends to not be installed and any application that has as many users as NM will be hit with a floodwave of support requests over it. From being involved in the GNOME team we know it's simply not possible. You haven't offered to do the work, but if you're willing then start out by triaging the existing bug reports! Talk is cheap, etc, etc. > > There are use-cases of network-manager without wpa-supplicant, when > either wifi is not used, or when IWD is used instead. Nothing prevents you from using iwd (while having wpasupplicant installed). If you feel you must get rid of wpasupplicant (why?), then here are a few options: * use equivs to create a dummy replacement * recompile NM packaging with wpasupplicant dependency changed (You could even contribute a patch which does this using build-profiles so you can rebuild without any changes to the source package!) * use dpkg exclude features to get wpasupplicant packages files not unpacked on your system while the package gets installed. * realize that wpasupplicant is small and useful to have as a fallback if something ever goes wrong. You seem to just argue over a theoretical supremacy idea, while not even trying to describe which practical problem you're trying to solve. > > Again, I do understand that such use-cases are not _recommended_ but > they are still _possible_ and _wanted_ for some unusual situations. Yes, it's still possible. So go do it! FFS I'm using it myself right now! It is certainly possible. Better yet start improving the NM iwd backend so that it becomes better. Maybe some day NM upstream will even reconsider and have it compiled by default (it comes with zero new build-time dependencies after all). After that they might even automatically fall back on using iwd without requiring manual configuration. > Debian Policy says to use Recommends: not Depends: for such relations. This is your interpretation. Please understand that the Debian project still has not managed to produce a way to turn mailinglist discussions into working code. The way to reach your goal is to improve the code by debugging current bugs (which there are quite a bunch of in the iwd backend of NM) and submitting patches upstream. As already mentioned, the debian packaging of NM is already ahead of the game on being cutting edge w.r.t. iwd. The ball is really in your court! If you want to support widespread iwd usage, then improve the code! This is the last time I'm repeating myself on this topic I've tried to keep this bug report up to date with latest information of progress, but I'm not sure if I find the motivation for even that. I will however repeat what I said last time: There are no progress being made anymore on the iwd backend in NM! Noone is working on improving it! Thus don't expect progress to be made, unless you contribute! You should likely expect the next step to be that the code is removed upstream given the current state of things unless someone (this means YOU!) steps up and starts improving it! Regards, Andreas Henriksson
Bug#919619: [Pkg-utopia-maintainers] Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend
Quoting Michael Biebl (2020-07-04 00:42:57) > Am 04.07.20 um 00:16 schrieb Jonas Smedegaard: > > Then how about _not_ recommend iwd but just lower from depending on > > wpasupplicant to only recommending it. Because that's what it is: > > Recommended for all except special situations. For now... Right? > > Hm, no. That's exactly the situation I want to avoid. The user > installing iwd, removing wpasupplicant in the process, network not > working anymore. A Recommends makes that even worse. Either iwd works as > a drop-in replacement (without requiring explicit configuration) or not. > That's basically my question. > If it does, I'm happy to add an alternative Depends assuming Andreas is > fine with that. I understand that neither you nor Andreas consider current release of IWD a _recommended_ alternative for wpa-supplicant. That is a good reason to not depend on or recommend iwd. I do not understand, however, why you will not relax relationship on wpa-supplicant to recommend it instead of depending on it. There are use-cases of network-manager without wpa-supplicant, when either wifi is not used, or when IWD is used instead. Again, I do understand that such use-cases are not _recommended_ but they are still _possible_ and _wanted_ for some unusual situations. Debian Policy says to use Recommends: not Depends: for such relations. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#919619: [Pkg-utopia-maintainers] Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend
On Sat, Jul 04, 2020 at 12:42:57AM +0200, Michael Biebl wrote: > Am 04.07.20 um 00:16 schrieb Jonas Smedegaard: > > Then how about _not_ recommend iwd but just lower from depending on > > wpasupplicant to only recommending it. Because that's what it is: > > Recommended for all except special situations. For now... Right? > > Hm, no. That's exactly the situation I want to avoid. The user > installing iwd, removing wpasupplicant in the process, network not > working anymore. A Recommends makes that even worse. Either iwd works as > a drop-in replacement (without requiring explicit configuration) or not. > That's basically my question. > If it does, I'm happy to add an alternative Depends assuming Andreas is > fine with that. I can confirm there's still no automatic fallback to use iwd. It has to be manually configured to even be attempted to be used. This is something I'd personally consider a blocker if I where NM Debian maintainer. I quickly asked upstream a while ago if we couldn't atleast automatically fall back on iwd if we detect that wpasupplicant isn't even *installed*, but their responses where negative. They don't seem to like or support iwd usage at all Additionally as previously mentioned the iwd backend in NM still needs more work to be production quality. Current state is that it's fully usable as far as I can tell, but you'll likely occationally need to restart NetworkManager.service when NM and iwd gets state out of sync. (I've experienced this alot, but have not debugged it in detail. There are likely many small issues to be found and ironed out here.) At this point I don't think it's safe to allow the general public of NM users to be able to uninstall wpasupplicant and people who really want to use iwd with NM and really want to uninstall wpasupplicant to use an equivs. I however would suggest keeping wpasupplicant around still in case of emergency, if you're not in a situtation that forces you to not have wpasupplicant installed for whatever reason (which should be rare enough that using equivs to solve it seems suitable). This is the situation as I see it for now. I've also previously mentioned that I don't see anyone putting work into the situation improving so I guess it'll remain the same for a forseeable future. Regards, Andreas Henriksson
Bug#919619: [Pkg-utopia-maintainers] Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend
Am 04.07.20 um 00:16 schrieb Jonas Smedegaard: > Then how about _not_ recommend iwd but just lower from depending on > wpasupplicant to only recommending it. Because that's what it is: > Recommended for all except special situations. For now... Right? Hm, no. That's exactly the situation I want to avoid. The user installing iwd, removing wpasupplicant in the process, network not working anymore. A Recommends makes that even worse. Either iwd works as a drop-in replacement (without requiring explicit configuration) or not. That's basically my question. If it does, I'm happy to add an alternative Depends assuming Andreas is fine with that. signature.asc Description: OpenPGP digital signature
Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend
Quoting Michael Biebl (2020-07-03 21:50:36) > Hi, > > On Tue, 26 May 2020 13:10:27 +0200 Andreas Henriksson > wrote: > > Just wanted to drop a comment about the iwd status in NM. > > NM has since 1.24.0, which is now in testing/unstable, basic > > support for connecting to a hidden network using the iwd backend. > > > > There are still many minor bugs remaining in the NM iwd backend > > both for hidden and any other network. Examples that comes to mind: > > - Removing a connection in NM doesn't seem to propagate > > to iwd known-network list. > > - NM and iwd sometimes gets out of sync for unknown reasons, > > stopping iwd and restarting NetworkManager then browsing menues > > to trigger dbus activation of iwd again can be used as a workaround. > > - nmcli errors out on trying to scan (for a hidden network!) even when > > specifying 'hidden yes' on the command line. (Working method to > > provision a hidden network includes using the "Connect to hidden > > network..." menu entry in gnome-control-center Wi-Fi pane.) > > - and more... > > > > Many minor workaroundable issues that needs more polish. > > Unfortunately it doesn't seem like anyone is working on improving > > the NM iwd backend since quite a while now (except for my basic hidden > > network contribution, which was a one-off for personal needs). > > That sounds a bit like the iwd is only semi-maintained in NM which makes > me a bit uncomfortable tbh. What also concerns me a bit is, that ttbomk > we don't have an automatic fallback to iwd. > Say I switch the dependency to wpasupplicant | iwd, wpasupplicant is > removed. NM is not automatically using iwd without explicit > configuration? Is that correct? Then how about _not_ recommend iwd but just lower from depending on wpasupplicant to only recommending it. Because that's what it is: Recommended for all except special situations. For now... Right? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend
Hi, On Tue, 26 May 2020 13:10:27 +0200 Andreas Henriksson wrote: > Just wanted to drop a comment about the iwd status in NM. > NM has since 1.24.0, which is now in testing/unstable, basic > support for connecting to a hidden network using the iwd backend. > > There are still many minor bugs remaining in the NM iwd backend > both for hidden and any other network. Examples that comes to mind: > - Removing a connection in NM doesn't seem to propagate > to iwd known-network list. > - NM and iwd sometimes gets out of sync for unknown reasons, > stopping iwd and restarting NetworkManager then browsing menues > to trigger dbus activation of iwd again can be used as a workaround. > - nmcli errors out on trying to scan (for a hidden network!) even when > specifying 'hidden yes' on the command line. (Working method to > provision a hidden network includes using the "Connect to hidden > network..." menu entry in gnome-control-center Wi-Fi pane.) > - and more... > > Many minor workaroundable issues that needs more polish. > Unfortunately it doesn't seem like anyone is working on improving > the NM iwd backend since quite a while now (except for my basic hidden > network contribution, which was a one-off for personal needs). That sounds a bit like the iwd is only semi-maintained in NM which makes me a bit uncomfortable tbh. What also concerns me a bit is, that ttbomk we don't have an automatic fallback to iwd. Say I switch the dependency to wpasupplicant | iwd, wpasupplicant is removed. NM is not automatically using iwd without explicit configuration? Is that correct? Michael signature.asc Description: OpenPGP digital signature
Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend
Hi, Just wanted to drop a comment about the iwd status in NM. NM has since 1.24.0, which is now in testing/unstable, basic support for connecting to a hidden network using the iwd backend. There are still many minor bugs remaining in the NM iwd backend both for hidden and any other network. Examples that comes to mind: - Removing a connection in NM doesn't seem to propagate to iwd known-network list. - NM and iwd sometimes gets out of sync for unknown reasons, stopping iwd and restarting NetworkManager then browsing menues to trigger dbus activation of iwd again can be used as a workaround. - nmcli errors out on trying to scan (for a hidden network!) even when specifying 'hidden yes' on the command line. (Working method to provision a hidden network includes using the "Connect to hidden network..." menu entry in gnome-control-center Wi-Fi pane.) - and more... Many minor workaroundable issues that needs more polish. Unfortunately it doesn't seem like anyone is working on improving the NM iwd backend since quite a while now (except for my basic hidden network contribution, which was a one-off for personal needs). Regards, Andreas Henriksson
