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 fedora-packager-container, edit your /etc/module-build-service/config.py (create the file if it doesn’t exist) so it contains the following:

from copy import deepcopy
from module_build_service.common.config import LocalBuildConfiguration as DefaultLocalBuildConfiguration
from module_build_service.common.config import ProdConfiguration

class LocalBuildConfiguration(DefaultLocalBuildConfiguration):
    DISTGITS = {
        # This is just the default
        "https://src.fedoraproject.org": (
            "fedpkg clone --anonymous {}",
            "fedpkg --release module sources",
        ),
        # "true" install of None so we dont' get the default distgit_src_get of 'rpkg sources'
        "file://": ("git clone {repo_path}", "true"),
    }

  • As more and more modules are being limited to build just on the supported architectures (aarch64 and x86_64 to save Fedora resources) you will need fm-orchestrator#1747 applied locally, otherwise the build will fail.

  • Edit your <application>.yaml and add a repository line:

    rpms:
      libpeas:
        repository: file:///<path to checkouts>/libpeas
        rationale: Runtime dependency
        ref: f37

  • Use fedpkg switch-branch to switch to the rfe from <application.yaml> (or change the ref: in <application.yaml> to be rawhide)

  • Make your changes, commit them and make sure that sources are downloaded with fedpkg sources

  • 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 do the following:

dnf install ~/modulebuild/cache/koji_tags/module-flatpak-runtime-f37-<latest-version>/flatpak-rpm-macros-*.x86_64.rpm

,then 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.

Want to help? Learn how to contribute to Fedora Docs ›