* micah ([EMAIL PROTECTED]) [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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
