Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

override ppc64le %_host_cpu #1195

Merged
merged 1 commit into from
Sep 16, 2024
Merged

override ppc64le %_host_cpu #1195

merged 1 commit into from
Sep 16, 2024

Conversation

praiskup
Copy link
Member

@praiskup praiskup commented Aug 23, 2023 •
edited
Loading

This is what Koji does for all architectures. The macro is used by
rpmbuild while matching 'ExclusiveArch' patterns. E.g. "%java_arches"
then contains 'ppc64le', but by default '_host_cpu' contains powerpc64le
on Fedora.

RPM checks %_target_cpu with %_build_cpu fallback:
https://github.com/rpm-software-management/rpm/blob/21457de886faf2415500a8bb7cc6c816d72939ef/build/parsePreamble.c#L442-L449

For 'BuildArch: noarch' packages, %_target_cpu is 'noarch', fallback is
used and '%_build_cpu' is defined as '%_host_cpu' in redhat-rpm-config.
This is set by 'config.guess' to powerpc64le.

TODO: submit a redhat-rpm-config issue
TODO: resolve other EPEL/Fedora targets
Relates: fedora-copr/copr#2870
Relates: https://bugzilla.redhat.com/show_bug.cgi?id=1461288

@packit-as-a-service
Copy link

We were not able to find or create Copr project packit/rpm-software-management-mock-1195 specified in the config with the following error:

Cannot create a new Copr project (owner=packit project=rpm-software-management-mock-1195 chroots=['fedora-rawhide-x86_64']): Response is not in JSON format, there is probably a bug in the API code.

Please check your configuration for:

  1. typos in owner and project name (groups need to be prefixed with @)
  2. whether the project name doesn't contain not allowed characters (only letters, digits, underscores, dashes and dots must be used)
  3. whether the project itself exists (Packit creates projects only in its own namespace)
  4. whether Packit is allowed to build in your Copr project
  5. whether your Copr project/group is not private

@praiskup praiskup force-pushed the praiskup-ppc64le-fedora branch from 33ea8eb to 7fd18b4 Compare August 23, 2023 21:25
@praiskup praiskup marked this pull request as draft August 23, 2023 21:26
@pmatilai
Copy link
Member

Before trodding deeper into these dark woods, it would be good to check what the current state of things is in rpm >= 4.19 where config.guess has nothing to do with anything (because cmake is used).

@praiskup
Copy link
Member Author

Thank you for your comment, @pmatilai.

OK, but that's not even in Rawhide, right? I'd like to fix builds for EPEL7+.

Otherwise yes, 4.19 seems to use CMAKE_HOST_SYSTEM_PROCESSOR, which is uname -m, which should be fine (ppc64le returned and set as %_host_cpu, both on our Power9 and Power8 machines). The question is how realistic is to fix the macro in old buildchroots so Mock correctly builds them.

E.g. %{java_arches} expands to just aarch64 ppc64le s390x x86_64. And this clearly looks like a Koji-targeted list (%_cpu_host is very predictable in Koji). Compare that with %go_arches i386 i486 i586 i686 pentium3 pentium4 athlon geode x86_64 armv3l armv4b armv4l armv4tl armv5tl armv5tel armv5tejl armv6l armv6hl armv7l armv7hl armv7hnl armv8l armv8hl armv8hnl armv8hcnl aarch64 ppc64le s390x mips mipsel mipsr6 mipsr6el mips64 mips64el mips64r6 mips64r6el which is much more interesting. Sadly, powerpc64le is missed even there!

As noted above, Koji overrides %_host_cpu. Is it OK to do that in Mock by default?

@praiskup
Copy link
Member Author

@pmatilai do you think this patch is a wrong idea?

@dmnks dmnks mentioned this pull request Nov 14, 2023
Closed
@praiskup
Copy link
Member Author

praiskup commented Dec 5, 2023

Per rpm-software-management/rpm#791 it seems this is going to be fixed for Fedora 39+ with rpm 4.19.0.

Since we know the preferred fix (%_host_cpu=ppc64le, not powerpc64le), overriding this macro in Mock for older chroots seems quite OK to me (considering Koji does this). @pmatilai wdyt?

@Conan-Kudo
Copy link
Member

I'm not @pmatilai, but I think that is reasonable. But does this behave reasonably when we do foreign arch mock runs (e.g. ppc64le on x86_64)?

@praiskup
Copy link
Member Author

praiskup commented Sep 9, 2024

But does this behave reasonably when we do foreign arch mock runs (e.g. ppc64le on x86_64)?

I guess? The %_host_cpu for target ppc64le would be unconditionally ppc64le, no matter on what system Mock is executed. The current behavior is similar, no matter the host system (even if x86_64):

$ mock -r epel-8-ppc64le --shell
<mock-chroot> sh-5.1# rpm --eval %_host_cpu
powerpc64le

@praiskup praiskup force-pushed the praiskup-ppc64le-fedora branch from 7fd18b4 to 608c1ad Compare September 11, 2024 13:09
@praiskup
configs: replace powerpc64le with ppc64le in the %_host_cpu macro
2ca7f75 
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
@praiskup praiskup force-pushed the praiskup-ppc64le-fedora branch from 608c1ad to 2ca7f75 Compare September 11, 2024 14:02
@praiskup praiskup marked this pull request as ready for review September 11, 2024 14:02
@praiskup
Copy link
Member Author

Trying to be brave, and marking this PR for review (see the commit message for the info). I still eventually believe this is worth merging (but it only affects EL 9 and older, all actively developed Fedora versions are OK).

@praiskup praiskup removed the blocked label Sep 11, 2024
@xsuchy xsuchy merged commit 9deb5d1 into rpm-software-management:main Sep 16, 2024
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@xsuchy xsuchy xsuchy approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@praiskup @pmatilai @Conan-Kudo @xsuchy