This adds a sleep(1) before each summary update (if there is a
pre-existing summary file). This avoids issues where a new summary
file get the same mtime (in seconds precision).
This is kind of a hacky work around, but it is good enought to get
the flatpak-1.8 branch working with latest ostree, and master has a better
fix already.
We enforce --no-update-summary when we create test apps and
runtimes, and then we ensure we always manually call update_repo
after all modifications are done.
This means we save work avoiding summary updates, but it also means we
can do special handling in update_summary and guarantee that this is
the only place this happens. For example, we want this to work around
the mtime handling of summary updates.
In case a transaction is uninstalling both an app and its runtime,
properly ensure the app is uninstalled first.
(cherry picked from commit c6647c2b14)
Every http operation (even when successfull) was spewing info about
whether to retry it which made it hard to read the logs.
(cherry picked from commit 3ebcd200ca)
Sometimes a server might return a HTTP error 500 (this seems to happen
sometimes with Microsoft’s VSCode server, for example). Map this to
`G_IO_ERROR_HOST_UNREACHABLE` for now, which is a bit more specific than
returning `G_IO_ERROR_FAILED`, but without the hassle of introducing a
new public error domain which could give more detail.
In particular, this should allow gnome-software to show an error message
to the user for such failed downloads, rather than hiding the error and
logging the following:
```
not handling error failed for action download: While downloading http://packages.microsoft.com/repos/vscode/pool/main/c/code/code_1.45.1-1589445302_amd64.deb: Server returned status 500: Internal Server Error
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry picked from commit 6c79a57114)
We were clearing the error from the anon test, and then not doing any
non-anon auth, so error was NULL, causing a crash when returning an
error message.
(cherry picked from commit 180d807d2a)
Fix lookup_installation_for_path() to not leave the GError pointer unset
on its error code path. This error is only used by the caller for a
debug message, and shouldn't be hit normally, but it could mean a NULL
pointer dereference when we try to print error->message.
(cherry picked from commit 075c86ca4f)
In case we need to authenticate for updates (in my test case i was
doing an OCI downgrade) we might need to download a commit object (or
in the OCI case a manifest json), so it did a request_required_tokens(),
but that noticed during the flatpak_transaction_normalize_ops() call
that the partial resolve to a particular commit actually was the
same as the local installed commit and marked op->skip = TRUE.
However, when we got back to resolving the op again we didn't actually
look at the skip, so it kept looping wanting (but never doing) auth.
The fix is to just directly resolve ops marked as skipped.
(cherry picked from commit d8086141fb)
Runtimes also have appstream data - with description, license information,
and so forth, so we should extract the appstream data from the index
for refs that start with runtime/ as well.
(cherry picked from commit 25ff00994f)
Without this patch, the remote-info command will sometimes emit a
critical error "g_utf8_strlen: assertion 'p != NULL || max == 0' failed"
and print (null) for the "Commit:" field, since the commit doesn't get
initialized properly.
(cherry picked from commit 238317d99b)
This commit is a follow-up for the commit "dir: Validate locally
configured collection IDs". Whereas in that commit we validate the
collection ID in flatpak_remote_state_fetch_commit_object(), here we do
it in _flatpak_dir_get_remote_state(), since fetch_commit_object() is
not called on the code path normally taken for a transaction (only if
try_resolve_op_from_metadata() fails and in other niche scenarios).
This should ensure that if someone erroneously sets a collection ID on a
remote, the error will be caught quickly. It also helps the eos-updater
unit tests pass.
(cherry picked from commit 332f75494b)
If the initial anonymous fails for any other reason than "not authorized"
we immediately fail the operation instead of asking for user/password.
The later is creating a very bad UX in case of e.g. networking or
infrastructure issues, as described in #3753.
(cherry picked from commit 09d57249f4)
These are system dbus calls that could potentially be somewhat slow
and its unlikely that the local config changes during runtime of the
session (because the desktop really needs a restart to pick up a new
locale). Also, if there are any issues with these (such as #3755) each
call will be the 25sec dbus timeout, which is not great.
Fixes https://github.com/flatpak/flatpak/issues/3792
Add flatpak-sideload-usb-repo.service.in to EXTRA_DIST regardless of if
the --enable-auto-sideloading configure option was passed. This allows
building a tarball without that option and then building from the
tarball with the option.
This matches what is done in system-helper/Makefile.am.inc with
flatpak-system-helper.service.in.
Picked from https://github.com/endlessm/flatpak/pull/228
(cherry picked from commit f1383c10be)
In applications with --filesystem=host or --filesystem=host-os, the
library directories in /run/host/usr and /run/host/lib* can be used
like a sysroot to inspect the host's library stack, regardless of
whether the host system has undergone the "/usr merge" or not. This is
particularly relevant for Steam's pressure-vessel container tool,
which imports graphics drivers from the host system, or for potential
future work on using host graphics drivers via libcapsule in Flatpak
apps.
The original implementation of this feature assumed that the /usr merge
always creates symbolic links /foo -> /usr/foo or /foo -> usr/foo, for
some value of foo. However, Arch Linux uses a variation of multilib
in which /usr/lib contains 64-bit libraries, and has a non-matching
symbolic link /lib64 -> usr/lib (instead of a chain of symlinks
/lib64 -> usr/lib64 -> lib). Similarly, Arch uses /sbin -> usr/bin
and /usr/sbin -> bin, instead of a chain of symlinks
/sbin -> usr/sbin -> bin.
This led to Flatpak ignoring the symlink and treating it like a directory,
so the host /usr/lib would be bind-mounted on both /run/host/usr/lib and
/run/host/lib64. This is *mostly* equivalent, but whether a directory
is a symlink or a real directory sometimes matters, for example when
evaluating relative symlinks that contain ".." components; so try harder
to preserve symlinks as symlinks.
Fixes: 08d65c54 "exports: If --filesystem=host, provide /run/host/lib etc."
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 12e3dc051f)
This fixes the following error when the "flatpak mask" command is used
with the system-helper: "error: Unsupported key: masked"
(cherry picked from commit 73644b00c9)
An interesting side effect of #3770 was that the portal would loop
forever, waiting for a process to come up every 100ms. This isn't really
ideal; of course, *ideally* nothing would hang, but in practice this
can happen in unusual cases, and spamming the logs every 100ms when it
does isn't terribly ideal.
Now, if the process is not running after around 2 seconds, the repeat
timer is changed to a full second. This isn't perfect, but it would help
prevent bizarre problems becoming even more problematic.
(cherry picked from commit 6d3b30dc9a)
clone() is a mad syscall with about 4 different argument orders. While
most of them agree that argument 0 is flags, s390 and s390x have the
flags argument second - A0 is the child stack pointer there.
[smcv: Add an explanatory comment; also test __CRIS__ for completeness]
Bug-Debian: https://bugs.debian.org/964541
Bug-Ubuntu: https://launchpad.net/bugs/1886814
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 8ba141c38f)
Currently if the user configures a collection ID on a remote which is
incorrect, either because it doesn't match the one configured server
side or because the server doesn't have one configured at all, Flatpak
will not notice the issue and happily still pull from the remote. This
is new since 1.7.1; before that such a problem would be caught because
the server wouldn't provide the ostree-metadata ref for the configured
collection ID.
This commit catches such errors by checking commit metadata, as we
already do for the ref binding metadata. Otherwise such a mismatch would
prevent successful offline distribution of the apps/runtimes provided by
the remote.
The impetus for this is to keep an eos-updater unit test passing with
Flatpak 1.8.x:
"/updater/install-flatpaks-pull-to-repo-error-if-collection-id-invalid"
(cherry picked from commit 1bf5f2ed9e)
When --device=all is *not* passed to Flatpak, --dev is passed to bwrap,
which causes it to use an intermediate user namespace to mount devpts
because it can only be mounted as UID 0. Therefore, when expose-pids
is used, Flatpak will pass both --userns *and* --userns2 to handle
the presence of the intermediate namespace.
However, when --device=all *is* passed, there is no intermediate
namespace. Thus, setns(userns2) will fail with EINVAL. In order to
handle this, --userns2 is no longer passed if the namespace is
identical to that passed via --userns.
Fixes#3722.
(cherry picked from commit 9833b90019)
We already verify that the ref is not installed on add_ref(), so we
did check for "user error". If the transaction either raced with some
other process, or the install from the install-authentitcator signal
that should not be treated as an error.
Ensure we normalize ops before requesting authentication so we
can trust the op->skip value to be set for no-op updates (which
don't need authentication).
Currently Flatpak only supports extensions which come from the same
remote as the thing being extended; for discussion on this see
https://github.com/flatpak/flatpak/issues/861
However in general it isn't clear from the metadata what remote provides
an extension. For example com.endlessm.apps.Platform//5 defines the
extension org.freedesktop.Platform.VAAPI.Intel (inherited from
org.freedesktop.Platform) which can be found on flathub not eos-sdk. So
we don't want to add an extension refspec to the transaction if the
current remote is not the one that actually provides it. In
flatpak_dir_find_remote_related_for_metadata() this invariant is
maintained because we check if the ref exists in the remote before
adding it with add_related(). However in
flatpak_dir_find_local_related_for_metadata() we check for existing
deploy data but omit checking that the deploy origin matches the origin
passed in, and in that case can accidentally add an incorrect refspec to
a transaction. So this commit adds the missing origin check.
One way to reproduce this issue is with this command, having both the
Endless platform and the VAAPI extension already installed:
$ flatpak update --no-pull com.endlessm.apps.Platform//5
Looking for updates…
error: Refspec 'eos-sdk:runtime/org.freedesktop.Platform.VAAPI.Intel/x86_64/1.6' not found
This issue also affects GNOME Software which does a no-deploy
transaction followed by a no-pull transaction (this issue occurs in the
latter) and is treated as fatal causing updates not to be applied.
However it only happens in some niche circumstances, because
flatpak_transaction_add_op() will only use the first remote passed to it
if called more than once for the same ref from different remotes. This
is normally fine; refs generally only come from one remote. But it does
mean this issue only occurs if the extension in question was not already
added to the transaction with a correct origin.
Instead of relying on the runtime tzdate we now always expose the host
/usr/share/zoneinfo in that location and make /etc/localtime a regular
symlink to it. This means applications that parse the content of the
localtime symlink will work, and additionally it means that we're
guaranteed that the host configure timezone exists (and works with)
the tzdata in the app.
This unfortunately means we no longer make the localtime an indirect
file via the session helper, and thus that localtime configurations
are static over the lifetime of an app sandbox. However, I don't
think there is a workable solution to this.
This fixes https://github.com/flatpak/flatpak/issues/3338
We only want the run dir to be overridable in unit tests because we
depend on it being /run/flatpak in flatpak-create-sideload-symlinks.sh,
so don't mention it in the flatpak man page.
