Peter Van Eynde <pvaneynd@...> writes:
> Christophe Rhodes wrote:
>> 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.
> Seeing the amount of pain I'm getting with the limited self-testing that
> sb-bsd-sockets involves I'm not certain that I want to have more testing
> being done. As a test across platforms that buildds suck: inconsistent
> build environment, bad error reporting, no manual intervention, etc. So the
> only thing that you are testing is if the system has enough marbles, yes?
Heh. In general, if the system builds to completion, it's usually OK
-- the self-tests and the ansi-tests are good stress-tests, picking up
our poor cache coherency issues more reliably, bugs in the gc, but
yes; the tests are developer-focussed, to make sure that a change
hasn't broken something which used to work.
>> 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?
> Well. As there is no stable sbcl for mips at the moment. So I was thinking
> of using an alternative build strategy that would solve most problems:
> 1 build a sbcl with clisp (version 2.33)
> 2 build a new sbcl with the generated sbcl
> 3 use this second generation sbcl as "final" version.
> This would eliminate the build-depends on sbcl, make possible the new
> version for mips and provide a minimal build-time test (step 2).
> How does that sound? Should I do a third step building another sbcl with
> the second generation sbcl, or is the second generation version equivalent
> with the N'the generation one?
They should be exactly equivalent to each other. If you can make this
work, then that's good; on the other hand, I believe that clisp-2.33.2
(and indeed the current version) has stack handling bugs in its pretty
printer, which can easily cause a broken build. (No-one ever said
this would be easy :-)
As for getting a mips binary, if the system needs to be
bootstrapped... as a Debian Developer you presumably have access to a
system? At that, Thiemo can probably provide one, too? I also have
an account on some mips/linux machines; if I can remember how to log
in, I'd quite like to test what we've got.