Hello Lubomir, great to get you feedback so quickly! And we are happy that you have good news for us already in the first mail :)
Let me summarize this quickly here, and I will come back and be more specific when I have more infos on your questions: - We are still using unity8 as shell, and there is indicator-network basically displaying that status of WiFi and radio network and allowing to operate the network connections, enable flight mode etc. Its a new development made specifically for unity8 if I remember right. And it should be able to talk to D-Bus. Debian wants to use them in the so-called Ayatana indicators package, too. - Regarding builds: The real issue is the rather tight coupling between the Ubuntu root fs and the Android container which is started at boot time. So far we are not able to just start Ubuntu Touch without it. A lot of scripts and magic wait for the successful bringup of the container. Moreover, some things just dont build correctly for amd64, but do for armhf. We are working form time to time to get it more sanitized, for example you could install unity8 shell with the indicators probably also on a normal PC already. Maybe thats enough? - The captive portal detection I tried to configure manually for my device, but since nothing is listening to that event, I cannot tell if it works properly or not. I might be able to hook up tcpdump or so on the device to see if he is querying on change of network. So if thats already in for ages, I hope we can use it right away ;) - What we currently see sometimes is a long switchover time between radio and WiFi. Is it NM trying to hold on for the WiFi connection for a longer time? What also can happen is that the DNS servers dont get updated, and when you come from WiFi you have a reall long interval without having DNS lookups. FYI here is our packaging for NM: https://github.com/ubports/network-manager-packaging/ I will talk with my guys how we can make a bit more Q&A with you guys, have a ncie weekend until then! BR Florian Am 21.11.2018 um 19:18 schrieb Lubomir Rintel: > Hello Florian, > > thanks for your message. > > We're dealing with exact same challenges on machines larger than phones > too. > > For quite some time I think the Canonical folks have done a good job at > upstreaming their changes. E.g. ofono support got in, which I figure > was one of the larger patches. > > Perhaps there wouldn't be too much stuff left if NM gets rebased to > something more recent (more on that below). > There's basically four regular contributors to NetworkManager at the > moment, all of us happy to improve its usefulness on phones, provided > we understand what the deficiencies are. > > A device could help, but I think even more useful would be an x86 > compose of your distribution that could be run in a VM. Do you have > such builds? I suppose that would help us understand what are the > specifics of the phone setup (I guess you run a different desktop > shell, have Android kernel beneath, ofono instead of ModemManager, > etc.). > > We don't break things, including API/ABI and do regularly test our > builds on Ubuntu 16.04. The version number in itself doesn't carry much > meaning -- an update to 1.14.x at this point should be staightforward > and safe. > > NetworkManager is doing captive portal detection for ages, though it > recently got somewhat better. The notification should be done in the > desktop shell. > > For the reference -- GNOME Shell deals with it and should provide a > good example. I guess KDE does too. nm-applet does not. > > Don't hesitate to ask more, especially when we do something that > doesn't make sense on a phone or miss something that would be useful. > The more technical context you provide the better. > > I'm quite certain it's not only me who appreciates that you decided to > keep the upstream project in the loop. > > Take care, > Lubo > _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
