Resolución de problemas
Recompilar un módulo contra un componente local
Si encuentra un problema al compilar con un componente en su módulo, querrá compilar el módulo utilizando una comprobación del git local para el módulo, tal que puede poner las reparaciones allí:
-
Extraer el módulo desde el dist-git utilizando
fedpkg clone
como un subdirectorio o<ruta para checkout>
-
A no ser que está utilizando fedora-packager-container, edite su
/etc/module-build-service/config.py
(cree el archivo si no existe) tal que contenga lo siguiente:
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
andx86_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 theref:
in<application.yaml
> to berawhide
) -
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
Actualmente, los guiones RPM que comprimen páginas del manual no comprimen páginas del manual en /app/
. Por tanto si un RPM tiene
%files [...] %{_mandir}/man1/<orden>.1.gz
Fallará al compilar en un módulo Flatpak. La recomendación en el paquete Fedora de las líneas de guía es tener:
%{_mandir}/man1/<instrucción>.1*
lo cual es más robusto frente a cambios futuros para el guión RPM para utilizar diferente compresión.
Problemas al compilar contenedor
Fallos en instalación de paquete
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.
Además pudo ver fallos si un paquete en el tiempo de ejecución crece una dependencia nueva y el tiempo de ejecuón no ha sido actualizado. Si el paquete con la dependencia causa el fallo de dnf no es parte de su módulo, por favor envíe un problema a flatpak-runtime.
Want to help? Learn how to contribute to Fedora Docs ›