Bug#871214: [Pkg-octave-devel] Bug#871214: octave-image FTBFS on i386: test hangs

[Sébastien Villemot]

On Thu, Aug 10, 2017 at 02:42:42PM +0300, Adrian Bunk wrote:
> On Thu, Aug 10, 2017 at 09:31:32AM +0200, Rafael Laboissière wrote:
> > 
> > I would guess that the culprit is the following unit test in bwdist:
> > 
> > ## The quasi-euclidean method is apparently sensitive to a machine precision
> > ## error that happens in x86 systems only. This test will cause an endless
> > ## loop in case of a regression.
> >...
> 
> That explains why the problem happens on i386 (where the 387 FPU
> that internally uses 80-bit precision is used) but not on amd64
> (where gcc defaults to using SSE instead of the 387).
> 
> If the problem is only in the test case,
> it should be disabled on any-i386.
> 
> But if the difference is actually considered a bug,
> then the following in debian/rules fixes the problem:
> 
> DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
> 
> ifneq (,$(filter $(DEB_HOST_ARCH), i386))
> export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store
> endif

Thanks Adrian for suggesting this solution.

However, it should be mentioned that this option has a significant performance
cost (since it basically adds a memory access after each floating point
computation).

I am not familiar enough with octave-image to decide whether IEEE compliance is
more important than performance, though.

-- 
⢀⣴⠾⠻⢶⣦   Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature

Bug#871214: [Pkg-octave-devel] Bug#871214: octave-image FTBFS on i386: test hangs

[Adrian Bunk]

On Tue, Aug 15, 2017 at 08:08:58PM +0200, Sébastien Villemot wrote:
> On Thu, Aug 10, 2017 at 02:42:42PM +0300, Adrian Bunk wrote:
> > On Thu, Aug 10, 2017 at 09:31:32AM +0200, Rafael Laboissière wrote:
> > > 
> > > I would guess that the culprit is the following unit test in bwdist:
> > > 
> > > ## The quasi-euclidean method is apparently sensitive to a machine 
> > > precision
> > > ## error that happens in x86 systems only. This test will cause an endless
> > > ## loop in case of a regression.
> > >...
> > 
> > That explains why the problem happens on i386 (where the 387 FPU
> > that internally uses 80-bit precision is used) but not on amd64
> > (where gcc defaults to using SSE instead of the 387).
> > 
> > If the problem is only in the test case,
> > it should be disabled on any-i386.
> > 
> > But if the difference is actually considered a bug,
> > then the following in debian/rules fixes the problem:
> > 
> > DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
> > 
> > ifneq (,$(filter $(DEB_HOST_ARCH), i386))
> > export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store
> > endif
> 
> Thanks Adrian for suggesting this solution.
> 
> However, it should be mentioned that this option has a significant performance
> cost (since it basically adds a memory access after each floating point
> computation).
> 
> I am not familiar enough with octave-image to decide whether IEEE compliance 
> is
> more important than performance, though.

This is also what I tried to say by giving two options and
"But if the difference is actually considered a bug".

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#871214: [Pkg-octave-devel] Bug#871214: octave-image FTBFS on i386: test hangs

[Adrian Bunk]

On Thu, Aug 10, 2017 at 09:31:32AM +0200, Rafael Laboissière wrote:
> 
> I would guess that the culprit is the following unit test in bwdist:
> 
> ## The quasi-euclidean method is apparently sensitive to a machine precision
> ## error that happens in x86 systems only. This test will cause an endless
> ## loop in case of a regression.
>...

That explains why the problem happens on i386 (where the 387 FPU
that internally uses 80-bit precision is used) but not on amd64
(where gcc defaults to using SSE instead of the 387).

If the problem is only in the test case,
it should be disabled on any-i386.

But if the difference is actually considered a bug,
then the following in debian/rules fixes the problem:

DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)

ifneq (,$(filter $(DEB_HOST_ARCH), i386))
export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store
endif


> Rafael

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#871214: [Pkg-octave-devel] Bug#871214: octave-image FTBFS on i386: test hangs

[Rafael Laboissière]

* Adrian Bunk  [2017-08-07 01:57]:


Source: octave-image
Version: 2.6.1-1
Severity: serious
Tags: buster sid

Some recent change in unstable and buster makes octave-image FTBFS on i386:

 https://tests.reproducible-builds.org/debian/history/octave-image.html
 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/octave-image.html

 ...
 Checking CC files ...
 warning: function /build/1st/octave-image-2.6.1/inst/private/iscolormap.m 
shadows a core library function
 warning: called from
/tmp/filePMKFm8 at line 1 column 1
 [__spatial_filtering__]
 PASSES 21 out of 21 tests
 [graycomatrix]
 PASSES 2 out of 2 tests
 [watershed]
 * test
 im = [
 2 330 2
 330 330
   2553130 4
 2   2553130
 1 2   255 5];

 labeled8 = [
 1 1 0 3
 1 1 0 3
 0 0 0 0
 2 2 0 4
 2 2 0 4];
 assert (watershed (im), labeled8);
 assert (watershed (im, 8), labeled8);
 ! test failed
 ASSERT errors for:  assert (watershed (im),labeled8)

  Location  |  Observed  |  Expected  |  Reason
   (3,4)  30 Abs err 3 exceeds tol 0
   (4,4)  04 Abs err 4 exceeds tol 0
 [bwdist]
 Sat Sep  8 05:36:25 UTC 2018 - pbuilder was killed by timeout after 18h.


I would guess that the culprit is the following unit test in bwdist:

## The quasi-euclidean method is apparently sensitive to a machine precision
## error that happens in x86 systems only. This test will cause an endless
## loop in case of a regression.
%!test
%! bw = [  0   1   1   0   0   0   1   0
%! 0   0   0   0   0   0   0   0
%! 1   1   0   0   0   0   0   0
%! 0   0   0   0   0   0   1   0
%! 0   0   0   0   1   0   0   1
%! 0   0   0   0   0   0   0   0
%! 1   0   0   0   0   0   0   0
%! 0   0   1   0   0   1   1   0];
%! out = single ([
%! 1.0   0.0   0.0   1.0   2.0   1.0   0.0   1.0
%! 1.0   1.0   1.0   sqrt(2)   sqrt(2)+1 sqrt(2)   1.0   sqrt(2)
%! 0.0   0.0   1.0   2.0   2.0   sqrt(2)   1.0   sqrt(2)
%! 1.0   1.0   sqrt(2)   sqrt(2)   1.0   1.0   0.0   1.0
%! 2.0   2.0   2.0   1.0   0.0   1.0   1.0   0.0
%! 1.0   sqrt(2)   2.0   sqrt(2)   1.0   sqrt(2)   sqrt(2)   1.0
%! 0.0   1.0   1.0   sqrt(2)   sqrt(2)   1.0   1.0   sqrt(2)
%! 1.0   1.0   0.0   1.0   1.0   0.0   0.0   1.0
%! ]);
%! assert (bwdist (bw, "quasi-euclidean"), out);

Should we run the test above only on non-x86 architectures?

Rafael





___ 
Pkg-octave-devel mailing list 
pkg-octave-de...@lists.alioth.debian.org 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-octave-devel