[Debian-med-packaging] Bug#969804: Bug#969804: bart: autopkgtest should be marked superficial

[Uecker, Martin]

Am Montag, den 21.09.2020, 17:57 +0200 schrieb Andreas Tille:
> On Mon, Sep 21, 2020 at 05:30:20PM +0200, Andreas Tille wrote:
> > 
> > May be I misunderstood you - but if you do not run the test at all
> > (as done in some architectures) how will you know whether the test
> > might fail?  May be I miss your point here and thus I implemented
> > my suggestion and we'll see what happends on the buildd logs soon.

Thank you! No, I meant running the tests but ignoring the results,
so exactly what you implemented!

> For instance
> 
>    https://buildd.debian.org/status/fetch.php?pkg=bart&arch=i386&ver=0.6.00-3&stamp=1600702554&raw
> =0
> 
> has
> 
> ...
> ./test_linop_matrix 
>  ./test_linop_matrix:  4/ 4 passed.
> ./test_linop 
>  [31mERROR:         ./test_linop:  2/ 3 passed.
>  [0mmake[3]: *** [Makefile:685: utests-all] Error 1
> make[3]: Leaving directory '/<<PKGBUILDDIR>>'
> make[2]: *** [Makefile:273: utest] Error 2
> 
> 
> --> I guess access to i386 should be simple.  You can either use
>     qemu or may be the issue can be even reproduced in an i386
>     pbuilder chroot

Yes, I think this is a problem I looked at before. Essentially
the floating point computation has a bigger error for some
reason. But I did not have to time to get on the bottom of it.

What would be really useful is to get bug reports for
failing tests which are not critical.

> 
> The s390x build
> 
>     https://buildd.debian.org/status/fetch.php?pkg=bart&arch=s390x&ver=0.6.00-3&stamp=1600702311&r
> aw=0
> 
> has the know issue.
> 
> So at least the logs do not hide the issues that might be worth
> investigating or not.

Yes, this is useful. I will try to change the tests so that a
failing test outputs more information.

Best,
Martin