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 confusion. Micah
Attachment:
signature.asc
Description: Digital signature