GNOME Bugzilla – Bug 777706
flatpak: GNOME Maps flatpak does not work due to no network problem
Last modified: 2017-10-09 18:54:33 UTC
[Disclaimer: I realize this might not be the perfect place to report this issue, but as there's no place so far to report problems with how flatpaks are built, and considering that in the long run ideally every app should "own" how flatpaks are built (i.e. maintaining their own JSON files) I thought this might be the least bad option] It is possible to install GNOME Maps flatpak from the GNOME flatpak repositories but when you run the application it is totally useless as it can't find the network for some reason, even if the 'network' permission is granted in the metadata file. Note that this is a problem reproducible not only on Endless, but also on other Linux systems, such as my Fedora 25 laptop Flatpak'ed GNOME Maps [1] starts up fine, but when you run the application it is totally useless as it can't find the network for some reason, even if the 'network' permission is granted in the flatpak's metadata file. Note that this is a problem reproducible in different systems (tried Endless 3.1 and Fedora 25), and probably on other Linux systems. [1] https://git.gnome.org/browse/gnome-apps-nightly/tree/org.gnome.Maps.json [2] http://flatpak.org/runtimes.html
Link 1 above doesn't work any more, as Maps moved its manifest in-tree. Note that --share=network is passed in the manifest already: https://git.gnome.org/browse/gnome-maps/tree/org.gnome.Maps.json#n13 org.gnome.Maps//master works just fine for me on a Fedora 25 host, the tiles are visible, I can search for addresses, ...
I was able to replicate this bug on a Fedora Atomic Workstation (rawhide) system. This is using 3.24.1 from the gnome-apps repo (https://sdk.gnome.org/gnome-apps.flatpakrepo). When I tried it with 3.25.1(master) from the gnome-apps-nightly repo (https://sdk.gnome.org/gnome-apps-nightly.flatpakrepo) it worked as expected.
There is one difference I can see between the stable and master manifests. Can you try running the stable app as follows: $ flatpak run --system-talk-name=org.freedesktop.NetworkManager org.gnome.Maps Does that fix the issue?
(In reply to Mathieu Bridon from comment #3) > There is one difference I can see between the stable and master manifests. > > Can you try running the stable app as follows: > > $ flatpak run --system-talk-name=org.freedesktop.NetworkManager > org.gnome.Maps > > Does that fix the issue? That seems like it fixes it here.
That is weird, why is it not using the network status portal instead? Do you have xdg-desktop-portal installed?
I can reproduce the issue as well and i have xdg-desktop-portal-0.5-1.fc25.x86_64 installed.
Hmm, first of all it seems like the sdk has both the gio network manager network status extension and the portal extensions built, and they have the same priority (30). We should probably raise the prio on the portal one.
I see. This is probably a bug in gnome-maps actually. It does: networkMonitor = Gio.NetworkMonitor.get_default(); networkMonitor.connect('network-changed', this._checkNetwork.bind(this)); But, in the case of the portal network monitor this will never trigger, because the network is accessible directly from the start, so it will never trigger the initial change event. However, maybe we should have a behaviour more like the network manager one where it starts off and emits a signal... Matthias?
I've bumped the priority of the portal implementation now. But I think it is just wrong of maps to omit the cold-plugging here. It needs to call checkNetwork explicitly there. The GNetworkMonitor docs make not guarantees about an initial signal emission.
We run this._checkNetwork() in vfunc_activate() though. Running (some old version of) the gnome-maps flatpak with debug enabled I get this in the terminal: "Gjs-Message: JS LOG: DEBUG: Connection failed: Network unreachable" and the checkNetwork method looks like this: _checkNetwork: function() { let addr = new Gio.NetworkAddress({ hostname: 'tile.openstreetmap.org', port: 80 }); networkMonitor.can_reach_async(addr, null, (function(networkMonitor, res) { try { if (networkMonitor.can_reach_finish(res)) this.connected = true; } catch(e) { this.connected = false; Utils.debug('Connection failed: ' + e.message); } }).bind(this)); } So the code gets triggered on start up, which makes me think it's something else.
I pushed a workaround by letting it talk to NetworkManager, but this really should be fixed.
Bug still exists on openSUSE Tumbleweed with the latest flatpak release.
I've just noticed something similar with Geary's use of GNetworkMonitor.can_reach_async(). The stable version installed from gnome-apps works fine, the unstable version from gnome-apps-nightly always gets a G_IO_ERROR_HOST_UNREACHABLE thrown, using the same network connection/flatpak/portal/etc. The code using GNetworkMonitor hasn't changed in years, so I suspect it's a runtime issue, since that's the other thing that changes between running the two versions. Sniffing dbus calls on the host side using dbus-monitor, I see a call to org.freedesktop.DBus.Properties.GetAll for org.freedesktop.portal.NetworkMonitor, which includes "available" being true in the return value, and which I assume results from requesting the default monitor instance. I never see a DBus call corresponding to GNetworkMonitor.can_reach_async however, whatever that may be. This started happening sometime in the last six months and while I can't say when precisely, I do think wasn't an issue when the runtime master was built from 3.24. As an aside, running Geary using "--system-talk-name=org.freedesktop.NetworkManager" as suggested in comment #3 does not seem to help.
Actually, the error thrown is G_IO_ERROR_NETWORK_UNREACHABLE. Looking at gnetworkmonitorbase, that only ever gets thrown if base->priv->networks->len is 0, i.e. no networks have been added by a call to g_network_monitor_base_set_networks/g_network_monitor_base_add_network, but I can't see calls to either in gnetworkmonitorportal.c, so I don't know how it was ever working in the first place. :(
One last thing — rebuilding geary master flatpak against older runtimes/sdks gives the following: org.gnome.Platform 3.26 & 3.24: g_network_monitor_can_reach_async always returns G_IO_ERROR_NETWORK_UNREACHABLE org.gnome.Platform 3.22: g_network_monitor_can_reach_async works correctly. So looks like either a regression in GIO or in the Flatpak sdk/runtime build between 3.22 and 3.24.
I also tried to "short-circuit" this logic by always setting the status to connected in the _checkNetwork function, bypassing the GNetworkMonitor stuff. Just to confirm that actual network access works (which it does).
Created attachment 360923 [details] [review] application: Use GNetworkMonitor::connectivity instead of can_reach_async() can_reach_async() doesn't seem to work well from a Flatpak. Relying on the connectivity property should be enough, and also should handle the captive portal case (if the user's system has enable captive portal detection in NetworkManager).
The patch in #17 works for me! Yay!
Created attachment 360987 [details] [review] configure.ac: Bump GIO dependency
Attachment 360923 [details] pushed as 233aecf - application: Use GNetworkMonitor::connectivity instead of can_reach_async() Attachment 360987 [details] pushed as 2590e7d - configure.ac: Bump GIO dependency
Would this be a good candidate for a 3.26.x point release? Or will it have to wait until 3.28?
(In reply to Nick Richards from comment #21) > Would this be a good candidate for a 3.26.x point release? Or will it have > to wait until 3.28? Yes, maybe. But I had to bump the GIO dependency to 2.44 for this. And I guess technically stable branches should keep dependencies static, but maybe this could be bent slightly since glib 2.44 was several GNOME releases back anyway.