The remote-ls command should skip remotes that have "xa.disable" set to
true or have no URL set, which can happen for remotes added for flatpak
bundle files.
Fixes https://github.com/flatpak/flatpak/issues/1427Closes: #1457
Approved by: alexlarsson
If the --show-details option is passed to the remotes command, show the
collection ID for each remote, which the user might need to know if
they're using flatpak's P2P support.
Closes: #1458
Approved by: alexlarsson
This isn't needed for servers and starting the a11y bus on a
fresh session bus takes upwards of 15 seconds.
Fixes#1471Closes: #1486
Approved by: alexlarsson
Currently the search command only searches remotes for apps and runtimes
that match the host architecture. This commit makes flatpak include all
supported architectures so for example you can see a 32-bit app on a
64-bit computer.
Fixes https://github.com/flatpak/flatpak/issues/1353Closes: #1430
Approved by: alexlarsson
On atomic, /home is a symlink to /var/home, which caused
problems in flatpak build when granting access to the homedir.
Due to a previous workaround (in 1aadc3ee40) we
make /var in the flatpak build sandbox be completely overridden
with $builddir/var so that the above symlink would not cause problems
in the persisted directory.
However, when we actually *want* to give access to that symlink this
causes problem.
In general, exposing /var in the sandbox has two uses:
* Allowing persisting tmpfiles in /var/tmp between individual
flatpak build commands (/tmp is per-build-command).
* Creating flatpaks from packages, such as rpms, where
we want to keep the rpm database (/var/lib/rpm) around during
the entire build so that dependencies can be resolved.
In order to handle these /var/home issues while still allowing
the above issues we instead persist only /var/tmp and /var/lib.
Fixes https://github.com/flatpak/flatpak/issues/1407Closes: #1421
Approved by: alexlarsson
When copying a commit, also bring forward any static deltas.
This is particularly interesting for flathub where we can
then generate static deltas on the build machines and then import
and sign it on the repo machine.
Closes: #1409
Approved by: alexlarsson
This fixes build-export so that it doesn't try to use uninitialized
memory in a timestamp object when creating appstream data. Before the
--timestamp option existed, a timestamp of 0 was used, so fall back to
that. Also, update a relevant comment.
Closes: #1408
Approved by: alexlarsson
For the "flatpak update" it makes sense to print a message when updating
the appstream data for each remote, but it makes less sense for the
search command, because it's output should just be the table of results.
Closes: #1352
Approved by: alexlarsson
Updating the appstream data on every invocation of the search command
involves a lot of overhead, so instead only update it if it's at least a
day out of date. This is consistent with how tools like dnf work.
Closes: #1352
Approved by: alexlarsson
This commit changes the search command to update appstream data from
each remote before searching it for the specified text. This way
users don't need to know to run "flatpak update --appstream".
Fixes https://github.com/flatpak/flatpak/issues/1339Closes: #1352
Approved by: alexlarsson
All flatpaks built using version 0.9.4 or newer should have the
xa.metadata field in the commit metadata, so warn if it doesn't exist.
This commit changes the info command to print a warning rather than
nothing and changes the info-remote command to print a warning rather
than error out.
Closes: #1351
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: #1351
Approved by: alexlarsson
This is now in xdg-desktop-portal. We keep a version of the document
portal dbus XML so that we avoid weird build dependencies.
Flatpak itself is technically not dependent on the document portal,
but it is very much recommended that you use it.
Closes: #1398
Approved by: alexlarsson
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
