On Thu, 2020-04-16 at 08:34 +0200, Thorsten Leemhuis wrote:
Am 15.04.20 um 15:41 schrieb Jeremy Cline:
On Wed, 2020-04-15 at 11:31 +0200, Thorsten Leemhuis wrote:
Am 15.04.20 um 00:37 schrieb Jeremy Cline:
On Tue, 2020-04-07 at 15:33 +0000, Jeremy Cline wrote:
On Wed, 2020-03-11 at 16:40 +0000, Jeremy Cline wrote:
There is one thing I really dislike about the scheme (one it didn't notice when I took a brief look at it weeks ago; sorry): There are no individual patches anymore in dist-git/the srpm and that afaics violates the packaging guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches […] So you you maybe change the scheme so individual patch files land in the src.rpm?
I'll look into how simple it is to change.
Thx. Until then or in general: If you have a minute it IMHO would be really nice to have a comment in the spec file that…
It's easy to see in the source tree, though, just look at the "ark-patches" branch.
…wound explain this with a link to the git repo. Then maintainers from other distros or interested people that look in dist-git or the src.rpm known where to look for patches.
And BTW: I wouldn't call that "easy". Simply browsing to https://src.fedoraproject.org/rpms/kernel/tree/f32 and looking for files that end with .patch is way easier, even if you know your way around with git. And if you want to take a closer look you don't have to clone only a small git repo instead of a really big fat one…
P.S.: The "--with-vanilla" build option afaics doesn't work anymore, as patch-%{rpmversion}-redhat.patch and linux-kernel-test.patch are always applied.
I'll see about that as well.
Great, thx.
Note that if you want a vanilla SRPM it's easy from the source tree:
$ git checkout master $ git merge internal $ sed -i 's/=13/=11/g' redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDE R $ make rh-srpm
What kind of sorcery is that? ;-) Well, I guess I'll understand if I dig deeper into the kernel-ark documentation...
The short story is internal is the (poorly named) branch that contains the config and build scripts. Fedora ships a patch that changes CONFIG_FORCE_MAX_ZONEORDER default so it's invalid if you prep the kernel without it. It might be best to not check configurations for completeness and validity by default.
This BTW might be the biggest problem with the whole new approach: It's not really obvious and a bit hard to understand. Yes, there are is lots of documentation in kernel-ark project, but if you are used to RPM or DEB packages and just want to peek into the Fedora kernel SRPM (say you have a kernel problem you want to track down and fix) then you might quickly feel lost, as there seems to be a lot of magic you have to learn for an otherwise small task. I know that this magic is supposed to make the kernel maintainers life easier, but it makes things a lot harder for other people that thus might give up instead of helping you. That's IMHO one of the reasons why the Fedora Packaging Committee put the rules in place I mentioned. Maybe a few more comments in the spec file or a document with a quickstart for this use case could help a lot.
I've proposed a readme[0] and something to break the patches out for those who prefer dist-git[1].
There's also a fix for the buildid reordering[2] and the moving of files around that breaks multiple preps[3].
I'm happy to make improvements and make this as easy as possible. It's not perfect to start out and I apologize to anyone who's been inconvenienced by that changes.
[0] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/303 [1] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/315 [2] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/296 [3] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/300
However, if you want to continue building from the dist-git, the patch is ignored if it's empty so doing
$ truncate -s 0 patch-*-redhat.patch
will also give you a vanilla build.
Ahh, good to know.
Thx for replying and looking into this,
Given this are do you still want a --with-vanilla option?
- Jeremy