On Tue, Apr 26, 2011 at 11:29:00PM +0200, Matthias Klose wrote:
> On 04/26/2011 08:36 PM, Aurelien Jarno wrote:
> >On Tue, Apr 26, 2011 at 04:41:23PM +0200, Matthias Klose wrote:
> >>On 04/26/2011 09:39 AM, Neil McGovern wrote:
> >>>I woudn't be particularly happy with that unless the gcc maintainers ok
> >>>it, and I'm still not sure that two days is also an acceptable
> >>>timescale.
> >>
> >>then please drop mips and mipsel as release architectures. At least
> >
> >What is your problem about MIPS? Why do you insist about dropping it? At
> >least be fair and don't spread FUD.
> >
> >GCC on mips/mipsel build in less than 2 days on the recent build
> >machines. It's true that the build time is slightly higher than other
> >architectures, but the testsuite is done on 3 different ABIs. This is
> >something that can be tweaked, as suggested for SH4.
> >
> >Here are the average build time for gcc-4.* since the release of
> >Squeeze [1]:
> >
> > | mips | mipsel |
> >+++
> >gcc-4.3 | 42864 | 141863 |
> >gcc-4.4 | 104400 | 149148 |
> >gcc-4.5 | 123498 | 114435 |
> >gcc-4.6 | 95725 | 167799 |
>
> gcc-4.6: 167799/3600 = 46.61, and this is with the libstdc++
> testsuite already disabled, because it did timeout or fail on the
> mipsel buildds. So this is *no* FUD. Did you look at the build
So you want to drop both mips and mipsel because mipsel is slow? Great.
> failures, or some other mips porter, before I did disable the tests?
Oh you disabled the libstdc++ testsuite? What about asking/warning the
porters next time?
> >The build time dispersion is explained by the fact we have buildds of
> >different speed, gcc-* is built by default on them (no_weak_autobuild),
> >unless this build daemon is already busy.
> >
> >
> >>sh4 has a workable, accessible developer machine,
> >
> >mips also has an accessible developer machine, gabrielli.debian.org.
> >It's true that mipsel doesn't have one (it's being working on), that
> >said, most issues are reproducible on both. People can also ask on
> >debian-mips for help in case it's a mipsel specific issue.
> >
> >
> >>and people within
> >>Debian who care about the architecture.
> >
> >MIPS also has Debian people who care about the architecture. See for
> >example my recent MIPS work:
> >
> >http://svn.debian.org/wsvn/kernel/?op=comp&compare%5B%5D=%2Fdists%2Fsid%2Flinux-2.6%2Fdebian@17159&compare%5B%5D=%2Fdists%2Fsid%2Flinux-2.6%2Fdebian@17161
> >http://svn.debian.org/wsvn/gcccvs/?op=comp&compare%5B%5D=%2Fbranches%2Fsid%2Fgcc-4.6%2Fdebian@5248&compare%5B%5D=%2Fbranches%2Fsid%2Fgcc-4.6%2Fdebian@5262
> >http://svn.debian.org/wsvn/gcccvs/?op=comp&compare%5B%5D=%2Fbranches%2Fsid%2Fgcc-4.5%2Fdebian@5263&compare%5B%5D=%2Fbranches%2Fsid%2Fgcc-4.5%2Fdebian@5267
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623014
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623015
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623162
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623598
> >http://lists.debian.org/debian-mips/2011/04/msg3.html
> >http://lists.debian.org/debian-mips/2011/04/msg00018.html
> >http://sourceware.org/bugzilla/show_bug.cgi?id=12606
>
> yes, the last one incomplete and only completed by myself. So who
So basically reporting an identical bug in bugzilla without checking
if a bug already exists is completing?
> else is doing toolchain work on mips in Debian? Thiemo did leave a
> big gap, and it was an effort of many people to release squeeze with
> mips. I just see that
I usually report bug upstream when needed (sometimes even providing
patches), and follow the upstream development to enable new features
(e.g.: SSP support, -mplt, defaulting to MIPS II ABI). I agree I
sometimes lack of time, but I don't see much more work than that on
other architectures.
> >All that said, I agree that mips and mipsel architectures are not in
> >their best shape, but people are working on that. If you consider they
> >don't follow the release criteria, please give objective arguments.
>
> the build time argument was brought up by the debian-release team,
> so this this seems to be an objective argument. If not, maybe the
> release criteria for new, current and "obsolet" ports should be made
> more transparent. I'm only aware of one table not differentiating
> new and current ports.
The SH4 people announced that they don't have any faster hardware and
that GCC needs 2 days with all the tests disabled.
It's clearly not comparable with mipsel which needs, with some of the
tests being run, slightly more than 2 days when built on the slowest
buildd, and about 1 day 6h on the fastest one, and for which
we are waiting for faster hardware.
> yes, other issues are the non-availabilty of a mipsel porter box and
> the instability of the existing mips porter box.
>
> and toolchain maintenance was rather difficult (longsoon, binutils)
> during the squeeze cycle.
The binutils issue was a real toolchain issue. As for the longsoo
