On Tue, Oct 04, 2005 at 11:58:11PM -0700, Russ Allbery wrote: > Steve Langasek <vorlon@debian.org> writes: > > Things are far enough along that I've gone ahead and added a preliminary > > hint for lam/mpich, visible at > > <http://ftp-master.debian.org/testing/hints/vorlon>. This will let us > > get feedback via > > http://ftp-master.debian.org/testing/update_output.txt.gz in subsequent > > britney runs, so we can see at a glance what issues are still > > outstanding, and also catch any problems that weren't visible to the > > naked eye. > I'm not really sure how to read the britney output. I think that this is > the relevant failure: > now: 157+0: a-13:a-14:h-13:i-18:i-14:m-17:m-16:m-13:p-14:s-15:s-10 > * alpha: blacs-mpich-dev, blacs-mpich-test, blacs1-mpich, libhdf5-mpich-1.6.2-0, libhdf5-mpich-dev, mpb-mpi, netpipe-mpich, scalapack-mpich-dev, scalapack-mpich-test, scalapack1-mpich > [...] > FAILED > but that would seem to imply that it's still exploding on all the > blacs-mpi stuff, which is part of the hint? Or maybe it wasn't part of > the hint at the last britney run and you just added that? It's not all that useful of a hint yet, because lam waits on gcc-4.0; I had split the hint into two parts to be able to get a partial look at things. The hint will start to give us more useful information once gcc-4.0 is closer to being sorted out. > Anyway, the whole thing won't go without new versions of: > Source: netpipe > Source: xmpi > Source: clustalw-mpi (non-free) > at least, even with more hint refinement. Maybe we're getting towards > time for NMUs of those remaining packages? Yes, that would be a good idea. > rmpi is in dep-wait on arm waiting for libf2c2 (which is building), and in > dep-wait on hppa waiting for r-base. r-base failed on hppa with an odd > error: > running code in 'utils-Ex.R' ...make[1]: *** [check] Terminated > make[2]: *** [test-all-basics] Terminated > make[3]: *** [test-Examples] Terminated > semop(2): encountered an error: Invalid argument > make: *** [check-stamp] Terminated > make[4]: *** [test-Examples-Base] Error 1 > Build killed with signal 15 after 150 minutes of inactivity > Not really sure what to do with that problem; it smells a little like a > buildd issue rather than a problem with the package? If the package previously built without trouble on hppa, it tends to suggest the package has gotten itself into an infinite loop of some kind, or else that a new version is substantially slower than previous versions for some unknown reason. It will almost certainly require coordination between the maintainer and the buildd admin to figure out. Note that the last version of r-base which succeeded only took 45 minutes to build; going from a 45-minute built to 150 minutes of inactivity is usually a sign of a package bug. > scalapack failed on powerpc with: > /usr/bin/ld: /usr/lib/gcc/powerpc-linux-gnu/4.0.2/../../../../lib/libf2c.a(lread.o)(.got2+0xbc): unresolvable R_PPC_ADDR32 relocation against symbol `f__units' > /usr/bin/ld: final link failed: Nonrepresentable section on output > Does this ring a bell with anyone? That looks like a gcc issue, not a > problem with the package. It's also in dep-wait on arm waiting for > libf2c2. My first guess was that scalapack was trying to link a shared library against non-PIC code, but that doesn't seem to be the case. It may be a problem with gcc, but it may be a once-removed problem with an *old* version of gcc that requires rebuilding libf2c to fix it. Dunno, someone will need to poke at this (maybe debian-powerpc?). > octave-gpc needs a requeue (and I think that's all) on alpha and mips, as > it couldn't find libgpcl-dev and that package now appears to be available. > I'm not sure what's going on with it on ia64; it installs libgpcl-dev and > then can't find the header file from that package. Maybe (he says > hopefully) a rebuild will help there too? Should I mail the arch > addresses @buildd.debian.org about those two requeues? Actually, libgpcl-dev has been in the archive for alpha and mips, at the same version, since before sarge's release. I think the issue is simply that the autobuilders aren't configured to draw build-dependencies from non-free; I've just checked with Ryan Murray, and he confirms this is a policy decision, not a bug. So someone will have to hand-build octave-gpc on alpha and mips (and possibly the others). > semidef-oct is now fine, as is parmetis. I still show parmetis as out-of-date on mips. This seems to be a wanna-build bug, since the package is listed in state 'Installed' even though there is a newer source version available. The package is in non-free anyway, so it'll need the same treatment as octave-gpc regardless. > For the removal of plplot9-driver-gnome, should I submit a bug against > ftp.debian.org, or leave that for the package maintainer to do? The removal will be semi-automatic once plplot has built on m68k, but that won't happen until octave2.1 is also available on m68k. But octave2.1 build-depends on gfortran, which is not available on m68k -- and not because the package hasn't built, because the package source is gcc-defaults. That looks like someone should file a bug against octave2.1, asking it to build-depend again on fort77 on m68k as previous versions did. 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/
Attachment:
signature.asc
Description: Digital signature