Similarly to commit 272af0f8c, this commit makes sure the child repo
used by the system helper has an accurate summary file so it can be
pulled from. This time it's for the fetches of the ostree-metadata ref
and the appstream data.
This fixes a bug that occurs if a remote has a collection ID set and
uses the "branches" key as well. Under those conditions, `flatpak
remote-ls -d REMOTE` and `flatpak update --appstream REMOTE` can fail
with "Error pulling from repo: No summary found".
Until recently, the /ostree/repo/config in Endless contained a remote
that was shared between flatpak and ostree, which had "branches" set. So
that's a use case where this helps.
Fixes https://github.com/flatpak/flatpak/issues/1440Closes: #1478
Approved by: pwithnall
After pulling multiple refs into the child repo using P2P code, the
summary file in the child repo will be the one from the last remote
used. Since that remote might be a peer on the network or a USB drive,
it may not have the same set of refs as were pulled into the child repo.
This means that when the system helper tries to pull from the child repo
into the main repo it fails because the summary file is inaccurate.
This commit addresses the issue by regenerating the summary file in the
child repo after the pulls finish. This has to only occur on the P2P
code paths because non-P2P code uses the summary file and its signature
as the security check.
To check that this fixes the bug, I set up another computer on the local
network as an update server and made sure it had an updated
ostree-metadata ref for the remote I'm going to use. Then from this
computer with the patched flatpak I installed an app that's **not**
installed on the update server (all using collection IDs). Flatpak
fetched the app from the Internet, fetched the ostree-metadata ref from
the network peer, and then successfully pulled and deployed the app into
the system repo.
Fixes https://github.com/flatpak/flatpak/issues/1425Closes: #1476
Approved by: pwithnall
Apparently when I rebased https://github.com/flatpak/flatpak/pull/1314
to master, git cleanly applied the patch in a different place than it
was originally. Commit c5ab9e22b moved the find_remotes_async() call to
find_latest_rev(), so all that needs to be done is pass along the
checksum in check_for_update(). This way when you're trying to downgrade
something the specified commit will be searched for instead of the
latest one.
Fixes https://github.com/flatpak/flatpak/issues/1431Closes: #1435
Approved by: barthalion
Now that the search command is attempting to update appstream data for
all supported architectures, error messages get printed when it's
missing, which is often the case for i386. This commit changes
flatpak_dir_check_for_appstream_update() to only print an error if the
the appstream data for the host architecture is missing, but not if it's
a secondary architecture.
Closes: #1430
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
Before the 2018.2 release of libostree there was no way to specify
commit IDs when using find_remotes_async(). The latest commit is always
pulled, so flatpak apps can't be downgraded when collection IDs are in
use. Now that an option is provided by libostree this commit uses it,
and updates the minimum required version to 2018.2 when P2P support is
enabled.
The effect is that `flatpak update --commit=HASH APP` will work when APP
comes from a repository that has a collection ID configured.
Fixes https://github.com/flatpak/flatpak/issues/1309Closes: #1314
Approved by: pwithnall
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
The process was printing a line for every mismatching component id
in the xml for each app, which is starting to get very large log files
on flathub.
Closes: #1426
Approved by: alexlarsson
On atomic /home is a symlink to /var/home, so when we bind-mount
the persistent directories we need to early-resolve the symlinks
to avoid running into issues with /newroot.
In most cases we do this already by calling flatpak_bwrap_add_bind_arg,
but the persistent dir case did not, because that function required
the target to exist, and the persistent directoried might not.
However, these days flatpak_bwrap_add_bind_arg is fine if the base
dir doesn't exists but the target does, which is the case here,
so we can use it now.
This fixes e.g. steam: https://github.com/flatpak/flatpak/issues/1278Closes: #1422
Approved by: cgwalters
This was needed for the document portal, which has been removed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #1417
Approved by: alexlarsson
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
