Thiemo Seufer <ths@...> writes:
> Christophe Rhodes wrote:
>> > Ignore tests which currently fail on mips. foreign.test.sh is the
>> > odd one out, mips falls in the debugger, I haven't had a closer look
>> > yet.
>> ... tests which fail. I don't like this, because the tests lose their
>> documenting and nagging nature in this case. On the other hand, if
>> this is what is required for Peter's debian package, that's fine, and
>> he can track mainline but with tests deactivated.
> Since the tests stop at the first bad one, the alternative would be
> to disable them completely for mips/mipsel. That's clearly worse than
> disabling only some of them.
Sorry, I wasn't clear. What I'm suggesting is that Peter, for Debian
packaging, maintains as part of the Debian .diff.gz a patch which
disables failing tests on platforms for which a .deb is built: at
least for those tests which really ought not to fail, such as the
foreign test. The distinction I want to draw is between automatically
running the tests, in which case known failures should not be run, and
manually running the tests, in which case the nag value of having to
delete files and rerun tests is partially worthwhile. (Though not, I
admit, as worthwhile as having a test suite which has known failure
information, and collates results at the end.)
>> Is the status now that, apart from these failing tests, the mips/linux
>> (and mipsel/linux) builds are expected to work?
> I have done some tests on a slower machine, but no full rebuild there.
> I don't see any breakage on a BCM91250A except for exhausted heap space
> with the ansi tests.
> I haven't tested mipsel yet, simply because the fastest machine I have
> ATM is an old DECstation. :-)
OK, so I guess the next thing to do is to ask Peter to re-enable the
mips and mipsel platforms in his packaging, and we'll see if the
buildds complain... Peter?