OK, I've created a separate linux-kernel-headers package, and I've modified glibc (nptl branch) to build using it. I've checked linux-kernel-headers into CVS; it's in the same CVS repository as glibc-package but the module is named linux-kernel-headers: cvs -d :ext:<user>@cvs.debian.org:/cvs/glibc co linux-kernel-headers
You'll need an .orig.tar.gz also; it's in ~dan/public_html/ on ftp-master. Unpack it into the same directory, it's just the contents of include/ from a recent -bk kernel. Um, ftp-master is down right now but I'm sure it will be back. I just checked in glibc support to use it. Unfortunately - this is regrettable - it makes glibc a bit harder to build for this first time. You need linux-kernel-headers installed. It conflicts with old versions of libc6-dev. Glibc will build without libc6-dev installed but you'll need an appropriate chroot. If anyone has a better suggestion I'd love to hear it, but I really believe we need to get this moved out to a separate package. It makes tracking patches against the kernel headers a whole lot easier, and we've already got one (MIPS msq). Plus eventually it will be the home for abi-headers; and it simplifies things for non-Linux ports (what we had now would not build on hurd-i386, or would include linux headers anyway). Making a chroot to build from on your own machine is easy. Building it on Debian machines will be a little trickier. For now, if you unpack linux-kernel-headers into a directory and use dpkg-buildpackage -d to ignore the build dep and set LINUX_SOURCE to point at linux-kernel-headers at it, then everything should work. So we can build test packages without getting linux-kernel-headers installed and then let the buildds sort out the bloodshed later for the official build; James and I both think that this will work without upsetting the daemons too much. If you build in a chroot without libc6-dev four extra tests will fail. annexc, isomac, check-textrel, check-c++-types.sh. Don't worry about it, this will go away once removing libc6-dev is no longer necessary (i.e. any time after linux-kernel-headers and a new libc-dev are in unstable). I now have no serious blocking issues for x86. There are failing NPTL tests. I am considering testing a newer glibc/nptl CVS snapshot to see if that fixes them. PowerPC and x86 build. ia64 still should also. I don't remember status on Alpha but I think it was OK. ARM has some issues and Phil is on it - at least two patches are needed. That leaves mips/mipsel (I believe more CPU time should be available next week for testing), m68k (<shrug> kernel headers may be a problem here), sparc (linux-kernel-headers needs some <asm/*> wrapper magic; Jeff Bailey is doing this now); hppa (Carlos is on it); and s390 (I have no reason to think it's broken but we'll have to find out; s390x requires a little voodoo). I think we're almost as ready as we're going to get. What do folks think? Are we almost ready? How much do you want done before we put this into unstable - should we ask debian-ports and debian-devel for arch builds and testing first? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
