More on additional glibc test to prevent Debian on Redhat+TUX VPS users to get in troubles when upgrading to glibc 2.7-3.

[PieterB <PieterB@gewis.nl>]

> > Can anybody help me find the kernel patch I should ask to be installed
> > (I doubt they do that in short time with a big hosting company like Strato).
>   actually it's a patch to remove (it's called the TUX patch afaict).

I found a broader description of it at 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454638

I now understand that the problem is caused by the non-standard RHEL kernel
my VPS-provider (Strato) uses. Debian maintainers blame the (non-standard)
Redhat+TUX kernel. Redhat blames the use of a non-standard TUX patch. The
VPS software people who used this kernel (probably Virtuozzo) should fix
this permanently by not using the TUX patch, or creating another fix.

I agree with Comment #5 from John Salmon at the Redhat glibc tracker at
http://sourceware.org/bugzilla/show_bug.cgi?id=5227#c5 in which he states:

   I see "no reason to ignore a straightforward test, modeled after the
   other tests in dirent/, that passes when glibc is working correctly and
   that fails on some systems which happen to be unsupported?"

The test code for finding failing on a non-standard kernel host system, can
be found in the Redhat bug tracker.

I hope Debian maintainers can re-open Bug#454638 and create a test that
prevents these problems, so that others don't have to run into these nasty
issues like I did. Please promote the additional test to the testing
distribution. My problems began after [2007-12-05] when glibc 2.7-3 was
MIGRATED to testing.

I'll hold libc6 upgrades in my Debian testing distribution next time I'll
upgrade my VPS. I first need to wait until my restore is done. I didn't
expect a restore of a big VPS hosting company to take up to 24 hours.

Regards,

Pieter