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 <http://wiki.debian.org/DebianM68kGcc>. My thoughts on the current failed packages (that are m68k-specific) are loosely sorted out at <http://people.debian.org/~smarenka/m68kbugs/reports/failed-bynotes.html>. 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! <stephen@marenka.net>
Attachment:
signature.asc
Description: Digital signature