Re: IRC Release Team Meeting on Mon, Aug 23rd, 20 UTC

[Josip Rodin <joy@entuzijast.net>]

On Wed, Aug 18, 2010 at 12:29:27AM +0200, Philipp Kern wrote:
> Well, for upstream support there is: at the bottom of the page.  According
> to doko sparc32 code generation is unmaintained upstream, and he doesn't
> want to step up to maintain it any longer.

Well, that is no less of a problem than it was before, no? I don't recall
seeing many sparc32 compiler bugs over the last few years. I do recall
some sparc kernel bugs, which were incidentally all eventually fixed.

> Furthermore I found the following thread dated back to 2007:
> http://lists.debian.org/debian-sparc/2007/07/msg00049.html

I think the only result from this was that a sparc32 kernel and installer
was dropped, as Jurij said there. That was during a time when that kernel
was particularly problematic, which has actually improved a lot upstream and
they had no problem keeping it - though it probably still lags a bit behind
because there's maybe one person regularly testing, the rest are on-and-off,
but it remains in the tree and is covered by all the generic changes and
testing.

Few people have been affected by this, because the remaining non-64-bit
machines (which can't run the 64-bit kernel) are both fairly scarce and
very slow by today's standards. OTOH, if we missed the squeeze release
altogether, all users of the port would be affected. Still not a whole lot
of people, but at the same time, it's a huge chunk of the users of Linux on
SPARC in general.

We shouldn't do this for reasons that are based on what boils down to
a rational fear of bit rot. It it certain that the problem can cause
bugs over the years. But at this rate, a dozen bugs is pretty much a drop
in the sea.

> So far nobody stepped up to provide us with a working sparc64 port.
> I know that aurel32 did some work on zee.debian.org, but was hurt by
> bad RAM in that box (AFAIR).

That sounds like a reason why a sparc64-only port would be unreleasable,
which bodes well for the actually working mixed port :)

> What we are currently struggling with are build failures that happen on
> one class of the builders, while not happening on the other, and IIRC
> this is happening vice-versa.  Hopefully others can fill in the gaps I
> left here.

Are these failures connected to the compiler issue, or is it just a manpower
issue in tracking it down?

-- 
     2. That which causes joy or happiness.