Adapted from: https://github.com/flatpak/flatpak/pull/6125
In systemd v259, /run/host/root will be a documented location
for bind mounting the host's root filesystem into a
container. Ref: https://github.com/systemd/systemd/pull/38384
host-root is the sledgehammer permission for file browsers
and similar apps that the user might want to give full access
to.
This works same as the existing host keywords by mounting into
/run/host/root. applications will need adjustments to essentially
treat that path as "root".
Since this opens the door to all sorts of malicious software, the
permission should be put under tight review in flatpak
repositories.
Resolves: #5723
Co-authored-by: Ryan Brue <ryanbrue.dev@gmail.com>
Xe module supports the discrete and new integrated GPUs (the Arc series) and
the i915 supports the older Intel integrated GPUs (Intel HD).
Closes: https://github.com/flatpak/flatpak/issues/5248
Fixes#2489
Adds and wires up a `reinstall` option to
`flatpak_dir_install_bundle`. Previously, bundle install
transactions would silently drop the reinstall flag.
Instead of using flatpak_oci_manifest_descriptor_get_ref which requires
the `org.opencontainers.image.ref.name` annotation, get any valid
manifest, and make sure to return NULL if there are multiple valid
manifests.
Closes: https://github.com/flatpak/flatpak/issues/6081
Since flatpak_image_source_new_remote() already tries to load files
from the registry, having a separate flatpak_image_source_set_token()
doesn't work - when the token is set, it's already too late to
be passed along with the initial requests.
The F_DUPFD and its relative F_DUPFD_CLOEXEC both expect an int argument
as extra argument, being the minimal value for the new FD. This argument
must be within the accepted range (see ulimit -H -n).
This was detected in Ubuntu during testing against the latest glibc,
stracing resulted in:
107244 fcntl(1, F_DUPFD_CLOEXEC, 1847846346272) = -1 EINVAL (Invalid argument)
On the system in question (ppc64el machine running Ubuntu Questing), the
relevant limit is 524288.
For the fix we use 3 as a reasonable floor value, as in the first one
after stderr. It also happens to be the one used in revokefs/main.c.
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2121039
This adds new FlatpakTransaction API, and a new top level CLI command to
preinstall flatpaks, that is to install flatpaks that are considered
part of the operating system.
A new drop-in directory /etc/flatpak/preinstall.d/ allows configuring
what apps should be preinstalled, and a new flatpak preinstall command
installs and removes apps based on the current configuration.
A drop-in loupe.preinstall file can look something like this:
[Flatpak Preinstall org.gnome.Loupe]
Branch=stable
IsRuntime=false
The corresponding API is flatpak_transaction_add_sync_preinstalled()
which can be implemented by GUI clients to drive the actual installs
on system startup.
Resolves: https://github.com/flatpak/flatpak/issues/5579
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
We want to use collection IDs to specify what remote to install from
when processing /etc/flatpak/preinstall.d; in order for this to work
for OCI remotes, we need to permit collection IDs.
- In flatpakrepo files, don't require a GPGKey for a OCI remote
with a collection - we don't have signature verification for GPG remotes.
- Don't validate that the collection ID appears in the summary -
the image index doesn't currently contain an image ID
Instead of passing the delta URL along with the image source, when
we create an image source for a remote registry, if we find a delta
URL in the metadata, set it on the FlatpakImageSource for later use.
Centralize duplicated code for creating an image source for a remote
repository based on a summary lookup into one place.
Add support for `oci-archive:` image sources by temporarily
unpacking the archive using libarchive.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Similar to bundle installs, add:
flatpak install [--image] docker://registry.example.com/image:latest
flatpak install [--image] oci:/path/to/image
These is useful for testing purposes and in certain cases when installing
Flatpaks on disconnected systems.
Which allows one to create an image source from a container location.
It also adds a new FlatpakDockerReference to access different parts of a
docker reference and changes to FlatpakOciIndex to get a manifest for a
specific architecture.
This will become useful in the next commit when we're going to add
support for installing OCI images.
To avoid passing around combinations of a FlaptakOciRegistry with
repository and digest, add a FlatpakImageSource type.
This also reduces duplicated code where every place that did
this independently retrieved the repository and image config.
flatpak run writes /run/host/font-dirs.xml, but flatpak build so far
didn't. This resulted in fontconfig writing:
Fontconfig error: Cannot load config file "/run/host/font-dirs.xml": No such file: /run/host/font-dirs.xml
to the stderr of all processes utilizing fontconfig and run during
flatpak build, as /run/host/font-dirs.xml is included via
/etc/fonts/50-flatpak.conf. This could cause issues for tests run during
building an application, for example.
Closes#6137
CI currently skips a lot of tests. This is due to AppArmor restricting
user namespacing to specific executables with a profile. We however
build bwrap ourselves and that makes it hard to have a profile for it.
Let's just turn the restriction off entirely.
Autotools support was removed as of commit 8e63eda,
remove mention of the Autotools support in the CONTRIBUTING file
Signed-off-by: Ryan Brue <ryanbrue.dev@gmail.com>
