Software update with gnome-software in TemplateVM not working

[umbratic]

Qubes OS version:

4.0

Affected component(s):

gnome-software, TemplateVM

---

Steps to reproduce the behavior:

Start Software (gnome-software 3.24.3) from the menu in Template: fedora-26

Expected behavior:

• gnome-software is not able to connect to repositories.
• Adding or updating software packages not possible

Actual behavior:

Cannot connect to repositories. Various error messages:

• Unable to contact "Fedora Project PkgDb" [admin.fedoraproject.org]
• Unable to download updates from "GNOME Shell extensions" [extensions.gnome.org]
• Unable to download firmware updates from "Linux Vendor Firmware project" [s2.amazonaws.com]
• Unable to download updates from "Open Desktop Review Server" [odrs.gnome.org]
• Oops, something has gone wrong. Please contact your software vendor. NetworkManager needs to be running

General notes:

• Update using dnf and update qube from menu works perfectly.
• gnome-software worked fine im Qubes R 3.2
• I believe gnome-soft does not respect new mechanism with qrexec-based updates proxy

---

Related issues:

[marmarek]

I've stumbled on this recently too. Not so short investigation left me with an impression that gnome-software is too tightly integrated with GNOME (too many assumptions about the environment) to work in Qubes VM. Unfortunately.

Details:

• first, it's about setting HTTP proxy in PackageKit (it's architecture doesn't allow it to use the one already set in /etc/dnf/dnf.conf); previously it was set in PackageKit.conf, but PackageKit maintainers decided to drop support for that setting
• now, the only supported method is setting http proxy using d-bus API, by each client (which IMHO is even more "kinda crazy"); for pkcon command using environment http_proxy and such variables kind of works (even if all_proxy is set, one need to set http_proxy anyway...); but gnome-software ignores them
• the only way for setting a proxy for gnome-software, is setting it globally in gnome network settings; two problems here: 1) we don't populate those settings at all (and also don't run NetworkManager in a template); 2) setting a proxy globally would defeat the main purpose of having it at all - giving network access only to package manager
• there are also (minor) problems related to network access detection - some parts of this puzzle like to conclude lack of network access when the system have only loopback interface and don't even bother to use provided proxy (which is running on this loopback interface)...

I haven't yet analyzed what is the best way to fix this, if at all.

[marmarek]

I've stumbled on this recently too. Not so short investigation left me with an impression that gnome-software is too tightly integrated with GNOME (too many assumptions about the environment) to work in Qubes VM. Unfortunately.

Details:

• first, it's about setting HTTP proxy in PackageKit (it's architecture doesn't allow it to use the one already set in /etc/dnf/dnf.conf); previously it was set in PackageKit.conf, but PackageKit maintainers decided to drop support for that setting
• now, the only supported method is setting http proxy using d-bus API, by each client (which IMHO is even more "kinda crazy"); for pkcon command using environment http_proxy and such variables kind of works (even if all_proxy is set, one need to set http_proxy anyway...); but gnome-software ignores them
• the only way for setting a proxy for gnome-software, is setting it globally in gnome network settings; two problems here: 1) we don't populate those settings at all (and also don't run NetworkManager in a template); 2) setting a proxy globally would defeat the main purpose of having it at all - giving network access only to package manager
• there are also (minor) problems related to network access detection - some parts of this puzzle like to conclude lack of network access when the system have only loopback interface and don't even bother to use provided proxy (which is running on this loopback interface)...

I haven't yet analyzed what is the best way to fix this, if at all.

[techgeeknz]

@marmarek With all due respect, I think all GNOME software is too tightly integrated with GNOME to be useful outside that environment. It seems to me we would resolve a lot of issues by piecewise-replacement of core GNOME software packages (starting with gnome-software, nautilus, and gnome-terminal) with equivalent software packages from XFCE or LXDE (such as thunar, lxterminal and xfce4-terminal.

Perhaps yum extender (for Fedora-based templates) or synaptic (for Debian-based templates) would be viable alternatives to gnome-software?

[techgeeknz]

@marmarek With all due respect, I think all GNOME software is too tightly integrated with GNOME to be useful outside that environment. It seems to me we would resolve a lot of issues by piecewise-replacement of core GNOME software packages (starting with gnome-software, nautilus, and gnome-terminal) with equivalent software packages from XFCE or LXDE (such as thunar, lxterminal and xfce4-terminal.

Perhaps yum extender (for Fedora-based templates) or synaptic (for Debian-based templates) would be viable alternatives to gnome-software?