On Tue, Nov 04, 2003 at 06:30:47AM +0800, csj said > At Mon, 03 Nov 2003 22:12:07 +0100, > wsa wrote: > > > > Thanks for explaining this in the other thread aswell. What i > > wanted to ask, could this package be the cause of custom 2.4.22 > > kernels not going past INIT (today's update fixed this problem) > > which i and a few other people experienced over the last > > weekend? > > I have recompiled (and run) my custom 2.4.X kernel against the > new libc6 without any problems. Just to clarify: your kernel makes NO USE AT ALL of your libc headers. The kernel is utterly unaware of libc and makes no use of it, ever. > > The original poster mentioned both mplayer and xawtv breakage, both i > > use because the server(mplayer self compiled)acts as a vcr aswell. Does > > this mean i should not recompile either one and leave them as is? > > Xine also fails to compile (ditto nvrec, a low overhead recording > program). My conclusion: all video applications are affected. Eh? The only things that could possibly be affected are those using kernel headers because they need to access some to special kernel service, like the framebuffer. If you build mplayer/whatever without framebuffer support, it will not use the kernel headers at all. > > And last question, if this new splitting stuff causes breakage > > who will solve this? is this a debian issue, a linux issue or > > should the sources of for example mplayer be changed? > > Actually I can see the benefits of splitting. For me the problem > was that the glibc team decided to use the broken (tm) 2.6 > kernel. As Colin said, this was neccessary for NPTL support. They should be completely backwards compatible. > Fixing the problem should be as easy as rebuilding the > linux-kernel-headers source by sticking in your own kernel-headers > (from your custom make-kpkg kernel) into ./include and perhaps > deleting the ./debian/patches directory. Do you know what will happen if you start mixing things with NPTL support compiled in with these programs? I don't. > My proposed reportbug fix is to have linux-kernel-headers as a > virtual "provides" package. Then we could have separate 2.2, 2.4 > and 2.6 headers packages, the same way we already have separate > kernel packages for 2.2, 2.4 and the broken 2.6 kernel. These are for userspace, not kernel modules. The 2.5 kernel headers should work fine with any kernel at all. If there is a bug in them, it should be fixed, not replaced. > > Every time i start to think 'i'm getting the hang of linux' > > things like this happen...lib stuff...compile stuff...at times > > i think i need spiked mountain shoes to climb the learning > > curve ;) Welcome to Sid :-) -- Rob Weir <rweir@ertius.org> | mlspam@ertius.org | Do I look like I want a CC? Words of the day: BLU-114/B Oil deals Europol South Africa e-bomb UOP basement
Attachment:
signature.asc
Description: Digital signature