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_ZONEORDER > $ make rh-srpm What kind of sorcery is that? ;-) Well, I guess I'll understand if I dig deeper into the kernel-ark documentation... 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. > 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, CU, knurd _______________________________________________ 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
