Bug#887682: r-cran-utf8: FTBFS on m68k: missing value where TRUE/FALSE needed

[Aaron M. Ucko]

Andreas Tille <ti...@debian.org> writes:

> Question: Is real m68k hardware used at all or is it just some people
> like you who run qemu instances for whatever reason?  This is an honest
> question since I'm pretty sure that no scientific software (like R and
> others) have any use on m68k and I'm afraid it just drains time from
> you (and other porters) and maintainers.

My understanding is that there are still some users with actual
hardware, but the autobuilders use qemu for better performance and/or
reliability, which I admit doesn't say much for the hardware. ;-)

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#887682: r-cran-utf8: FTBFS on m68k: missing value where TRUE/FALSE needed

[Aaron M. Ucko]

Dylan Aïssi <bob.dyb...@gmail.com> writes:

> This package was built correctly for m68k on 2018-02-27 [1].
> Can we close this bug?

Yes, please.  IIRC, this failure turned out to stem from a problem with
the build setup (specifically, a qemu bug); sorry for the noise.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#882555: r-cran-ddalpha: FTBFS on m68k: no boost::math::Rlog1p

[Aaron M. Ucko]

Dylan Aïssi <bob.dyb...@gmail.com> writes:

> This package was built correctly for m68k on 2018-03-23 [1].
> Can we close this bug?

Yes, please.  IIRC, this failure turned out to stem from a problem with
the build setup (specifically, a qemu bug); sorry for the noise.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#887680: r-cran-git2r: FTBFS on m68k: missing value where TRUE/FALSE needed

[Aaron M. Ucko]

Dylan Aïssi <bob.dyb...@gmail.com> writes:

> This package was built correctly for m68k on 2018-02-27 [1].
> Can we close this bug?

Yes, please.  IIRC, this failure turned out to stem from a problem with
the build setup (specifically, a qemu bug); sorry for the noise.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#893756: ignition-common: FTBFS on hurd-i386: PATH_MAX not declared

[Aaron M. Ucko]

Source: ignition-common
Version: 1.0.1-1
Severity: normal
Tags: upstream
User: debian-h...@lists.debian.org
Usertags: hurd

The build of ignition-common for hurd-i386 (admittedly not a release
architecture) failed:

  /<>/src/FilesystemBoost.cc: In function 'std::__cxx11::string 
ignition::common::cwd()':
  /<>/src/FilesystemBoost.cc:134:25: error: 'PATH_MAX' was not 
declared in this scope

The Hurd makes a point of not having a static PATH_MAX.  Best practice
is dynamically accommodating whatever you actually encounter, for
instance by taking advantage of realpath's policy of allocating the
buffer itself when supplied a NULL buffer.  (You'll of course need to
free it when done.)

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#892231: sdformat: FTBFS on hurd-i386: PATH_MAX undeclared

[Aaron M. Ucko]

Source: sdformat
Version: 6.0.0+dfsg-4
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-h...@lists.debian.org
Usertags: hurd

The latest build of sdformat for hurd-i386 (admittedly not a release
architecture) failed:

  /<>/sdformat-6.0.0+dfsg/src/Filesystem.cc:133:21: error: 'PATH_MAX' 
was not declared in this scope

The Hurd notoriously has no static PATH_MAX.  Best practice is to
accommodate whatever you actually encounter, since fixed-size buffers
generally either waste memory or risk being too small.  In particular,
I would suggest taking advantage of realpath's policy of allocating
memory itself if you pass a NULL buffer.  (You'll of course need to
free the resolved path when you're done with it.)

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#892151: ignition-fuel-tools: FTBFS w/ignition-cmake 0.3.0 (on alpha)

[Aaron M. Ucko]

Source: ignition-fuel-tools
Version: 1.0.0+dfsg4-2
Severity: normal
User: debian-al...@lists.debian.org
Usertags: alpha

The build of ignition-fuel-tools for alpha (admittedly not a release
architecture) failed to find four of the libraries it needs, as
detailed in [1]:

  -- BUILD ERRORS: These must be resolved before compiling.
  --Missing: IgnCURL
  --Missing: JSONCPP
  --Missing: YAML
  --Missing: ZIP
  --  END BUILD ERRORS

On a presumably related note, ignition-cmake is still at 0.3.0 here,
due to some sort of problems with the Ruby stack.  Please specifically
build-depend on libignition-cmake-dev (>= 0.4) to ensure you pull in a
new enough version.

Thanks!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=ignition-fuel-tools=alpha=1.0.0%2Bdfsg4-2=1519096893=0

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#890571: libmseed-dev: libmseed.h misses unistd.h on non-Linux

[Aaron M. Ucko]

Package: libmseed-dev
Version: 2.19.5-1
Severity: normal
Tags: upstream
User: debian-h...@lists.debian.org
Usertags: hurd
Control: affects -1 src:mseed2sac

libmseed.h's #include directive for  is conditional on

  defined(LMP_LINUX) || defined(LMP_BSD) || defined(LMP_SOLARIS)

none of which winds up defined on the Hurd (or even kFreeBSD, seeing
how LMP_BSD is conditionalized).  Any halfway modern __unix system
(including in particular all Debian architectures) will have this
header; please #include it more widely.

As it stands, this conditionalization breaks the build of mseed2sac
for hurd-i386 [1] (admittedly not a release architecture):

  mseed2sac.c:543:9: warning: implicit declaration of function 'access'; did 
you mean 'acosl'? [-Wimplicit-function-declaration]
  mseed2sac.c:543:26: error: 'F_OK' undeclared (first use in this function)

Could you please take a look?

Thanks!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=mseed2sac=hurd-i386=2.2%2Bds1-2=1518262290=0

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#888220: ignition-math4: FTBFS on mips(el) and hppa: UNIT_Helpers_TEST fails badly

[Aaron M. Ucko]

Source: ignition-math4
Version: 4.0.0+dfsg1-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-m...@lists.debian.org
Usertags: mips mipsel

Builds of ignition-math4 for mips, mipsel, and the non-release
architecture hppa have been failing as detailed at

https://buildd.debian.org/status/fetch.php?pkg=ignition-math4=mips=4.0.0%2Bdfsg1-1=1516376024=0
https://buildd.debian.org/status/fetch.php?pkg=ignition-math4=mipsel=4.0.0%2Bdfsg1-1=1516373688=0
https://buildd.debian.org/status/fetch.php?pkg=ignition-math4=hppa=4.0.0%2Bdfsg1-1=1516373442=0

On mips, this test manages to make ctest itself to run out of memory:

Start 11: UNIT_Helpers_TEST
  terminate called after throwing an instance of 'std::bad_alloc'
what():  std::bad_alloc
  Makefile:143: recipe for target 'test' failed
  make[2]: *** [test] Aborted

On mipsel and hppa, HelpersTest.Pair spews millions(!) of errors and
then hits a timeout:

  11/75 Test #11: UNIT_Helpers_TEST ..***Timeout 240.12 sec
  [...]
  [ RUN  ] HelpersTest.Pair
  /<>/ignition-math4-4.0.0+dfsg1/src/Helpers_TEST.cc:516: Failure
Expected: a
Which is: 4294962295
  To be equal to: c
Which is: 4294962296
  [...]
  /<>/ignition-math4-4.0.0+dfsg1/src/Helpers_TEST.cc:516: Failure
Expected: a
Which is: 4294963544
  To be equal to: c
Which is: 4294963545
  
Start 12: check_UNIT_Helpers_TEST

(above output from mipsel, hppa is similar)

NB: the mipsel and hppa logs are a couple hundred megs apiece, so you
may wish to consider taking it easy on your browser by downloading raw
logs and viewing them with less. ;-)

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#888219: ignition-math4: FTBFS on *i386: OrientedBoxTest.OperatorStreamOut fails

[Aaron M. Ucko]

Source: ignition-math4
Version: 4.0.0+dfsg1-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of ignition-math4 for i386 and the non-release architecture
hurd-i386 both failed due to one error in UNIT_OrientedBox_TEST:

  27/75 Test #27: UNIT_OrientedBox_TEST ..***Failed0.01 sec
  Running main() from gtest_main.cc
  [==] Running 13 tests from 1 test case.
  [...]
  [ RUN  ] OrientedBoxTest.OperatorStreamOut
  /<>/ignition-math4-4.0.0+dfsg1/src/OrientedBox_TEST.cc:333: Failure
Expected: stream.str()
Which is: "Size[0.1 1.2 2.3] Pose[3.4 4.5 5.6 -0 -0.1 0.2]"
  To be equal to: "Size[0.1 1.2 2.3] Pose[3.4 4.5 5.6 0 -0.1 0.2]"
  [  FAILED  ] OrientedBoxTest.OperatorStreamOut (0 ms)
  [...]
   1 FAILED TEST
  [...]
  99% tests passed, 1 tests failed out of 75

It may be worth noting that i386 (i387) floating-point registers have
more precision than a standard double, which occasionally yields this
sort of surprise.  You might try disabling that feature by building
with -ffloat-store on these architectures.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#887682: r-cran-utf8: FTBFS on m68k: missing value where TRUE/FALSE needed

[Aaron M. Ucko]

Source: r-cran-utf8
Version: 1.1.3-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-...@lists.debian.org
Usertags: m68k

The build of r-cran-utf8 for m68k (admittedly not a release
architecture) failed:

  Error in if (any(i)) x[i] <- paste0(x[i], "\n", indentString) :
missing value where TRUE/FALSE needed
  ERROR: installing package indices failed

This is the same mysterious error message as with r-cran-git2r, just
in a different context; there may well be a bug in R itself here.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#887680: r-cran-git2r: FTBFS on m68k: missing value where TRUE/FALSE needed

[Aaron M. Ucko]

Source: r-cran-git2r
Version: 0.21.0-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-...@lists.debian.org
Usertags: m68k

