[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [buildd] Etch?

On Fri, Aug 04, 2006 at 01:43:46AM +1000, Finn Thain wrote:
> On Thu, 3 Aug 2006, Wouter Verhelst wrote:
> > Hi all,
> > 
> > I don't know what everyone else thinks about it here, but it would 
> > appear to me that making it in time for Etch is not going to happen 
> > anymore now.
> > * Too many compiler bugs
> Do you have the toolchain bug IDs at hand?

The issues I know about and have been chasing when I have time are at 

My thoughts on the current failed packages (that are m68k-specific) are
loosely sorted out at

The -O2 bug which I started playing with in 378599 in particular is annoying 
me because I haven't had time to get back to it. libgc is a good candidate 
example, something about the selftest program itself gets miscompiled.
It looks like the library compiles fine -O2, but the self-test program
needs to be compiled -O0.

Hopefully the same bug seems to be causing the binutils problems documented
in 378355. I doing a binNMU of binutils with -O0, which will hopefully
get kdelibs back on track.

A different bug gets emacs21, subversion, and guile-1.6 -- no idea yet
what it is, but -O0 doesn't seem to solve it.

Something is causing gnustep problems too. I suspect gnustep-base needs
to be recompiled (binNMU), but compiling has crashed the three different 
amigas I've tried it on.

So something like 24 of 86 failed packages have solutions, just waiting
on something or other (gcc-4.1 bugs, binutils, retry). The rest need
diagnosed and fixes.

> > * As a result, too many uncompiled packages since *ages*. We haven't 
> >   been over the 95% mark of the buildd.debian.org "graph" (as opposed to 
> >   "graph2") since almost a year, if I'm not mistaken, which is just 
> >   terribly bad.
> I may be able help with some compute cycles, as I've just obtained a 
> Quadra 840AV.

I don't think compute cycles is the problem. We need people to track
down and fix the bugs. gcc upstream seems to be willing to help diagnose 
m68k bugs, but there's *no* priority to fix them.

> Assuming a working tool chain, I'd play off the backlog delay against 
> usual release delays caused by other architectures and other issues.

> > * Even if we *would* be able to fix our toolchain in time (I would find 
> >   that highly unlikely, but still), then it would take us at least some 
> >   weeks, if not months, to compile away our backlog. There are some 
> >   large packages in failed and dep-wait currently.

If the toolchain worked, I think we could catch up. We've run dry
several times recently. We spend a fair amount of time compiling
packages we know are going to fail.

> > I'm a bit pessimistic about the future of our port currently. What are 
> > everyone else's thoughts on this?
> > 
> > Should we just accept that we're not going to make it, or am I being too 
> > quick to forget about it here?

If I thought more people would jump in and start helping, I'd be a bit
more optimistic. 

> Assuming a broken tool chain, yes, the port is defunct.

Broken since gcc-4.0 rolled in and caught us napping. gcc-4.1 is way better, 
but still has problems.

Right now, I'm kinda bummin'. On the plus side, I've sure learned alot
and enjoyed the experience.

Stephen R. Marenka     If life's not fun, you're not doing it right!

Attachment: signature.asc
Description: Digital signature

Reply to: