[OS-BUILD PATCHv2 0/4] Add libperf packages and build kernel tools for Fedora

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907

When kernel-tools was split out to a separate package in Fedora, it was due to
several factors. Most of those issues have been mitigated in other ways, and
there are advantages to building tools with the kernel build. Let's turn on
tools for Fedora.  To do so, we need to add the libperf packages, but this
enables them for Fedora only.
It is worth noting that the Fedora package for bpftool will retain the
upstream kernel versioning.  This is because the bpftool versioning scheme is
incompatible with the stable Fedora process.

---
 redhat/kernel.spec.template |  81 +++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 78 insertions(+), 3 deletions(-)

[OS-BUILD PATCHv2 1/4] add libperf packages and enable perf, libperf, tools and bpftool packages

[Justin M. Forbes (via Email Bridge)]

From: Thorsten Leemhuis

add libperf packages and enable perf, libperf, tools and bpftool packages

Signed-off-by: Thorsten Leemhuis

diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100644
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -224,6 +224,8 @@ Summary: The Linux kernel
 %define with_cross_headers   %{?_without_cross_headers:   0} %{?!_without_cross_headers:   1}
 # perf
 %define with_perf      %{?_without_perf:      0} %{?!_without_perf:      1}
+# libperf
+%define with_libperf   %{?_without_libperf:   0} %{?!_without_libperf:   1}
 # tools
 %define with_tools     %{?_without_tools:     0} %{?!_without_tools:     1}
 # bpf tool
@@ -300,9 +302,10 @@ Summary: The Linux kernel
 # no stablelist
 %define with_kernel_abi_stablelists 0
 # Fedora builds these separately
-%define with_perf 0
-%define with_tools 0
-%define with_bpftool 0
+%define with_perf 1
+%define with_libperf 1
+%define with_tools 1
+%define with_bpftool 1
 # No realtime fedora variants
 %define with_realtime 0
 %define with_arm64_64k 0
@@ -388,6 +391,7 @@ Summary: The Linux kernel
 %define with_realtime 0
 %define with_vdso_install 0
 %define with_perf 0
+%define with_libperf 0
 %define with_tools 0
 %define with_bpftool 0
 %define with_kernel_abi_stablelists 0
@@ -402,6 +406,7 @@ Summary: The Linux kernel
 %define with_base 0
 %define with_vdso_install 0
 %define with_perf 0
+%define with_libperf 0
 %define with_tools 0
 %define with_bpftool 0
 %define with_kernel_abi_stablelists 0
@@ -417,6 +422,7 @@ Summary: The Linux kernel
 %define with_debuginfo 0
 %define with_vdso_install 0
 %define with_perf 0
+%define with_libperf 0
 %define with_tools 0
 %define with_bpftool 0
 %define with_kernel_abi_stablelists 0
@@ -480,6 +486,7 @@ Summary: The Linux kernel
 %define with_cross_headers 0
 %define with_tools 0
 %define with_perf 0
+%define with_libperf 0
 %define with_bpftool 0
 %define with_selftests 0
 %define with_debug 0
@@ -572,6 +579,7 @@ Summary: The Linux kernel

%define with_debuginfo 0
 %define with_perf 0
+%define with_libperf 0
 %define with_tools 0
 %define with_bpftool 0
 %define with_selftests 0
@@ -1124,6 +1132,23 @@ This package provides debug information for the perf python bindings.
 # with_perf
 %endif

+%if %{with_libperf}
+%package -n libperf
+Summary: The perf library from kernel source
+License: GPL-2.0-only AND (LGPL-2.1-only OR BSD-2-Clause)
+%description -n libperf
+This package contains the kernel source perf library.
+
+%package -n libperf-devel
+Summary: Developement files for the perf library from kernel source
+License: GPL-2.0-only AND (LGPL-2.1-only OR BSD-2-Clause)
+%description -n libperf-devel
+This package includes libraries and header files needed for development
+of applications which use perf library from kernel source.
+
+# with_libperf
+%endif
+
 %if %{with_tools}
 %package -n %{package_name}-tools
 Summary: Assortment of tools for the Linux kernel
