When the specified remote existed, but had no updates we printed
a message like: error: Remote "flathub" not found
Closes: #1363
Approved by: alexlarsson
If flatpak is compiled with P2P support and the commit in question has a
collection ID in its metadata, show it.
Closes: #1312
Approved by: alexlarsson
When the --show-metadata option is used with remote-info, the metadata
variable is never initialized, causing flatpak to print "(null)". This
commit makes sure the variable is properly initialized so the metadata
prints correctly.
Closes: #1313
Approved by: alexlarsson
When a remote is found in multiple installations and we ask "Which do
you want to use (0 to abort)?", the 0 choice isn't working because the
min value in the call to flatpak_number_prompt() was set to 1. Fix that
so the user can abort if they want.
Fixes https://github.com/flatpak/flatpak/issues/1305
The error wasn’t being propagated properly, leading to a NULL pointer
dereference.
Coverity CID: 1463075
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1267
Approved by: alexlarsson
If the remote is a local path (absolute or relative starting with ./)
then we convert this to a file: uri, which are now supported to
install directly from a local repo.
This is very useful when testing locally built apps.
Closes: #1244
Approved by: alexlarsson
If you're installing something and its already installed, we undeploy
the old install first before deploying the new. This makes it very
easy to switch an application from one remote to another, without
having to uninstall first, which is both painful and could cause
the download to be unnecessary large.
Closes: #1241
Approved by: alexlarsson
This lets you add overrides that affect all applications. Application
overrides have higher priority so will override the global overrides.
Closes: #1245
Approved by: alexlarsson
This is a no-op on regular (archive) repos, but on bare repos it is
an optimization if the source is a checkout from the repo. This
happens in flatpak-builder (https://github.com/flatpak/flatpak-builder/pull/81)
when it commits the build to the cache during --install without --repo.
Closes: #1249
Approved by: alexlarsson
Now that flatpak update does both per-user and systemwide
per default it makes a lot of sense to say which one is being
updated.
Closes: #1248
Approved by: alexlarsson
I got this:
app/flatpak-main.c:364:20: warning: variable 'dir' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
else if (opt_installations != NULL)
^~~~~~~~~~~~~~~~~~~~~~~~~
app/flatpak-main.c:374:34: note: uninitialized use occurs here
g_ptr_array_add (dirs, dir);
^~~
app/flatpak-main.c:364:16: note: remove the 'if' if its condition is always true
else if (opt_installations != NULL)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
app/flatpak-main.c:358:26: note: initialize the variable 'dir' to silence this warning
FlatpakDir *dir;
^
= NULL
However, that is never hit, its just the compiler being confuses, so we add a
g_assert_not_reached() in the last else case.
Reachability analysis:
If opt_installations is != NULL we will at the very least take the
last if, and if opt_installations == NULL, we will take the first one
if !opt_user, and the second if opt_user.
Closes: #1251
Approved by: alexlarsson
Now that flatpak_resolve_duplicate_remotes checks if a remote exists, we
don't need to use ostree_repo_remote_get_url to do so. This commit
doesn't change the behavior for remotes with empty URLs (which means
they're disabled), because the empty string is an allowed value as far
as OSTree is concerned.
Closes: #1247
Approved by: alexlarsson
We should use the same flags for the flatpak_option_context_parse() call
in flatpak_complete_list_remotes as we do in
flatpak_builtin_list_remotes, so the options are parsed correctly.
Closes: #1205
Approved by: alexlarsson
Currently "flatpak remotes" shows remotes across user and system
installations, but other remote commands (remote-delete, remote-modify,
remote-ls, remote-info) only work on one installation: the system one
unless overridden using --user or --installation. This commit changes
each command to infer the correct installation by checking which has
the specified remote. In case multiple installations have remotes by
the same name, the user is prompted to decide which to use.
This commit also adds unit tests and updates the man pages for the
aforementioned commands.
Fixes https://github.com/flatpak/flatpak/issues/787Closes: #1205
Approved by: alexlarsson
Some builtin flatpak commands work on a single installation, and others
work on multiple installations (such as the remotes command that lists
both system and user remotes). Currently flatpak_option_context_parse()
only supports returning one installation to its caller, and any commands
that want to support multiple installations have to implement that
themselves which leads to a lot of code duplication.
This commit changes flatpak_option_context_parse() to take three new
flags:
* FLATPAK_BUILTIN_FLAG_ONE_DIR maintains the old behavior by
returning one installation (i.e. user if --user was passed, system if
--system, etc.).
* FLATPAK_BUILTIN_FLAG_STANDARD_DIRS will get all the installations
specified by the options, or the user and system ones if none were.
* FLATPAK_BUILTIN_FLAG_ALL_DIRS includes non-default system
installations along with the user and system ones if none were
specified.
These flags also affect what options are parsed and whether the
directories are ensured to exist, so it makes sense in some
circumstances for callers to pass a NULL out_dirs even when not using
FLATPAK_BUILTIN_FLAG_NO_DIR.
This commit also changes all the callers of
flatpak_option_context_parse() so they maintain their behavior. The only
functional change introduced by this is that using --installation
multiple times for commands that only support one now leads to an
error emitted by flatpak rather than by g_option_context_parse().
A follow-up commit will use this refactoring to make many commands
behave more intelligently in determining which installation to use.
Closes: #1205
Approved by: alexlarsson
The "flatpak remote-ls" command can be used without specifying a remote,
so change the man page and --help output to reflect that.
Closes: #1210
Approved by: alexlarsson
This means flatpak can bootstrap itself from an empty /var on stateless
systems, which fixes https://github.com/flatpak/flatpak/issues/113, at
least for the CLI case.
Closes: #1195
Approved by: alexlarsson
This replaces the old unused FLATPAK_BUILTIN_FLAG_NO_REPO with a
version that tries to init the repo, but doesn't fail otherwise.
Also, we drop the explicit flatpak_dir_ensure_path() call, because
flatpak_dir_ensure_repo() calls that anyway.
Closes: #1195
Approved by: alexlarsson
This adds the Date, Subject and Parent fields that are shown
by remote-info so these match for the fields where it makes sense.
Closes: #1192
Approved by: alexlarsson
This changes the search command to print debug output when accessing a
flatpak directory, to match the behavior of other commands.
Closes: #1186
Approved by: TingPing
The other commands that support --user and --system allow you to specify
an installation using --installation, so this makes search consistent
with that.
Closes: #1185
Approved by: TingPing
This shows information about a ref in a remote. Of particular interest
is the --log option which gives you a history which can be used
with update --commit=XXX to roll back an update.
Closes: #1174
Approved by: alexlarsson
This means the url of the remote is a service supporting:
https://github.com/owtaylor/metastore/blob/master/docs/protocol.md
And we use that to find all flatpak images and the repository url
itself.
This also add support for docker-v2 registries that support OCI
images.
Closes: #1171
Approved by: alexlarsson
This makes /app (or other destinations) read-only, which will be
later used by flatpak-builder when running tests, that should not
affect the build.
Closes: #1172
Approved by: alexlarsson
This variable is never actually read, as it is protected by
the ostree_metadata_checksum check, but some compilers warn about it.
Closes: #1178
Approved by: mwleeds
* Update appstream data on "flatpak update"
This is especially useful since we now have flatpak search which uses
this data.
* fixup! Update appstream data on "flatpak update"
Due to the way as_app_search_matches() works, "flatpak search" only
checks if the search text is a prefix of an element of the app ID, not
if it's any substring. Add a substring check, so for example you can
find SuperTuxKart using "flatpak search tuxkart".
Closes: #1161
Approved by: TingPing
The code assumes that *all* refs in a remote contain a slash, which
technically is not the case, and pragmatically is definitely not the
case once the remote has an ostree-metadata ref.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1153
Approved by: mwleeds
If `flatpak repo --info` is run on a repository which doesn’t have a
summary file, or an ostree-metadata branch, it previously printed a very
unhelpful, unadorned, ‘No such file or directory’. Add a bit more
context to that error message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1155
Approved by: cgwalters
On RHEL7 compiler I got things like:
app/flatpak-builtins-search.c:196:3: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (guint j = 0; j < remote_stores->len; ++j)
Maybe we should allow this and tweak the warnings, but for now, just make it build.
Closes: #1151
Approved by: alexlarsson
