When calculating the progress of a flatpak installation,
it considers the extra-data and OSTree pull as different
operations and that makes the progress to go back and
forth between 0% and 100%.
Consumers of this API, like GNOME Software, end up having
a bad experience reporting the progress of a Flatpak app
instalation.
Fix that by using a set of heuristics to improve the process,
splitting the operation in parts that can be tracked (or at
least estimated).
By splitting the extra-data setup - where we set the number of
extra-data downloads and auxiliary information - and download -
where we actually fetch the extra-data - we can have more precise
progress reports.
* Append flatpak data dirs if XDG_DATA_DIRS is already set
Otherwise it will be impossible to run flatpak apps from desktop menus.
This issue can happen if another app (e.g. snapd) wants to add custom
folders to XDG_DATA_DIRS through /etc/profile.d
If XDG_DATA_DIRS is empty or unset, define it as before.
Fixes#606
A few options aren't documented in the manpages. This commit adds
documentation for them based on the --help output and relevant commit
messages. Some of it could probably use more elaboration.
For a few commands the options aren't fully documented. This commit
makes the manpage documentation (almost) match the options shown
when you run "<command> --help" on the command line.
This means an extension point can include extensions of multiple
(specified) versions. This is useful for e.g. the GL extensions,
where we want a single extension for all the essentially unversioned
GL extensions (like the nvidia one) that is used by all the
runtimes.
This is useful for modules that don't have a make install rule.
You can use the new build-commands which is run after make to
create your own custom installation phase.
Fixes https://github.com/flatpak/flatpak/issues/458
Currently if you pass flatpak-run an app that's not installed it prints
an error message to that effect, but if you pass it a runtime that's not
installed (and use the full ref format, e.g.
runtime/org.gnome.Sdk//master) it prints this message and crashes:
(flatpak run:15104): GLib-CRITICAL **: g_propagate_error: assertion 'src != NULL' failed
flatpak:ERROR:app/flatpak-main.c:394:flatpak_run: assertion failed: (success || error)
This commit makes flatpak print the appropriate error message, while
still printing an "app not found" error if the user didn't specify
whether the ref is an app or runtime.
The ability to use flatpak-run to enter into a shell in a runtime was
added in flatpak 0.6.13 but the docs weren't updated to reflect that.
This commit updates the flatpak-run documentation to explain the
functionality.
We're doing a post-commit checkout directly to the app dir, which
means the fuse filesystem cache may get out of sync with the backing
directory. So, to ensure this doesn't happen we mount a fresh rofiles
fs for each build.
Since we now only look at changed files we need to handle
the case where a .py file changed and the .pyc didn't, and
remove the now stale .pyc files.
Previously we looked at all files, so we detected this via
the stale .pyc file.
The CLI is pretty similare to the `git bisect` one and works as follow:
$ flatpak-bisect org.app.App start # Update application and get the history
$ flatpak-bisect org.app.App bad # Sets current commit as first bad commit
$ flatpak-bisect org.app.App checkout GoodHash # Checkout the first known good commit
$ flatpak-bisect org.app.App good # Sets GoodHash as first good commit
... Here it starts bisection and checkouts a commit on the way, the user should launch the
app to check if the commit is good or bad and run:
$ flatpak-bisect org.app.App good # if commit is good
$ flatpak-bisect org.app.App bad # if commit is bad
flatpak-bisect will tell when the first bad commit is found.
Fixes https://github.com/flatpak/flatpak/issues/530
