Thanks for the report, we'll look into this as prio 1 of course.

The warnings seem to be for a good reason:

%define uname_suffix %{lua:
        local flavour = rpm.expand('%{?1:+%{1}}')
        flavour = flavour:gsub('-', '_')
        if flavour ~= '' then
                print(flavour)
        end
}

That is *not* a paremetric macro, so there's never any macro %{1} defined. I don't see how that would have ever worked for the argumented case, but older rpm versions just didn't warn about this. Fixing this is simple enough: just add parentheses after the macro name for both these macros, ie

%define uname_suffix() %{lua:
...

As for the the errors, I see the following: 

1) apparent compile switch errors, such as:
- relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: failed to set dynamic section sizes: bad value
- clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for target 'x86_64-redhat-linux-gnu'

2) error: could not create '/kernel-6.10-rc1-27-g4a4be1ad3a6e': Permission denied

The latter looks like some macro is expanding to "" unexpectedly, no idea would that or the compile switch problems be. I'll report back as soon as I have something, off to investigate now.

> I did attempt to rebuild the srpm from Monday's kernel build just to verify that it was rpm and not a kernel change. 

If you have the logs, it would be helpful to be able to compare the success/failure of an otherwise identical kernel build. I can see eln-builds on koji but I'm not sure how closely that reflects current Fedora.

Looking at the logs from the most recent successful f41 build before rpm 4.20: https://koji.fedoraproject.org/koji/buildinfo?buildID=2457885, eg https://kojipkgs.fedoraproject.org//packages/kernel/6.10.0/0.rc1.20240528git2bfcfd584ff5.18.fc41/data/logs/x86_64/build.log

The -fPIE and '-mtls-dialect=' errors are there already, eg:

usr/bin/ld: /builddir/build/BUILD/kernel-6.10-rc1-13-g2bfcfd584ff5/linux-6.10.0-0.rc1.20240528git2bfcfd584ff5.18.fc41.x86_64/samples/bpf/bpftool/bootstrap/libbpf/libbpf.a(libbpf-in.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for target 'x86_64-redhat-linux-gnu'
clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for target 'x86_64-redhat-linux-gnu'
make[1]: *** [Makefile:231: /builddir/build/BUILD/kernel-6.10-rc1-13-g2bfcfd584ff5/linux-6.10.0-0.rc1.20240528git2bfcfd584ff5.18.fc41.x86_64/tools/testing/selftests/bpf/liburandom_read.so] Error 1

So, there are things failing in that build before 4.20, whether you were aware of that or not. Anyway, for me this is good news because I couldn't see how rpm would throw up bad compiler options now. So the issue with 4.20 comes down to just this:

error: could not create '/kernel-6.10-rc1-27-g4a4be1ad3a6e': Permission denied

Now I only need to find what *that* is...

Okay, found where it goes wrong. On a successful build this looks like:

> '/usr/bin/python3' util/setup.py --quiet install --root='//builddir/build/BUILDROOT/kernel-6.10.0-0.rc1.20240528git2bfcfd584ff5.18.fc41.x86_64'
> [...]
>  self.initialize_options()
> + mkdir -p /builddir/build/BUILDROOT/kernel-6.10.0-0.rc1.20240528git2bfcfd584ff5.18.fc41.x86_64//usr/share/man/man1

On the failing builds:

> '/usr/bin/python3' util/setup.py --quiet install --root='/kernel-6.10-rc1-27-g4a4be1ad3a6e'
> [...]
>  self.initialize_options()
> error: could not create '/kernel-6.10-rc1-27-g4a4be1ad3a6e': Permission denied

So somehow somewhere the %{buildroot} and/or $RPM_BUILD_ROOT is empty. There have been changes around that so it kinda figures and the path is quite different now, but then it works for most of the spec so this must be some rather special case. Back to digging.

Okay so the problem comes, somehow, from this:

%global __spec_install_pre %{___build_pre}

I don't yet quite understand how that causes RPM_BUILD_ROOT to be empty inside %install, but that's it, I've been able to reproduce this locally with a much smaller spec.

I don't know how to build a custom kernel on fedora infra without uploading an entire src.rpm so haven't been able to test this (yet anyway), but changing the %global to %define *should* fix it. 

The Fedora recommendation to always use %global is a bad one because it's much more subtle than that, %global causes the macro body to be expanded immediately whereas many, many uses want expand-on-use behavior instead.

I'm off to chase down the underlying cause here because this doesn't seem right, but using %define would seem more appropriate there regardless of rpm version. Assuming that works, because it IS certainly possible to have problems in the other direction too.

Scratch the above, I see kernel is aware of the %global/%define difference and crafted for it. I'll note that such overrides to deep internals are playing with fire.

But I see the actual issue now. There's a well over 20 years old conditional in rpm macros around buildroot that is used for setting up RPM_BUILD_ROOT environment in the scriptlet execution environment:

> %{?buildroot:RPM_BUILD_ROOT=\"%{buildroot}\"

At the very early part of the spec this __spec_install_pre is being expanded, the *real* buildroot is not yet known at all because name, version etc are not known. For the rest of the stuff like RPM_PACKAGE_NAME=%{NAME} it doesn't matter because it "falls through" as-is, and gets re-expanded later to the proper value, but that silly conditional from pre-historic times causes RPM_BUILD_ROOT to be dropped entirely from the scriptlet execution environment.

Fix coming right up.

That particular issue fixed in rpm-4.19.91-5.fc41 now, hopefully that's all there is.

Apologies for the disruption, this was a good catch, but the kernel spec is meddling with internals that we cannot guarantee to stay stable in all cases. And you'll probably want to look into those unrelated pre-existing errors in the build.

Actually, lets leave this open until verified by a build...

Build here https://bodhi.fedoraproject.org/updates/FEDORA-2024-15aa3e51a5, once it passes the gating (makes airports seem walk in the park, these gates)

I have a new kernel build going, thanks for looking into this so quickly.  Yes, the compile error is on some selftests which are explicitly allowed to fail.

Right, seems to be passing (although not entirely complete yet).

Completed now. Thank you very much!