The build of r-cran-git2r for m68k (admittedly not a release
architecture) failed:

  Error in if (nc[currentIndex] == 0L) upperBlockIndex <- c(upperBlockIndex,  : 
missing value where TRUE/FALSE needed
  ERROR: installing package DESCRIPTION failed for package 'git2r'

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#886886: ros-bond-core: FTBFS on m68k: timeout generating Python from MSG bond/Constants

[Aaron M. Ucko]

John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> writes:

> Hi Aaron!

Hi, Adrian.

> Either way, thanks for spotting this issue. I will look into it and will
> file a qemu-m68k bug if my initial suspicion turns out to be right.

Great, thanks.  Your hypothesis would certainly explain why this package
suddenly broke.

Meanwhile, what's your take on
https://buildd.debian.org/status/fetch.php?pkg=tinyssh=m68k=20180101-1=1515027549=0?
More qemu lossage or an actual tinyssh bug?

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#886886: ros-bond-core: FTBFS on m68k: timeout generating Python from MSG bond/Constants

[Aaron M. Ucko]

Source: ros-bond-core
Version: 1.8.1-2
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: m68k

Builds of ros-bond-core 1.8.1-2 for m68k (admittedly not a release
architecture) have been failing, per the below excerpt from [1]:

  [ 54%] Generating Python from MSG bond/Constants
  cd /<>/obj-m68k-linux-gnu/bond && 
../catkin_generated/env_cached.sh /usr/bin/python /usr/lib/genpy/genmsg_py.py 
/<>/bond/msg/Constants.msg -Ibond:/<>/bond/msg 
-Istd_msgs:/usr/share/std_msgs/cmake/../msg -p bond -o 
/<>/obj-m68k-linux-gnu/devel/lib/python2.7/dist-packages/bond/msg
  E: Build killed with signal TERM after 600 minutes of inactivity

This version already received a second build attempt, so the problem
wasn't just a one-off glitch, and builds are otherwise generally
quick.  (The only other instance I see on [2] of taking more than an
hour was an m68k build of 1.7.16-3+b1 in February of 2016 that took
about 9.5 hours; most other builds were well under an hour.)

Could you please take a look?

Thanks!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=ros-bond-core=m68k=1.8.1-2=1515504032=0
[2] https://buildd.debian.org/status/logs.php?pkg=ros-bond-core

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#886421: python-escript: FTBFS on m68k: hwloc_set_cpubind returned "Error" for bitmap "0"

[Aaron M. Ucko]

Source: python-escript
Version: 5.1-5
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: m68k

Builds of python-escript for m68k (admittedly not a release
architecture) have been failing lately per the below excerpts from
https://buildd.debian.org/status/fetch.php?pkg=python-escript=m68k=5.1-5=1514854858=0.
FWIW, automatic builds for this architecture run with nocheck in
DEB_BUILD_OPTIONS because there's little overall incremental value to
running tests on such a slow architecture.  However, it's perhaps just
as well that that setting had no effect here, since this problem
doesn't affect any other Debian architectures and may be worth
investigating.

Could you please take a look?

Thanks!

--

/<>/debian/stage2M/bin/run-escript 
/<>/debian/tmp2M/scripts/release_sanity.py
--
WARNING: a request was made to bind a process. While the system
supports binding the process itself, at least one node does NOT
support binding memory to the process location.

  Node:  vs90

Open MPI uses the "hwloc" library to perform process and memory
binding. This error message means that hwloc has indicated that
processor binding support is not available on this machine.
[...]
This is a warning only; your job will continue, though performance may
be degraded.
--
--
Open MPI tried to bind a new process, but something went wrong.  The
process was killed without launching the target application.  Your job
will now abort.

  Local host:vs90
  Application name:  /<>/debian/stage2M/lib/pythonMPI
  Error message: hwloc_set_cpubind returned "Error" for bitmap "0"
  Location:  rtc_hwloc.c:190
--
scons: *** [dummy] Error 213
scons: building terminated because of errors.

*** Config Summary (see config.log and /lib/buildvars for details) ***
Escript revision 6608
  Install prefix:  /<>/debian/stage2M
  Python:  /usr/bin/python (Version 2.7.14)
   boost:  /usr (Version 1.62.0)
   numpy:  YES (with headers)
 MPI:  OPENMPI (Version 2.1.1)
  Solver library:  paso
   Direct solver:  NONE
 domains:  dudley, finley, ripley, speckley
  netcdf:  YES (3)
   weipa:  YES
  openmp:  YES

  DISABLED features: boomeramg cppunit cuda debug gdal gmsh gzip lapack mkl 
papi parmetis pyproj scipy silo sympy trilinos umfpack visit
  Treating warnings as errors

WARNING: Cannot import scipy. NetCDF sources will not be available for 
inversions.
WARNING: Cannot import pyproj. Inversions may not work.
WARNING: Cannot import gdal. Inversions will not honour WKT coordinate system 
information.
WARNING: Cannot import sympy. Symbolic toolbox and nonlinear PDEs will not be 
available.
WARNING: matplotlib not found, will skip some unit tests
WARNING: gmsh not available. Skipping tests usersguide/trapezoid.py 
usersguide/quad.py usersguide/brick.py usersguide/refine.py 
cookbook/example04a.py cookbook/example04b.py cookbook/example05a.py 
cookbook/example05b.py cookbook/example05c.py cookbook/example06.py 
cookbook/example08c.py cookbook/example09m.py cookbook/example09a.py 
cookbook/example10m.py inversion/dc_forward.py!

ERROR: build stopped due to errors

debian/rules:57: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
debian/rules:30: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#886141: visp: FTBFS on mips: six tests time out

[Aaron M. Ucko]

Source: visp
Version: 3.1.0-1
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-m...@lists.debian.org
Usertags: mips

Builds of visp for mips have been failing lately.  Part of the problem
is that all 12 mbtGenericTrackingDepth tests generally fail on
big-endian architectures, as I just reported (#886140).  On top of
that, six tests timed out on this specific architecture, as detailed at
https://buildd.debian.org/status/fetch.php?pkg=visp=mips=3.1.0-1=1514685910=0:

  2 - testConversion (Timeout)
 23 - testMatrix (Timeout)
 27 - testMatrixPseudoInverse (Timeout)
 60 - testImgproc (Timeout)
 80 - testKeyPoint-5 (Timeout)
 81 - testKeyPoint-6 (Timeout)

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#886140: visp: FTBFS (big-endian): mbtGenericTrackingDepth tests fail

[Aaron M. Ucko]

Source: visp
Version: 3.1.0-1
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-m...@lists.debian.org
Usertags: mips

Builds of visp for big-endian architectures have been failing lately,
with errors in all 12 mbtGenericTrackingDepth tests.  The details vary
to some extent by architecture, but I suspect the root cause is the
same.  Specifically:

* On the 32-bit big-endian architectures mips and powerpc[*], these
  tests all fail with

terminate called after throwing an instance of 'std::bad_array_new_length'
  what():  std::bad_array_new_length

  which CTest reports as OTHER_FAULT.  (The mips build also
  encountered six other test failures, which I'll report separately.
  As for m68k[*], that build nominally succeeded only because builds
  there generally run with nocheck in DEB_BUILD_OPTIONS.)

* On s390x, these tests all encountered segmentation faults.

* On ppc64[*], these tests all failed with an unspecified "Exception:
  Other".

Could you please take a look?

Thanks!

[*] Admittedly not a release architecture.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#885889: sasview: FTBFS: debian/sasview might not exist

[Aaron M. Ucko]

Source: sasview
Version: 4.2.0~git20171031-2
Severity: serious
Justification: fails to build from source

Builds of sasview covering only its architecture-dependent
python-sasview binary package (as on the autobuilders, or with
dpkg-buildpackage -B) have been failing:

  dh_install
  mv debian/python-sasview/usr/bin/sasview debian/sasview/usr/bin/sasview
  mv: cannot move 'debian/python-sasview/usr/bin/sasview' to 
'debian/sasview/usr/bin/sasview': No such file or directory
  debian/rules:27: recipe for target 'override_dh_install' failed
  make[1]: *** [override_dh_install] Error 1
  make[1]: Leaving directory '/<>'
  debian/rules:16: recipe for target 'binary-arch' failed
  make: *** [binary-arch] Error 2

Could you please take a look?  You may wish to consider splitting
override_dh_install into -arch and -indep targets.

Bonus points for additionally accounting for builds that cover only
the architecture-independent packages, as with dpkg-buildpackage -A
(allowing for source-only uploads). ;-)

Thanks!

FTR, I'm classifying this bug as a regression because it would affect
any needed binary-only rebuilds for amd64.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#884939: mumps: FTBFS on m68k: mpi-fort.pc not found, mpi_* undefined

[Aaron M. Ucko]

Source: mumps
Version: 5.1.1-3+b1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-...@lists.debian.org
Usertags: m68k

Builds of mumps for m68k (admittedly not a release architecture) have
been failing as detailed in [1]:

  Package mpi-fort was not found in the pkg-config search path.
  Perhaps you should add the directory containing `mpi-fort.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'mpi-fort' found
  gfortran -shared lr_common.o ana_omp_m.o [...] mumps_save_restore_C.o 
-Wl,-soname,libmumps_common_ptscotch-5.1.2.so -L../lib -L../PORD/lib/ 
-lpord_ptscotch -L/usr/lib -lptesmumps -lptscotch -lptscotcherr -lscotch 
-lpthread  -lmpi -o ../lib/libmumps_common_ptscotch-5.1.2.so -Wl,-z,defs
  mumps_static_mapping.o: In function 
`__mumps_static_mapping_MOD_mumps_init_arch_parameters':
  mumps_static_mapping.F:(.text+0xd0d8): undefined reference to `mpi_comm_rank_'
  [...]
  tools_common.F:(.text+0x13b4): undefined reference to `mpi_bcast_'
  collect2: error: ld returned 1 exit status
  Makefile:177: recipe for target '../lib/libmumps_common_ptscotch.so' failed
  make[5]: *** [../lib/libmumps_common_ptscotch.so] Error 1

I'm not sure where mpi-fort.pc is expected to come from -- the only
.pc file I see in [2] is mpich.pc -- but perhaps it would help to link
(and for that matter, compile) with mpifort rather than directly
invoking and attempting to tune gfortran.

Could you please take a look?

Thanks!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=mumps=m68k=5.1.2-2=1513807447=0
[2] https://packages.debian.org/sid/m68k/libmpich-dev/filelist

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#884054: polyml: FTBFS on sh4: MemMgr: Assertion `t->tree[r] == 0' failed.

[Aaron M. Ucko]

Source: polyml
Version: 5.7.1-1
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-sup...@lists.debian.org
Usertags: sh4

Builds of polyml 5.7.x for sh4 (admittedly not a release architecture)
have been failing:

  echo "use \"./ROOT.sml\";" | ../../poly -q -error-exit
  poly: memmgr.cpp:957: void MemMgr::AddTreeRange(SpaceTree**, MemSpace*, 
uintptr_t, uintptr_t): Assertion `t->tree[r] == 0' failed.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#882711: segyio: FTBFS on hurd-i386: some *.segy tests still fail

[Aaron M. Ucko]

... ok
test_read_line_mmap (test.segyio_c._segyioTests) ... ERROR
test_read_text_header (test.segyio_c._segyioTests) ... ok
test_textheader_size (test.segyio_c._segyioTests) ... ok
test_write_text_header (test.segyio_c._segyioTests) ... ok

==
ERROR: test_read_line_mmap (test.segyio_c._segyioTests)
--
Traceback (most recent call last):
  File "/<>/.pybuild/pythonX.Y_3.6/build/python/test/segyio_c.py", 
line 475, in test_read_line_mmap
_segyio.close(f)
OSError: [Errno 1073741902] Function not implemented

--
Ran 20 tests in 0.030s

FAILED (errors=1)
[...]
90% tests passed, 3 tests failed out of 31

Total Test time (real) =   3.69 sec

The following tests FAILED:
  1 - c.segy (Failed)
  3 - python.segy (Failed)
      4 - python.h.segy (Failed)
Errors while running CTest

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#882555: r-cran-ddalpha: FTBFS on m68k: no boost::math::Rlog1p

[Aaron M. Ucko]

Source: r-cran-ddalpha
Version: 1.3.1-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-m...@lists.debian.org
Usertags: m68k

The build of r-cran-ddalpha for m68k (admittedly not a release
architecture) failed:

  g++ -std=gnu++11 -I/usr/share/R/include -DNDEBUG  
-I"/usr/lib/R/site-library/Rcpp/include"-fpic  -g -O2 
-fdebug-prefix-map=/build/r-base-vkBOGA/r-base-3.4.2.20171120=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -c Polynomial.cpp -o Polynomial.o
  In file included from /usr/lib/R/site-library/Rcpp/include/RcppCommon.h:72:0,
   from /usr/lib/R/site-library/Rcpp/include/Rcpp.h:27,
   from stdafx.h:27,
   from Polynomial.cpp:14:
  /usr/include/boost/math/special_functions/log1p.hpp: In static member 
function 'static void boost::math::detail::log1p_initializer<T, Policy, 
tag>::init::do_init(const mpl_::int_<64>&)':
  /usr/share/R/include/Rmath.h:76:15: error: 'Rlog1p' is not a member of 
'boost::math'
   #define log1p Rlog1p
 ^
  /usr/share/R/include/Rmath.h:76:15: note: suggested alternative: 'log1p'
  /usr/lib/R/etc/Makeconf:168: recipe for target 'Polynomial.o' failed
  make[1]: *** [Polynomial.o] Error 1

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#882452: FTBFS: unknown opcode pause in delaunay_3d.cpp

[Aaron M. Ucko]

Source: ovito
Version: 2.9.0+dfsg1-5
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-h...@lists.debian.org
Usertags: hppa

Builds of ovito for hppa, m68k, powerpc, and ppc64 (all admittedly
non-release architectures) have been failing lately with variants of

  /tmp/ccA1UlEM.s: Assembler messages:
  /tmp/ccA1UlEM.s:12621: Error: Unknown opcode: `pause'
  src/3rdparty/geogram/CMakeFiles/geogram.dir/build.make:425: recipe for target 
'src/3rdparty/geogram/CMakeFiles/geogram.dir/delaunay/delaunay_3d.cpp.o' failed

as detailed in

https://buildd.debian.org/status/fetch.php?pkg=ovito=hppa=2.9.0%2Bdfsg1-5=1511233991=0
https://buildd.debian.org/status/fetch.php?pkg=ovito=m68k=2.9.0%2Bdfsg1-5=1511332288=0
https://buildd.debian.org/status/fetch.php?pkg=ovito=powerpc=2.9.0%2Bdfsg1-5=1511222775=0
https://buildd.debian.org/status/fetch.php?pkg=ovito=ppc64=2.9.0%2Bdfsg1-5=1511219276=0

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#882451: ovito: FTBFS on armel: QOpenGLFunctions_* does not name a type

[Aaron M. Ucko]

Source: ovito
Version: 2.9.0+dfsg1-5
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-...@lists.debian.org
Usertags: armel

Builds of ovito for armel have been failing lately as detailed in
https://buildd.debian.org/status/fetch.php?pkg=ovito=armel=2.9.0%2Bdfsg1-5=1511236739=0
with a cascade of errors starting with

  
/<>/ovito-2.9.0+dfsg1/src/opengl_renderer/OpenGLSceneRenderer.h:255:2:
 error: 'QOpenGLFunctions_2_0' does not name a type; did you mean 
'QOpenGLFunctions'?

IIRC, Qt uses GLES rather than traditional OpenGL here.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#882421: segyio: FTBFS on sparc64: test_rotation: AssertionError: 1.571 != 0.0 within 3 places

[Aaron M. Ucko]

Source: segyio
Version: 1.3.3-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-sp...@lists.debian.org
Usertags: sparc64

The build of segyio for sparc64 (admittedly not a release
architecture) failed per the below excerpts from
https://buildd.debian.org/status/fetch.php?pkg=segyio=sparc64=1.3.3-1=1511256932=0.
1.571 is of course approximately π/2.

Could you please take a look?

Thanks!



16/17 Test  #6: python.tools .***Failed0.61 sec
test_cube_filename (tools.ToolsTest) ... ok
test_cube_identity (tools.ToolsTest) ... ok
test_cube_identity_prestack (tools.ToolsTest) ... ok
test_dt_fallback (tools.ToolsTest) ... ok
test_dt_no_fallback (tools.ToolsTest) ... ok
test_empty_text_header_creation (tools.ToolsTest) ... ok
test_native (tools.ToolsTest) ... ok
test_rotation (tools.ToolsTest) ... FAIL
test_sample_indexes (tools.ToolsTest) ... ok
test_unstructured_rotation (tools.ToolsTest) ... ok
test_values_text_header_creation (tools.ToolsTest) ... ok
test_wrap (tools.ToolsTest) ... ok

==
FAIL: test_rotation (tools.ToolsTest)
--
Traceback (most recent call last):
  File "/<>/.pybuild/pythonX.Y_3.6/build/python/test/tools.py", 
line 128, in test_rotation
close(right, rotation(f, line = 'slow'),  places = 3)
AssertionError: 1.571 != 0.0 within 3 places

--
Ran 12 tests in 0.032s

FAILED (failures=1)
[...]
94% tests passed, 1 tests failed out of 17

Total Test time (real) =   0.92 sec

The following tests FAILED:
  6 - python.tools (Failed)
Errors while running CTest
Makefile:122: recipe for target 'test' failed

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#882420: segyio: FTBFS on s390x: Assertion failed in file: /<>/lib/test/segy.c on line: 547

[Aaron M. Ucko]

Source: segyio
Version: 1.3.3-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-s...@lists.debian.org
Usertags: s390x

The build of segyio for s390x failed with a strange error, per the
below excerpt from 
https://buildd.debian.org/status/fetch.php?pkg=segyio=s390x=1.3.3-1=1511256490=0:

   1/17 Test  #1: c.segy ...***Failed0.00 sec
  Assertion failed in file: /<>/lib/test/segy.c on line: 547
  Expected: 4.24, Actual: 4.24, diff: 0.00, eps: 0.00
  starting
  interpret file
  read inline 4

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#881951: cctz: FTBFS on mips(el): time_zone_lookup_test fails

[Aaron M. Ucko]

Source: cctz
Version: 2.1~git~a59b930afc8+dfsg1-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-m...@lists.debian.org
Usertags: mips mipsel

Builds of cctz for mips and mipsel (but not mips64el, or any other
architectures) failed:

  2/4 Test #2: time_zone_lookup_test ***Exception: Other  0.05 sec
  Running main() from gtest_main.cc
  [==] Running 31 tests from 7 test cases.
  [--] Global test environment set-up.
  [--] 1 test from TimeZones
  [ RUN  ] TimeZones.LoadZonesConcurrently
  terminate called without an active exception
  [...]
  75% tests passed, 1 tests failed out of 4
  [...]
  The following tests FAILED:
  2 - time_zone_lookup_test (OTHER_FAULT)
  Errors while running CTest

The logs don't give any more details, but perhaps you can reproduce
the problem on a porter box.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#881873: trilinos: FTBFS on sparc64: Bus errors in 11 tests

[Aaron M. Ucko]

Source: trilinos
Version: 12.10.1-4+b1
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-sp...@lists.debian.org
Usertags: sparc64

Builds of trilinos for sparc64 (admittedly not a release architecture)
have been failing lately with bus errors (indicating attempts to use
underaligned pointers, about which sparc64 is notoriously strict), per
the below excerpts from
https://buildd.debian.org/status/fetch.php?pkg=trilinos=sparc64=12.12.1-1=1510746436=0.

Could you please take a look?

Thanks!



[...]
521/871 Test #521: EpetraExt_Transpose_test_LL_MPI_4 
..***Failed2.31 sec
Epetra::MpiComm::Processor 0 of 4 total processors.
EpetraExt in Trilinos 12.12.1

Epetra::MpiComm::Processor 1 of 4 total processors.
Epetra::MpiComm::Processor 2 of 4 total processors.
Epetra::MpiComm::Processor 3 of 4 total processors.
[landau:24458] *** Process received signal ***
[landau:24458] Signal: Bus error (10)
[landau:24458] Signal code: Invalid address alignment (1)
[landau:24458] Failing at address: 0x15ef4bc
[landau:24459] *** Process received signal ***
[landau:24459] Signal: Bus error (10)
[landau:24459] Signal code: Invalid address alignment (1)
[landau:24459] Failing at address: 0x15eca7c
[landau:24458] *** End of error message ***
[landau:24459] *** End of error message ***
[landau:24456] *** Process received signal ***
[landau:24456] Signal: Bus error (10)
[landau:24456] Signal code: Invalid address alignment (1)
[landau:24456] Failing at address: 0x160a96c
[landau:24457] *** Process received signal ***
[landau:24457] Signal: Bus error (10)
[landau:24457] Signal code: Invalid address alignment (1)
[landau:24457] Failing at address: 0x15ef4dc
[landau:24456] *** End of error message ***
[landau:24457] *** End of error message ***
--
mpiexec noticed that process rank 1 with PID 0 on node landau exited on signal 
10 (Bus error).
--
[...]
The following tests FAILED:
517 - EpetraExt_Permutation_test_LL_MPI_4 (Failed)
521 - EpetraExt_Transpose_test_LL_MPI_4 (Failed)
523 - EpetraExt_inout_test_LL_MPI_4 (Failed)
525 - EpetraExt_MatrixMatrix_test_LL_MPI_4 (Failed)
621 - AztecOO_AztecOO_test_LL_MPI_4 (Failed)
633 - ML_AztecSimple_MPI_4 (Failed)
636 - ML_MatrixFree_MPI_4 (Failed)
638 - ML_ML_Operator2Epetra_RowMatrix_MPI_4 (Failed)
639 - ML_MLP_Maxwell_MPI_4 (Failed)
640 - ML_MLP_NonSym_MPI_4 (Failed)
648 - Komplex_simple_MPI_4 (Failed)
Errors while running CTest

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#881870: normaliz: FTBFS on alpha: recipe for target 'test-v/medium.diff' failed

[Aaron M. Ucko]

Source: normaliz
Version: 3.4.1+ds-1
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-al...@lists.debian.org
Usertags: alpha

Builds of normaliz for alpha (admittedly not a release architecture)
have been failing lately:

  /<>/normaliz-3.4.1+ds/_build/../test/Makefile.classic:52: recipe 
for target 'test-v/medium.diff' failed

As with #881869, I don't know what the diff turned out to read, but
perhaps you can reproduce the problem on a porter box.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#881869: FTBFS: recipe for target 'test-/5x5PF.diff' failed

[Aaron M. Ucko]

Source: normaliz
Version: 3.4.1+ds-1
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-powe...@lists.debian.org
Usertags: powerpc ppc64 ppc64el

Builds of normaliz 3.4 for arm64, ppc64el, s390x, and the non-release
architectures powerpc and ppc64 (but for some reason not powerpcspe)
have been failing:

  /<>/normaliz-3.4.1+ds/_build/../test/Makefile.classic:52: recipe 
for target 'test-/5x5PF.diff' failed

I don't know what the diff turned out to read (or even whether it's
the same on all of these architectures!), but perhaps you can
reproduce the problem on a porter box.

