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