Resolving ELN build failures
This page provides information to assist package maintainers remediate ELN build failures.
Background
For general information about ELN, visit the overview.
Note what’s different with the buildroot for ELN.
The set of packages that currently need to build for ELN can be found at https://tiny.distro.builders/view--view-eln.html. The expanded package set including build dependencies can be found at https://tiny.distro.builders/view--view-eln-and-buildroot.html.
There is also an ELN Build Status page showing which packages are currently failing to build for ELN, as well as those that have a discrepancy between Fedora Rawhide and ELN builds.
Debugging ELN build failures
Check the details about how to build
with koji and mock using the ELN buildroot.
Fixing ELN build failures
If the package doesn’t build for Rawhide, fix that first!
| If the package doesn’t build for Rawhide, fix that first! |
If the package doesn’t build for Rawhide, fix that first!
Is that message loud and clear enough? Getting the package build fixed for Rawhide may very well be all that’s needed to fix it for ELN as well.
Accounting for differences between Fedora and RHEL
Most build failures can be fixed by modifying the SPEC file. However, such modifications should be kept to a minimum.
If your package needs to institute different code paths or package dependencies between Fedora and RHEL, it is important to only account for the difference for the releases where it is required.
Generally, this means limiting the difference in old versions of Fedora, while letting the next version of RHEL adopt the Fedora code path.
As one common scenario where a difference is required, RHEL often ends
up with a smaller set of dependencies than Fedora.
The %{fedora} and %{rhel} macros, when defined, contain the major
release versions per distro.
Consider this SPEC file snippet:
%if 0%{?fedora} >= 29 || 0%{?rhel} >= 9
BuildRequires: SomePackage
%endifThis conditional will be met when %{rhel} is defined as 9 or greater.
It is also shareable between earlier and later versions of Fedora and RHEL.
Often it is better to use < to limit behaviors to RHEL 8 and earlier:
%if 0%{?fedora} < 32 && 0%{?rhel} < 9
%global rhel8orearlier 1
%else
%global rhel9orlater 1
%endifThe best spec files alter default behavior only for released versions of Fedora or RHEL, making the default policy the one applicable to the current versions of Fedora or RHEL.
As a last resort, there is an %{eln} macro available.
Using it should be avoided if at all possible.
However, if you find you do need to use it you should only check if it
is set to a non-zero value.
For example:
%if 0%{?eln}
# something specific to ELN only
...
%endif
%if 0%{?fedora} || 0%{?eln}
# something specific to Fedora or ELN
...
%endif
%if 0%{?rhel} && ! 0%{?eln}
# something specific to RHEL only, not ELN.
...
%endifPython 2 deprecation
Just as recent Fedora releases have deprecated Python 2, so have RHEL 9 and ELN. There has been a recurring pattern with ELN build failures that can be resolved by adjusting the SPEC conditionals to disable Python 2. For example, if you have something like this:
%if 0%{?fedora} >= 30
%global python2_enabled 0
%else
%global python2_enabled 1
%endifChange the conditional to:
%if 0%{?fedora} >= 30 || 0%{?rhel} >= 9Architecture dependencies
ELN is built for the same set of architectures as Rawhide.
However, the kernel package in ELN no longer produces a full
kernel for any 32-bit architecture.
Notably, there is no kernel package for architecture armv7hl,
only the kernel-headers package.
To help address this difference, there is a new %{kernel_arches} macro
available that can be used in the SPEC file. For example:
%ifarch %{kernel_arches}
BuildRequires: kernel
%else
BuildRequires: kernel-headers
%fiWant to help? Learn how to contribute to Fedora Docs ›