Troubleshooting
Rebuilding a module against a local component
If you find a build problem with a component in your module, you’ll want to build the module using a local git checkout for the module, so you can put fixes in there:
-
Checkout the module from dist-git using
fedpkg clone
as a subdirectory of<path to checkouts>
-
Unless you are using fedora-packager-container, edit your
/etc/module-build-service/config.py
changeRPMS_ALLOW_REPOSITORY = False
toRPMS_ALLOW_REPOSITORY = True
, and at the end, add:
LocalBuildConfiguration.DISTGITS = { 'https://src.fedoraproject.org': ('fedpkg clone --anonymous {}', 'fedpkg --release module sources'), 'file:///<path to checkouts>/': ('git clone file:///<path to checkouts>/{0}; git -C {0} remote set-url origin ssh://<username>@pkgs.fedoraproject.org/rpms/{0}', 'fedpkg --release module sources'), }
-
Edit your
<application>.yaml
and add a repository line:
rpms:
libpeas:
repository: file:///<path to checkouts>/libpeas
rationale: Runtime dependency
ref: f33
-
Use
fedpkg switch-branch
to switch to the rfe from<application.yaml>
(or change theref:
in<application.yaml
> to bemaster
) -
Make your changes and commit them
-
Try building your module again
Quickly debugging prefix=/app builds
If you hit a problem where a component fails to build with prefix=/app and
you need to debug in detail, as a shortcut, you can temporarily dnf
install
~/modulebuild/cache/koji_tags/module-flatpak-runtime-f33-<latest-version>/flatpak-rpm-macros-*.x86_64.rpm
,
try rebuilding the package with fedpkg local
, fix problems, then uninstall
flatpak-rpm-macros. Leaving flatpak-rpm-macros installed will cause all
packages you build locally to be built with _prefix=/app and not work.
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.
Uncompressed manual pages
Currently, the RPM scripts that compress manual pages don’t compress manual
pages in /app
. So if an RPM has
%files [...] %{_mandir}/man1/<command>.1.gz
It will fail to build in a Flatpak module. The recommendation in the Fedora packaging guidelines is to have:
%{_mandir}/man1/<command>.1*
which is more robust against future changes to the RPM scripts to use different compression.
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 built in your module. 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.
fedmod rpm2flatpak
should have added all necessary dependencies not in the
runtime to your module. However, subsequent packaging changes might require
updates to your module.
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 module, please bug an issue against flatpak-runtime.