Re: Bug#344615: missinglib: ftbfs [sparc] *** [test] Bus error
On Tue, 2006-01-03 at 11:58 -0500, Mike Furr wrote:
> Julien Cristau wrote:
> > %i1 contains 0xa3f74, which is indeed not double-word aligned.
> > The ocaml float allocation function doesn't take care of alignment, so
> > we've reported this problem upstream.
> Hmm... The new version of omake which I just uploaded failed to build
> for exactly the same reason it seems. I wonder how many packages this
> has affected for sparc. It looks like it will only surface when the
> resulting code is run and I know a lot of packages don't have test
> suites. :-(
I am curious to know Debian policy on testing.
Felix does include a test suite -- but it takes quite some
time to run. This will get worse as number of tests goes up,
and number of combinations of options to test goes up.
Furthermore, some new features require testing that begins to
look nasty -- for example testing sockets requires opening
sockets (we're using localhost .. but it isn't clear if even
that is really permitted), and creation of pthreads
(which in event of a bug could run away on some platforms ..
and there is no point in tests that will never catch bugs,
so one has to assume all tests can and will fail).
Worse may be coming, for example testing killing of
an application may require launching another process
with sufficient authority which sends it a kill signal
(and could kill autobuilder by mistake .. :) Yet the
build scripts themselves are fairly arbitrary so there
is already a risk of this.
One technique might be a separate test package which
build-requires the binary package being tested.
However if the suite fails, the binary -- not the test
suite -- should be flagged as bugged: it isn't clear
the Debian autobuilder etc would handle all that properly.
[Perhaps some new coding, such as:
OnError: Packname
which says to bug out Packname if this package
fails to build .. rather than this package]
Even trickier .. bootstrapped systems, which build
depend on themselves .. :)
Any advice on how far to go in original package would
be of interest, and how to cope with 'extra testing'
since the need for that will certainly arise: there
have to be *some* limits on testing in original package,
but there should also be a way to automate testing
and bugging out of packages.
Yes I know there are ways to do this manually.. but I hate to
burden DD with a complex set of test instructions that have
to be followed manually -- rather burden him with verifying
scripts that automate this process are doing the right thing .. :)
Perhaps this whole issue transcends Ocaml .. but at least
considered responses may occur here. An Ocaml policy on
this might leak into the rest of Debian, as well as
any tools created to aid the process.
If I were a DD I'd not be supporting packages WITHOUT
tests -- even if the tests are inadequate they can be
added to. Without a harness built-in this is much
harder. Building the harness without a Policy is
also difficult.
Example: ocaml Policy could require some testing,
then Bug raised in BTS on all packages without it,
this is then fixed with at least a stub suitable
for extension. However some packages can't be
tested without risk and manual intervention, eg
a GUI is hard as is any real time code or for example
mod-caml plugin.. I just don't know.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
Reply to: