Fedora's build environment runs inside a systemd-nspawn(1) container and
runs into this test failure:
...
...
Adding library /lib/libcap.so.2
Adding library /lib/libpcre2-8.so.0
Adding library /lib/libselinux.so.1
Adding library /lib/libtinfo.so.6
error: /tmp/tmp.ppnOBuhUOv/export/share/icons/hicolor/64x64/apps/org.test.Hello.png
is not a valid icon: bwrap: Can't mount proc on /newroot/proc:
Operation not permitted
OK closing connection
(test program exited with status code 1)
... which, otherwise, passes when run interactively on a Fedora
Workstation 39 system.
It is the 'flatpak build-export ...' call in tests/make-test-runtime.sh,
which calls 'flatpak-validate-icon --sandbox' to validate the icons in a
bwrap(1) sandbox. This used to work in the recent past, even with the
build running inside a systemd-nspawn(1) container, but not anymore,
likely because of other changes in the build environment.
Therefore, there's no point in blocking flatpak-builder builds until the
tests are fixed.
https://src.fedoraproject.org/rpms/flatpak-builder/pull-request/4
There is a general desire to migrate away from FUSE 2 to FUSE 3:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UUOKLRLQHN2AC4SLAXERC7QAKW6FBSFX/
flatpak-builder requires FUSE indirectly through it's use of OSTree's
rofiles-fuse binary. Until now, flatpak-builder could only work with
a rofiles-fuse binary that was built against FUSE 2 because of the
use of some optimization options that are only needed for FUSE 2 and
hence don't work with FUSE 3. See:
https://github.com/flatpak/flatpak-builder/commit/99b35552274150bd
This disables the optimization in the hope that OSTree will switch to
building against FUSE 3. In the meantime, flatpak-builder will be
slower but will continue to work with FUSE 2.
Since 1.0.11, flatpak-builder prefers Breezy (brz) over Bazaar-NG
(bzr). The former is a "friendly fork" that's been ported to Python 3
and is maintained, while the latter uses Python 2 and appears to be
essentially unmaintained.
No need to issue a build just for this.
There is no need to pull them in for everybody that installs
flatpak-builder. If people want to build code from a bzr repo, they can
just install bzr manually then.
They may or may not be needed depending on what code is being built.
Moving it all to recommends makes it possible for people who e.g. know
they don't need or want to install one of these to exclude it.
This also makes it simpler for RHEL where we can just leave all of the
archive handlers in as recommends, instead of disabling them when they
don't happen to be available in RHEL core.
flatpak-builder currently Requires: subversion to support manifests that
use subversion.
Probably most manifests won't need that feature, since subversion has
been largely replaced by git, so using a Requires is a little harsh.
Resolves: #1639355
