Bug#844403: src:nfft: FTBFS on ppc64el

2016-12-14 Thread Breno Leitao
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

2016-12-14 Thread Ghislain Vaillant

On Mon, 12 Dec 2016 13:09:10 -0200 Breno Leitao  wrote:

> 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

2016-12-12 Thread Breno Leitao
> 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 Leitao   Fri, 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

2016-12-09 Thread Breno Leitao
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

2016-12-09 Thread Ghislain Vaillant

On Mon, 28 Nov 2016 11:24:27 -0200 Breno Leitao  wrote:

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

2016-11-28 Thread Breno Leitao
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.


> 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

2016-11-27 Thread Ghislain Vaillant

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?

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

2016-11-15 Thread Ghislain Antony Vaillant
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)