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

[Andreas Tille]

Hi Danny,

I fully agree that we should ignore test results on other than amd64
architecture.  Please let me know if you intend to implement the needed
change or whether you suggest that I should do so.

Kind regards

      Andreas.

On Sun, Nov 13, 2016 at 04:56:50PM +0100, Danny Edel wrote:
> 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.
> 




-- 
http://fam-tille.de