Hi, Thanks for pointing out that my analysis wasn't good - the arm patch doesn't change anything for ppc64el (which make sense whatsoever) - the problem on ppc64el is similar to the one on arm except the test value are opposite ! ( which was confusing). So what do we need to do ? expect that someone with a better expertise help going though it ? ( can you confirm we stay with that bug for both arch or do we need to open one for ppc64el ?) Thanks
On 02/02/2019 07:15, Andreas Tille wrote: > Hi, > > I think these are just rounding errors due to different representation of > floating point numbers. Relaxing the precision of the test would solve > the problem (but I have no idea about the test suite and so do not know > how to implement this). > > What I do also not understand why a fix that only occures on arm64 now > has an influence on ppc64el. Did ppc64el compiled fine for version > 0.5.0+dfsg-1 (without that fix)? > > Kind regards > > Andreas. > > On Fri, Feb 01, 2019 at 04:41:04PM +0100, Thierry fa...@linux.ibm.com wrote: >> Unfortunately the workaround mentioned for arm64 breaks ppc64el arch as >> compiling on buster fails with following error - what do we do ? >> Thanks >> >> ------------------------------------------------------------------------ >> BT check (recess model): prob vs. prob_fv OK >> 2c2 >> < rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 >> 544.518 437.583 -567.388 435.04 1.75239 >> --- >>> rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 >> 544.518 437.583 -567.387 435.04 1.75239 >> BT check (2df model): prob vs. prob_fv >> FAILED >> FAIL test_bt.sh (exit status: 1) >> ------------------------------------------------------------------------- >> >> >> >> On Sun, 13 Jan 2019 16:37:02 +0200 Adrian Bunk <b...@debian.org> wrote: >>> Source: probabel >>> Version: 0.5.0+dfsg-1 >>> Severity: serious >>> Tags: ftbfs >>> >>> https://buildd.debian.org/status/fetch.php?pkg=probabel&arch=arm64&ver=0.5.0%2Bdfsg-1&stamp=1538603399&raw=0 >>> >>> ... >>> FAIL: test_bt >>> ============= >>> >>> Analysing BT... >>> BT check: dose vs. dose_fv OK >>> BT check (add model): prob vs. prob_fv OK >>> BT check (domin model): prob vs. prob_fv OK >>> BT check (over_domin model): prob vs. prob_fv OK >>> BT check (recess model): prob vs. prob_fv OK >>> 2c2 >>> < rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 >>> 437.583 -567.387 435.04 1.75239 >>> --- >>>> rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 >>>> 437.583 -567.388 435.04 1.75239 >>> BT check (2df model): prob vs. prob_fv >>> FAILED >>> FAIL test_bt.sh (exit status: 1) >>> >>> ============================================================================ >>> Testsuite summary for ProbABEL 0.5.0 >>> ============================================================================ >>> # TOTAL: 11 >>> # PASS: 10 >>> # SKIP: 0 >>> # XFAIL: 0 >>> # FAIL: 1 >>> # XPASS: 0 >>> # ERROR: 0 >>> ============================================================================ >>> See checks/test-suite.log >>> Please report to genabel-de...@r-forge.wu-wien.ac.at >>> ============================================================================ >>> make[4]: *** [Makefile:713: test-suite.log] Error 1 >>> >>> >>> I suspect this might be a problem with the NEON code in Eigen 3, >>> and the fact that this can be fixed with the following workaround >>> makes that even more probable: >>> >>> --- debian/rules.old 2019-01-09 15:07:11.950823327 +0000 >>> +++ debian/rules 2019-01-09 15:17:23.280539016 +0000 >>> @@ -6,6 +6,10 @@ >>> >>> export DEB_BUILD_MAINT_OPTIONS=hardening=+all >>> >>> +ifeq ($(DEB_HOST_ARCH),arm64) >>> + export DEB_CXXFLAGS_MAINT_APPEND = -march=armv8-a+nosimd >>> +endif >>> + >>> include /usr/share/dpkg/default.mk >>> >>> # Location of the example files, will be converted to the >>> >>> >> _______________________________________________ >> Debian-med-packaging mailing list >> debian-med-packag...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Thierry Fauck @ fr.ibm.com
