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

Reply via email to