This should stop the noise seen with flatpak-module-tools, as
/run/host/font-dirs.xml exists only when running flatpaks or building with
flatpak-builder, but not when building in mock (which does not involve
running flatpak).
Fontconfig error: Cannot load config file "/run/host/font-dirs.xml": No such file: /run/host/font-dirs.xml
The XPM loader from gdk-pixbuf2-modules-extra is sometimes needed
at build time as well (e.g. openslide tests). In that case, the
loaders.cache in /usr also needs to be updated for build time usage
in addition to that in /app for running the flatpak.
When using the SDK as a replacment for FD.o/GNOME/KDE upstream's to build
with flatpak-builder, libraries will be built into /app/lib rather than in
/app/lib64 as in Fedora builds.
Using LD_LIBRARY_PATH for adding to the default library search path is not
always reliable, as sometimes subprocesses may be launched without this
environment variable, which may cause it to fail if it needs libraries
outside of the runtime.
Instead, we should follow the lead of Flathub flatpaks, and use dynamic
ld.so.cache generation instead. This automatically creates (or updates) a
cache file in ~/.var/app/$APP_ID/.ld.so/ based on the runtime, app, and any
extensions, and works even for subprocesses with a limited environment.
To implement this, in addition to the changes here, the runtimes need to
*not* pass --env=LD_LIBRARY_PATH, and add the following to finish-args:
# enable dynamic ld.so.cache generation
[ -e /usr/bin/ldconfig ] || ln -s ../sbin/ldconfig /usr/bin/ldconfig
cat /etc/ld.so.conf.d/*.conf > /etc/ld.so.conf
rm -f /etc/ld.so.conf.d/*.conf
This is necessary because the feature requires ldconfig in /bin (where we
still have a separate /sbin), and the code is not designed to handle
/etc/ld.so.conf.d/*.conf. This also allows %_sysconfdir/ld.so.conf.d to
work for both RPM builds and flatpak apps rather than having to defining
--env=LD_LIBRARY_PATH in the app too.
https://github.com/flatpak/flatpak/blob/1.15.12/common/flatpak-run.c#L2663https://github.com/flatpak/flatpak/blob/1.15.12/common/flatpak-run.c#L3083
Fixes: rhbz#2272376
Alternatives-based symlinks work when building RPMs, but break in
flatpaks because /etc/alternatives is not writable. Since flatpak
RPMs are only installed, not removed, this retargets such symlinks
to their intended destination.
X11 Type1 and TTF fonts are not included in the runtime but should
be handled by fontconfig if present; e.g. the full java-N-openjdk
requires the Type1 fonts for Swing.
This avoids broken symlinks in maven-lib when one of maven's
dependencies are built in /app for flatpaks (e.g. apache-commons-cli,
for freecol and jmol).
graphviz utilitizes a plugin cache which needs to be created once
installed. While graphviz does have its own %post to do so, when built
in /app it does not work because it first requires ldconfig to be run
(so that the plugins can resolve graphviz's own libraries).
graphviz's %post has been converted to a trigger in rawhide (F40), but
in the meantime for F39, this avoids the issue.
/app/lib*/pythonX.Y/site-packages should be treated as a distro site
directory, not a user site one. The difference being that sitecustomize
is still respected with scripts using the `python3 -s` shebang, as in
distro-built scripts.
This ended up causing weird issues with build dependencies, e.g.
packages that 'BuildRequires: systemd' for systemd rpm macros no longer
building because they ended up pulling in flatpak-runtime-config instead
of systemd.
This reverts commit ccc5a2ff39.
As implemented in redhat-rpm-config, package notes requires several
RPM-specific environment variables to be set, and therefore only work
with RPM builds. This causes gcc to be unable to compile in other use
cases, such as with flatpak-builder.
This works around Python prefix changes in F36 that broke our
usercustomize.py, leading to python module search paths changing to
/app/local/lib.
As a work around, do the path mangling in the spec file and avoid doing
it at runtime.
https://bugzilla.redhat.com/show_bug.cgi?id=2112499
This should make both the runtime and the sdk correctly show up in gnome-software.
I am not sure what to do with the license field; I've left it as
GPL-2.0+ for now, matching what the freedesktop and gnome runtimes are
doing, but it's clearly not correct (we include many libraries with many
different licenses, not just GPL-2.0+). I've left a FIXME in the appdata
files for now.
