forked from rpm-software-management/mock
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
configs: replace
powerpc64le
with ppc64le
in the %_host_cpu
macro
In older RPM versions, the `%_host_cpu` macro was not correctly set for the `ppc64le` architecture. Let's work around this issue in Mock. This problem arises because RPM determines the per-distribution value of the `%_host_cpu` macro at its build time (rpm.rpm package). The value is provided by the build system, from the build environment analysis. Older RPM versions use the `config.guess` script (file copy from the Automake package) for this purpose. However, even as of 2024, this script still returns an incorrect architecture string on ppc64le boxes: $ /usr/lib/rpm/redhat/config.guess powerpc64le-unknown-linux-gnu ^^^^^^^^^^^ Newer versions of RPM (v4.19+ in Fedora 39+ and EL 10+) use the CMake build system, which sets the correct `%_host_cpu` value `ppc64le`. This commit addresses the issue by overriding the macro in older chroots (RPM v4.18 and earlier). This is what the Fedora Koji build system has been doing for **all** `ppc64le` Mock chroots for a long time—now, it's being applied for Mock users in `mock-core-configs`. The `%_host_cpu` macro is used by `/bin/rpmbuild` when validating architectures, especially with the `ExclusiveArch/ExcludeArch` checks for `BuildArch: noarch` packages. Maintainers sometimes do: BuildArch: noarch ExcludeArch: %java_arches However, since `%java_arches` doesn't include the "non-standard" `powerpc64le` architecture string (and no other "similar" macro does, including the more extensive ones like `%go_arches`), builds in Mock can fail early with the error: error: Architecture is not included: powerpc64le Building target platforms: ppc64le Building for target ppc64le This happens because: $ rpm --eval %java_arches aarch64 ppc64le s390x x86_64 $ rpm --eval %_host_cpu powerpc64le The arch-specific packages care about `%_target_cpu` value (which seems valid everywhere) so they don't suffer from this problem. The 'noarch' are affected because of the `%_target_cpu → %_host_cpu` fallback: https://github.com/rpm-software-management/rpm/blob/21457de886faf2415500a8bb7cc6c816d72939ef/build/parsePreamble.c#L442-L449 And given by fact that the `%_build_cpu` macro is just `%_host_cpu`: $ rpm --showrc | grep build_cpu -13: _build_cpu %{_host_cpu} Relates: fedora-copr/copr#2870 Relates: https://bugzilla.redhat.com/show_bug.cgi?id=1461288
- Loading branch information
Showing
10 changed files
with
31 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
13 changes: 13 additions & 0 deletions
13
releng/release-notes-next/ppc64le-not-powerpc64le-host-cpu.config
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
We [updated the configuration][PR#1195] files for chroots that still use older | ||
RPM versions (v4.18 and earlier), which affects RHEL/CentOS 9 and older. These | ||
older RPM versions were built with an incorrect default for the `%_host_cpu` | ||
macro in `ppc64le` chroots, where the macro incorrectly resolved to | ||
`powerpc64le` instead of `ppc64le`. | ||
|
||
This incorrect value caused issues during architecture validation, such as when | ||
checking `ExclusiveArch: ppc64le` for `BuildArch: noarch` packages (done | ||
in-chroot by `/bin/rpmbuild`). | ||
|
||
The incorrect macro value has now been overridden in the relevant `ppc64le` | ||
configuration files in Mock, ensuring that `ExcludeArch` and `ExclusiveArch` | ||
validations resolve correctly. |