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 <deb...@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
