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

Re: automatic custom kernels?

Andreas Barth schrieb am Friday, den 16. December 2005:

> > 1. Automatically obtain the latest list of kernel-patch packages (patch
> > packages can be hinted out that are known to be problematic, or only
> > apply to upstream vanilla)
> > 2. Automatically obtain the latest list of linux-source packages
> > 3. If either #1 or #2 has new items, proceed
> > 4. Individually attempt to apply each patch (verbose) to source making
> > patch logs available, if failure is detected do not proceed
> > 5. If indicated somewhere attempt to apply a second patch (allowing for
> > kernels with grsecurity+vserver patches for example)
> we could for a first round make a list of "apply patches foo, bar, baz",
> so that these patches are applied in this order.

I think the first step would be to get a process together to handle
single kernel patches first. Once this is sorted out, then we can look
at the larger idea of multiple different patches.

I was thinking it might be an interesting idea to try and do this in a
similar way as is taken with buildds. A patch is somehow queued to be
applied to the kernels. The queue runs and pulls the kernel source and
the kernel patch, unpacks the kernel source, runs
/usr/src/kernel-patches/all/apply/$patchname and then mails the patch
maintainer the results. If they sign the log and return it this means
that they have verified that the patch has applied cleanly, and the
kernel-patch+kernel_version would then proceed to be compiled.

I'm not sure if this extra confirmation would be necessary as it might
be trivial to just test the result-code of the attempted patch and not
proceed if it is non-zero. This needs some scripting to see how it
would work.

> > The solution to this could be having a separate repository for
> > these patched kernel images, so you would have to make a conscious
> > decision to use this repository and thus would know what you are getting
> > into.
> Well, perhaps we even should make the patches to be part of the
> filename, so you can get something like
> deb $url vserver/
> oder
> deb $url vserver-grsecurity/
> With this szenario, you get only the kernels to see that you really
> want.

This would be good, although it would be better if users did not have
to add a new entry to their sources.list to be able to find these
patched kernels. However, I'm wary of uploading patched kernels to the
main archive for all the different flavors as this would quickly
result in a looong list of available kernels, which can cause


Attachment: signature.asc
Description: Digital signature

Reply to: