[Debian-med-packaging] Bug#830984: fixed in ball 1.4.3~beta1-2 -- only on amd64

[Danny Edel]

Control: reopen -1

On Sun, 13 Nov 2016 09:18:53 +0000 Danny Edel <debian at danny-edel.de> wrote:
> We believe that the bug you reported is fixed in the latest version of
> ball, which is due to be installed in the Debian FTP archive.

Hello Andreas, hello Steffen,

it seems like the fixes were indeed only effective on amd64, so I am
reopening the FTBFS/test-suite bug.  Also, I removed the other bugs from
CC, so you don't get each mail 4 times : )

From what I can tell, the testsuite failures fall into two categories:

1.  Most likely completely harmless, -- 0.000001 difference in a
floating-point calculation.  The PoseClustering_test seems to be
involved in this on a few arches, where it compares a string rendering
(letter-by-letter) instead of using a fuzzy-compare of the values.

  * arm64
  * ppc64el

2.  Something is really broken and needs debugging on the appropriate
hardware.  Segfaults, integer mismatches (8 != 0), really weird output,
etc...

  * i386
  * s390x
  * kfreebsd-amd64
  * kfreebsd-i386
  * powerpc
  * x32

[at the time of writing, not all arches had finished/failed]

In the case of kfreebsd, the source will likely need patches for the
different kernel, since Sysinfo_test fails with statements like:

TEST_EQUAL(getTotalMemory() > 0, true): got 0, expected 1)

I fear that the tests are likely to keep failing on non-amd64
architectures until someone with access to a corresponding box puts in
the effort to investigate, and adjust the tests for the subtle differences.

Until then, I propose to run, but ignore the return code, of the
testsuite on "anything other than linux-amd64" for now, to have a chance
of re-entry into stretch.

Rationale behind running anyway:  We can load the logfile and grep for
'*Failed' to keep track of the problematic tests.  This string also
works great with the web interface and the ctrl+f feature of most browsers.

Rationale behind ignoring right now:  I assume that the vast majority of
users run amd64 (popcon backs me on this), and those would benefit from
seeing the package in stretch.  Even on the now-FTBFS arches, the
(comprehensive) testsuite suggests that 99% of the library is working as
intended, which should qualify the problem as important, but not
release-critical in my opinion.

If (!) there is a userbase of BALL on Debian-but-non-amd64/non-linux,
there is also the hope one of them will step up and provide assistance
in tracking this down or confirming the actual impact, which is a lot
easier if the package is available as a binary.

What is your opinion?

	Danny

-- 

PS:  I submitted a basic travis-ci configuration to upstream for review.
 If it gets accepted, I can work from there to approach the
'will-it-build-on-jessie/stretch/sid/xenial' question.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20161113/e8d8a9b8/attachment.sig>