Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Peter Van Eynde <pvaneynd@de...> - 2005-05-02 06:43:21
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?
> 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?