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.
signature.asc
Description: OpenPGP digital signature