Resolución de problemas

Problemas de compilación del módulo

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"),
    }
  • Como más y más módulos están siendo limitados para compilar tan solo en la arquitecturas soportadas (aarch64 y x86_64 para guardar recursos Fedora) necesitará fm-orchestrator#1747 aplicado localmente, en otro caso la construcción fallará.

  • Edite su <application>.yaml y añada una línea de repositorio:

    rpms:
      libpeas:
        repository: file:///<ruta a checkouts>/libpeas
        rationale: Runtime dependency
        ref: f37
  • Utilice fedpkg switch-branch`para intercambiar a la rfe desde `<application.yaml> (o cambie el ref: en <application.yaml> para que sea rawhide)

  • Haga sus cambios, commit them y asegure que las fuentes sean descargadas con fedpkg sources

  • Intente compilar su módulo de nuevo

Rápidamente depura compilaciones prefix=/app

Si no encuentra un problema donde un componente falla al compilar con prefix=/app y necesita depurar en detalle, como un enlace, puede temporalmente hacer lo siguiente:

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

, entonces trata recompilar el paquete con fedpkg local, repara los problemas, después desinstala flatpak-rpm-macros. Deja flatpak-rpm-macros instalado causará todos los paquetes que construyó localmente sean compilados con _prefix=/app y no funcionen.

Archivos externos a /app

La razón más común para un paquete fallando al compilar es que algun archivo del paquete está instalado con una ruta codificada dura de /usr en vez de respetar las macos como %{_prefix}, %{_libdir}, etc. Esto quizá requiera ajuste del archivo spec, pasando variables adicionales en la instrucción make, o en casos extraños, parcheando el los Makefile.

Páginas del manual descomprimidas

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

Durante la instalación de paquetes para construir un contenedor Flatpak, el conjunto de paquetes está restringido a paquetes en el tiempo de ejecución y paquetes compilados en su módulo. Otros paquetes en Fedora serán descartados. Si ve un mensaje sobre ausencia de dependencias que conoce que están dentro de Fedora, esto es porque están siendo ignorados debido a esta restricción.

`fedmod rpm2flatpak`tendría añadida una dependencia necesaria no dentro del tiempo de ejecución para su módulo. Sin embargo, subsecuentemente el cambio del empaquetado quizá requiere actualizaciones de su módulo.

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.