Last commit made on 2018-07-08
Get this branch:
git clone -b wip/jrocha/pull-runtime-related-refs

Branch merges

Branch information


Recent commits

25a1a07... by Joaquim Rocha <email address hidden> on 2018-07-05

flatpak: Add test for installing extensions when updating an app

When updating an app, if its runtime needs an extension and it's missing
(e.g. because it wasn't correctly installed before), then install the
extension while updating the app too.

9b06e9d... by Joaquim Rocha <email address hidden> on 2018-05-23

flatpak: Include related refs to the app's runtime on install/update

When installing/updating an app, if its related refs and its runtime
need to be installed as well, then they do. However, refs that are
related to the runtime itself do not get installed, and this is a
problem because some apps may need them (besides being a discrepancy
between using the Flatpak CLI and GNOME Software for installing Flatpak

Thus, these changes add any refs related to an app's runtime to the
list of refs that should be installed when installing or updating an
app. Note that it deliberately doesn't update refs related to the
runtime though, just as it doesn't update the runtime when updating an
app. Thus, refs that are related to the runtime get updated together
with it.

48afd1d... by Joaquim Rocha <email address hidden> on 2018-07-05

flatpak: Fix app extension test

The app extension test (1) was not working since we stopped having the
global cache because it was relying on a plugin loader method , so this
patch fixes it by directly getting the app from the plugin's own cache.

(1) /gnome-software/plugins/flatpak/app-runtime-extension

7faa5b7... by Joaquim Rocha <email address hidden> on 2018-07-05

flatpak: Test updating an app to a version with an extension

When an installed app has no extension, but an update to it makes it
now use an extension, and the extension is available, then the extension
should be installed upon updating the app.

f7488c9... by Joaquim Rocha <email address hidden> on 2018-07-05

flatpak: Add missing app-extension test dir

The app-extension test dir (with a test app + extension) is being used
in the tests (because it's in the repos tarball) but is not part of the
source tree, so this patch adds it.

8d699a5... by Joaquim Rocha <email address hidden> on 2017-12-13

flatpak: Check if a related app is installed even when dealing with updates

When dealing with updates, gs-flatpak gets the list of related apps
(usually runtime extensions) that should be updated together with the
main app. However, if one of those related apps is not installed, the
gs_app_is_updatable call will return FALSE and the app will not be
This is a problem when e.g. a runtime extension has been mistakenly
removed, or when an app is updated and needs a new runtime extension.

This patch simply adds a further test for whether the app is installed,
together with the logic mentioned above.

e8ef085... by Joaquim Rocha <email address hidden> on 2018-05-23

Revert "Revert "flatpak: Use "list of related apps for install" when updating an app""

This reverts commit 79c14a2c67ec1ac459ace6c2e08dce74f78a9e16 and brings
back the ae5c13cc39eae89ab261bab44ea2fd0fc941f9d5 and

The mentioned functionality had been reverted in order for the release
3.28 but it's necessary for getting the related apps when updating apps.

3db3e55... by Kalev Lember <email address hidden> on 2018-07-05

Don't hardcode packagekit for Fedora upgrades

Instead adapt the upgrade GsApp in packagekit-upgrade and rpm-ostree
plugins, so that depending on which one is active either one can handle
the upgrade.

0763e8a... by Kalev Lember <email address hidden> on 2018-07-04

rpm-ostree: Implement distro upgrade downloading

This just hardcodes rebasing to ostree://fedora/%s/x86_64/workstation,
where %s is the next available distro version. In the future, we can
hopefully be smarter with contructing the refspec, but this is a start.

ec43729... by Kalev Lember <email address hidden> on 2018-07-03

update monitor: Only update the update check timestamp when it succeeds

When we do background update checks and fail to do a check (e.g. because
there's no network access), don't update the saved timestamp. This
ensures that we:

 a) continue trying to get updates and not give up for the day, and
 b) don't show misleading "Last checked: " text on the updates page on
    first launch when there's no network connection