Bug#844403: src:nfft: FTBFS on ppc64el
Hi Ghis, On 12/14/2016 09:30 AM, Ghislain Vaillant wrote: > Thanks for your contribution. Let me know if a long-term solution comes up > later. Sure. I closed the bug on the changelog, but, you can keep it open to track the final and long term solution.
Bug#844403: src:nfft: FTBFS on ppc64el
On Mon, 12 Dec 2016 13:09:10 -0200 Breno Leitaowrote: > Sure. Since the problem is only related to long double, you can bypass > either all the tests on ppc64el, or, disable long double on ppc64el and keep > the tests. Either way it should work. In fact, I came up with a better solution. Just disable the tests for long on ppc64el. Let me know if it works for you. Thank you, Breno Yes I was about to do the same. I'll teak your patch slightly to handle powerpc as well, since it suffers from the same problem as ppc64el. Thanks for your contribution. Let me know if a long-term solution comes up later. Ghis
Bug#844403: src:nfft: FTBFS on ppc64el
> Sure. Since the problem is only related to long double, you can bypass > either all the tests on ppc64el, or, disable long double on ppc64el and keep > the tests. Either way it should work. In fact, I came up with a better solution. Just disable the tests for long on ppc64el. Let me know if it works for you. Thank you, Breno diff -Nru nfft-3.3.2/debian/changelog nfft-3.3.2/debian/changelog --- nfft-3.3.2/debian/changelog 2016-10-31 05:00:52.0 -0400 +++ nfft-3.3.2/debian/changelog 2016-12-09 16:12:51.0 -0500 @@ -1,3 +1,11 @@ +nfft (3.3.2-1.1) UNRELEASED; urgency=medium + + * Avoid running tests with long double on ppc64el due to failing tests +(Closes: #844403) + * Add build-dependency for latex. + + -- Breno LeitaoFri, 09 Dec 2016 16:12:51 -0500 + nfft (3.3.2-1) unstable; urgency=medium * New upstream version 3.3.2 diff -Nru nfft-3.3.2/debian/control nfft-3.3.2/debian/control --- nfft-3.3.2/debian/control 2016-10-31 05:00:52.0 -0400 +++ nfft-3.3.2/debian/control 2016-12-09 16:12:51.0 -0500 @@ -8,7 +8,8 @@ libcunit1-dev, libfftw3-dev, libncurses5-dev, - pkg-config + pkg-config, + texlive Build-Depends-Indep: doxygen Standards-Version: 3.9.8 Vcs-Browser: https://anonscm.debian.org/cgit/debian-science/packages/nfft.git diff -Nru nfft-3.3.2/debian/rules nfft-3.3.2/debian/rules --- nfft-3.3.2/debian/rules 2016-10-31 05:00:52.0 -0400 +++ nfft-3.3.2/debian/rules 2016-12-09 16:12:51.0 -0500 @@ -7,6 +7,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed +export DEB_HOST_ARCH = $(shell dpkg-architecture -q DEB_HOST_ARCH) # Available precisions. PRECISIONS = single double @@ -57,7 +58,13 @@ dh_auto_build --builddirectory=build-double -- doc override_dh_auto_test-arch: - for p in $(PRECISIONS) ; do \ + # Not running test for long double on ppc64el + if [ "$(DEB_HOST_ARCH)" = "ppc64el" ] ; then \ + PRECISIONS_TEST="single double" ;\ + else \ + PRECISIONS_TEST="$(PRECISIONS)" ;\ + fi ;\ + for p in $$PRECISIONS_TEST; do \ dh_auto_test --builddirectory=build-$$p ; \ done
Bug#844403: src:nfft: FTBFS on ppc64el
Hello Ghislain, On 12/09/2016 07:01 AM, Ghislain Vaillant wrote: > I might eventually just bypass testing for ppc64el to let the package > transition to testing, unless you think you are gonna have a fix ready very > soon. With the transition window extended to 10 days and the soft-freeze > deadline happening, I cannot wait for very much longer. Sure. Since the problem is only related to long double, you can bypass either all the tests on ppc64el, or, disable long double on ppc64el and keep the tests. Either way it should work. > Please keep me up-to-date, and thanks for investigating. Sure. things are a bit confused with long double on ppc64el, as for example the following bug, so, I suspect we are facing something similar: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
Bug#844403: src:nfft: FTBFS on ppc64el
On Mon, 28 Nov 2016 11:24:27 -0200 Breno Leitaowrote: On 11/27/2016 07:16 PM, Ghislain Vaillant wrote: > On Thu, 24 Nov 2016 18:49:29 -0200 Breno Leitao wrote: >> I am looking at this issue, and the first test set is checkall. >> >> If I run it inside dpkg-buildpackage, it fails as in the log, but, if I run >> it isolated, I see no errors, as showed: >> >> $ ./checkall 2>&1 | grep -i fail >> $ >> >> Looking all tests I see "-> OK". Anyway, I am continue to debug what is the >> problem here. > > It could be a lucky shot. Have you tried running them multiple times? Yes, and it works, but it fails when running in multi thread mode. Anyway, I am able to reproduce the problem here. Ack. > If you look carefully at the log you will find that some tests have an > unrealistically low tolerance value (in the order of 1E-322), which make them > succeed when the difference is exactly 0 and fail otherwise. That is interesting, Float precision might be a platform characterstic, mainly if using long double, or, quad float precision. Anyway, I will go deeper in the code to understand the problem here. I might eventually just bypass testing for ppc64el to let the package transition to testing, unless you think you are gonna have a fix ready very soon. With the transition window extended to 10 days and the soft-freeze deadline happening, I cannot wait for very much longer. Please keep me up-to-date, and thanks for investigating. Ghis
Bug#844403: src:nfft: FTBFS on ppc64el
On 11/27/2016 07:16 PM, Ghislain Vaillant wrote: > On Thu, 24 Nov 2016 18:49:29 -0200 Breno Leitaowrote: >> I am looking at this issue, and the first test set is checkall. >> >> If I run it inside dpkg-buildpackage, it fails as in the log, but, if I run >> it isolated, I see no errors, as showed: >> >> $ ./checkall 2>&1 | grep -i fail >> $ >> >> Looking all tests I see "-> OK". Anyway, I am continue to debug what is the >> problem here. > > It could be a lucky shot. Have you tried running them multiple times? Yes, and it works, but it fails when running in multi thread mode. Anyway, I am able to reproduce the problem here. > If you look carefully at the log you will find that some tests have an > unrealistically low tolerance value (in the order of 1E-322), which make them > succeed when the difference is exactly 0 and fail otherwise. That is interesting, Float precision might be a platform characterstic, mainly if using long double, or, quad float precision. Anyway, I will go deeper in the code to understand the problem here.
Bug#844403: src:nfft: FTBFS on ppc64el
On Thu, 24 Nov 2016 18:49:29 -0200 Breno Leitaowrote: I am looking at this issue, and the first test set is checkall. If I run it inside dpkg-buildpackage, it fails as in the log, but, if I run it isolated, I see no errors, as showed: $ ./checkall 2>&1 | grep -i fail $ Looking all tests I see "-> OK". Anyway, I am continue to debug what is the problem here. It could be a lucky shot. Have you tried running them multiple times? If you look carefully at the log you will find that some tests have an unrealistically low tolerance value (in the order of 1E-322), which make them succeed when the difference is exactly 0 and fail otherwise. The other tests have an adequate tolerance value set (1E-16). I don't know enough about the codebase to tell you why these tolerances are different, but that's probably where the issue is. I would expect all tolerances to be in the same order (1E-16). Cheers, Ghis
Bug#844403: src:nfft: FTBFS on ppc64el
Package: src:nfft Version: 3.3.2-1 Severity: important Justification: fails to build from source Usertags: ppc64el The nfft source package fails to build from source on ppc64el [1]. The build fails at the testing stage for the long-double precision version of the library. Upstream has been alerted [2] but a solution is yet to be found. The tolerance values in the failing tests look off. [1] https://buildd.debian.org/status/fetch.php?pkg=nfft=ppc64el=3.3.2-1=1477913387 [2] https://github.com/NFFT/nfft/issues/28 There is currently a request of removal pending for ppc64el and powerpc but perhaps ppc64el porters may be able to solve this problem. Cheers, Ghis -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)