English Spanish
Troubleshooting
Module build problems
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 https://github.com/owtaylor/fedora-packager-container[fedora-packager-container]**,
edit your `/etc/module-build-service/config.py`
change `RPMS_ALLOW_REPOSITORY = False` to `RPMS_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:
Make your changes and **commit them**
Try building your module again
Quickly debugging prefix=/app builds
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