The idea is that when an app's runtime is missing, or one of its
should-download related refs is missing, the app will be returned as
updatable by flatpak_installation_list_installed_refs_for_update(), and
will be subsequently added to a transaction by gnome-software. Progress
updates on the app are calculated using the progress of the related
operations. However if the app itself doesn't need an update,
_transaction_operation_done() will never be called for it and so its
state never gets set to AS_APP_STATE_INSTALLED. Fix this by setting the
app to installed when the related thing is, if the app is being skipped
and the related thing is the last operation in the transaction needed
for the app.
It would be great to add a unit test for this, but there's no way
through the flatpak plugin's API to uninstall an app's runtime without
uninstalling the app, so we'd have to do something tricky like call out
to "flatpak uninstall --force-remove ..."
dd100c8...
by
Matthew Leeds <email address hidden>
flatpak: Set app to installed when a related thing is updated
When an app's locale extension is updated but the app is not, we put
progress updates on the app so they are user visible. However since
_transaction_operation_done() is only ever called for the locale, the
app never gets set to AS_APP_STATE_INSTALLED and instead gets frozen in
the "Preparing..." state when gs_plugin_loader_helper_free() sets the
progress to GS_APP_PROGRESS_UNKNOWN on it.
So set the app to installed when one of its related refs is updated, if
the app itself is being skipped.
Relatedly, update the unit test which tests extension updates so it
succeeds with Flatpak older than 1.7.3, because the changes in this
patch aren't active for those versions.
b6f7d5d...
by
Matthew Leeds <email address hidden>
flatpak: Update progress for some skipped ops
Currently we don't do any progress updates (gs_app_set_progress()) for
operations in a FlatpakTransaction that are skipped. This is problematic
in some situations such as when an app or runtime is up to date but its
locale extension needs an update to add a language (because the user
changed the system language since installing it). In these situations,
the app's progress is stuck at "Preparing..." forever and never gets to
1%. Fix the issue by updating progress for even skipped operations (in
which case the progress calculation excludes the size of the app itself
and only takes into account related operations' size).
Ideally we would test this situation in gs-self-test.c, which already
has a test for an extension update and connects to
notify::progress on the main app, but in practice adding
"g_assert_cmpint (progress_cnt, >, 0);" after "g_assert
(got_progress_installing);" leads to that assertion failing. It seems
the progress is only ever updated to GS_APP_PROGRESS_UNKNOWN even though
in actual use this works. I also tried adding 100 MB to extension update
in case the update was too small for progress to work, but still no
luck. gs_plugins_flatpak_app_update_func() has its assertion on
progress_cnt commented out, so I guess something is wrong even in the
case where there are no extensions.
99284d5...
by
Matthew Leeds <email address hidden>
flatpak: Rename an internal function argument
Currently in update_progress_for_op_recurse_up() we call
update_progress_for_op() with root_op as the second-to-last argument,
but the implementation has the last argument called root_op, which is
pretty confusing. So rename that variable to current_op which is
accurate: it is always the operation in progress which triggered
_transaction_progress_changed_cb(). Also rename op to root_op so it
matches the variable name in update_progress_for_op(). The root_op is
the op for which we are updating progress and it is always related to
current_op, directly or indirectly.
This introduces no functional changes.
c9d2df0...
by
Matthew Leeds <email address hidden>
flatpak: Make related ops debug message more helpful
decd0aa...
by
Matthew Leeds <email address hidden>
flatpak: Set extensions to updatable properly
This avoids the warning "State change on
user/flatpak/test/runtime/org.test.Chiron.Extension/master from
installed to installing is not OK", by setting the extension to
updatable when it is, even though this won't be reflected in the UI (the
state on the main app will be).
I have also seen this warning when updating an extension for real, not
just in the unit tests.
f2a1e05...
by
Matthew Leeds <email address hidden>
flatpak: Fix gitignore in test data dirs
Every other directory ignores the app-info directory which gets created
by build.py so ignore it in app-update too. Also ignore the repo
directories which are also made by build.py and stored in
flatpakrepos.tar.gz
8c7cb13...
by
Matthew Leeds <email address hidden>
flatpak: Fix app extension in tests
Unlike other runtimes, extensions use a "files" subdirectory when
building instead of "usr". So fix the test app extension and build.py to
account for that. Also modify chiron.flatpak and flatpakrepos.tar.gz as
a result of running build.py
Tests were skipped in 15c6a8d15 due to missing files. Add the files,
so that the tests can be re-enabled again.
ca51adc...
by
Matthew Leeds <email address hidden>
Add vim modelines and missing emacs modelines
Add vim modelines to the files which only had emacs modelines, and add
modelines to src/gs-shell-search-provider.[ch] and lib/gs-ioprio.[ch]
which didn't have any. This makes it much easier to not accidentally use
spaces instead of tabs.