Could you please take a look?

Thanks!

--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#881739: benchmark: FTBFS on hurd-i386: clock_gettime(CLOCK_THREAD_CPUTIME_ID, ...) failed

[Aaron M. Ucko]

Source: benchmark
Version: 1.3.0-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd-i386

The build of benchmark for hurd-i386 (admittedly not a release
architecture) failed per the below excerpt from
https://buildd.debian.org/status/fetch.php?pkg=benchmark=hurd-i386=1.3.0-1=1510615243=0:

  The following tests FAILED:
  1 - benchmark (Failed)
  2 - filter_simple (Failed)
  4 - filter_suffix (Failed)
  6 - filter_regex_all (Failed)
  8 - filter_regex_blank (Failed)
 12 - filter_regex_wildcard (Failed)
 14 - filter_regex_begin (Failed)
 16 - filter_regex_begin2 (Failed)
 18 - filter_regex_end (Failed)
 20 - options_benchmarks (Failed)
 21 - basic_benchmark (Failed)
 22 - diagnostics_test (Failed)
 23 - skip_with_error_test (Failed)
 25 - fixture_test (OTHER_FAULT)
 26 - register_benchmark_test (Failed)
 27 - map_test (Failed)
 28 - multiple_ranges_test (OTHER_FAULT)
 29 - reporter_output_test (Failed)
 30 - templated_fixture_test (Failed)
 31 - user_counters_test (Failed)
 32 - user_counters_tabular_test (Failed)
 33 - cxx03 (Failed)
 34 - complexity_benchmark (Failed)
  Errors while running CTest

In all, or at least most, cases, the failures stemmed from

  ERROR: clock_gettime(CLOCK_THREAD_CPUTIME_ID, ...) failed

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#881738: benchmark: FTBFS on kFreeBSD: tests report 0 ns elapsed

[Aaron M. Ucko]

Source: benchmark
Version: 1.3.0-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-...@lists.debian.org
Usertags: kfreebsd

Builds of benchmark for kfreebsd-* (admittedly not release
architectures) failed; the kfreebsd-amd64 log
https://buildd.debian.org/status/fetch.php?pkg=benchmark=kfreebsd-amd64=1.3.0-1=1510632713=0
reports

The following tests FAILED:
 29 - reporter_output_test (OTHER_FAULT)
 31 - user_counters_test (OTHER_FAULT)
 32 - user_counters_tabular_test (OTHER_FAULT)
Errors while running CTest

and the kfreebsd-i386 log
https://buildd.debian.org/status/fetch.php?pkg=benchmark=kfreebsd-i386=1.3.0-1=1510617549=0
reports

The following tests FAILED:
 29 - reporter_output_test (OTHER_FAULT)
 31 - user_counters_test (OTHER_FAULT)
Errors while running CTest

On both architectures, the failed tests are reporting 0 ns wall and
cpu time, making for infinite rates that rightly don't match the
expected patterns.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#881736: benchmark: FTBFS: You need to define CycleTimer for your OS and CPU

[Aaron M. Ucko]

Source: benchmark
Version: 1.3.0-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-s...@lists.debian.org
Usertags: s390x

Builds of benchmark for some architectures have failed with

  /<>/src/cycleclock.h:166:2: error: #error You need to define 
CycleTimer for your OS and CPU

So far, this error has shown up on s390x and the non-release
architectures hppa and sh4, and I anticipate encountering it on the
non-release architectures alpha and m68k as well.

I'm usertagging the relevant architectures in hopes that porters will
weigh in with recommendations, but see that cycleclock.h does also
supply a fallback implementation whose scope you can broaden as
needed.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#881678: primesieve: FTBFS: __atomic_fetch_add_8 undefined

[Aaron M. Ucko]

Source: primesieve
Version: 6.2+ds-1
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

Builds of primesieve for armel, mips, mipsel, and the non-release
architectures m68k, powerpc, powerpcspe, and sh4 have started failing:

  libprimesieve.so.8.2.0: undefined reference to `__atomic_fetch_add_8'
  collect2: error: ld returned 1 exit status

On these architectures, you should be able to find this symbol in
libatomic.  I'd suggest linking with -Wl,--as-needed -latomic
everywhere so that you don't have to special-case any platforms or get
formal dependencies on libatomic on the platforms that don't need it
here.

Could you please take a look?

Thanks!

--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#865671: scotch hides build failures

[Aaron M. Ucko]

Source: scotch
Version: 6.0.4.dfsg1-2
Followup-For: Bug #865671

Specifically, debian/rules contains several shell loops that run
without either set -e or explicit error handling.  As such, Hurd
builds running afoul of #881200 attempt to build all four variants of
the library, encounter compilation and upstream installation errors
for each of them, and don't actually fail until debian/rules tries to
rename gmap.1 to scotch_gmap.1 (presumably to avoid a file conflict).

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#881200: scotch: FTBFS on hurd-i386: storage size of 'tv' isn't known

[Aaron M. Ucko]

Source: scotch
Version: 6.0.4.dfsg1-2
Severity: important
Justification: fails to build from source (but built successfully in the past)
User: debian-h...@lists.debian.org
Usertags: hurd-i386

Builds of scotch for hurd-i386 (admittedly not a release architecture)
have started failing:

  common.c: In function '_SCOTCHclockGet':
  common.c:114:23: error: storage size of 'tv' isn't known
 struct timeval  tv;

AFAICT, this is because the Hurd does not yet support POSIX timers
and nothing predefines HAVE_SYS_TIME_H.

Could you please take a look and generally arrange to predefine any
applicable HAVE_* macros?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#880206: freeimage: FTBFS on hppa: testImageType.cpp:428: `bResult' failed.

[Aaron M. Ucko]

Source: freeimage
Version: 3.17.0+ds1-5
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-h...@lists.debian.org

