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

Re: sh4 architecture into Wheezy

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/msg00003.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 longsoon part,
it is a silicon issue, not a toolchain one. It was workarounded by one
patch in binutils and one patch in gcc. How can you consider that part
difficult toolchain maintenance?

>   Matthias
> Please note that this thread did start about sh4, and some comments
> about the sh4 toolchain by some members of the release team, which
> apply for mips* too, and which are used against the sh4 port.

Yes, and as always when you can hijack a thread or an IRC discussion to
complain about mips, you don't hesitate.

> I appreciate your work on mips, but I think a lot more needs to be
> done to keep it as a release architecture, and that arguments that
> are overlooked by intent for existing release architectures should
> not be used against a new port.

The release team has clear release criteria, but allow a few of them
to not be fully satisfied, otherwise no other architecture than amd64
and i386 would stay in the archive. In any case criteria have to be 
compared objectively.

Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: Digital signature

Reply to: