Hi Dann Now I have gone though all the patches that Kir sent and are now doing a test build of the proposed patch (attached).
I have attached the changes to changelog and 14-extra file and also included a tar.gz file with all the openvz patches in the patches/features/all/openvz dir. As you can see the patch directory contais a number of more fixes than included in the 14-extra file, simply because they are (likely) ABI breakers. I have tried to exclued all potential ABI breakers. My test build will show that for sure in an hour or so. You can also see that a number of the fixes do not have a Debian bug attached to them. Should I file one for each (they are all important at least) or is it enough with one or a few more general ones? You can also see that we have a number of security issues that I have not included because they are ABI breakers. This really means that we should bump the ABI version. Best regards, // Ola On Mon, Mar 09, 2009 at 01:42:10PM -0600, dann frazier wrote: > On Mon, Mar 09, 2009 at 08:13:28PM +0100, Ola Lundqvist wrote: > > Hi Dann > > > > On Sun, Mar 08, 2009 at 11:17:09PM -0600, dann frazier wrote: > > > On Tue, Mar 03, 2009 at 09:44:04PM +0100, Ola Lundqvist wrote: > > > > Hi Dann > > > > > > > > You asked about the latest status and here it is. > > > > Please tell which ones you want me to fix for the next lenny release of > > > > the kernel. I'll prepare > > > > a patch and regression test that version for you. > > > > > > > > #510787: > > > > Refers to an other bug report that was not openvz specific. Should it be > > > > forwarded to an non-openvz version of the kernel or kept here? > > > > > > I don't think it really matters - you can reassign to linux-2.6 if you > > > like though. > > > > Done that now. > > > > > > In any case I have added latest information to the report and told where > > > > the problem has been forwarded. > > > > > > Thanks! > > > > > > > #511165: > > > > Patch exist for 2.6.24 and 2.6.26. Fix is available in > > > > http://git.openvz.org/?p=linux-2.6.26-openvz;a=commit;h=b5e1f74cee5bc2c45bdca53a7218fb8de89215dd > > > > Not sure if this is an ABI breaker. > > > > > > Seems straightforward, and shouldn't change the ABI. I'll commit it > > > assuming my test build shows that. > > > > This tells me that there is an easy way to check that. How is that done? > > I assume some files are compared, but I can not find that in the debian > > directory (without building). > > This is just based on looking at the patch - I don't see anything > there that would change an exported symbol. Things to look for > structure definition changes, or changes to exported function calls. > Adding/removing includes can also have non-obvious effects. > > My test build did succeed, and this change has been committed. > > > > > #500876: > > > > Fix available in: > > > > http://git.openvz.org/?p=linux-2.6.26-openvz;a=commit;h=777e8164ebf8a03e43511983cdec472f8691a8af > > > > Problem is about to be verified. Regression tested without problems > > > > seen. > > > > > > I couldn't reproduce this one (tried dual quad core intel server & a > > > single quad core amd), but user claims this fixed the bug for me and I > > > haven't seen any issues with this patch so its been committed. > > > > I think you need to have a quad-core amd64 for this. But let us commit it > > as it do not seem to hurt. > > I tried on a quad-core/one socket amd64, but maybe it requires > multiple sockets? > > > > > #503097: > > > > Reported as http://bugzilla.openvz.org/show_bug.cgi?id=930 > > > > Seems to be a duplicate of #500876 above. > > > > > > Cool. If you think so, it might be good to have Carlos test one of > > > these builds to verify: > > > http://people.debian.org/~dannf/bugs/500876/ > > > > Ok, I'll ask him at once. > > Thanks! > > > > (Tomorrow's snapshot builds should also include it) > > > > > > > #505174: > > > > This is a request to go up to the latest version that includes fixes for > > > > all the ones in this mail that describe that there is a fix available. > > > > Unfortunatly there are ABI breakers... > > > > > > Its probably a good idea to stick with specific issues/fixes now that > > > its a stable release. > > > > Maybe so. The openvz development team has proven to provide quite well > > tested kernels. However the safer approach may still be to stick to the > > specific issues. > > Yeah, I certainly don't mistrust the openvz team - but all changes > come with a risk of regression, and its easier to regression test > specific changes. > > > > > #508773: > > > > Patch available in http://bugzilla.openvz.org/show_bug.cgi?id=1054 > > > > Fix in > > > > http://git.openvz.org/?p=linux-2.6.24-openvz;a=commit;h=20bd90762d4df4a3c7c247b660c696bdd0a27709 > > > > Do not look like an ABI breaker to me. > > > > > > Yep, definitely shouldn't break the ABI, and seems like a good > > > candidate. > > > > Good. Please tell if you want me to prepare some patch or check in > > something. > > Patches that apply directly to kernel svn are certainly > welcome. Normally, that should mean adding a changelog entry, a series > file entry, and a new patch file. > > This one is pretty trivial, so I'll go ahead and generate a changeset > to commit - but it would be great if you could ensure that the > snapshot builds get regression tested after they become available. > > > > > #500145: > > > > Forwarded to http://bugzilla.openvz.org/show_bug.cgi?id=1143 > > > > Marked as dupliate of http://bugzilla.openvz.org/show_bug.cgi?id=1067 > > > > Not solved yet. > > > > > > ok > > > > > > > #501985: > > > > From: maximilian attems > > > > the upstream nfs fixes are abi breakers and thus can't be integrated > > > > at this point they will be for the first point release were abi > > > > breaking will be allowed again. > > > > > > What is the fix for this - does upstream openvz include it? > > > > Yes it is found upstream. See the file > > http://download.openvz.org/kernel/branches/2.6.26/current/patches/patch-chekhov.1-combined.gz > > The current patch do not touch any nfs/ files and upstream does. The patch > > now in use was not fully completed when it was incorporated by Maximilian. > > I see - so we need to identify which additional changes are needed. > http://git.openvz.org/?p=linux-2.6.26-openvz;a=commitdiff;h=66ec7f7f493fb98e8baa6591e9225086ae640fb8 > http://git.openvz.org/?p=linux-2.6.26-openvz;a=commitdiff;h=39bb1ee59237272cd20e1f8696cefbd6a787cfc8 > > Is this severe enough to fix in a stable release? If we consider this > a regression from etch (since kernel-patch-openvz supplied this), than > maybe so. Is the risk of regression low? Well - these patches would > only get applied on openvz kernels which currently don't support nfs > at all so, assuming these changes are nfs-specific, risk should be > low. > > > > > #494445: > > > > There are a number of problems in this area. Fixes are available. > > > > However some of them are ABI breakers. > > > > > > The nf_conntrack_ipv6 module doesn't appear to be in 2.6.26-13. Maybe > > > it was disabled because of this bug? At this point, turning it > > > on/fixing probably falls into the category of a feature requests that > > > doesn't enable hardware, so wouldn't have a sufficient severity (>= > > > important). > > > > True. > > > > > > #500645: > > > > Fix available in http://bugzilla.openvz.org/show_bug.cgi?id=1034 > > > > http://git.openvz.org/?p=linux-2.6.26-openvz;a=commit;h=6d18ba377cfa3e86ee830fe6a5fce52b8fd51039 > > > > I can not see that this is an ABI breaker, so it should be possibly to > > > > apply this one without problem. > > > > > > The patch itself certainly looks trivial enough - but the bug is only of > > > severity "normal". If we think this actually deserves a >= important > > > severity, we should bump the severity of the report. > > > > Yes this one is really important. I'll change the severity now. > > ok > > -- > dann frazier > > -- --- Inguza Technology AB --- MSc in Information Technology ---- / o...@inguza.com Annebergsslingan 37 \ | o...@debian.org 654 65 KARLSTAD | | http://inguza.com/ Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --------------------------------------------------------------- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
