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 _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
