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

Re: sh4 architecture into Wheezy

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 failures, or some other mips porter, before I did disable the tests? 


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 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 


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.
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. 

  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.
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.
Reply to: