1. 29 Jul, 2020 12 commits
    • Matthew Leeds's avatar
      flatpak: Set apps to installed upon missing runtime install · 87b8de86
      Matthew Leeds authored
      This commit is a rework of
      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 ..."
    • Matthew Leeds's avatar
      flatpak: Set app to installed when a related thing is updated · dd100c88
      Matthew Leeds authored
      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.
    • Matthew Leeds's avatar
      flatpak: Update progress for some skipped ops · b6f7d5d6
      Matthew Leeds authored
      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.
    • Matthew Leeds's avatar
      flatpak: Rename an internal function argument · 99284d57
      Matthew Leeds authored
      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.
    • Matthew Leeds's avatar
    • Matthew Leeds's avatar
      flatpak: Set extensions to updatable properly · decd0aa9
      Matthew Leeds authored
      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.
    • Matthew Leeds's avatar
      flatpak: Fix gitignore in test data dirs · f2a1e052
      Matthew Leeds authored
      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
    • Matthew Leeds's avatar
      flatpak: Fix app extension in tests · 8c7cb13f
      Matthew Leeds authored
      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
    • Umang Jain's avatar
      flatpak: Enable tests related to extensions · 45aad529
      Umang Jain authored
      Tests were skipped in 15c6a8d1 due to missing files. Add the files,
      so that the tests can be re-enabled again.
    • Matthew Leeds's avatar
      Add vim modelines and missing emacs modelines · ca51adc4
      Matthew Leeds authored
      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.
    • Phaedrus Leeds's avatar
      flatpak: Use g_assert_true() in self tests · b52aa1a8
      Phaedrus Leeds authored
      g_assert() can be accidentally compiled out with G_DISABLE_ASSERT;
      g_assert_true() cannot.
    • Matthew Leeds's avatar
      flatpak: Fix self tests RuntimeRepo warning · 30a9cfde
      Matthew Leeds authored
      Flatpak now emits a warning when RuntimeRepo isn't present in a
      flatpakref, so add it to fix the unit tests. See
  2. 27 Jul, 2020 1 commit
  3. 23 Jul, 2020 1 commit
  4. 21 Jul, 2020 1 commit
  5. 18 Jul, 2020 2 commits
  6. 12 Jul, 2020 1 commit
  7. 11 Jul, 2020 1 commit
  8. 10 Jul, 2020 1 commit
  9. 08 Jul, 2020 4 commits
  10. 07 Jul, 2020 7 commits
  11. 06 Jul, 2020 3 commits
    • Richard Hughes's avatar
      fwupd: Add support for the update action · cf565603
      Richard Hughes authored
      Some future dock hardware needs the user to manually restart it after the update
      has completed. This patch adds the update-action functionality and shows a
      dialog box just like the existing detach-action one.
    • Richard Hughes's avatar
      Do not use GsApp screenshot for transient screenshots · bea12331
      Richard Hughes authored
      We currently support showing the user a screenshot which provides a more
      friendly way to put a device into bootloader mode. Devices that support this
      currently add a screenshot to the GsApp and then it gets shown before the update
      is applied.
      This isn't really suitable as when the update has been installed we then show
      the screenshot prominently in the details page, which is really confusing.
      It's a transient screenshot that's only requried for GsAppFlags _USER_ACTION so
      give the property it deserves.
    • Richard Hughes's avatar
      fwupd: Send our implemented feature set · 7235af26
      Richard Hughes authored
      At the moment we just blindly assume the capabilities of the front-end client
      when installing firmware. We can somewhat work around this limitation by
      requiring a new enough fwupd daemon version, but the GUI client software may be
      much older than the fwupd version or just incomplete.
      Clients that do not register features are assumed to be dumb and won't be
      offered firmware that has a hard requirement on showing text or screenshots.
  12. 05 Jul, 2020 1 commit
  13. 03 Jul, 2020 3 commits
  14. 02 Jul, 2020 1 commit
  15. 01 Jul, 2020 1 commit