Resolve "fwupd: Do not propagate 'not supported' error on updates check"

Closes #1104

See merge request !567

This change avoids two error messages in the GUI on available updates refresh:

   Unable to get list of updates: The name is not activatable

and

   Sorry, something went wrong: The name is not activatable

Closes GNOME/gnome-software#1104

fwupd: add some missing instances of error conversion (#1104)

See merge request GNOME/gnome-software!566

This should prevent FwupdError domain from leaking up to the GUI.

Suggested-by: Milan Crha <mcrha@redhat.com>
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>

tests: Allow progress to be unknown or 100% after flatpak installation

Closes #1107

See merge request GNOME/gnome-software!565

This might fix a flaky test in the CI, where sometimes the progress
after installation is queried as 100%, and sometimes it’s queried as
unknown.

I think the race happens because flatpak operations (and progress
updates) happen in another thread, and the unit test code can query at
the point of installation being complete (seeing 100%), or once the app
progress has been reset after installation (seeing unknown).

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Fixes: #1107

Resolve "gs-details-page: Show also release date"

Closes #585

See merge request GNOME/gnome-software!556

Merge branch '594-update-all-button-should-be-insensitive-when-installing-flatpak-updates' into 'master'

Resolve "Update All button should be insensitive when installing flatpak updates"

Closes #594

See merge request GNOME/gnome-software!557

fwupd: Ignore errors from `fwupd_client_set_feature_flags`

See merge request !562

Show also release date on the details page when it is available
for the chosen application.

Closes GNOME/gnome-software#585

Closes GNOME/gnome-software#594

Resolve "gs-application: Search for the installed application in app.launch"

Closes #1103

See merge request !555

Merge branch '1074-gs-details-page-fully-sandboxed-flatpak-apps-have-high-permissions' into 'master'

Resolve "gs-details-page: Fully-sandboxed Flatpak apps have "High" permissions"

Closes #1074

See merge request !563

The "High" permission text is used as a fallback, when the softer
options do not match. The None permission doesn't fit any group.

Closes #1074

This will allow using a newer library but an older daemon.

Resolve "gs-repos-dialog: Hide empty frame"

Closes #801

See merge request !559

Hide the repositories frame, when it contains no repository, to not
clutter the GUI with a frame line.

Closes #801
Closes !559

Support renaming Flatpak apps

See merge request !535

Resolve "gs-shell: Close the window on Ctrl+Q key press"

Closes #850

See merge request !558

Closes #850
Closes !558

gs-app: Avoid using pointers before validation

See merge request !533

Minor warning and bug fixes spotted by clang

See merge request !551

gs-details-page: Don’t show the origin box if not on the details page

Closes #988

See merge request !540

data: Drop outdated shell extensions repo key

Closes #997

See merge request !542

gs-application: Fix NULL GVariant handling

See merge request !544

Clicking 'Launch' button in the "application was installed" bubble doesn't
launch just installed flatpak application. The problem is that the app.launch
is called only with the application ID, and then a GsApp instance is just
created from this ID, which is not enough to even refine the internal things,
because the app doesn't know what plugin it belongs to.

The fix is to:
 * pass both management plugin and the application ID to app.launch
 * search for the application by its ID
 * traverse returned list of found applications and find a matched installed application from the given plugin
 * launch the found application

Closes #1103
Closes !555

Kjartan Maraas authored Dec 01, 2020 and Administrator committed Dec 01, 2020

(cherry picked from commit b06d8444)

Add missing g_return_*_if_fail() calls, and, in a few cases, don't use
the app pointer or the priv pointer before validation. It's safe to call
get_instance_private() on a pointer before validating it, since that
only does pointer arithmetic.

Without a message the user may be confused why they can't find the app
by looking for the name they remember.

Currently for apps that have been renamed on Flathub, at least
org.gnome.iagno for example, the appstream data only exists under the
new name, so the app doesn't get properly displayed in the updates list
as it should so it can be updated to the new name. Instead there are
errors in the log "GsPluginFlatpak no match for ....: no results for
XPath query" and later "Gs app invalid as no name ..."

So use the appstream data under the new name in such circumstances. This
is not perfect in that we'll show the new name before the app has
actually been renamed, but it's certainly better than not showing the
app at all, and in practice renames are often just to change the app ID.

This makes renamed apps display properly in the Installed and Updates
lists, but there is still a remaining issue: after updating an app to
a new name, it doesn't show in the Installed list until after
gnome-software is closed and restarted.

When an app is renamed, appropriate metadata is set server-side so that
FlatpakTransaction::end-of-lifed-with-rebase is emitted. On the CLI the
user can choose whether to install the renamed app. GNOME Software
currently ignores the signal so such apps stay on their old names
forever. This commit makes g-s follow such redirects and install the new
app without user interaction, since that is what most users will want. A
follow-up commit will add a message in the UI so the user can be
informed in case the application's name is changing (as opposed to only
the application ID changing, which shouldn't be user-visible).

Note that in the special case where the installed commit is the one with
the eol-rebase metadata (as opposed to being an older commit), such apps
will not be returned by
flatpak_installation_list_installed_refs_for_update() without this
patch: https://github.com/flatpak/flatpak/pull/3945