On Sat, May 20, 2006 at 05:34:08AM +0000, Aurelien Jarno wrote: > It has been a long time since the sparc status on the architecture > requalification page [1] has been updated. A few things seems to have > changed: > - There is now 3 sparc buildds (mrpurply, spontini and auric), so I > think the "buildd redundancy" box could be set to green. Yes, this appears to be correct; I checked with Ryan about this at DebConf, and we do seem to have full redundancy now for sparc buildds. > - The kernel failures (that occurs only on SMP boxes) seems to be gone, > at least on the build daemons. I don't know what has been done (if > somebody know, please tell us), but the two packages that were killing > the buildds (ie glibc and openoffice.org) are now building correctly (4 > last uploads for the glibc, last upload for openoffice.org). What's been done is to install a kernel which is newer than any that are actually available in sid or etch. The fact that this seems to fix the problem is a positive step in the right direction, but it's not sufficient for the release qual as it leaves us with very low confidence in the usability of the port when we can't use the Debian kernels for etch on any of the relevant project machines.[1] So the ideal solution is that, now that we have a known-working version, someone determines whether 2.6.16 includes the same fixes and if not, gets them backported to 2.6.16 for etch. There is also the question of having appropriate kernel images on the buildds for the remainder of sarge's term as "stable", but I don't see any way that this should be a blocker for sparc's inclusion as an etch release arch if the *current* buildd kernel problems don't make sparc unreleasable package-wise. > If the kernel failures still appear to be present, would it be possible > to qualify the port for non-SMP only? AIUI most of the sparc hardware people want to *use* Debian on is SMP kit, so I think it would be a shame to call a UP port releasable but would certainly take the opinions of the sparc porters into consideration. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/ [1] independent of whether DSA actually uses stock Debian kernels on most Debian systems, which TTBOMK is actually not the case
Attachment:
signature.asc
Description: Digital signature