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