Hi Steve,
See my comments below.
Steve Langasek wrote:
If so I need to be prepared as that will probably break this patch.
Why is this patch so fragile? If it breaks that easily, it hardly seems
releasable -- how do we protect against it being broken by security updates?
I suggest that
a. A workaround is to have kernel-image-openvz, the same as
Linux-VServer does. Thus people will not run into troubles.
b. A solution is to coordinate Debian security updates with OpenVZ
kernel team. Thus OpenVZ team can timely (i.e. before you release)
prepare a patch which is surely applicable to your kernel flavour.
Answering your question -- there were two fails, I looked through .rej
files and found their causes:
One failed hunk in net/ipv6/udp.c -- looks like the patch from 2.6.18.5
is not applied to linux-source-2.6.18-7:
* http://tinyurl.com/2n9554
Six failed hunks in net/ipv4/ip_tables.c -- same, looks like a few
patches from 2.6.18.y-stable are not applied to linux-source-2.6.18-7. I
see at least the following ones:
* http://tinyurl.com/2l5sae
* http://tinyurl.com/38bgxa
* http://tinyurl.com/2wx9jz
I have just checked that after applying four patches linked above,
kernel-patch-openvz-028test007.1 applies cleanly on top of
linux-source-2.6.18-2.6.18-7.
Thus the question: are you tracking the -stable tree, and how closely do
you follow it?
Regards,
Kir.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]