I got weird crashes in the local repo pull case where the default
progress reporting callback tried to get some unset key on
the progress. We don't want any progress reporting anyway, so fix
this by dropping all progress reporting.
Closes: #1243
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
We regressed on supporting --filesystem=xdg-config/kdeglobals:ro which
would create a "kdeglobals" in the apps own XDG_CONFIG_DIR which has
content from the host one. This broke in
f1df5cb1d9
where we added a symlink resolve, but that breaks when the target file
doesn't exist.
It seems like all callers rely on just the final element of the destination
path being created, so lets just resolve symlinks on the dir part.
Closes: #1229
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 tries to ensure that FlatpakDir->repo is set, but if the
repo doesn't exists and we're unable to create it that is fine
and we continue running with repo == NULL.
This is useful because there are only a few operations that really
are useful/make sense with no repo set up, and we can ensure these
handle this well.
In particular, we want to allow flatpak remote-add using the
system-helper to work even if /var/lib/flatpak doesn't exist, so that
we can bootstrap a working flathub from a fresh /var.
Closes: #1195
Approved by: alexlarsson
Some apps, such as gnome-builder wants to access data from the
host, for instance in builders case the system includes. If you
have full filesystem access it is not really a loss of security
to also have /ect and /usr access, but for technical reasons
we can't expose them in the normal locations. However, we
can expose them in /run/host, so do that.
Closes: #1193
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
I think this enhances readability significantly, reduces code duplication
and allows you to follow the rationale behind why monitors are being
added/removed a lot more clearly than the previous nested/ad-hoc logic in
file_changed. Also adds debug printouts in the case that file monitors
are not created successfully.
Closes: #1194
Approved by: pwithnall
The monitor data structures are never replaced in the hash table, so
it's not necessary. Keep MonitorData pointers in scope in main() and
set up g_autoptr instead.
Closes: #1194
Approved by: pwithnall
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
