Troubleshooting
Package build problems
Rebuilding a flatpak against a local component
If you find a build problem with a package in your flatpak, you’ll want to build the flatpak using a local git checkout for the package, so you can put fixes in there:
-
Checkout the package from dist-git using
fedpkg clone
-
Use
fedpkg switch-branch
to switch to the f42 branch (if significantly different fromrawhide
) -
Make your changes, and make sure that sources are downloaded with
fedpkg sources
-
Build locally with
flatpak-module build-rpms-local /path/to/checkout
-
As needed, build any further packages with
flatpak-module build-rpms-local --auto
-
Once successful, install locally with
flatpak-module build-container-local --install
Quickly debugging prefix=/app builds
If you hit a problem where a package fails to build with prefix=/app
and you need to debug in detail,
-
Build locally with
flatpak-module build-rpms-local --auto
(or specify the failing package by SRPM name) -
If the build fails, the console output will display the log files and also include directions for entering the buildroot:
python-pyside6: Build failed x86_64/work/rpms/python-pyside6/build.log x86_64/work/rpms/python-pyside6/hw_info.log x86_64/work/rpms/python-pyside6/installed_pkgs.log x86_64/work/rpms/python-pyside6/mock_output.log x86_64/work/rpms/python-pyside6/root.log x86_64/work/rpms/python-pyside6/state.log chroot: /var/lib/mock/flatpak-module-f42-x86_64-0/root/ Enter chroot: mock -r x86_64/work/rpms/mock.cfg --uniqueext 0 --shell
Files outside of /app
The most common reason for a packaging failing to build is that some file in the
package is installed with a hard-coded path of /usr
rather than respecting the
macros such as %{_prefix}
, %{_libdir}
, etc. This might require adjustment
of the spec file, passing additional variables into the make command, or in rare
cases, patching the Makefiles.
Container build problems
Package installation failures
During installation of packages to build a Flatpak container, the set of packages is restricted to packages in the runtime and packages rebuilt for flatpaks. Other packages in Fedora will be ignored. If you see a message about missing dependencies that you know are in Fedora, this is because they are being ignored because of this restriction.
flatpak-module build-rpms --auto
should build all necessary dependencies not
in the runtime for the flatpak. However, subsequent packaging changes
might add new dependencies, in which case you may need to run this multiple times.
You could also see failures if a package in the runtime grew a new dependency and the runtime hasn’t been updated. If the package with the dependency causing the dnf failure isn’t part of your flatpak, please file an issue in the Fedora Flatpaks issue tracker.
Want to help? Learn how to contribute to Fedora Docs ›