Builds of freeimage for hppa (admittedly not a release architecture)
have been failing lately:

  testAPI: testImageType.cpp:428: void testImageType(unsigned int, unsigned 
int): Assertion `bResult' failed.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#880205: gmsh: FTBFS w/Java 1.5 (on hurd-i386)

[Aaron M. Ucko]

Source: gmsh
Version: 3.0.5+dfsg1-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org

The build of gmsh for hurd-i386 (admittedly not a release
architecture) has been failing.  The immediate cause of failure at
this point presumably relates to this architecture's continued use of
Java 1.5, since newer versions are unavailable there (or on hppa, also
a non-release architecture, on which gmsh's build dependencies are
currently impossible to satisfy at all due to a freeimage FTBFS I'll
report shortly).

At any rate, per
https://buildd.debian.org/status/fetch.php?pkg=gmsh=hurd-i386=3.0.5%2Bdfsg1-1=1509336181=0
the errors are

  
/<>/gmsh-3.0.5+dfsg1/wrappers/java/WrappingJava/src/main/java/org/geuz/gmsh/utils/NativeSet.java:147:
 error: The method hasNext() of type NativeSet.NativeSetIterator must 
override a superclass method
  
/<>/gmsh-3.0.5+dfsg1/wrappers/java/WrappingJava/src/main/java/org/geuz/gmsh/utils/NativeSet.java:157:
 error: The method next() of type NativeSet.NativeSetIterator must override 
a superclass method
  
/<>/gmsh-3.0.5+dfsg1/wrappers/java/WrappingJava/src/main/java/org/geuz/gmsh/utils/NativeSet.java:171:
 error: The method remove() of type NativeSet.NativeSetIterator must 
override a superclass method

If making this code compatible with Java 1.5 is infeasible, I suppose
one option might be to skip the Java build and corresponding binary
package here and on hppa, though the Architecture: field alas lacks
support for negative entries.  Another alternative could be to version
the default-jdk build dependency; if you go that route, please bear in
mind that it currently has an epoch of 2, so you'd want to specify
default-jdk (>= 2:1.8~).

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#880147: cvc4: FTBFS on sparc64: bus error => massive test suite failure

[Aaron M. Ucko]

Source: cvc4
Version: 1.5-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-sp...@lists.debian.org

The build of cvc4 for sparc64 (admittedly not a release architecture)
encountered even more test suite failures than other non-x86 builds,
as detailed at

https://buildd.debian.org/status/fetch.php?pkg=cvc4=sparc64=1.5-1=1509309061=0

Most if not all of these failures stemmed from bus errors, which
generally correspond to unaligned memory access attempts.

Could you please take a look?

Thanks!

FTR, the overall testing summary was

=== TESTING SUMMARY =
150 TOTAL, 6 PASS, 144 FAIL
/.../production/test/regress/regress0/test-suite.log
32 TOTAL, 32 FAIL
/.../production/test/regress/regress0/arith/test-suite.log
14 TOTAL, 14 FAIL
/.../production/test/regress/regress0/arith/integers/test-suite.log
32 TOTAL, 32 FAIL
/.../production/test/regress/regress0/arrays/test-suite.log
37 TOTAL, 37 FAIL
/.../production/test/regress/regress0/aufbv/test-suite.log
11 TOTAL, 11 FAIL
/.../production/test/regress/regress0/auflia/test-suite.log
86 TOTAL, 86 FAIL
/.../production/test/regress/regress0/bv/test-suite.log
65 TOTAL, 65 FAIL
/.../production/test/regress/regress0/bv/core/test-suite.log
62 TOTAL, 1 PASS, 61 FAIL
/.../production/test/regress/regress0/datatypes/test-suite.log
18 TOTAL, 18 FAIL
/.../production/test/regress/regress0/decision/test-suite.log
8 TOTAL, 8 FAIL
/.../production/test/regress/regress0/expect/test-suite.log
56 TOTAL, 56 FAIL
/.../production/test/regress/regress0/fmf/test-suite.log
4 TOTAL, 4 FAIL
/.../production/test/regress/regress0/lemmas/test-suite.log
29 TOTAL, 29 FAIL
/.../production/test/regress/regress0/nl/test-suite.log
4 TOTAL, 4 FAIL
/.../production/test/regress/regress0/parser/test-suite.log
18 TOTAL, 18 FAIL
/.../production/test/regress/regress0/precedence/test-suite.log
16 TOTAL, 16 FAIL
/.../production/test/regress/regress0/preprocess/test-suite.log
24 TOTAL, 24 FAIL
/.../production/test/regress/regress0/push-pop/test-suite.log
21 TOTAL, 21 FAIL
/.../production/test/regress/regress0/push-pop/arith/test-suite.log
51 TOTAL, 51 FAIL
/.../production/test/regress/regress0/push-pop/boolean/test-suite.log
74 TOTAL, 74 FAIL
/.../production/test/regress/regress0/quantifiers/test-suite.log
93 TOTAL, 93 FAIL
/.../production/test/regress/regress0/rels/test-suite.log
7 TOTAL, 7 FAIL
/.../production/test/regress/regress0/rewriterules/test-suite.log
39 TOTAL, 39 FAIL
/.../production/test/regress/regress0/sep/test-suite.log
68 TOTAL, 68 FAIL
/.../production/test/regress/regress0/sets/test-suite.log
70 TOTAL, 70 FAIL
/.../production/test/regress/regress0/strings/test-suite.log
33 TOTAL, 33 FAIL
/.../production/test/regress/regress0/sygus/test-suite.log
27 TOTAL, 27 FAIL
/.../production/test/regress/regress0/tptp/test-suite.log
33 TOTAL, 33 FAIL
/.../production/test/regress/regress0/uf/test-suite.log
20 TOTAL, 20 FAIL
/.../production/test/regress/regress0/uflia/test-suite.log
20 TOTAL, 20 FAIL
/.../production/test/regress/regress0/uflra/test-suite.log
47 TOTAL, 47 FAIL
/.../production/test/regress/regress0/unconstrained/test-suite.log
5 TOTAL, 2 PASS, 3 FAIL
/.../production/test/system/test-suite.log
4 TOTAL, 4 PASSin unit
=== TESTING SUMMARY =

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#880146: cvc4: FTBFS on non-x86: test suite errors

[Aaron M. Ucko]

Source: cvc4
Version: 1.5-1
Severity: important
Tags: upstream
Justification: fails to build from source

All non-x86 builds of cvc4 to date have failed with test suite errors,
as detailed at

https://buildd.debian.org/status/logs.php?pkg=cvc4=1.5-1

So far, these errors have occurred on arm64, ppc64el, s390x, and the
non-release architectures powerpc, ppc64, and sparc64.  On almost all
of these architectures, the testing summary took the form

  === TESTING SUMMARY =
  150 TOTAL, 136 PASS, 14 FAIL
  /.../production/test/regress/regress0/test-suite.log
  32 TOTAL, 32 PASS  in regress/regress0/arith
  14 TOTAL, 14 PASS  in regress/regress0/arith/integers
  32 TOTAL, 12 PASS, 20 FAIL
  /.../production/test/regress/regress0/arrays/test-suite.log
  37 TOTAL, 31 PASS, 6 FAIL
  /.../production/test/regress/regress0/aufbv/test-suite.log
  11 TOTAL, 11 PASS  in regress/regress0/auflia
  86 TOTAL, 60 PASS, 26 FAIL
  /.../production/test/regress/regress0/bv/test-suite.log
  65 TOTAL, 4 PASS, 61 FAIL
  /.../production/test/regress/regress0/bv/core/test-suite.log
  62 TOTAL, 62 PASS  in regress/regress0/datatypes
  18 TOTAL, 12 PASS, 6 FAIL
  /.../production/test/regress/regress0/decision/test-suite.log
  [long run of fully successful tests elided]
  33 TOTAL, 9 PASS, 24 FAIL
  /.../production/test/regress/regress0/uf/test-suite.log
  [shorter run of fully successful tests elided]
  === TESTING SUMMARY =

The one exception was sparc64, which encountered many more errors;
I'll report a separate bug for that architecture.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#878830: opencv: FTBFS w/tbb 4.x: has_trivial_copy_constructor missing

[Aaron M. Ucko]

Mattia Rizzolo <mat...@debian.org> writes:

> Well, it didn't reach the point it failed before…

Good point; I'd noticed that the error had changed, but didn't properly
register why. :-)  Looks good now, thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#878830: opencv: FTBFS w/tbb 4.x: has_trivial_copy_constructor missing

[Aaron M. Ucko]

Source: opencv
Version: 3.2.0+dfsg-2
Severity: important
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org

Thanks again for looking into #878705.  Builds for x32 now do slightly
better, but still fail:

  /usr/include/tbb/pipeline.h:328:74: error: 'has_trivial_copy_constructor' is 
not a member of 'std'

Per https://github.com/01org/tbb/issues/12, this error stems from
tbb's historic use of a non-standard GCC extension that went away in
GCC 7.  However, updated tbb packages FTBFS on x32 and a couple of
other non-release architectures, so only old, broken versions are
available there.  Please version the build dependency on libtbb-dev to
(>= 2017~) to avoid bothering to try building against these old
versions.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#878705: opencv: FTBFS on x32: sysctl(.h) unsupported

[Aaron M. Ucko]

Mattia Rizzolo <mat...@debian.org> writes:

> Hi Aaron,

Hi, Mattia.

Thanks for the quick response!  I can't readily test a fix[1], but
suspect the problem is the second half of

> #elif defined __APPLE__ || !defined __GNU__

which results in trying to #include  on a wide range of
architectures.  (Only the Hurd predefines __GNU__.)  Seeing as cmake
detects that  is unusable on x32, I'd suggest merging and
simplifying the second and third branches to something along the lines of

#if defined __linux__ || defined __APPLE__ ||  defined __GLIBC__
#include 
#include 
#include 
#if defined __ANDROID__
#include 
#elif defined HAVE_SYS_SYSCTL_H
#include 
#endif
#endif

[1] I'm not a porter or buildd maintainer, just a regular DD who cares
about portability and checks buildd logs from anything building
binary packages newly showing up on amd64 and/or i386.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#878705: opencv: FTBFS on x32: sysctl(.h) unsupported

[Aaron M. Ucko]

Source: opencv
Version: 2.4.9.1+dfsg1-2
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org

Builds of opencv for x32 (admittedly not a release architecture) have
been failing lately:

  In file included from /usr/include/x86_64-linux-gnux32/sys/sysctl.h:63:0,
   from 
/<>/opencv-3.2.0+dfsg/modules/core/src/parallel.cpp:60:
  /usr/include/x86_64-linux-gnux32/bits/sysctl.h:19:3: error: #error "sysctl 
system call is unsupported in x32 kernel"

Per sysctl(2), this interface is generally deprecated, so my
recommendation would be to steer clear of it on any Linux
architecture.  Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#878349: gpyfft: FTBFS on non-Linux: CLFFT_INCL_DIRS is not defined

[Aaron M. Ucko]

Source: gpyfft
Version: 0.7.0-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-...@lists.debian.org

Builds of gpyfft for kFreeBSD (admittedly not a release architecture)
have been failing:

  Traceback (most recent call last):
File "setup.py", line 39, in 
  include_dirs= CLFFT_INCL_DIRS + CL_INCL_DIRS,
  NameError: name 'CLFFT_INCL_DIRS' is not defined

I expect builds for the Hurd (not a release architecture either) would
fail in the same fashion if python-opencl were to become available
there.  (From what I gather, it's waiting for an OpenCL ICD.)

In general, I see that setup.py features hardcoded path settings that
are specific to the upstream developer's systems and has no provision
for operating systems other than Linux, Windows, and macOS.  Until
upstream removes these settings, I would encourage explicitly
resetting them on all platforms.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#876747: ros-ros-comm: FTBFS on kFreeBSD: TCP_KEEP* undeclared

[Aaron M. Ucko]

Source: ros-ros-comm
Version: 1.13.2+ds1-2
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-...@lists.debian.org

Builds of ros-ros-comm for kfreebsd-* (admittedly not release
architectures) have been failing:

  
/«BUILDDIR»/ros-ros-comm-1.13.2+ds1/clients/roscpp/src/libros/transport/transport_tcp.cpp:184:36:
 error: 'TCP_KEEPIDLE' was not declared in this scope
  
/«BUILDDIR»/ros-ros-comm-1.13.2+ds1/clients/roscpp/src/libros/transport/transport_tcp.cpp:190:36:
 error: 'TCP_KEEPINTVL' was not declared in this scope
  
/«BUILDDIR»/ros-ros-comm-1.13.2+ds1/clients/roscpp/src/libros/transport/transport_tcp.cpp:196:36:
 error: 'TCP_KEEPCNT' was not declared in this scope

I suspect builds for hurd-i386 will fail in the same way if and when
somebody helps them past #876745.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#876745: ros-ros-comm: FTBFS on hurd-i386: Unable to generate messages for package 'roscpp'

[Aaron M. Ucko]

Source: ros-ros-comm
Version: 1.13.2+ds1-2
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org

Builds of ros-ros-comm for hurd-i386 (admittedly not a release
architecture) have been failing:

  cd /<>/ros-ros-comm-1.13.2+ds1/obj-i686-gnu/clients/roscpp && 
../../catkin_generated/env_cached.sh /usr/bin/python 
/usr/lib/genpy/genmsg_py.py 
/<>/ros-ros-comm-1.13.2+ds1/clients/roscpp/msg/Logger.msg 
-Iroscpp:/<>/ros-ros-comm-1.13.2+ds1/clients/roscpp/msg -p roscpp -o 
/<>/ros-ros-comm-1.13.2+ds1/obj-i686-gnu/devel/lib/python2.7/dist-packages/roscpp/msg
  Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/genpy/generator.py", line 985, in 
generate_messages
  outfile = self.generate(msg_context, full_type, f, outdir, search_path) 
#actual generation
File "/usr/lib/python2.7/dist-packages/genpy/generator.py", line 958, in 
generate
  os.makedirs(outdir)
File "/usr/lib/python2.7/os.py", line 157, in makedirs
  mkdir(name, mode)
  OSError: [Errno 1073741841] File exists: 
'/<>/ros-ros-comm-1.13.2+ds1/obj-i686-gnu/devel/lib/python2.7/dist-packages/roscpp/msg'
  
  ERROR: Unable to generate messages for package 'roscpp': while processing 
'/<>/ros-ros-comm-1.13.2+ds1/clients/roscpp/msg/Logger.msg': [Errno 
1073741841] File exists: 
'/<>/ros-ros-comm-1.13.2+ds1/obj-i686-gnu/devel/lib/python2.7/dist-packages/roscpp/msg'

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#876485: plplot: FTBFS on mipsel: ocaml tests misbehave

[Aaron M. Ucko]

Source: plplot
Version: 5.13.0+dfsg-1
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-m...@lists.debian.org

The mipsel build of plplot 5.13 failed because one ocaml test crashed
and another encountered a (generous) timeout, presumably due to
hanging or spinning.  I don't have details beyond

https://buildd.debian.org/status/fetch.php?pkg=plplot=mipsel=5.13.0%2Bdfsg-1=1506091509=0

but perhaps you can reproduce this misbehavior on a porter box.  Could
you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#876288: python3-fabio-dbg should depend on python3-pyqt4-dbg

[Aaron M. Ucko]

Package: python3-fabio-dbg
Version: 0.5.0+dfsg-1
Severity: serious
Justification: Policy 7.2
Control: affects -1 src:silx

python3-fabio-dbg depends on python-qt4-dbg rather than python3-pyqt4-dbg.
As such, builds of silx in minimal environments (as on the autobuilders)
have been failing because it build depends on Qt4 bindings only via fabio:

File 
"/<>/silx-0.5.0+dfsg/.pybuild/pythonX.Y-dbg_3.6/build/silx/gui/qt/_qt.py",
 line 110, in 
  from PyQt4.QtCore import *  # noqa
  ModuleNotFoundError: No module named 'PyQt4.QtCore'

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#875465: sagemath: FTBFS on arm64: partitions doctests fail

[Aaron M. Ucko]

Source: sagemath
Version: 8.0-7
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

The latest arm64 build of sagemath encountered errors in two
sage.combinat.partitions.* doctests, as detailed at
https://buildd.debian.org/status/fetch.php?pkg=sagemath=arm64=8.0-7=1505101830=0

  2 items had failures:
10 of  26 in sage.combinat.partitions.number_of_partitions
 1 of   3 in sage.combinat.partitions.run_tests
  [35 tests, 11 failures, 8.05 s]

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#875331: r-cran-dotcall64: FTBFS on hurd-i386: PATH_MAX undeclared

[Aaron M. Ucko]

Source: r-cran-dotcall64
Version: 0.9.04-1
Severity: important
Tags: upstream
Justification: fails to build from source

The build of r-cran-dotcall64 for hurd-i386 (admittedly not a release
architecture) failed:

  dotCall64.c:88:19: error: 'PATH_MAX' undeclared (first use in this function); 
did you mean 'INT8_MAX'?

The Hurd has no hard PATH_MAX.  Best practice is to substitute
pathconf(_PC_PATH_MAX), which can in turn entail allocating more
buffers dynamically.  Alternatively, you can supply a fallback
constant definition, typically 4096.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#873677: wslay: FTBFS on kFreeBSD: epoll is required

[Aaron M. Ucko]

Source: wslay
Version: 1.0.1~39-g6abacc1-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of wslay for kFreeBSD and the Hurd (admittedly not release
architectures) have been failing:

  -- Looking for include file sys/epoll.h
  -- Looking for include file sys/epoll.h - not found
  CMake Error at examples/CMakeLists.txt:6 (message):
epoll is required

Please either allow wslay to fall back to traditional poll or restrict
its Architecture field to linux-any so that autobuilders for other
architectures don't bother trying to build it.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#868992: python-ltfatpy: FTBFS on hurd-i386: No module named 'matplotlib._path'

[Aaron M. Ucko]

Source: python-ltfatpy
Version: 1.0.9-1
Severity: important
Justification: fails to build from source

Thanks for taking care of #861094.  Alas, the build of python-ltfatpy
on hurd-i386 (admittedly not a release architecture) is still failing:

  E   ModuleNotFoundError: No module named 'matplotlib._path'

I see that hurd-i386 still just has matplotlib 1.5.x, whereas the
other architectures have 2.x; please version the build dependencies on
python(3)-matplotlib accordingly.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#868991: libgpuarray: FTBFS with cython 0.23

[Aaron M. Ucko]

Source: libgpuarray
Version: 0.6.8-1
Severity: important
Justification: fails to build from source

Builds of libgpuarray for the non-release architectures hurd-i386 and
x32 (on both of which cython 0.23.x is the latest available version):

  Exception: cython is too old or not installed (at least 0.25 required)

Please version the build dependency on cython accordingly.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#861095: python-ltfatpy: FTBFS: ValueError: Little-endian buffer not supported

[Aaron M. Ucko]

Source: python-ltfatpy
Version: 1.0.8-1
Severity: important
Justification: fails to build from source

The builds of python-ltfatpy for s390x and the non-release
architectures ppc64 and sparc64 failed with

E   ValueError: Little-endian buffer not supported on big-endian compiler

You can find the full s390x log at

https://buildd.debian.org/status/fetch.php?pkg=python-ltfatpy=s390x=1.0.8-1=1492853102=0#

The builds for the big-endian non-release architectures m68k and
powerpcspe both nominally succeeded, but AFAICT only because they
skipped the test suite altogether for some reason.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#861094: python-ltfatpy: FTBFS (32-bit): TypeError: dim should be an integer

[Aaron M. Ucko]

Source: python-ltfatpy
Version: 1.0.8-1
Severity: important
Justification: fails to build from source

Builds of python-ltfatpy for 32-bit architectures such as i386 failed
because most (all?) tests didn't care for dim's type:

if (not isinstance(dim, six.integer_types) and
   not isinstance(dim, np.int_)):
>   raise TypeError("dim should be an integer.")
E   TypeError: dim should be an integer.

You can find the full i386 log at
https://buildd.debian.org/status/fetch.php?pkg=python-ltfatpy=i386=1.0.8-1=1492853191=0

The builds for the 32-bit non-release architectures m68k and
powerpcspe both nominally succeeded, but AFAICT only because they
skipped the test suite altogether for some reason.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#861091: python-ltfatpy: FTBFS: TestInstfreqplot AssertionError

[Aaron M. Ucko]

Source: python-ltfatpy
Version: 1.0.8-1
Severity: important
Justification: fails to build from source

The builds of python-ltfatpy for arm64, mips64el, and ppc64el all
failed with assertion errors in TestInstfreqplot, as detailed in

https://buildd.debian.org/status/fetch.php?pkg=python-ltfatpy=arm64=1.0.8-1=1492853219=0
https://buildd.debian.org/status/fetch.php?pkg=python-ltfatpy=mips64el=1.0.8-1=1492855642=0
https://buildd.debian.org/status/fetch.php?pkg=python-ltfatpy=ppc64el=1.0.8-1=1492853314=0

On arm64, I see

>   assert_allclose(out, outputs[0], rtol=2e-15, err_msg=msg)
E   AssertionError:
E   Not equal to tolerance rtol=2e-15, atol=0
E   Wrong value in output of instfreqplot with inputs {'method': 'dgt', 
'display': False, 'f': array([ 0.20742711,  0.60920036,  0.07727744,  
0.49253249,  0.25168163,
E   0.24451649,  0.15068151,  0.8799212 ,  0.4495264 ,  
0.57848901,
E   0.47870028,  0.87543732,  0.42257947])}
E   (mismatch 3.296703296703299%)

The mips64el and ppc64el builds encountered worse mismatches, roughly
4.4% and 7.7% respectively.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#855081: giac: FTBFS on kfreebsd-i386: Illegal instruction

[Aaron M. Ucko]

Source: giac
Version: 1.2.3.25+dfsg1-1
Severity: important
Justification: fails to build from source

On kfreebsd-i386 (admittedly not a release architecture), giac's
chk_cas and chk_fhan tests both failed with "Illegal instruction," as
detailed at
https://buildd.debian.org/status/fetch.php?pkg=giac=kfreebsd-i386=1.2.3.25%2Bdfsg1-1=1486951903=0

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#855080: giac: FTBFS on hurd-i386: Too many recursion levels Error: Bad Argument Value

[Aaron M. Ucko]

Source: giac
Version: 1.2.3.25+dfsg1-1
Severity: important
Justification: fails to build from source

The build of giac for hurd-i386 (admittedly not a release
architecture) failed with many errors along the lines of

Unable to eval 1/(x^4-1)^10: Too many recursion levels Error: Bad Argument Value

as detailed at
https://buildd.debian.org/status/fetch.php?pkg=giac=hurd-i386=1.2.3.25%2Bdfsg1-1=1486947346=0

(affecting every top-level test, and what appears to be nearly all
individual cases).

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#855078: giac: FTBFS: [algo.pdf] Error 139 (Segmentation fault)

[Aaron M. Ucko]

Source: giac
Version: 1.2.3.25+dfsg1-1
Severity: important
Justification: fails to build from source

On several architectures, icas failed with a segmentation fault while
attempting to produce doc/fr/algo.pdf -- e.g., on arm64,

  xvfb-run ../../src/icas "algo.tex"
  ./algo.tex:4: Warning: Command not found: \textheight
  /usr/share/hevea/hyperref.hva:65: Warning: Ignoring option: 'pdftex'
  /usr/share/hevea/hyperref.hva:65: Warning: Ignoring option: 'colorlinks'
  ./algo.tex:33: Warning: Application of '\~' on 'p' failed
  Exclude comment 'comment'
  // Using locale /usr/share/locale/
  // C
  // /usr/share/locale/
  // giac
  // UTF-8
  // Maximum number of parallel threads 3
  // Unable to find keyword file doc/en/keywords
  Help file doc/en/aide_cas not found
  Added 0 synonyms
  Giac pdflatex and HTML5 output
  Partly inspired from pgiac by Jean-Michel Sarlat
  Segmentation fault
  Makefile:648: recipe for target 'algo.pdf' failed
  make[4]: *** [algo.pdf] Error 139
  make[4]: *** Waiting for unfinished jobs

I see this (general) failure mode on arm64, mips, mips64el, ppc64el,
s390x, and the non-release architectures alpha, hppa, m68k, powerpc,
ppc64, sparc64, and x32.

Could you please take a look?

Thanks!

NB: some of the above output may be from hevea, which ran in parallel
with icas.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#855076: giac: FTBFS: .../giac-doc/...: No such file or directory

[Aaron M. Ucko]

Source: giac
Version: 1.2.3.25+dfsg1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of giac covering only its architecture-dependent binary
packages have been failing:

  find debian/giac-doc/usr/share/giac/examples/ \
\( -name '*.cas' -o -name '*.xws' -o -name '*.cxx' \) -exec chmod -x '{}' \;
  find: 'debian/giac-doc/usr/share/giac/examples/': No such file or directory
  debian/rules:26: recipe for target 'override_dh_fixperms' failed
  make[1]: *** [override_dh_fixperms] Error 1
  make[1]: Leaving directory '/«BUILDDIR»/giac-1.2.3.25+dfsg1'
  debian/rules:7: recipe for target 'binary-arch' failed
  make: *** [binary-arch] Error 2

(On some architectures, the build fails earlier, due to unrelated
issues I'll report separately.)

Please conditionalize the debian/rules commands that work with
giac-doc appropriately, for instance by renaming override_dh_fixperms
to override_dh_fixperms-indep.

Thanks!

FTR, even though giac is new to Debian, I'm classifying this bug as a
regression because it would affect potential binNMUs.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848634: python-cartopy: FTBFS on *i386: test_lambert_azimuthal_equal_area fails

[Aaron M. Ucko]

Ghislain Vaillant <ghisv...@gmail.com> writes:

> So, you think it would help to request src:proj to be build with 
> -ffloat-store then?

Yes; testing in a personal chroot confirms that adjusting its build
settings is both necessary and sufficient.  (I don't recommend turning
this flag on blindly.)

diff --git a/debian/rules b/debian/rules
index ad58979..ab7da14 100755
--- a/debian/rules
+++ b/debian/rules
@@ -24,6 +24,11 @@ CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
 CFLAGS += -g
 endif
+
+ifneq (,$(filter i386-%,$(DEB_HOST_MULTIARCH)))
+CFLAGS += -ffloat-store
+endif
+
 # `nostrip' handled by dh_strip...

 CFLAGS += -I$(JAVA_HOME)/include/linux

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848634: python-cartopy: FTBFS on *i386: test_lambert_azimuthal_equal_area fails

