Add a flag that triggers extra processing of the 'rest'
commandline arguments, as follows: When we see arguments
that are enclosed in a pair of '@@' arguments, we interpret
them as file paths, export them in the document store, and
pass the resulting document path to the launched application.
Currently, the files are exported non-persistent (i.e. only
for the current session), and with read and write permissions
for the app.
Add an annotation that lets us pass an fd-list to
the generated wrapper around Add(). This is more
convenient than calling the method manually.
Currently, we have no callers for the wrapper, so
this does not affect any other code.
Its quite possible that a custom TMPDIR is not mapped
in the sandbox, and /tmp is per-app anyway, so it doesn't
really make sense to use the custom one.
Fixes https://github.com/alexlarsson/spotify-app/issues/41
At least, to the extent that it is needed for tests to pass.
If any of --show-ref, --show-commit, --show-origin or --show-size
are given, emit the previous one-line format. Otherwise, use the
new, friendly multi-line format.
Sometimes we need to pull a commit without using static deltas to e.g.
make sure that an app with a corrupted commit can still be updated by
pulling the new commit in full.
This option has been added to the FlatpakUpdateFlags,
FlatpakInstallFlags, as well as a parameter for the CLI.
The script was using stdout=subprocess.STDOUT but the Popen
documentation does not mention this as a valid value.
An exception was being thrown when running flatpak-bisect <name> log:
OSError: [Errno 9] Bad file descriptor
Show the installed and download size for each ref,
when --show-details is given. The tabular display
could be improved by making FlatpakTablePrinter support
alignment at the decimal point.
This is a pretty standalone object, and it is nicer to
have it in its own files. All users have been updated
to include the new flatpak-table-printer.h header.
After the introduction of linear progress reports based on
heuristics, Flatpak still couldn't make precise reports for
the extra-data field is contained in the commits. When we
were setting extra-data up, Flatpak didn't have the commits,
so it always failed.
Fix that by downloading the commits first, and then setting
up the extra-data fields.
flatpak/flatpak#609
Some previous g_set_error messages were related to 'unknown type', but this one about 'unknown location'. So it would probably be best to suggest 'valid locations', instead of 'valid types'.
Matthias Clasen