On 22/02/10 at 17:30 +0100, Marc Brockschmidt wrote: > Jurij Smakov <ju...@wooyd.org> writes: > > On spontini: > > > > Linux spontini 2.6.26-2-sparc64-smp #1 SMP Thu Feb 11 03:39:06 UTC 2010 > > sparc64 GNU/Linux > > > > cat /proc/cpuinfo > > cpu : TI UltraSparc II (BlackBird) > > fpu : UltraSparc II integrated FPU > > prom : OBP 3.11.26 1998/04/15 14:52 > > type : sun4u > > ncpus probed : 2 > > ncpus active : 2 > > D$ parity tl1 : 0 > > I$ parity tl1 : 0 > > Cpu0ClkTck : 000000001574ff27 > > Cpu2ClkTck : 000000001574ff27 > > MMU Type : Spitfire > > State: > > CPU0: online > > CPU2: online > > > > Any chance of upgrading one of the buildds to 2.6.32 to see if it > > helps? > > DSA told me that they do not want to run any non-standard (aka, > non-Debian stable) kernel on these machines, not even for short > tests. I'm not sure that's the best way to handle this, but I can't > change it.
I gave a try on smetana, but could not reproduce the same failure. I don't see any way forward, since the failure is only reproducible on the buildds. Also, analyzing that failure might require quite a lot of sparc expertise, which I don't have. I think that the two remaining options are: (1) remove the ruby1.9.1 binaries for sparc, and have ruby1.9.1 added to P-a-s on sparc. (2) accept that ruby1.9.1 can only be built on porter boxes, not on the buildds. Ruby is clearly in a bad state on SPARC, and upstream doesn't want to support it (http://redmine.ruby-lang.org/issues/show/1172), so (1) is probably the more reasonable option. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org