[Aaron M. Ucko]

Ghislain Vaillant <ghisv...@gmail.com> writes:

> I tried your suggestion out but it did not work on a test build in
> debomatic. The same errors are reported at the test stage.

I'm sorry to hear that.  In that case, the calculations affected by the
lack of -ffloat-store are presumably taking place in some underlying
library; I particularly suspect proj4.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#849150: sagemath: FTBFS on arm64 and ppc64el: cannot allocate memory building docs

[Aaron M. Ucko]

Ximin Luo <infini...@debian.org> writes:

> The error occurs right when the docbuild starts, before it actually
> attempts to build anything, so my guess is that it would also occur
> when starting the normal Sage CLI. So I don't think we should skip the
> docbuild and release the build products as-is.

Thanks for clarifying.  You might want to consider conditionalizing the
docbuild anyway to save build time and disk space, since crashing at
startup would presumably also break the test suite.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#849152: sagemath: FTBFS on i386: many tests fail

[Aaron M. Ucko]

Source: sagemath
Version: 7.4-3
Severity: important
Justification: fails to build from source

The i386 build of sagemath failed with many test suite errors
(including some outright crashes), as detailed at

https://buildd.debian.org/status/fetch.php?pkg=sagemath=i386=7.4-3=1482425583

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#849150: sagemath: FTBFS on arm64 and ppc64el: cannot allocate memory building docs

