English Spanish
Checkout the module from dist-git using `fedpkg clone` as a subdirectory of `<path to checkouts>`
Container build problems
Currently, the RPM scripts that compress manual pages don't compress manual pages in `/app`. So if an RPM has
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.
Edit your `<application>.yaml` and add a repository line:
`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.
%files
[...]
%{_mandir}/man1/<command>.1.gz
Files outside of `/app`
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:
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.
It will fail to build in a Flatpak module. The recommendation in the Fedora packaging guidelines is to have:
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'),
}
Make your changes and **commit them**
%{_mandir}/man1/<command>.1*
Module build problems
Package installation failures
Quickly debugging prefix=/app builds
Rebuilding a module against a local component
rpms:
libpeas:
repository: file:///<path to checkouts>/libpeas
rationale: Runtime dependency
ref: f33
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.