Goto, I thought the plan was to simply push glibc 2.3.1 into sid, no? I have been running the glibc 2.3 debian cvs source patches and glibc cvs (built almost daily) on debian ppc sid for about a month now. I have seen no issues running gcc 2.95.4/glibc 2.2.5 built binaries under it. I would vote to simply do the push into sid and fix the breakage. Other than problems with glibc not passing make check on some arches (which can be captured by just letting those offending builds go into sid), the only real issue left should be a bit of libgcc-compat code on arches like mips. I have already posted the outline of a patch for them to fix that...
http://lists.debian.org/debian-glibc/2002/debian-glibc-200210/msg00154.html In short, I doubt we will get sufficient testing on problematic arches unless we take the leap and push into sid. However I would make sure that the findsyms perl script I wrote has been run on the debian sid package archives for any arches which we have to create a libgcc-compat for to make sure our list of libgcc symbols is complete. I'm not sure that is the case for mips yet for example. http://lists.debian.org/debian-glibc/2002/debian-glibc-200209/msg00164.html Jack