[Aaron M. Ucko]

Source: sagemath
Version: 7.4-3
Severity: important
Justification: fails to build from source

The automatic builds of sagemath for arm64 and ppc64el both ran out of
memory when trying to build documentation:

  [dochtml] ImportError: /usr/lib/«ARCH»/libgomp.so.1: cannot allocate memory 
in static TLS block
  Makefile:1059: recipe for target 'doc-html' failed
  make[4]: *** [doc-html] Error 1

Could you please take a look?  Since this documentation presumably
winds up in an architecture-independent binary package, perhaps you
can arrange for binary-only builds to skip building it.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848634: python-cartopy: FTBFS on *i386: test_lambert_azimuthal_equal_area fails

[Aaron M. Ucko]

Source: python-cartopy
Version: 0.14.2+dfsg1-1
Severity: important
Justification: fails to build from source

The builds of python-cartopy on i386 and the non-release architecture
hurd-i386 both failed, per the below output.  I expect the kfreebsd-i386
build will fail the same way in due course.  Could you please take a
look?  Compiling native code with -ffloat-store might help.

Thanks!

  ==
  FAIL: test_default 
(cartopy.tests.crs.test_lambert_azimuthal_equal_area.TestLambertAzimuthalEqualArea)
  --
  Traceback (most recent call last):
File 
"/«BUILDDIR»/python-cartopy-0.14.2+dfsg1/.pybuild/pythonX.Y_2.7/build/cartopy/tests/crs/test_lambert_azimuthal_equal_area.py",
 line 41, in test_default
  decimal=4)
File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 523, 
in assert_almost_equal
  return assert_array_almost_equal(actual, desired, decimal, err_msg)
File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 918, 
in assert_array_almost_equal
  precision=decimal)
File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 739, 
in assert_array_compare
  raise AssertionError(msg)
  AssertionError: 
  Arrays are not almost equal to 4 decimals
  
  (mismatch 100.0%)
   x: array([-12727770.6158,  12727770.6158])
   y: array([-12727770.5987,  12727770.5987])
  
  --
  Ran 70 tests in 0.066s
  
  FAILED (SKIP=1, failures=1)

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#835406: trilinos: FTBFS on 32-bit architectures

[Aaron M. Ucko]

Graham Inggs <gin...@debian.org> writes:

> // Have assumed a 64bit build (8byte pointers) throughout the code base.

That's annoying, though at least they clearly acknowledge it up front.

> Amesos2, Ifpack2, Phalanx, Stokhos, Teko, Tpetra and Zoltan2 packages
> which depend on Kokkos.  Nico felt that half of a Trilinos package on
> 32-bit architectures would not be useful.

Fair enough, particularly given that the only reverse dependency I see
is deal.ii, which relies on several indirectly affected packages.

Thanks for looking into the problem!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#843670: libgtkdatabox: Needs to be updated to use multiarch paths

[Aaron M. Ucko]

Source: libgtkdatabox
Version: 1:0.9.3.0+dfsg-1
Followup-For: Bug #843670

As the latest upload demonstrated, (automatic) builds against current
unstable are now failing:

  dh_install -plibgtkdatabox-0.9.3-0-glade 
usr/share/glade/catalogs/gtkdatabox.xml
   install -d 
debian/libgtkdatabox-0.9.3-0-glade//usr/share/glade/catalogs
   cp --reflink=auto -a 
debian/tmp/usr/share/glade/catalogs/gtkdatabox.xml 
debian/libgtkdatabox-0.9.3-0-glade//usr/share/glade/catalogs/
  dh_install -plibgtkdatabox-0.9.3-0-glade 
usr/lib/glade/modules/libgladedatabox.*
  dh_install: Cannot find (any matches for) 
"usr/lib/glade/modules/libgladedatabox.*" (tried in "." and "debian/tmp")
  dh_install: libgtkdatabox-0.9.3-0-glade missing files: 
usr/lib/glade/modules/libgladedatabox.*
  dh_install: missing files, aborting

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#843083: brial: FTBFS: hash discrepancies in UnitTests

[Aaron M. Ucko]

Source: brial
Version: 0.8.5-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Automated builds of brial have been failing with test suite
discrepancies, as detailed at

https://buildd.debian.org/status/logs.php?pkg=brial=0.8.5-1

The observed hash values still appear to vary only by word size, but
are different from what the tests expect.  Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#840462: openfoam: FTBFS on m68k: mpi.h: No such file or directory

[Aaron M. Ucko]

Source: openfoam
Version: 4.0+dfsg1-3
Severity: important
Justification: fails to build from source

The m68k build of openfoam failed:

  PstreamGlobals.H:41:17: fatal error: mpi.h: No such file or directory
   #include 

The issue appears to be that debian/rules assumes that mpi-defaults-dev
yields OpenMPI; although that's thankfully valid for all release
architectures nowadays, the non-release architectures m68k and sh4 both
still use MPICH.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#840461: openfoam: FTBFS (32-bit): ambiguous overload for 'operator<<'

[Aaron M. Ucko]

Source: openfoam
Version: 4.0+dfsg1-3
Severity: important
Justification: fails to build from source

Builds of openfoam for 32-bit architectures have been failing:

  db/dictionary/functionEntries/codeStream/codeStream.C: In static member 
function 'static void (* Foam::functionEntries::codeStream::getFunction(const 
Foam::dictionary&, const Foam::dictionary&))(Foam::Ostream&, const 
Foam::dictionary&)':
  db/dictionary/functionEntries/codeStream/codeStream.C:200:44: error: 
ambiguous overload for 'operator<<' (operand types are 'Foam::Ostream' and 
'off_t {aka long int}')

The problem is that, on these architectures, off_t is formally long
whereas int32_t (for which an operator<< variant exists) is formally
int; although the types are de facto equivalent on these
architectures, C++ insists on treating them as distinct.

I would suggest adding explicit long and unsigned long variants on
these architectures (but not 64-bit architectures, on which they'll
duplicate the existing [u]int64_t variants.)

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#840458: linbox: FTBFS on i386: illegal instruction in test-{cra, charpoly}

[Aaron M. Ucko]

Source: linbox
Version: 1.4.2-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

The i386 build of linbox failed:

  ../build-aux/test-driver: line 107: 16085 Illegal instruction "$@" > 
$log_file 2>&1
  FAIL: test-cra
  [...]
  ../build-aux/test-driver: line 107: 16135 Illegal instruction "$@" > 
$log_file 2>&1
  FAIL: test-charpoly

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#840457: linbox: FTBFS w/fflas-ffpack 1.x: No package 'fflas-ffpack' found

[Aaron M. Ucko]

Source: linbox
Version: 1.4.2-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of linbox on architectures that still have fflas-ffpack 1.6.0-1
due to #840454 have been failing:

  checking pkg-config is at least version 0.9.0... yes
  checking for FFLAS_FFPACK... no
  configure: error: Package requirements (fflas-ffpack) were not met:
  
  No package 'fflas-ffpack' found
  
  Consider adjusting the PKG_CONFIG_PATH environment variable if you
  installed software in a non-standard prefix.

Please version the build dependency on fflas-ffpack to ensure you get
a version that ships fflas-ffpack.pc.  (Alternatively, if the 1.6.0
API is sufficient for your purposes, you could explicitly set
FFLAS_FFPACK_{CFLAGS,LIBS}.)

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#840455: fflas-ffpack: FTBFS on sparc64: test-pluq-check uncaught FailureTrsmCheck

[Aaron M. Ucko]

Source: fflas-ffpack
Version: 2.2.2-2
Severity: important
Justification: fails to build from source (but built successfully in the past)

The latest fflas-ffpack build for the non-release architecture sparc64
encountered one architecture-specific error in addition to the
multi-architecture Modular errors I just reported as #840454:

  FAIL: test-pluq-check
  =
  
  terminate called after throwing an instance of 'FailureTrsmCheck'
  FAIL test-pluq-check (exit status: 134)

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#836130: trilinos: FTBFS without __sync_val_compare_and_swap_8

[Aaron M. Ucko]

Graham Inggs <gin...@debian.org> writes:

> I'm dropping this bug's severity to wishlist as Trilinos last built on
> 32-bit architectures in 2010 [1], before the Kokkos package was
> introduced.  These binaries are not in testing and therefore should
> not prevent Trilinos from migrating.

So I see.  It looks like the only outstanding regression is on alpha,
which is a non-release, 64-bit architecture, and moreover hit a cp
segfault(!) rather than anything that could plausibly be interpreted as
a Trilinos portability bug.

> We have opened a PR [3] with upstream, in the hopes that we can work
> together on a solution.

Great; thanks for all your work here.

> PS: If you are happy with the outcome of #815725, please close it.

Done earlier today.  In retrospect, that really should have been two
separate reports.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#836413: opengm: FTBFS on powerpc: test-io-hdf5 data types not equal

[Aaron M. Ucko]

Source: opengm
Version: 2.3.6+20160901-1
Severity: important
Justification: fails to build from source

opengm now compiles on powerpc (thanks!), but hits a test suite error:

  23/49 Test #24: test-io-hdf5 .***Exception: Other  0.11 
sec
  terminate called after throwing an instance of 'std::runtime_error'
what():  Data types not equal error.

FWIW, sparc64 hit the same error in 2.3.6+20160814-1.  (As of this
report, builds of 2.3.6+20160901-1 for sparc64 and most other
architectures are still in progress.)

Could you please take a look?

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#836216: opengm: FTBFS (32-bit): SelfFusion/LazyFlipper type mismatch

[Aaron M. Ucko]

Source: opengm
Version: 2.3.6+20160131-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Thanks for taking care of #806379!

opengm is now in good shape on 64-bit architectures (apart from one
test failure on sparc64, which isn't a release architecture), but
32-bit builds are hitting compilation errors (heavily excerpted below).

AFAICT, these errors stem from the fact that the intended
LazyFlipper<...>::Parameter constructor requires a size_t

https://anonscm.debian.org/cgit/debian-science/packages/opengm.git/tree/include/opengm/inference/lazyflipper.hxx#n156

but CSelfFusion<...>::Parameter::maxSubgraphSize_ has type UInt64Type

https://anonscm.debian.org/cgit/debian-science/packages/opengm.git/tree/include/opengm/inference/self_fusion.hxx#n356

and these types are equivalent only on 64-bit architectures.

Could you please take a look?

Thanks!

---

  In file included from 
/«BUILDDIR»/opengm-2.3.6+20160814/src/interfaces/commandline/double/../../common/caller/lazyflipper_caller.hxx:5:0,
   from 
/«BUILDDIR»/opengm-2.3.6+20160814/src/interfaces/commandline/double/opengm_min_sum.cxx:22:
  /«BUILDDIR»/opengm-2.3.6+20160814/include/opengm/inference/lazyflipper.hxx: 
In instantiation of 'opengm::LazyFlipper::Parameter::Parameter(const 
P&)
   [with P = long long unsigned int;
 GM = opengm::GraphicalModel, opengm::SimpleDiscreteSpace >;
 ACC = opengm::Minimizer]':
  
