Check the return value of repo_get_remote_collection_id like we do
in other places. This doesn't really affect the result, because
we return NULL both before and after in the failure case, but
it makes things clearer.
This means use x11 if no alternative is present, and should be used
for applications that support both X11 and wayland, but want to be
sandboxed when running under a wayland compositor (but still want to
run under an X server).
Closes: #1416
Approved by: alexlarsson
Emacs needs ADDR_NO_RANDOMIZE during the build, and its possible
that other things do too. Also this make sense, as personality
seems like a syscall on the level of ptrace() which is already
in devel.
Closes: #1414
Approved by: alexlarsson
This commit breaks out the code in flatpak_dir_check_for_update() that
finds the latest revision of a ref into its own function and uses it in
flatpak_dir_check_for_appstream_update(). This allows appstream updates
to work even for offline machines.
Fixes https://github.com/flatpak/flatpak/issues/1404Closes: #1397
Approved by: alexlarsson
Before doing an update, flatpak fetches remote repo metadata to find
related refs and other information. But after fetching the metadata
flatpak fetches the remote summary to get the checksum that was just
fetched, which can fail if the computer is offline. So instead get the
checksum by reading the local repo, which has the side benefit of
eliminating a race condition (the summary being updated right after the
fetch happens).
Closes: #1397
Approved by: alexlarsson
In the last step in a LAN app update when the system helper is called to
deploy the update, there's a call chain to pull from the temporary child
repo:
handle_deploy() ->
flatpak_dir_pull_untrusted_local() ->
repo_pull_one_local_untrusted() ->
ostree_repo_pull_with_options()
But since repo_pull_one_local_untrusted() isn't aware of the existence
of collection IDs, it doesn't pass a collection ID along to libostree
and sets gpg-verify-summary to true. This leads to the error "GPG
verification enabled, but no summary.sig found" because P2P code paths
don't use summary signatures.
Add the appropriate ostree pull options to
repo_pull_one_local_untrusted() so that P2P updates work when the
system-helper is used.
Fixes https://github.com/flatpak/flatpak/issues/1388Closes: #1397
Approved by: alexlarsson
Currently P2P flatpak app updates aren't working when
the system installation is being used (but they work for the user
installation). This is because there's a
flatpak_dir_remote_fetch_summary() call in flatpak_dir_update() which
fails if the machine isn't connected to the Internet. And in fact we
don't need to pull the summary from the system remote, we need the one
from the temporary P2P remote, and that gets pulled as a result of the
flatpak_dir_pull() call to get the ref because
OSTREE_REPO_PULL_FLAGS_MIRROR is used. So this commit changes
flatpak_dir_update() to avoid fetching the system remote summary fetch
when P2P support and collection IDs are being used.
Similar logic applies to flatpak_dir_install() and
flatpak_dir_update_appstream() (although P2P appstream updates don't
seem to be working yet).
This is a partial fix for https://github.com/flatpak/flatpak/issues/1388Closes: #1397
Approved by: alexlarsson
repo_get_remote_collection_id() already squashes empty ("") collection
IDs into NULL, and ignores the collection ID when P2P support isn't
enabled. So use that helper function in
flatpak_dir_get_remote_collection_id() for consistency. At the moment
that function is only used in tests, so this doesn't immediately affect
anything.
Closes: #1411
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
Instead of just assuming the default pulseaudio socket we look
at the same environment and config files that pulseaudio does.
This does not currently look at the X11 properties.
This is a cleaned up and rebased version of https://github.com/flatpak/flatpak/pull/1208Closes: #1410
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
The document portal is essentially optional, so avoid spewing errors
if it is not available, but also report this nicer with -v.
Closes: #1387
Approved by: alexlarsson
If you're exporting a path that the target app has access to but it is
read-only and the requested permissions include write access then
we create the document rather than reusing the path.
Closes: #1387
Approved by: alexlarsson
If a ref can't be found in a remote it could be because it's truly not
there or it could be that the collection ID configured locally doesn't
match the one on the remote. This commit improves the "No such ref"
error message to include the collection ID in two more locations in
flatpak-dir.c to make it easier to debug "wrong collection ID" errors.
Closes: #1384
Approved by: pwithnall
For security, only root can downgrade flatpaks in the system
installation. However, the error message explaining this when a normal
user attempts a downgrade was removed in commit 44cf5076f. This commit
adds back the error message.
Since the current behavior is for a downgrade by a non-root user to fail
with the message "No updates", this commit doesn't fix a security issue.
It's purely about usability.
Fixes https://github.com/flatpak/flatpak/issues/1303Closes: #1366
Approved by: alexlarsson
It’s somehow possible (I haven’t investigated how) for
flatpak_dir_setup_extra_data() to be called before the main keys (such
as `outstanding-fetches`) are set on a new OstreeAsyncProgress during a
flatpak_dir_pull() call with no OstreeAsyncProgress object provided by
the caller.
This means that an OstreeAsyncProgress with only the extra-data keys
would be passed through to
ostree_repo_pull_default_console_progress_changed(), which would cause
an assertion failure when it tried to read the `outstanding-fetches`
key.
Avoid that by not calling
ostree_repo_pull_default_console_progress_changed() until
`outstanding-fetches` is set.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1361
Approved by: alexlarsson
We no longer run appstream-builder (see commit 455d3a7b2) so update the
documentation for the --update-appstream option.
Closes: #1360
Approved by: alexlarsson
Since flatpak_export_paths_export_context and flatpak_exports_from_context
are now in flatpak-context.c we make them begin with flatpak_context_
Closes: #1374
Approved by: alexlarsson
