Re: testing packages at build
On Thu, Oct 09, 2003 at 08:49:13PM +0800, Cameron Patrick wrote:
> On Thu, Oct 09, 2003 at 02:15:03PM +0200, Bill Allombert wrote:
>
> | My first goal is to persuade developers that running tests is
> | worthwhile. For the implentation I have mainly 3 questions:
> |
> | 1) Do porters and autobuilders admins want to be able to skip the tests ?
>
> Surely skipping the tests on autobuilders would be a bad idea? The
> tests may pass on one architecture but not on another (e.g. gnucash in
> sid), and being able to catch such problems sounds like a Good Thing.
I wrote 'want to be able to skip' not 'want to skip'. They may want
to be able to do it, while not willing to do it customarily.
For example with very slow and resource constraint autobuilder.
> | 3) Do we want to allow for autorecovery ? If gcc -O2 leads to a broken
> | binary, why not set up debian/rules to automatically retry with gcc
> | -O0 ?
>
> This sounds like something that is best done with human intervention,
> not by an automated process which could potentially break things further
> when it screws around with compiler options.
The first step of human intervention is to try out with -O0.
So at least it would be already done. The maintainer is welcome
to read the buildlog to see what has happened.
> Are gcc optimiser bugs really that common?
Yes they are. Not on i386 of course with current gcc-3.3, but other
architectures (ia64,arm,m68k,hppa) with the first releases of gcc-3.2.
Also as a rule, g++ make more optimisation mistake that gcc.
For example sp was broken on m68k for some time this year. The package
compiled fine but sp just silently fail and produced no output.
This break builds of packages using debiandoc-sgml. A simple test
whether sp was able to process a simple example file would have
reduced the problem. Automatically rebuilding with -O0 would make it
nearmy inexistent.
Investigating cause of optimisation error can be quite long. Having a
-O0 package today make the migration to testing faster without forbiding
anyone to upload a fixed package wrt this optimisation error when
possible or report a bug against the compiler.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: