If the command calling `flatpak build` has already specified a
font-dirs.xml to map, then mapping in again may break (as exemplified in
Builder and Foundry).
This checks to see if an argument has already been mapped in before doing
so and resolves the issue with Builder/Foundry.
Follow-up to !6138Fixes: GNOME/gnome-builder#2387
(cherry picked from commit c896faae19)
If the binaries are not available in the environment, the trigger will
not do anything. The tests will not know about this and fail. So only
test for the results of the triggers if they have the dependencies they
require.
(cherry picked from commit 78b3c47c13)
There are a number of races, and failure conditions which can lead to a
pid of 0 being returned from flatpak_instance_get_child_pid. This would
lead to a whole bunch of things getting killed.
We will skip the instance in those cases now, and retry a few times. We
also notice when the instance just goes away by itself now.
This should make killing more robust, and especially not SIGKILL pid 0.
(cherry picked from commit 8354ee56cf)
Sudo can be used in several ways other than calling a command with the
root user. For example, one can use -u to run the command as the
specified user, or -g to specify a primary group to run the command
as.
Flatpak adds a check when --user is used to prevent an installation in
the root's directory, for example, but it does it by only checking if
sudo was used. As stated previously, it does not necessarily imply
root, so this patch explicitly checks if the command is being run with
the root user.
Fixes: https://github.com/flatpak/flatpak/issues/5979
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
(cherry picked from commit f61d931da8)
When an xdg dir is not available, it is supposed to point at $HOME. We
do not want to mount $HOME though in that case, so we just skip the xdg
dir instead.
The check compares the strings of the the xdg dir path and the home dir
path. So far it relied on the functions internally canonicalizing the
paths in the same way, but there was a glib regression:
https://gitlab.gnome.org/GNOME/glib/-/issues/3811
("g_get_user_special_dir doesn't strip trailing slash from $HOME")
Which then was fixed in cb3e9fe74 ("gutils: Strip all trailing
slashes").
We can however just canonicalize on the paths on the caller side to make
this more robust, so let's just do that.
Closes: #6323
(cherry picked from commit bb2d517bb1)
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
(cherry picked from commit f53cef0041)
Fixes#2489
Adds and wires up a `reinstall` option to
`flatpak_dir_install_bundle`. Previously, bundle install
transactions would silently drop the reinstall flag.
(backported from commit 919d2922bf)
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
(cherry picked from commit 3773617f30)
If an SDK is already installed in a dir that is not targeted with a
flatpak transaction, and the transaction has auto_install_sdk set,
add_new_dep_op returns NULL in dep_op which is not correctly handled in
add_deps.
Fixes#5894
(cherry picked from commit c4af112df4)
Without doing so, flatpak_dir_get_config() won't reflect changes made
with flatpak_dir_set_config().
This fixes passing multiple patterns to `flatpak mask` for the system
installation.
Closes#5464
(cherry picked from commit a7ac4206c6)
Fixes c75ba1c7e1
```
In file included from /usr/lib/aarch64-linux-gnu/glib-2.0/include/glibconfig.h:9,
from /usr/include/glib-2.0/glib/gtypes.h:34,
from /usr/include/glib-2.0/glib/galloca.h:34,
from /usr/include/glib-2.0/glib.h:32,
from /usr/include/glib-2.0/gobject/gbinding.h:30,
from /usr/include/glib-2.0/glib-object.h:24,
from /usr/include/glib-2.0/gio/gioenums.h:30,
from /usr/include/glib-2.0/gio/giotypes.h:30,
from /usr/include/glib-2.0/gio/gio.h:28,
from ../common/flatpak-utils-http.c:23:
In function ‘glib_autoptr_clear_GFileEnumerator’,
inlined from ‘glib_autoptr_cleanup_GFileEnumerator’ at /usr/include/glib-2.0/gio/gio-autocleanups.h:69:1,
inlined from ‘flatpak_get_certificates_for_uri’ at ../common/flatpak-utils-http.c:284:34:
/usr/include/glib-2.0/glib/gmacros.h:1361:10: warning: ‘enumerator’ may be used uninitialized [-Wmaybe-uninitialized]
1361 | { if (_ptr) (cleanup) ((ParentName *) _ptr); } \
| ^
/usr/include/glib-2.0/glib/gmacros.h:1379:3: note: in expansion of macro ‘_GLIB_DEFINE_AUTOPTR_CLEANUP_FUNCS’
1379 | _GLIB_DEFINE_AUTOPTR_CLEANUP_FUNCS(TypeName, TypeName, func)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/gio/gio-autocleanups.h:69:1: note: in expansion of macro ‘G_DEFINE_AUTOPTR_CLEANUP_FUNC’
69 | G_DEFINE_AUTOPTR_CLEANUP_FUNC(GFileEnumerator, g_object_unref)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
../common/flatpak-utils-http.c: In function ‘flatpak_get_certificates_for_uri’:
../common/flatpak-utils-http.c:284:34: note: ‘enumerator’ was declared here
284 | g_autoptr(GFileEnumerator) enumerator;
```
(cherry picked from commit cd0212aa40)
The current documentation is misleading, and confused multiple
experienced developers for the past two years.
Fixes#5501
(cherry picked from commit 0152272d6c)
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
(cherry picked from commit 7399dea960)
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
(cherry picked from commit 054f4f4a7b)
Docker and podman can be configured to use mutual TLS authentication
to the registry by dropping files into system-wide and user
directories. Implement this in a largely compatible way.
(Because of the limitations of our underlying libraries, we
can't support multiple certificates within the same host config,
but I don't expect anybody actually needs that.)
The certs.d handling is extended so that certificates are separately
looked up when downloading the look-aside index. This is mostly
to simplify our tests, so we can use one web server for both -
in actual operation, we expect the indexes to be unauthenticated.
Also for testing purposes, FLATPAK_CONTAINER_CERTS_D is supported
to override the standard search path.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
The systemd Desktop Environments conventions for cgroup names is
app[-<launcher>]-<ApplicationID>-<RANDOM>.scope
where RANDOM should ensure that multiple instances of the application
can be launched. Currently flatpak uses the PID of itself but the
instance fullfills this convention and is a bit more useful for matching
the cgroup to a flatpak instance.
There are cases where flatpak is doing some internal work (apply extra
data) where there is no instance id, and more philosophically also no
app instance. In those cases we simply do not move the process to the
cgroup with the XDG convention.
The original idea behind this code was that the initial lockless scan
of reachable objects will make the locking one fast enough that
it won't matter to software managing flatpak repos like flat-manager.
Few years later I can say this is not true, and the locking variant
of scan does take too long and affects Flathub's publishing process.
By keeping only the lockless variant in dry run, we can run it on a
weekly schedule without affecting operations, and issue actual pruning
with flat-manager which will hold a lock in external system and avoid
executing any actions requiring locking to avoid errors/timeouts.
We already build and test with asan with the newer
toolchain in the ubuntu 24.04 job. Sometimes the older
toolchain found in 22.04 or the asan version will
trigger issues that are either false positive or that
have been already against in newer versions.
