Re: automatic custom kernels?
* micah (micah@riseup.net) [051225 23:06]:
> 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.
yes, of course.
> 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.
well, we can basically do a special pseudo-suite that queues packages
like kernel-2.6.14^vserver, and the used package builder just jumps into
a special hook in case of this pseudo-suite. Of course, the question of
version numbers needs to be resolved for this, but that's a good
question anyways. This would allow us maximum reusability and at the
same time, easy integration on the machine where we want to use this.
> 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.
Well, I'd just send out the build logs "as usual", and also put them on
a web site somewhere.
> > > 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
> confusion.
We could always decide later on to put some special kernel variants also
on the main archive.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Reply to: