Re: Upcoming Fedora kernel workflow changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux