RFC: Repos with vanilla kernel packages

[Thorsten Leemhuis]

Hi!

On 23.01.2012 15:09, Josh Boyer wrote:
> On Sun, Jan 22, 2012 at 06:43:44PM +0100, Thorsten Leemhuis wrote:
> [...]
>> I included the source for above wiki page and the patch kernel.spec
>> below. I hope that makes yelling in my direction ^w^w^w^w commenting on
>> it easier, as I suppose some people will not like the idea as a whole
>> ^w^w^w^w^w some of the decisions I made when adjusting the spec file for
>> my purposes. if that's the case please let me know, as I do not plan to
>> mention the effort anywhere else over the next few days; that way I
>> should be able to adjust details if there are good reasons to do so,
>> before to many people get aware of those repos.
> Well volunteered.  I appreciate the effort and hope that you have more
> success than I did when I was building these by hand.

Time will tell.

>> Note, the next step I plan is to set up a second repo with packages that
>> have the latest mainline development kernels (3.3-rc). But I thought I
>> collect options on the current state of things first before moving on.
> Good plan.  I have just a few minor comments below.

Many thanks for those!

>  Overall I think the
> wiki page is very well written and addresses most of the common question
> that always come up.

Hope so. I also hope the text scares some of those people away that
don't really know what they are doing.

>>> == FAQ ==
>>> ==== Are the kernels from the kernel-vanilla repositories as good as
>>> those Fedora provides? ====
>>>
>>> No. There are several reasons for why not; the most important ones:
>>>
>>> * the developers that take care of the kernel package in Fedora are
>>> far more experienced in packaging kernels and kernel development than
>>> those that take care of the kernel-vanilla repositories * the kernels
>>> that get used in Fedora or released as proper update get a lot of
>>> testing; the kernels from the kernel-vanilla repositories get nearly
>>> no testing * some of the kernel-vanilla repositories contain kernels
>>> that are still under heavy development and sometimes are known to
>>> have serious bugs * the official Fedora kernels sometimes contain
>>> changes that fix security problems before they get upstream
> At times, the Fedora kernel contains fixes for issues that even prevent
> booting on machines as well.  This is particularly true for the
> development -rcX series, with the kmemleak.patch we're carrying on top
> of 3.3-rc1 being a good example.  Such patches should be carried only
> the short time it takes before they get into mainline, but they are
> fairly important.

Good point, added a few words about that to the wiki page.

>>> ==== Do you plan to provide packages for "linux-next" or "linux-rt"
>>> as well? ====
>>>
>>> For now: No. I know there is some interest in packages for them, but
>>> maintaining those will consume a lot of time regularly and we have
>>> not enough resources to do it properly right now. But if you want to
>>> step up and help, [[user:thl|get in contact]].
> If people are interested in the linux-rt project, I would suggest they
> work with the CCMA people as they're already based on that.  There's no
> reason to duplicate effort if their work will suffice.

Argh. I actually had thought about that a day after writing that para,
but then forgot to adjust it. Done now.

> I would avoid packaging linux-next entirely.  Leave that to people that
> hand build kernels.

I used similar words once when discussing the idea with a developer that
regularly contributes patches to the kernel. He argued in favor of
pre-build kernel packages for -next and convinced me up to the point
where I said "yeah, maybe you are right and it makes sense". But for now
I won't touch that area, as it is to much work.

>> Patch
>>
>>> --- a/kernel.spec
>>> +++ b/kernel.spec
>>> @@ -23,7 +23,7 @@ Summary: The Linux kernel
>>>  #
>>>  # (Uncomment the '#' and both spaces below to set the buildid.)
>>>  #
>>> -# % define buildid .local
>>> +%define buildid .vanilla.knurd
>>>  ###################################################################
>>>  
>>>  # The buildid can also be specified on the rpmbuild command line
>>> @@ -109,7 +109,7 @@ Summary: The Linux kernel
>>>  # kernel-PAE (only valid for i686)
>>>  %define with_pae       %{?_without_pae:       0} %{?!_without_pae:       1}
>>>  # kernel-debug
>>> -%define with_debug     %{?_without_debug:     0} %{?!_without_debug:     1}
>>> +%define with_debug     %{?_with_debug:        1} %{?!_with_debug:        0}
>>>  # kernel-doc
>>>  %define with_doc       %{?_without_doc:       0} %{?!_without_doc:       1}
>>>  # kernel-headers
>>> @@ -119,7 +119,7 @@ Summary: The Linux kernel
>>>  # tools
>>>  %define with_tools     %{?_without_tools:     0} %{?!_without_tools:     1}
>>>  # kernel-debuginfo
>>> -%define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 1}
>>> +%define with_debuginfo %{?_with_debuginfo:    1} %{?!_with_debuginfo:    0}
>>>  # kernel-bootwrapper (for creating zImages from kernel + initrd)
>>>  %define with_bootwrapper %{?_without_bootwrapper: 0} %{?!_without_bootwrapper: 1}
>>>  # Want to build a the vsdo directories installed
>>> @@ -164,7 +164,7 @@ Summary: The Linux kernel
>>>  %define with_sparse    %{?_with_sparse:       1} %{?!_with_sparse:       0}
>>>  
>>>  # Include driver backports (e.g. compat-wireless) in the kernel build.
>>> -%define with_backports %{?_without_backports: 0} %{?!_without_backports: 1}
>>> +%define with_backports %{?_with_backports: 1} %{?!_with_backports: 0}
>>>  
>>>  # Set debugbuildsenabled to 1 for production (build separate debug kernels)
>>>  #  and 0 for rawhide (all kernels are debug kernels).
>>> @@ -234,7 +234,7 @@ Summary: The Linux kernel
>>>  
>>>  %if %{nopatches}
>>>  %define with_bootwrapper 0
>>> -%define variant -vanilla
>>> +#define variant -vanilla
> 
> I don't see where you define nopatches or with_vanilla in this patch.
> Did you do that when you actually built and just didn't include it in
> this patch?

Sigh. Seems I just made a fool out of myself in public :-)

Yes, I redid the git repo and the patch yesterday and it looks like I
forgot this part when reapplying the patch manually:

-%define with_vanilla %{?_with_vanilla: 1} %{?!_with_vanilla: 0}
+%define with_vanilla %{?_without_vanilla: 0} %{?!_without_vanilla: 1}

And stupid as I am I did not check if everything worked as it was
supposed to be. Crivens.

Will prepare and upload updated packages. Thanks again for your comments.

Cu
 knurd