Easy way to write specs for custom kernel?

I’m trying to build an custom kernel to rpm package, but with patches, new config options, and submit it to COPR for ci/cd.

What I tried

Follow guides

I tried the standerd guide, edit fedora/kernel and make srpm. But my custom kernel has Kconfig conflict with mainstream, so it reports error when trying to merge configs. Also i dont want to patch config for all .config in that repo.

Write custom spec

I try to write an Kbuild from nothing, but it was pretty hard to properlly install everything fedora wants.

What I expect

So does fedora has some kinda kernel-build rpm macros? Like gentoo eclass:

Might or might not be a help for you, I build something that can be used to quickly build a srpm from any git tree: Files · arkify-arkify · Thorsten Leemhuis / linux · GitLab

But modifying the kernel config might not be that easy, never thought about that use case or how to make that easier. And the whole concept is a by-product of Kernel Vanilla Repositories - Fedora Project Wiki anyway.

I recommend that you start with the Fedora kernel SRPM and use it’s spec file and patches as the starting point for your custom kernel.

I recommend that you start with the Fedora kernel SRPM

Yeah, in the past I would have done that, too (and it seems that’s what the poster tries). But these days the SRPM is generated from dist.git, and its content are generated from cki-project / kernel-ark · GitLab – so it might be better to start right there, especially if you are familiar with git. And arkify makes that easy. But of course going down that route has downsides, too.

1 Like

Update: I found that i can just overwrite single config file, turn off the config checks and ignore all other configs. Its pretty ugly but do works.

 #
 # check for mismatched config options
-%define with_configchecks %{?_without_configchecks:        0} %{?!_without_configchecks:        1}
+%define with_configchecks 0
 
 #
 # gcov support

I do plan to update the custom kernel guide before Flock this year. As for your solution, that is by far the easiest method to integrate config changes if you are not worried about what other changes you might introduce. For patches, you can always add them to the linux-kernel-test.patch which is empty, and applied specifically for this purpose. Anything more complex, it is recommended to work in kernel-ark source git.