| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
The libflatpak API reference link was broken. Let's just link to
docs.flatpak.org
|
| |
|
|
|
|
|
|
| |
If available, always read-only bind-mount /etc/os-release as
/run/host/os-release (or /usr/lib/os-release as fallback)
as suggested by the os-release specification:
https://www.freedesktop.org/software/systemd/man/os-release.html
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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"
|
| | |
|
| | |
|
| |
|
|
| |
I mistakenly omitted these in 9caf664fabc911419cc483125bf543c4550604c7
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Don't leave options set on the remote in one of the unit tests. If
something should be set for every test it should be done in
global_setup(). This commit also changes the FlatpakRemote
implementation to allow unsetting title and default branch.
|
| |\
| |
| | |
po: Update Ukrainian translation
|
| | | |
|
| |\ \
| |/
|/| |
transaction: Update get_operations() docs
|
| |/
|
|
|
|
| |
Document that operations are executed in the same order they are
returned because gnome-software is depending on that:
https://gitlab.gnome.org/GNOME/gnome-software/-/blob/cf5656031f0d25c9c36e2ad0e6e6cfd4b4f2c718/plugins/flatpak/gs-flatpak-transaction.c#L279
|
| |
|
|
| |
This fixes #3636
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
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).
|
| |
|
|
|
| |
This moves the operation normalization code to the
flatpak_transaction_normalize_ops() helper function.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently with the sideload implementation of offline updates you have
to manually create a symlink to your USB drive to sideload from it,
which is a regression compared to the previous implementation which
scanned all mounted filesystems in OstreeRepoFinderMount in libostree.
So this commit adds a few systemd units and a bash script so that any
time a USB drive is plugged in and automatically mounted by udisks, a
symlink to it is created in /run/flatpak/sideload-repos. When the drive
is unplugged the symlink is removed.
However this solution still has a lot of moving parts, so we may want to
instead have libflatpak use GVolumeMonitor and find the mounted
filesystems itself; see https://github.com/flatpak/flatpak/issues/3705
Fixes https://github.com/flatpak/flatpak/issues/3490
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we only support links in /var/lib/flatpak/sideload-repos,
/run/flatpak/sideload-repos, etc. to be actual ostree repos, but this
commit makes it so you can also link to the root directory of a USB,
and Flatpak will check the subpaths "ostree/repo", ".ostree/repo", and
".ostree/repos.d" for compatibility with "flatpak create-usb". This will
allow the logic in the following commit to be much simpler, where we're
linking to hot-plugged drives in a script run by systemd.
Note that we still only allow actual repos in the other places where a
sideload path can be specified, such as the --sideload-repo CLI option.
|
| | |
|
| |
|
|
| |
This is needed now that we emit a warning when it's not present.
|
| |
|
|
|
|
|
|
| |
This is making the flatpakref file less portable,
so we should warn to give developers a hint that
this is a possible problem.
Closes #2120
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
If a transaction requires to install an authenticator before it can
continue this signal will be emitted, allowing you to create a new
transaction to install the required authenticator.
|
| |
|
|
|
|
|
| |
get_remote_auto_install_authenticator_ref
We only ever returned this one ref anyway, and we want to use it in were
its *only* for the authenticator.
|
| |
|
|
|
|
|
|
|
|
| |
As mentioned in https://github.com/flatpak/flatpak/pull/3679 and
https://github.com/flatpak/flatpak/issues/3678 it is causing issues,
and the systemd generators we have should be fine for most uses
anyway.
If a distros need it the gdm file can easily be re-enabled with
--enable-gdm-env-file.
|
| |\
| |
| | |
Update documentation for sideload-repos
|
| |/
|
|
| |
It is no longer a config option; it was changed to be a directory.
|
| |
|
|
| |
GError conventions require we set the error pointer on error code paths.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per the conventions around using GError, failure code paths must set a
GError if a non-NULL pointer is passed for that parameter. And in case
the error is left unset it leads to an assertion failure (and crash) in
flatpak_installation_list_installed_refs_for_update(); see
https://github.com/endlessm/flatpak/pull/224
So add assertions to the failure code paths in
flatpak_transaction_real_run() to catch such mistakes earlier and make
the resulting crash stack trace more useful, since it points closer to
where the problem is. This could be implemented with the "goto out;"
idiom but I don't think that's a good idea in this case because in the
latter half of the function we have to do some cleanup before returning.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commits 32194f2d2 and b8d2196c2 made create-usb detect partially
installed commits and omit them except when --allow-partial is specified
(and in the case of extensions of related refs omit them
unconditionally). The reasoning was that if on the other computer using
the USB for an installation you need a different subpath of a commit
(such as a different language of a locale extension), the installation
will fail. But in most real world cases the users on both ends will
speak the same language so it will not often be an issue. Also, if you
are offline and have only your own language's subpaths for your locale
extensions, it makes sense to put them on the USB because you have no
way to get the full locale extension and the receiver probably wants the
same subpath as you.
The way "flatpak create-usb" is most often used in Endless is via
gnome-software which calls it under the hood. So while we could have it
pass --allow-partial that would not accomplish much; it doesn't solve
the problems above.
For the online case we may want to attempt to download the full locale
extensions before copying to the USB, but that is for a later commit.
Fixes https://github.com/flatpak/flatpak/issues/3491
|
| |
|
|
|
| |
We were checking for --allow-partial in the other two places we handle
partial commits but not here.
|
| | |
|
