When we deploy e.g. app/org.foo.bar/x86_64/stable, then we
also create a deploy/app/org.foo.bar/x86_64/stable ref pointing to
the latest deployed commit. We also remove it when an app is uninstalled.
This means that a prune operation will not delete objects that are deployed
(which would not save any space anyway). This is nice because this can
happen for instance when you flatpak update --no-deploy.
Fixes https://github.com/flatpak/flatpak/issues/2085Closes: #2563
Approved by: alexlarsson
When a running cli transaction is interupted by Ctrl-C,
we exit with a hidden cursor. Add a signal handler which
shows the cursor before exiting.
Closes: #2561Closes: #2570
Approved by: alexlarsson
Use OPTIONAL_REPO since an empty repo seems repairable,
and also dont stop completing options after the second.
This is a copy-paste error from other completion functions.
Closes: #2585
Approved by: alexlarsson
This lets completion keep working after you type
flatpak remote-add --installation=empty
We already use OPTIONAL_REPO in the command, so there
is really no reason to not do the same for completion.
Closes: #2585
Approved by: alexlarsson
This lets completion keep working after you type
flatpak make-current --installation=empty
It is somewhat cosmetic since there's nothing to
install on an empty repo, but no need to silently
disappear the remaining options.
Closes: #2585
Approved by: alexlarsson
This lets completion keep working after you type
flatpak install --installation=empty
It is somewhat cosmetic since there's nothing to
install on an empty repo, but no need to silently
disappear the remaining options.
Closes: #2585
Approved by: alexlarsson
The --list and --get implementations work just fine
on empty repos (reporting the default values). So
don't err out prematurely during option parsing.
Closes: #2585
Approved by: alexlarsson
Move the code that is handling the empty options
(--version, etc) to the one place where we parse them.
This gets this code out of the completion path and
make flatpak_option_context_parse easier to understand.
Closes: #2585
Approved by: alexlarsson
We never want g_option_context_parse to produce help
output when we are in the middle of completion.
But we still want to see --help, -h, -? among the
completions.
To achieve that, disable the built-in help and add
(ignored) help entries to our option context when
we are completing.
Closes: #2585
Approved by: alexlarsson
It's no longer true that it's the pull code's job to resolve a ref to a
specific commit. Ever since commit 66eee3c2c this is the job of the
resolve_ops() function used by FlatpakTransaction (at least, when a
transaction is being used). So update a couple comments to avoid
confusion.
Closes: #2587
Approved by: alexlarsson
The generated DBus permission header is included by an header in under
app/ that we include from testcommon.c. We already added the app/
directory under the source directory, but we need to include the same
directory under the build directory in order for the compiler to find
the generated header.
Fixes the build in GNOME Continuous, which is failing with:
```
In file included from ../tests/testcommon.c:10:0:
../app/flatpak-builtins-utils.h:28:47: fatal error: flatpak-permission-dbus-generated.h: No such file or directory
compilation terminated.
```
This tests the situation when we can't accommodate
the requested width with the available shrinkage.
This used to cause an infinite loop in the table
printer.
Closes: #2498
Approved by: matthiasclasen
We may not want to guarantee all the formats that this
datetime parser accepts, but NOW seems useful enough and
is already mentioned in flatpak-build-commit-from(1).
Closes: #2498
Approved by: matthiasclasen
Add another test that links against libflatpak-common.la
and tests functions that are not part of the public
library api.
Closes: #2498
Approved by: matthiasclasen