/«BUILDDIR»/opengm-2.3.6+20160814/include/opengm/inference/self_fusion.hxx:150:53:
   required from 'size_t opengm::FusionVisitor::fuseVisit(INF&)
   [with INF = opengm::MessagePassing, 
opengm::Minimizer, opengm::BeliefPropagationUpdateRules<...>, 
opengm::MaxDistance>;
 SELF_FUSION = opengm::SelfFusion >;
 SELF_FUSION_VISITOR = 
opengm::visitors::TimingVisitor 
> >;
 size_t = unsigned int]'
  
/«BUILDDIR»/opengm-2.3.6+20160814/include/opengm/inference/self_fusion.hxx:99:35:
   required from 'size_t opengm::FusionVisitor::operator()(INF&)
   [with INF = opengm::MessagePassing<...>;
 SELF_FUSION = opengm::SelfFusion >;
 SELF_FUSION_VISITOR = 
opengm::visitors::TimingVisitor 
> >;
 size_t = unsigned int]'
  
/«BUILDDIR»/opengm-2.3.6+20160814/include/opengm/inference/messagepassing/messagepassing.hxx:384:17:
   required from 'void opengm::MessagePassing::inferAcyclic(VisitorType&)
   [with VisitorType = opengm::FusionVisitor, 
opengm::SelfFusion<...>, opengm::visitors::TimingVisitor<...> >;
 GM = opengm::GraphicalModel, opengm::DiscreteSpace<> >;
 ACC = opengm::Minimizer;
 UPDATE_RULES = 
opengm::BeliefPropagationUpdateRules, opengm::DiscreteSpace<> >, 
opengm::Minimizer, opengm::MessageBuffer > >;
 DIST = opengm::MaxDistance]'
  
/«BUILDDIR»/opengm-2.3.6+20160814/include/opengm/inference/messagepassing/messagepassing.hxx:259:19:
   required from 'opengm::InferenceTermination opengm::MessagePassing::infer(VisitorType&)
   [with VisitorType = opengm::FusionVisitor, 
opengm::SelfFusion >, 
opengm::visitors::TimingVisitor<...> >;
 GM = opengm::GraphicalModel, opengm::DiscreteSpace<> >;
 ACC = opengm::Minimizer;
 UPDATE_RULES = 
opengm::BeliefPropagationUpdateRules, 
opengm::Minimizer, opengm::MessageBuffer<...> >;
 DIST = opengm::MaxDistance]'
  
/«BUILDDIR»/opengm-2.3.6+20160814/include/opengm/inference/self_fusion.hxx:470:4:
   required from 'opengm::InferenceTermination 
opengm::SelfFusion::infer(VisitorType&)
   [with VisitorType = 
opengm::visitors::TimingVisitor 
> >;
 INFERENCE = opengm::MessagePassing, 
opengm::Minimizer, opengm::BeliefPropagationUpdateRules<...>, 
opengm::MaxDistance>]'
  
