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 from rawhide)

  • 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:

console output
  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 ›