@@ -2728,6 +2753,12 @@ chmod +x tools/perf/check-headers.sh
 %{perf_make} DESTDIR=$RPM_BUILD_ROOT all
 %endif

+%if %{with_libperf}
+%global libperf_make \
+  %{__make} %{?make_opts} EXTRA_CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" %{?cross_opts} -C tools/lib/perf V=1
+%{libperf_make} DESTDIR=$RPM_BUILD_ROOT
+%endif
+
 %global tools_make \
   CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" %{make} %{?make_opts}

@@ -3009,6 +3040,10 @@ mkdir -p %{buildroot}/%{_mandir}/man1
 rm -rf %{buildroot}%{_libdir}/traceevent
 %endif

+%if %{with_libperf}
+%{libperf_make} DESTDIR=%{buildroot} prefix=%{_prefix} libdir=%{_libdir} install install_headers
+%endif
+
 %if %{with_tools}
 %ifarch %{cpupowerarchs}
 %{make} -C tools/power/cpupower DESTDIR=$RPM_BUILD_ROOT libdir=%{_libdir} mandir=%{_mandir} CPUFREQ_BENCH=false install
@@ -3494,6 +3529,37 @@ fi\
 # with_perf
 %endif

+%if %{with_libperf}
+%files -n libperf
+%{_libdir}/libperf.so.0
+%{_libdir}/libperf.so.0.0.1
+
+%files -n libperf-devel
+%{_libdir}/libperf.so
+%{_libdir}/pkgconfig/libperf.pc
+%{_includedir}/internal/*.h
+%{_includedir}/perf/bpf_perf.h
+%{_includedir}/perf/core.h
+%{_includedir}/perf/cpumap.h
+%{_includedir}/perf/perf_dlfilter.h
+%{_includedir}/perf/event.h
+%{_includedir}/perf/evlist.h
+%{_includedir}/perf/evsel.h
+%{_includedir}/perf/mmap.h
+%{_includedir}/perf/threadmap.h
+%{_mandir}/man3/libperf.3.gz
+%{_mandir}/man7/libperf-counting.7.gz
+%{_mandir}/man7/libperf-sampling.7.gz
+%{_docdir}/libperf/examples/sampling.c
+%{_docdir}/libperf/examples/counting.c
+%{_docdir}/libperf/html/libperf.html
+%{_docdir}/libperf/html/libperf-counting.html
+%{_docdir}/libperf/html/libperf-sampling.html
+
+# with_libperf
+%endif
+
+
 %if %{with_tools}
 %ifnarch %{cpupowerarchs}
 %files -n %{package_name}-tools
@@ -3543,6 +3609,8 @@ fi\
 %files -n %{package_name}-tools-libs-devel
 %{_libdir}/libcpupower.so
 %{_includedir}/cpufreq.h
+%{_includedir}/cpuidle.h
+%{_includedir}/powercap.h
 %endif

%files -n rtla

--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907

[OS-BUILD PATCHv2 2/4] Don't ship libperf.a in libperf-devel

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes

Don't ship libperf.a in libperf-devel

Signed-off-by: Justin M. Forbes

diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100644
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -3042,6 +3042,8 @@ rm -rf %{buildroot}%{_libdir}/traceevent

%if %{with_libperf}
 %{libperf_make} DESTDIR=%{buildroot} prefix=%{_prefix} libdir=%{_libdir} install install_headers
+# This is installed on some arches and we don't want to ship it
+rm -rf %{buildroot}%{_libdir}/libperf.a
 %endif

%if %{with_tools}

--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907

[OS-BUILD PATCHv2 3/4] Don't use upstream bpftool version for Fedora package

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes

Don't use upstream bpftool version for Fedora package

Upstream bpftool went with their own versioning. While this works in
rawhide and RHEL where release is bumped wth every build, it does not
work with Fedora. Because bpftool sublevel is not bumped with stable
updates, and we don't update the release in Fedora when the version has
changed, we ended up with a failure because the bpftool subpackage
version already exists. For Fedora, we will stick with the kernel
versioning for the package. bpftool -V still displays the upstream
bpftool version number.

Signed-off-by: Justin M. Forbes

diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100644
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -1227,7 +1227,14 @@ analysing the logical and timing behavior of Linux.

%if %{with_bpftool}

+%if 0%{?fedora}
+# bpftoolverion doesn't bump with stable updates so let's stick with
+# upstream kernel version for the package name. We still get correct
+# output with bpftool -V.
+%define bpftoolversion  %specrpmversion
+%else
 %define bpftoolversion %%SPECBPFTOOLVERSION%%
+%endif

%package -n bpftool
 Summary: Inspection and simple manipulation of eBPF programs and maps

--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907

[OS-BUILD PATCHv2 4/4] Remove separate license tag for libperf

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes

Remove separate license tag for libperf

Signed-off-by: Justin M. Forbes

diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100644
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -1135,13 +1135,11 @@ This package provides debug information for the perf python bindings.
 %if %{with_libperf}
 %package -n libperf
 Summary: The perf library from kernel source
-License: GPL-2.0-only AND (LGPL-2.1-only OR BSD-2-Clause)
 %description -n libperf
 This package contains the kernel source perf library.

%package -n libperf-devel
 Summary: Developement files for the perf library from kernel source
-License: GPL-2.0-only AND (LGPL-2.1-only OR BSD-2-Clause)
 %description -n libperf-devel
 This package includes libraries and header files needed for development
 of applications which use perf library from kernel source.

--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1740885...

Possibly, but to be honest the versioning is not exactly interesting either.
As you can see from the commit 9910a74d6ebf6 there isn't a whole lot of reason
for anyone to care about the bpftool version number.  It is pulled from the
kernel tree, but with a dynamically linked libbpf  we may well have a
completely incorrect version number.

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1741124...

@mh21_rh It appears we might need to add --without libperf to the cki builds
for this MR.

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745089...

when you say "for this MR", do you mean that this is not going to be needed
for other MRs going in later, and for the Rawhide/ELN baseline builds?

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745186...

It will be needed for all other MRs after this is merged, it just was not
needed before this MR.

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745213...

looking at the failing pipelines, there are some for ELN that are now failing
as well 🤔:
> 00:06:29 cc1: error: bad value ‘z15’ for ‘-mtune=’ switch

00:06:29 cc1: note: valid arguments to ‘-mtune=’ switch are: nocona core2
nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell
core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client
rocketlake icelake-server cascadelake tigerlake cooperlake sapphirerapids
emeraldrapids alderlake raptorlake meteorlake graniterapids graniterapids-d
bonnell atom silvermont slm goldmont goldmont-plus tremont gracemont
sierraforest grandridge knl knm intel x86-64 eden-x2 nano nano-1000 nano-2000
nano-3000 nano-x2 eden-x4 nano-x4 lujiazui k8 k8-sse3 opteron opteron-sse3
athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3
bdver4 znver1 znver2 znver3 znver4 btver1 btver2 generic native
00:06:29 make[2]: *** [/tmp/rpmbuild/BUILD/kernel-6.8.0-0.rc1.615d30064886.13.
test/linux-6.8.0-0.rc1.615d30064886.13.test.eln.s390x/tools/build/Makefile.bui
ld:106: core.o] Error 1

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745226...

There are, which makes no sense, as this MR is "include in release" and
neither Fedora or ELN builds failed yesterday with this MR included.

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745249...

at what CKI pipeline are you looking from https://gitlab.com/cki-
project/kernel-ark/-/pipelines?page=1&scope=all&ref=ark-latest?

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745260...

I meant actual builds in koji.
https://koji.fedoraproject.org/koji/buildinfo?buildID=2378280 for Rawhide and
https://koji.fedoraproject.org/koji/buildinfo?buildID=2378291 for ELN. As can
be seen there, this MR does exactly what it aims to do. No build failures. CKI
is the issue here, not this MR.

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745263...

yes, this looks like a cross-compiler mixup

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745264...

@dzickusrh ^ do you have an idea why the cross compiler is not correctly
selected here after the changes even for ELN?

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745269...

@jmflinuxtx as the MR only talks about Fedora, do you expect the spec file
changes to affect ELN in any way?

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745272...

@jmflinuxtx for Fedora, the CKI pipelines do not use native tools builds; when
you say "turn on tools", do you want to enable the native tools build in the
CKI pipelines, or do you expect this to work in a cross-compile setup?

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745275...

I do not. with_libperf is only set for Fedora at the moment.  If ELN/Rawhide
want to turn it on, the would need to do so with another MR.  This can be seen
in the resulting builds from koji where ELN does not build libperf packages,
but Fedora does.

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745279...

When I say "turn on tools" I mean simply enabling those subpackages in Fedora.
Most (excluding libperf) have always been enabled in ELN, but Fedora used a
separate package to build them.  Fedora is getting rid of that separate
package and wishes to build the tools subpackages as part of kernel now.

[Scott Weaver (via Email Bridge)]

From: Scott Weaver on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745281...

We are building the libperf package in cs9 but somehow missed porting that to
ark. So we should have it enable for ELN.

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745285...

ack; so iiuc

- Fedora/Rawhide pipelines should enable native tools builds, so that the
tools subpackage building is handled the same way as for ELN, where it
_normally_ is working correctly
- somehow this MR is breaking the libperf build even for ELN, but maybe this
is because it was not enabled before at all

?

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745288...

I suppose so. I am guessing this is because we don't add --without libperf
which is a new option now. Realistically libperf is turned off for ELN now
though so, not sure why it is being built.

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745290...

@scweaver It may be, but when I emailed acme about it, he said it wasn't ready
to be turned on. I am guessing it is moving too quickly and RHEL 10 will be
enabled with a specific ABI?

[Scott Weaver (via Email Bridge)]

From: Scott Weaver on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745295...

Ah. Ok so that explains why it's not in ark yet. So we can leave it off for
ELN and handle it in RHEL10 then.

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745452...

- for tracking: https://gitlab.com/cki-project/pipeline-
definition/-/issues/223
- move `--with libperf` to native tools stage: https://gitlab.com/cki-
project/pipeline-definition/-/merge_requests/1879

I'm still confused why this is affecting the ELN builds, rpmbuild is called
via `rpmbuild --rebuild --target ppc64le --with cross --with up --with base
--without bpftool --without selftests --without ipaclones --without perf
--without tools --without trace --without debug --without arm64_16k --without
arm64_64k --without realtime --without zfcpdump`
[[1]](https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-
pipelines/cki-trusted-contributors/-/jobs/6000516388#L91) which does not
include `--with libperf` at all, @jmflinuxtx could you take a look at the
conditionals in the spec file again?

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745461...

@jmflinuxtx checking Koji,
https://koji.fedoraproject.org/koji/buildinfo?buildID=2378291 is the latest
ELN kernel build and has the `libperf` subpackage. Which build did you check
that included this MR but did have the `libperf` subpackage successfully
disabled?

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745476...

I have looked at them, and they are off for eln. As you can see from the ELN
build linked above, we do not build libperf on ELN. I don't think that CKI is
actually failing on libperf here for ELN. It is failing on cross compile
issues.

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745480...

now I'm totally confused 😂 - the link above has
libperf-6.8.0-0.rc1.20240125git6098d87eaf31.15.eln134.aarch64.rpm, is that the
wrong package?

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1745521...

Indeed they are, the turned off are for other places where tools are turned
off.

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749852...

whatever is failing the Rawhide pipeline in this MR is also failing e.g.
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2912, so this
particular breakage seems to be caused by something that was merged before.

ppc64le build from this MR - https://gitlab.com/redhat/red-hat-ci-
tools/kernel/cki-internal-pipelines/cki-trusted-
contributors/-/jobs/6052447795#L105:
> 00:00:24 + /usr/bin/make CROSS_COMPILE=ppc64le-linux-gnu- -s HOSTCFLAGS=

HOSTLDFLAGS= ARCH=powerpc 'KCFLAGS= ' WITH_GCOV=0 -j24 vmlinux
> 00:00:28 cc1: error: bad value ‘power8’ for ‘-mtune=’ switch

ppc64le build from !2912 - https://gitlab.com/redhat/red-hat-ci-
tools/kernel/cki-internal-pipelines/cki-trusted-
contributors/-/jobs/6033136409#L106:
> 00:00:22 + /usr/bin/make CROSS_COMPILE=ppc64le-linux-gnu- -s HOSTCFLAGS=

HOSTLDFLAGS= ARCH=powerpc 'KCFLAGS= ' WITH_GCOV=0 -j24 vmlinux
> 00:00:26 cc1: error: bad value ‘power8’ for ‘-mtune=’ switch

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749862...

This MR is "include in release" so it is being tested in all pipelines.

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749862...

To enable native tools for Rawhide similar to ELN, the only change to
`.gitlab-ci.yml` is

```yaml
.trigger_rawhide:
  variables:
    native_tools: 'true'
```

As the Rawhide non-debug pipelines are the only ones affected by this, the
above issue needs to be fixed first to be able to validate that `native_tools:
true` is indeed also working for Rawhide.

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749864...

This is a cross-compile issue so is not visible in Brew; if this is not
something you want to keep green for Fedora/Rawhide, should we remove the
ppc64le/s390x arches for the Rawhide pipelines?

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749868...

same for the Clang pipeline which seem to be red everywhere, @dzickusrh should
we remove them as well?

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749868...

Why would we remove arches which should work fine? If we can build tools for
ELN with the native_tools bit, we should be able to do the same for rawhide,
no?

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749870...

I assumed it has nothing to do with native tools as https://gitlab.com/cki-
project/kernel-ark/-/merge_requests/2912 is also impacted?

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749872...

aaah the builds merge `ark-latest` now 🤦

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749873...

As I said above, this particular MR is include in releases because I need koji
building these packages.  Since pipelines now run on include in releases, this
MR should be impacting others too.

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749878...

the first failure is 30 seconds into the build:

```
> /usr/bin/make CROSS_COMPILE=ppc64le-linux-gnu- ... vmlinux
> 00:00:28 cc1: error: bad value ‘power8’ for ‘-mtune=’ switch

```

I'm a bit at a loss why this `cc1` is not the cross compiler, but the native
one; the same seems (?) to work fine on ELN

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749892...

checking an ELN log, the same error is present there 🤦

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749901...

ok, one mistake found: the Rawhide pipeline was never restarted with the
change in https://gitlab.com/cki-project/pipeline-
definition/-/merge_requests/1879, so the `--without --libperf` was missing in
the cross-compile `build` jobs

I recreated a new child pipeline for `ark_merge_request` that should pick up
these changes.

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749908...

@jmflinuxtx do you have an idea whether it is expected that the above rpmbuild
command still hits Makefile.perf?

```
00:33:18 make[1]: *** [Makefile.perf:251: sub-make] Error 2
```

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749916...

I do not expect that it would hit Makefile.perf for any reason.

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749965...

I'll keep on digging...

[Michael Hofmann (via Email Bridge)]

From: Michael Hofmann on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749970...

@jmflinuxtx ah I think I have an idea, the spec file now has the following
lines for Fedora:

```
%define with_libperf 1
%define with_tools 1
```

with these, is it even possible to disable tools and libperf build via
`--without libperf --without tools`?

[Justin M. Forbes (via Email Bridge)]

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2907#note_1749975...

I believe you are correct. Will fix it up.