/«BUILDDIR»/opengm-2.3.6+20160814/src/interfaces/commandline/double/../../common/caller/inference_caller_base.hxx:185:40:
   required from 'void opengm::interface::InferenceCallerBase::infer(GM&, opengm::interface::InferenceCallerBase::OutputBase&, bool, const PARAMETER&) const
   [with INF = opengm::SelfFusion >;
 VISITOR = 

Bug#836130: trilinos: FTBFS on non-x86 32-bit architectures

[Aaron M. Ucko]

Source: trilinos
Version: 12.6.4-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Thanks for looking into #835406!  trilinos now successfully builds on
i386 and x32, and the builds for other 32-bit architectures don't fail
as quickly as they used to, but they nevertheless remain broken (at
least on mips, mipsel, and powerpc -- builds for other architectures
are still in progress):

  /usr/bin/mpicxx -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -std=c++11   -Wl,-z,relro -Wl,--as-needed 
CMakeFiles/Amesos2_klu2_simple.dir/klu2_simple.cpp.o  -o 
Amesos2_klu2_simple.exe -rdynamic 
../../../../../tpetra/core/ext/libtrilinos_tpetraext.so.12.6.4 
../../../../../tpetra/core/inout/libtrilinos_tpetrainout.so.12.6.4 
../../../../../tpetra/core/src/libtrilinos_tpetra.so.12.6.4 
../../../../../tpetra/tsqr/src/libtrilinos_kokkostsqr.so.12.6.4 
../../../../../tpetra/kernels/src/libtrilinos_tpetrakernels.so.12.6.4 
../../../../../tpetra/classic/LinAlg/libtrilinos_tpetraclassiclinalg.so.12.6.4 
../../../../../tpetra/classic/NodeAPI/libtrilinos_tpetraclassicnodeapi.so.12.6.4
 ../../../../../tpetra/classic/src/libtrilinos_tpetraclassic.so.12.6.4 
../../../../../amesos/src/libtrilinos_amesos.so.12.6.4 
../../../../../kokkos/algorithms/src/libtrilinos_kokkosalgorithms.so.12.6.4 
../../../../../kokkos/containers/src/libtrilinos_kokkoscontainers.so.12.6.4 
../../../../../epetraext/src/libtrilinos_epetraext.so.12.6.4 
../../../../../triutils/src/libtrilinos_triutils.so.12.6.4 
/usr/lib/powerpc-linux-gnu/hdf5/openmpi/libhdf5.so -lz -lsmumps -ldmumps 
-lcmumps -lzmumps -lmumps_common -lpord -lmumps_common -lpord -ltbb 
../../../../../epetra/src/libtrilinos_epetra.so.12.6.4 
../../../../../teuchos/kokkoscomm/src/libtrilinos_teuchoskokkoscomm.so.12.6.4 
../../../../../teuchos/kokkoscompat/src/libtrilinos_teuchoskokkoscompat.so.12.6.4
 ../../../../../teuchos/remainder/src/libtrilinos_teuchosremainder.so.12.6.4 
../../../../../teuchos/numerics/src/libtrilinos_teuchosnumerics.so.12.6.4 
-llapack -lblas 
../../../../../teuchos/comm/src/libtrilinos_teuchoscomm.so.12.6.4 
../../../../../teuchos/parameterlist/src/libtrilinos_teuchosparameterlist.so.12.6.4
 ../../../../../teuchos/core/src/libtrilinos_teuchoscore.so.12.6.4 
../../../../../kokkos/core/src/libtrilinos_kokkoscore.so.12.6.4 
  ../../../../../kokkos/core/src/libtrilinos_kokkoscore.so.12.6.4: undefined 
reference to `__sync_val_compare_and_swap_8'
  collect2: error: ld returned 1 exit status
  
packages/amesos2/src/SuiteSparse/KLU2/Source/CMakeFiles/Amesos2_klu2_simple.dir/build.make:132:
 recipe for target 
'packages/amesos2/src/SuiteSparse/KLU2/Source/Amesos2_klu2_simple.exe' failed
  make[4]: *** 
[packages/amesos2/src/SuiteSparse/KLU2/Source/Amesos2_klu2_simple.exe] Error 1

Could you please take a look?

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#815725: trilinos: FTBFS on non-amd64

[Aaron M. Ucko]

notfixed 815725 12.6.3-4
found 815725 12.6.3-4
thanks

Graham Inggs <gin...@debian.org> writes:

>* Only enable Kokkos assembly functions on amd64 (Closes: #815725)

Alas, builds for 32-bit architectures such as i386 are still failing:

  
/«PKGBUILDDIR»/packages/kokkos/core/src/impl/Kokkos_Atomic_Generic.hpp:144:49: 
error: no matching function for call to 'atomic_compare_exchange(long long 
unsigned int*, long long unsigned int&, long long unsigned int&)'
  [...]
  
/«PKGBUILDDIR»/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp:143:3:
 error: invalid use of incomplete type 'struct Kokkos::Impl::enable_if<false, 
const long long unsigned int&>'
  [...]
  
/«PKGBUILDDIR»/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp:165:3:
 error: invalid use of incomplete type 'struct Kokkos::Impl::enable_if<false, 
const long long unsigned int&>'
  [...]
  
/«PKGBUILDDIR»/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp:207:3:
 error: invalid use of incomplete type 'struct Kokkos::Impl::enable_if<false, 
const long long unsigned int>'

Could you please take another look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#835140: ros-geometry-experimental: FTBFS: Could not find messages

[Aaron M. Ucko]

Source: ros-geometry-experimental
Version: 0.5.13-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of ros-geometry-experimental against libgeometry-msgs-dev
1.12.4-3 have been failing:

  Could not find messages which
  '/«PKGBUILDDIR»/tf2_msgs/msg/TFMessage.msg'
  depends on.  Did you forget to specify generate_messages(DEPENDENCIES ...)?

  Cannot locate message [TransformStamped] in package [geometry_msgs] with
  paths [['/usr/share/geometry_msgs/cmake/../msg']]

Could you please take a look?  I suspect you'll need an explicit
build dependency on the split-out ros-geometry-msgs package.

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#835138: form: FTBFS: tests fail on several architectures

[Aaron M. Ucko]

Source: form
Version: 4.1-1
Severity: important
Justification: fails to build from source

form's tests failed on several architectures, as detailed at
https://buildd.debian.org/status/logs.php?pkg=form=4.1-1 .
Could you please take a look?

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#834562: fcl: FTBFS on mips: test_fcl_octomap times out (hangs?)

[Aaron M. Ucko]

Source: fcl
Version: 0.5.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

The mips build of fcl failed with a timeout in test_fcl_octomap,
likely due to a hang.  Could you please take a look?

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#832540: evolver: FTBFS on kFreeBSD and the Hurd: sysinfo undeclared

[Aaron M. Ucko]

Source: evolver
Version: 2.70+ds-1
Severity: important
Justification: fails to build from source

Builds of evolver for kFreeBSD and the Hurd failed:

  ../../../src/painter.c: In function 'painter_start':
  ../../../src/painter.c:441:20: error: storage size of 's' isn't known
 { struct sysinfo s;
  ^
  ../../../src/painter.c:442:5: warning: implicit declaration of function 
'sysinfo' [-Wimplicit-function-declaration]
   sysinfo();
   ^

The issue appears to be that include.h's conditional inclusion of
 misses these architectures.  Could you please take a look?

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#832538: evolver: FTBFS on i386: PROF_* calls broken

[Aaron M. Ucko]

Source: evolver
Version: 2.70+ds-1
Severity: important
Justification: fails to build from source

The i386 build of evolver failed:

  ../../../src/tmain.c: In function 'task_caller':
  ../../../src/extern.h:2383:38: error: subscripted value is neither array nor 
pointer nor vector
 asm("movl %%eax,%0" : "=m"(fullname[0]) : ); \
^
  ../../../src/tmain.c:1133:1: note: in expansion of macro 'PROF_NOW'
   PROF_NOW(now);
   ^

The problem appears to be that the PROC_* definitions in use here
expect to work with an array of two 32-bit values, whereas the actual
usage is with a single 64-bit value (matching the macro definitions
used on Windows).

Please either fix these macros to match their usage or simply disable
them altogether, as already done for other processor types.

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#830739: mpi-testsuite: FTBFS on non-Linux: 'override_dh_auto_configure' failed

[Aaron M. Ucko]

Source: mpi-testsuite
Version: 3.2+dfsg-1
Severity: important
Justification: fails to build from source

Builds of mpi-testsuite on kFreeBSD and the Hurd have been failing:

  config.status: executing default-4 commands
  for i in `find . -name "testlist" | grep -v ^..build`;\
  do\
if [ ! -e build-openmpi/$i ];   \
then\
  ln -s `pwd`/$i `pwd`/build-openmpi/$i;\
fi; \
  done
  ln: failed to create symbolic link 
'/«BUILDDIR»/mpi-testsuite-3.2+dfsg/build-openmpi/./.pc/disable_large_tests.patch/group/testlist':
 No such file or directory
  debian/rules:14: recipe for target 'override_dh_auto_configure' failed

The error from ln also appears on Linux, so it's probably a red
herring; it's not clear from the log what the actual problem is.

Could you please take a look?

Thanks!

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#830738: mpi-testsuite: FTBFS: test suite times out (hangs?)

[Aaron M. Ucko]

Source: mpi-testsuite
Version: 3.2+dfsg-1
Severity: important
Justification: fails to build from source

Builds of mpi-testsuite for most architectures failed with test suite
timeouts, as detailed at
https://buildd.debian.org/status/logs.php?pkg=mpi-testsuite=3.2%2Bdfsg-1

The last test started varies by architecture, so there may actually be
several bugs here.

  arm64:lockcontention
  armel:win_shared_gacc_flush_load
  armhf:nonblocking
* hppa: win_shared_cas_flush_load
  i386: win_shared_gacc_flush_load
  mips: cartzero
  mips64el: nonblocking
  mipsel:   nonblocking
  powerpc:  nonblocking_inpf
* ppc64:nonblocking
  ppc64el:  adlb_mimic1
  s390x:commcreate1
* sparc64:  cartzero

* Not a release architecture.

Non-Linux builds failed at the configuration stage; I'll report that
bug separately.

Could you please take a look?

BTW, the message

  Could not execute ps command

came up pretty frequently.  You might want to declare a build
dependency on procps, if only to cut down on noise.

Thanks!

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#826659: hfst: FTBFS: twolc test fails or times out

[Aaron M. Ucko]

Source: hfst
Version: 3.10.0~r2798-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of hfst for many architectures failed because the hfst-twolc
test either hit an inactivity timeout (which is generous enough that
it typically indicates a hang) or explicitly failed (details not
reported or saved, but likely reproducible on a porterbox).

Specifically: I see timeouts on the release architectures arm64,
armel, armhf, powerpc, ppc64el, and s390x, and on the non-release
architecture ppc64.  I see explicit failures on the release
architecture mips and on the non-release architectures hppa, m68k, and
sparc64.

Could you please take a look?

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#826070: python-escript: FTBFS in indep-only mode: no prerm scripts to tweak

[Aaron M. Ucko]

Santiago Vila <sanv...@unex.es> writes:

> Please note that if we apply the same standard to every bug like this
> (i.e. FTBFS when using dpkg-buildpackage -A), lots of bugs here should
> be serious as well:

That's a good point.  However, I'd argue that pure source-only uploads
with no maintainer-supplied arch-all packages (as occurred here) call
for a higher severity in this scenario.

> (BTW: I have just added this bug to the collection :-)

Great, thanks.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#826070: python-escript: FTBFS in indep-only mode: no prerm scripts to tweak

[Aaron M. Ucko]

Source: python-escript
Version: 4.2.0.1-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Thanks for fixing python-escript's build dependencies quickly.
Architecture-specific builds now look good for the most part (aside
from portability issues to some non-release architectures), but the
arch-all-only build failed:

  sed -i -e 's/#PACKAGE#/python-escript/' debian/python-escript/DEBIAN/prerm
  sed: can't read debian/python-escript/DEBIAN/prerm: No such file or directory
  debian/rules:133: recipe for target 'override_dh_gencontrol' failed

Could you please take a look?  I think it might suffice to rename the
target to override_dh_gencontrol-indep.

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#825874: python-escript: FTBFS - netcdf.h not found under /usr

[Aaron M. Ucko]

Source: python-escript
Version: 4.2.0.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of python-escript in minimal environments (notably, on the
autobuilders) have been failing:

  RuntimeError: netcdf.h not found under /usr:
File "/«PKGBUILDDIR»/SConstruct", line 520:
  env=checkOptionalLibraries(env)
File "/«PKGBUILDDIR»/site_scons/dependencies.py", line 286:
  netcdf_inc_path,netcdf_lib_path=findLibWithHeader(env, 
env['netcdf_libs'], 'netcdf.h', env['netcdf_prefix'], lang='c++')
File "/«PKGBUILDDIR»/site_scons/site_init.py", line 44:
  raise RuntimeError('%s not found under %s'%(header,paths))
  debian/rules:58: recipe for target 'override_dh_auto_build' failed
  make[1]: *** [override_dh_auto_build] Error 2

Please declare a build dependency on libnetcdf-dev, and confirm with
pbuilder or the like that you haven't missed any others.  (Please note
that the build dependency on libnetcdf-cxx-legacy-dev is insufficient,
because that package does NOT depend on libnetcdf-dev, though perhaps
it should.)

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#818567: openbsc: FTBFS: db test fails on several architectures

[Aaron M. Ucko]

Source: openbsc
Version: 0.15.0-1
Severity: important
Justification: fails to build from source

Builds of openbsc failed on several architectures (arm64, i386, mips,
and mipsel, so far) because test #3 (db) failed.  I don't have further
details because the build system didn't report them before bailing,
but perhaps a build in an i386 chroot, or a suitable porterbox, will
fail in the same fashion.

Could you please take a look?

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#816424: r-cran-httpuv: FTBFS on non-Linux: 'src/unix/async.o' failed

[Aaron M. Ucko]

Source: r-cran-httpuv
Version: 1.3.3-3
Severity: important
Justification: fails to build from source

Thanks for taking care of #814720/#814878!  Linux builds of
r-cran-httpuv are doing well, but builds for kFreeBSD and the Hurd are
now hitting another issue:

  In file included from /«PKGBUILDDIR»/src/libuv/include/uv.h:67:0,
   from src/unix/async.c:25:
  /«PKGBUILDDIR»/src/libuv/include/uv-private/uv-unix.h:131:9: error: unknown 
type name 'pthread_rwlock_t'
   typedef pthread_rwlock_t uv_rwlock_t;
   ^
  /«PKGBUILDDIR»/src/libuv/include/uv-private/uv-unix.h:148:9: error: unknown 
type name 'pthread_barrier_t'
   typedef pthread_barrier_t uv_barrier_t;
   ^
  In file included from src/unix/async.c:25:0:
  /«PKGBUILDDIR»/src/libuv/include/uv.h:386:42: warning: 'struct addrinfo' 
declared inside parameter list
 struct addrinfo* res);
^
  /«PKGBUILDDIR»/src/libuv/config-unix.mk:189: recipe for target 
'src/unix/async.o' failed
  make[2]: *** [src/unix/async.o] Error 1
  make[2]: Leaving directory '/«PKGBUILDDIR»/src/libuv'
  make[1]: *** [libuv.a] Error 2

Per Policy 4.13, the best course of action would be to build against
separately packaged libuv1-dev, particularly considering that it
already supports these platforms.  However, if you specifically need
to use the convenience copy, please patch it appropriately; I suspect
you just need to enable a conditional #include directive or two.

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#815725: trilinos: FTBFS on non-amd64

[Aaron M. Ucko]

Source: trilinos
Version: 12.4.2-1
Severity: important
Justification: fails to build from source

Builds of trilinos for architectures other than amd64 have been
failing; please either address these errors or set its Architecture
field accordingly.  Specifically:

- On 32-bit architectures such as i386, there are errors related to
  type usage, starting with

  
/«PKGBUILDDIR»/packages/kokkos/core/src/impl/Kokkos_Atomic_Generic.hpp:144:49: 
error: no matching function for call to 'atomic_compare_exchange(long long 
unsigned int*, long long unsigned int&, long long unsigned int&)'
   oldval.i = ::Kokkos::atomic_compare_exchange( (unsigned long long 
int*)dest , assume.i , newval.i );

- On 64-bit architectures other than amd64, there are errors related
  to the use of x86 assembly:

  /tmp/ccSfso5b.s: Assembler messages:
  /tmp/ccSfso5b.s:2095: Error: unknown mnemonic `lock' -- `lock incl[x1,88]'
  /tmp/ccSfso5b.s:2213: Error: unknown mnemonic `lock' -- `lock incl[x1,92]'
  /tmp/ccSfso5b.s:2330: Error: unknown mnemonic `lock' -- `lock incl[x1,68]'
  /tmp/ccSfso5b.s:3627: Error: unknown mnemonic `lock' -- `lock decl[x20]'
  /tmp/ccSfso5b.s:3732: Error: unknown mnemonic `lock' -- `lock decl[x20]'
  packages/kokkos/core/src/CMakeFiles/trilinos_kokkoscore.dir/build.make:401: 
recipe for target 
'packages/kokkos/core/src/CMakeFiles/trilinos_kokkoscore.dir/Threads/Kokkos_Threads_TaskPolicy.cpp.o'
 failed

Could you please take a look?

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#815683: liburdfdom-headers-dev: gratuitous pointer size check

[Aaron M. Ucko]

Package: liburdfdom-headers-dev
Version: 0.4.1-1
Severity: serious
Justification: makes urdfdom FTBFS on 32-bit architectures

/usr/share/urdfdom_headers/cmake/urdfdom_headers-config.cmake refuses
to support systems with different pointer sizes than the (64-bit)
system on which it was built:

  # check that the installed version has the same 32/64bit-ness as the one 
which is currently searching:
  if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8")
math(EXPR installedBits "8 * 8")
set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
set(PACKAGE_VERSION_UNSUITABLE TRUE)
  endif()

This logic appears to come from cmake's
BasicConfigVersion-SameMajorVersion.cmake.in, but is uncalled for
here.

Please either formally change this package's architecture to any or
arrange to suppress this spurious logic.  As it stands, 32-bit builds
of urdfdom are failing:

  CMake Error at CMakeLists.txt:41 (find_package):
Could not find a configuration file for package "urdfdom_headers" that is
compatible with requested version "0.4".
  
The following configuration files were considered but not accepted:
  
  /usr/share/urdfdom_headers/cmake/urdfdom_headers-config.cmake, version: 
0.4.0 (64bit)
  
  
  
  -- Configuring incomplete, errors occurred!
  See also "/«PKGBUILDDIR»/obj-i586-linux-gnu/CMakeFiles/CMakeOutput.log".

Could you please take a look?

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#815383: r-cran-glmnet: FTBFS: dependencies 'Matrix', 'foreach' are not available

[Aaron M. Ucko]

Source: r-cran-glmnet
Version: 2.0-2-1
Severity: serious
Justification: fails to build from source

Hi, Daniel.

Builds of r-cran-glmnet in minimal environments (notably, on the
autobuilders) have been failing:

  ERROR: dependencies 'Matrix', 'foreach' are not available for package 'glmnet'
  * removing '/«PKGBUILDDIR»/debian/r-cran-glmnet/usr/lib/R/site-library/glmnet'
  /usr/share/R/debian/r-cran.mk:98: recipe for target 'R_any_arch' failed
  make: *** [R_any_arch] Error 1

Please declare build dependencies on r-cran-matrix and r-cran-foreach,
and confirm with pbuilder or the like that you haven't missed any others.

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#815373: r-cran-tm: FTBFS: dependencies 'NLP', 'slam' are not available

[Aaron M. Ucko]

Source: r-cran-tm
Version: 0.6.2-1
Severity: serious
Justification: fails to build from source

Hi, Daniel.

Builds of r-cran-tm in minimal environments (notably, on the
autobuilders) have been failing:

  ERROR: dependencies 'NLP', 'slam' are not available for package 'tm'
  * removing '/«PKGBUILDDIR»/debian/r-cran-tm/usr/lib/R/site-library/tm'
  /usr/share/R/debian/r-cran.mk:98: recipe for target 'R_any_arch' failed
  make: *** [R_any_arch] Error 1

Please declare build dependencies on r-cran-nlp and r-cran-slam, and
confirm with pbuilder or the like that you haven't missed any others.

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#815372: FTBFS: dependency 'stringr' is not available

[Aaron M. Ucko]

Source: r-cran-lubridate
Version: 1.5.0-1
Severity: serious
Justification: fails to build from source

Hi, Daniel.

Builds of r-cran-lubridate in minimal environments (notably, on the
autobuilders) have been failing:

  ERROR: dependency 'stringr' is not available for package 'lubridate'
  * removing 
'/«PKGBUILDDIR»/debian/r-cran-lubridate/usr/lib/R/site-library/lubridate'
  /usr/share/R/debian/r-cran.mk:98: recipe for target 'R_any_arch' failed
  make: *** [R_any_arch] Error 1

Please declare a build dependency on r-cran-stringr and confirm with
pbuilder or the like that you haven't missed any others.

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#814720: r-cran-httpuv: FTBFS: dependency 'Rcpp' is not available

[Aaron M. Ucko]

Source: r-cran-httpuv
Version: 1.3.3-2
Severity: serious
Justification: fails to build from source

Builds of r-cran-httpuv in minimal environments (notably, on the
autobuilders) have been failing:

  ERROR: dependency 'Rcpp' is not available for package 'httpuv'
  * removing '/«PKGBUILDDIR»/debian/r-cran-httpuv/usr/lib/R/site-library/httpuv'
  /usr/share/R/debian/r-cran.mk:98: recipe for target 'R_any_arch' failed
  make: *** [R_any_arch] Error 1

Please declare a build dependency on r-cran-rcpp and confirm with
pbuilder or the like that you haven't missed any others.

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#810662: ros-pluginlib: FTBFS: cannot create obj-x86_64-linux-gnu/...

[Aaron M. Ucko]

Source: ros-pluginlib
Version: 1.10.1-1
Severity: important
Justification: fails to build from source

Builds of ros-pluginlib for architectures other than amd64 have been
failing due to a hardcoded architecture tuple:

  -- Build files have been written to: /«PKGBUILDDIR»/obj-i586-linux-gnu
  echo 
'add_definitions(-DCMAKE_LIBRARY_ARCHITECTURE=\\"${CMAKE_LIBRARY_ARCHITECTURE}\\")'
 >> obj-x86_64-linux-gnu/catkin_generated/installspace/pluginlibConfig.cmake
  /bin/sh: 1: cannot create 
obj-x86_64-linux-gnu/catkin_generated/installspace/pluginlibConfig.cmake: 
Directory nonexistent

Could you please take a look?  I'd suggest either substituting the
dpkg-architecture DEB_HOST_GNU_TYPE variable or simply using a wildcard.

Thanks!

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers