Bug#887682: r-cran-utf8: FTBFS on m68k: missing value where TRUE/FALSE needed
Andreas Tille 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
Dylan Aïssi 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
Dylan Aïssi 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
Dylan Aïssi 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
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
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)
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&arch=alpha&ver=1.0.0%2Bdfsg4-2&stamp=1519096893&raw=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
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&arch=hurd-i386&ver=2.2%2Bds1-2&stamp=1518262290&raw=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
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&arch=mips&ver=4.0.0%2Bdfsg1-1&stamp=1516376024&raw=0 https://buildd.debian.org/status/fetch.php?pkg=ignition-math4&arch=mipsel&ver=4.0.0%2Bdfsg1-1&stamp=1516373688&raw=0 https://buildd.debian.org/status/fetch.php?pkg=ignition-math4&arch=hppa&ver=4.0.0%2Bdfsg1-1&stamp=1516373442&raw=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
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
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
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
John Paul Adrian Glaubitz 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&arch=m68k&ver=20180101-1&stamp=1515027549&raw=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
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&arch=m68k&ver=1.8.1-2&stamp=1515504032&raw=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"
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&arch=m68k&ver=5.1-5&stamp=1514854858&raw=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
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&arch=mips&ver=3.1.0-1&stamp=1514685910&raw=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
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
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
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&arch=m68k&ver=5.1.2-2&stamp=1513807447&raw=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.
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
(test.segyio_c._segyioTests) ... 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
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::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
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&arch=hppa&ver=2.9.0%2Bdfsg1-5&stamp=1511233991&raw=0 https://buildd.debian.org/status/fetch.php?pkg=ovito&arch=m68k&ver=2.9.0%2Bdfsg1-5&stamp=1511332288&raw=0 https://buildd.debian.org/status/fetch.php?pkg=ovito&arch=powerpc&ver=2.9.0%2Bdfsg1-5&stamp=1511222775&raw=0 https://buildd.debian.org/status/fetch.php?pkg=ovito&arch=ppc64&ver=2.9.0%2Bdfsg1-5&stamp=1511219276&raw=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
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&arch=armel&ver=2.9.0%2Bdfsg1-5&stamp=1511236739&raw=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
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&arch=sparc64&ver=1.3.3-1&stamp=1511256932&raw=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
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&arch=s390x&ver=1.3.3-1&stamp=1511256490&raw=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
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
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&arch=sparc64&ver=12.12.1-1&stamp=1510746436&raw=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
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
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
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&arch=hurd-i386&ver=1.3.0-1&stamp=1510615243&raw=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
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&arch=kfreebsd-amd64&ver=1.3.0-1&stamp=1510632713&raw=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&arch=kfreebsd-i386&ver=1.3.0-1&stamp=1510617549&raw=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
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
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
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
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.
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)
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&arch=hurd-i386&ver=3.0.5%2Bdfsg1-1&stamp=1509336181&raw=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
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&arch=sparc64&ver=1.5-1&stamp=1509309061&raw=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
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&ver=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
Mattia Rizzolo 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
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
Mattia Rizzolo 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
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
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
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'
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
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&arch=mipsel&ver=5.13.0%2Bdfsg-1&stamp=1506091509&raw=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
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
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&arch=arm64&ver=8.0-7&stamp=1505101830&raw=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
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
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'
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
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
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&arch=s390x&ver=1.0.8-1&stamp=1492853102&raw=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
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&arch=i386&ver=1.0.8-1&stamp=1492853191&raw=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
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&arch=arm64&ver=1.0.8-1&stamp=1492853219&raw=0 https://buildd.debian.org/status/fetch.php?pkg=python-ltfatpy&arch=mips64el&ver=1.0.8-1&stamp=1492855642&raw=0 https://buildd.debian.org/status/fetch.php?pkg=python-ltfatpy&arch=ppc64el&ver=1.0.8-1&stamp=1492853314&raw=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
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&arch=kfreebsd-i386&ver=1.2.3.25%2Bdfsg1-1&stamp=1486951903&raw=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
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&arch=hurd-i386&ver=1.2.3.25%2Bdfsg1-1&stamp=1486947346&raw=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)
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
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
Ghislain Vaillant 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
Ghislain Vaillant 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
Ximin Luo 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
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&arch=i386&ver=7.4-3&stamp=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
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
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
Graham Inggs 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
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
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&ver=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
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<<'
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}
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
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
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#840454: fflas-ffpack: FTBFS: several tests fail
Source: fflas-ffpack Version: 2.2.2-2 Severity: serious Justification: fails to build from source Builds of fflas-ffpack 2.2.2-2 for armel, mips, powerpc, and s390x, and the non-release architectures hppa, ppc64, and sparc64, all failed with similar test-suite errors involving Modular, as detailed at https://buildd.debian.org/status/logs.php?pkg=fflas-ffpack&ver=2.2.2-2 Previous 2.x builds have also been failing on these architectures, so they all still have version 1.6.0-1 in unstable. Specifically: - On most of these architectures (all but armel), test-lu reports failures of both test cases involving Modular. FWIW, for other types, it issues a lot of warnings of the form "120xN pluq verification failed!" (However, those test cases all pass, and the Modular tests encounter no such warnings.) - On most of these architectures (again, all but armel), test-echelon crashes after performing three ModularBalanced tests, having presumably moved on to Modular. These crashes take the form of a bus error on hppa and a segmentation violation on the remaining architectures. - On all of these architectures, the test-rankprofiles test case involving Modular fails, with no details reported. - On all of these architectures, the test-fgemm test case involving Modular fails, with copious diagnostic output. There was one additional error on sparc64, which I'll report separately since it didn't occur anywhere else and wasn't obviously related. 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
Graham Inggs 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
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
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 = opengm::visitors::TimingVisitor >; PARAMETER = opengm::SelfFusion >::Parameter; IO = opengm::interface::IOCMD; GM = opengm::GraphicalModel, opengm::DiscreteSpace<> >; ACC = opengm::Minimizer; CHILD = opengm::interface::SelfFusionCaller, opengm::Minimizer>]' /«BUILDDIR»/opengm-2.3.6+20160814/src/interfaces/commandline/double/../../common/caller/selffusion_caller.hxx:108:7: required from 'void opengm::interface::SelfFusionCaller::runImpl(GM&, opengm::interface::SelfFusionCaller::OutputBase&, bool) [with IO = opengm::interface::IOCMD; GM = opengm::GraphicalModel, opengm::DiscreteSpace<> >; ACC = opengm::Minimizer; opengm::interface::SelfFusionCaller::OutputBase = opengm::interface::InferenceCallerBase, opengm::Minimizer, opengm::interface::SelfFusionCaller, opengm::Minimizer> >
Bug#836130: trilinos: FTBFS on non-x86 32-bit architectures
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
notfixed 815725 12.6.3-4 found 815725 12.6.3-4 thanks Graham Inggs 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' [...] /«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' [...] /«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' 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
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
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&ver=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?)
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
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(&s); ^ 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
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
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?)
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&ver=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#827199: hfst: FTBFS: twolc test fails on big-endian systems
Source: hfst Version: 3.10.0~r2798-2 Severity: serious Justification: fails to build from source (but built successfully in the past) Thanks for taking care of the twolc errors I reported in #826659. The twolc test now succeeds on little-endian systems, and no longer hangs anywhere, but still fails on big-endian architectures (mips, powerpc, s390x, and several non-release architectures). I don't have further details, but perhaps you can reproduce the problem on a porterbox. 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#826659: hfst: FTBFS: twolc test fails or times out
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
Santiago Vila 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
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
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
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
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
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
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
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
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
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