Bug#855883: pybind11: FTBFS in stretch

[Santiago Vila]

Package: src:pybind11
Version: 2.0.1-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3,sphinxdoc --buildsystem=cmake
   dh_testdir -i -O--buildsystem=cmake
   dh_update_autotools_config -i -O--buildsystem=cmake
   dh_autoreconf -i -O--buildsystem=cmake
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- -DPYBIND11_TEST=ON
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DPYBIND11_TEST=ON
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info

[... snipped ...]

9637: .def(py::init<>())
9637: .def("f", ::f);
9637: 
9637: m.def("call_f", call_f);
9637: 
9637: 
9637: 
9637: struct A2 {
9637: virtual ~A2() {}
9637: virtual void f() { py::print("A2.f()"); }
9637: };
9637: 
9637: struct PyA2 : A2 {
9637: PyA2() { py::print("PyA2.PyA2()"); }
9637: ~PyA2() { py::print("PyA2.~PyA2()"); }
9637: void f() override {
9637: py::print("PyA2.f()");
9637: { pybind11::gil_scoped_acquire gil; pybind11::function 
overload = pybind11::get_overload(static_cast(this), "f"); if 
(overload) { auto o = overload(); if 
(pybind11::detail::cast_is_temporary_value_reference::value) { static 
pybind11::detail::overload_caster_t caster; return 
pybind11::detail::cast_ref(std::move(o), caster); } else return 
pybind11::detail::cast_safe(std::move(o)); } } return A2::f();
9637: }
9637: };
9637: 
9637: py::class_(m, "A2")
9637: .def(py::init_alias<>())
9637: .def("f", ::f);
9637: 
9637: m.def("call_f", [](A2 *a2) { a2->f(); });
9637: 
9637: });
=== END GCC DUMP ===
tests/CMakeFiles/pybind11_tests.dir/build.make:89: recipe for target 
'tests/CMakeFiles/pybind11_tests.dir/test_alias_initialization.cpp.o' failed
make[4]: *** 
[tests/CMakeFiles/pybind11_tests.dir/test_alias_initialization.cpp.o] Error 1
make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu'
CMakeFiles/Makefile2:160: recipe for target 
'tests/CMakeFiles/pybind11_tests.dir/all' failed
make[3]: *** [tests/CMakeFiles/pybind11_tests.dir/all] Error 2
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
Makefile:130: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
dh_auto_build: make -j1 returned exit code 2
debian/rules:27: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
debian/rules:15: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/pybind11/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine.
I only tried twice and it failed twice, but it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pybind11.html

so hope this may be reproduced easily.

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#852995: givaro: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:givaro
Version: 4.0.2-5
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with autoreconf 
   dh_testdir -i
   dh_update_autotools_config -i
   dh_autoreconf -i
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'macros'.
libtoolize: copying file 'macros/libtool.m4'
libtoolize: copying file 'macros/ltoptions.m4'
libtoolize: copying file 'macros/ltsugar.m4'
libtoolize: copying file 'macros/ltversion.m4'
libtoolize: copying file 'macros/lt~obsolete.m4'
configure.ac:149: installing 'build-aux/compile'

[... snipped ...]

ERROR a4 != a6
ERROR a7 != a8
ERROR a9 != a10
ERROR a1 != a3
ERROR a4 != a7
ERROR a2 != a5
ERROR a1 != a9
FAIL test-crt (exit status: 1)


Testsuite summary for Givaro 4.0.2

# TOTAL: 62
# PASS:  61
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log
Please report to jean-guillaume.du...@imag.fr

Makefile:1904: recipe for target 'test-suite.log' failed
make[6]: *** [test-suite.log] Error 1
make[6]: Leaving directory '/<>/tests'
Makefile:2010: recipe for target 'check-TESTS' failed
make[5]: *** [check-TESTS] Error 2
make[5]: Leaving directory '/<>/tests'
Makefile:2535: recipe for target 'check-am' failed
make[4]: *** [check-am] Error 2
make[4]: Leaving directory '/<>/tests'
Makefile:1797: recipe for target 'check-recursive' failed
make[3]: *** [check-recursive] Error 1
make[3]: Leaving directory '/<>/tests'
Makefile:579: recipe for target 'check-recursive' failed
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory '/<>'
dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2
debian/rules:41: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'
debian/rules:52: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/givaro/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

(Note: Failure rate is very low, around 1%, it might be more interesting to skip
trying to reproduce it and instead look at the build logs and try to guess how
it may happen).

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#852642: scoop: FTBFS randomly (sbuild hangs)

[Santiago Vila]

Package: src:scoop
Version: 0.7.1.1-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3,sphinxdoc --buildsystem=pybuild
   dh_testdir -i -O--buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py config 
running config
I: pybuild base:184: python3.5 setup.py config 
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:184: /usr/bin/python setup.py build 
running build
running build_py
creating /<>/.pybuild/pythonX.Y_2.7/build/scoop

[... snipped ...]

copying scoop/shared.py -> /<>/.pybuild/pythonX.Y_3.5/build/scoop
copying scoop/utils.py -> /<>/.pybuild/pythonX.Y_3.5/build/scoop
copying scoop/__main__.py -> /<>/.pybuild/pythonX.Y_3.5/build/scoop
copying scoop/futures.py -> /<>/.pybuild/pythonX.Y_3.5/build/scoop
copying scoop/encapsulation.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop
copying scoop/fallbacks.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop
creating /<>/.pybuild/pythonX.Y_3.5/build/scoop/bootstrap
copying scoop/bootstrap/__init__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/bootstrap
copying scoop/bootstrap/__main__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/bootstrap
creating /<>/.pybuild/pythonX.Y_3.5/build/scoop/launch
copying scoop/launch/__init__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/launch
copying scoop/launch/workerLaunch.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/launch
copying scoop/launch/brokerLaunch.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/launch
creating /<>/.pybuild/pythonX.Y_3.5/build/scoop/broker
copying scoop/broker/__init__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/broker
copying scoop/broker/__main__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/broker
copying scoop/broker/brokertcp.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/broker
copying scoop/broker/structs.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/broker
copying scoop/broker/brokerzmq.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/broker
creating /<>/.pybuild/pythonX.Y_3.5/build/scoop/_comm
copying scoop/_comm/scooptcp.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/_comm
copying scoop/_comm/__init__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/_comm
copying scoop/_comm/scoopzmq.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/_comm
copying scoop/_comm/scoopexceptions.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/_comm
creating /<>/.pybuild/pythonX.Y_3.5/build/scoop/discovery
copying scoop/discovery/__init__.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/discovery
copying scoop/discovery/minusconf.py -> 
/<>/.pybuild/pythonX.Y_3.5/build/scoop/discovery
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
PYBUILD_SYSTEM=custom \
PYBUILD_TEST_ARGS="cd {dir}/test; {interpreter} tests.py" \
dh_auto_test
I: pybuild base:184: cd /<>/test; python2.7 tests.py
.
--
Ran 77 tests in 49.575s

OK
I: pybuild base:184: cd /<>/test; python3.5 tests.py
.
--
Ran 77 tests in 52.916s

OK
E: Build killed with signal TERM after 60 minutes of inactivity


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/build-logs/scoop/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

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#851726: liggghts: FTBFS on single-CPU machines (not enough slots available)

[Santiago Vila]

Package: src:liggghts
Version: 3.5.0+repack1-8
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=cmake 
--builddirectory=/<>/liggghts-3.5.0+repack1/debian/build --parallel
   dh_testdir -i -O--buildsystem=cmake 
-O--builddirectory=/<>/liggghts-3.5.0\+repack1/debian/build 
-O--parallel
   dh_update_autotools_config -i -O--buildsystem=cmake 
-O--builddirectory=/<>/liggghts-3.5.0\+repack1/debian/build 
-O--parallel
   dh_auto_configure -i -O--buildsystem=cmake 
-O--builddirectory=/<>/liggghts-3.5.0\+repack1/debian/build 
-O--parallel
cmake ../.. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var
-- The C compiler identification is GNU 6.2.1
-- The CXX compiler identification is GNU 6.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done

[... snipped ...]

cd /<>/liggghts-3.5.0+repack1/debian/build/src && /usr/bin/mpicxx   
-Dlibliggghts_EXPORTS 
-DvtkRenderingCore_AUTOINIT="3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL)"
 -I/usr/include/vtk-6.3 -I/usr/include/freetype2 
-I/usr/include/x86_64-linux-gnu -I/usr/include/eigen3 
-I/<>/liggghts-3.5.0+repack1 
-I/<>/liggghts-3.5.0+repack1/src  -g -O2 
-fdebug-prefix-map=/<>/liggghts-3.5.0+repack1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -DLAMMPS_VTK6 -DLAMMPS_VTK -std=c++0x -DLAMMPS_JPEG -fPIC  
 -o CMakeFiles/libliggghts.dir/write_dump.cpp.o -c 
/<>/liggghts-3.5.0+repack1/src/write_dump.cpp
[ 98%] Building CXX object src/CMakeFiles/libliggghts.dir/write_restart.cpp.o
cd /<>/liggghts-3.5.0+repack1/debian/build/src && /usr/bin/mpicxx   
-Dlibliggghts_EXPORTS 
-DvtkRenderingCore_AUTOINIT="3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL)"
 -I/usr/include/vtk-6.3 -I/usr/include/freetype2 
-I/usr/include/x86_64-linux-gnu -I/usr/include/eigen3 
-I/<>/liggghts-3.5.0+repack1 
-I/<>/liggghts-3.5.0+repack1/src  -g -O2 
-fdebug-prefix-map=/<>/liggghts-3.5.0+repack1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -DLAMMPS_VTK6 -DLAMMPS_VTK -std=c++0x -DLAMMPS_JPEG -fPIC  
 -o CMakeFiles/libliggghts.dir/write_restart.cpp.o -c 
/<>/liggghts-3.5.0+repack1/src/write_restart.cpp
[ 99%] Linking CXX shared library libliggghts.so
cd /<>/liggghts-3.5.0+repack1/debian/build/src && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/libliggghts.dir/link.txt --verbose=1
/usr/bin/mpicxx  -fPIC -g -O2 
-fdebug-prefix-map=/<>/liggghts-3.5.0+repack1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -DLAMMPS_VTK6 -DLAMMPS_VTK -std=c++0x -DLAMMPS_JPEG 
-Wl,-z,relro -Wl,--as-needed  -shared -Wl,-soname,libliggghts.so.3 -o 
libliggghts.so.3.3.1 CMakeFiles/libliggghts.dir/angle.cpp.o 
CMakeFiles/libliggghts.dir/angle_hybrid.cpp.o 
CMakeFiles/libliggghts.dir/atom.cpp.o CMakeFiles/libliggghts.dir/atom_map.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_atomic.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_charge.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_ellipsoid.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_hybrid.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_line.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_sph.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_sph_var.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_sphere.cpp.o 
CMakeFiles/libliggghts.dir/atom_vec_sphere_w.cpp.o CMakeFiles/libliggghts.dir/
 bond.cpp.o CMakeFiles/libliggghts.dir/bond_hybrid.cpp.o 
CMakeFiles/libliggghts.dir/bounding_box.cpp.o 
CMakeFiles/libliggghts.dir/cfd_datacoupling.cpp.o 
CMakeFiles/libliggghts.dir/cfd_datacoupling_file.cpp.o 
CMakeFiles/libliggghts.dir/cfd_datacoupling_mpi.cpp.o 
CMakeFiles/libliggghts.dir/cfd_regionmodel_none.cpp.o 
CMakeFiles/libliggghts.dir/change_box.cpp.o 
CMakeFiles/libliggghts.dir/citeme.cpp.o CMakeFiles/libliggghts.dir/comm.cpp.o 
CMakeFiles/libliggghts.dir/compute.cpp.o 
CMakeFiles/libliggghts.dir/compute_atom_molecule.cpp.o 
CMakeFiles/libliggghts.dir/compute_bond_local.cpp.o 
CMakeFiles/libliggghts.dir/compute_centro_atom.cpp.o 
CMakeFiles/libliggghts.dir/compute_cluster_atom.cpp.o 
CMakeFiles/libliggghts.dir/compute_cna_atom.cpp.o 
CMakeFiles/libliggghts.dir/compute_com.cpp.o 
CMakeFiles/libliggghts.dir/compute_com_molecule.cpp.o 
CMakeFiles/libliggghts.dir/compute_contact_atom.cpp.o 
CMakeFiles/libliggghts.dir/compute_coord_atom.cpp.o 
CMakeFiles/libliggghts.dir/compute_displace_atom.c
 pp.o CMakeFiles/libliggghts.dir/compute_erotate_multisphere.cpp.o 

Bug#848859: getfem++: FTBFS randomly (failing tests)

[Santiago Vila]

BTW: We are deviating from this particular bug.

It was marked as unreproducible after building it just 5 times.

As I've explained, this is mathematically and statistically not ok.

Could anybody here please try to build a lot more times and share the
results? I see that the unreproducible tag is sometimes being used too
happily.

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#848859: FTBFS randomly (failing tests)

[Santiago Vila]

> >> My experience is that the buildds that are currently in use provide more
> >> build problems than the packages themself. BTW, why don't you count this
> >> as RC?
> > 
> > Can you clarify the question? I don't understand what you refer exactly.
> 
> It does not make sense to have 100% reliability on the package itself to
> build but only 95% on the buildds. If we want to have reliability, then
> every chain member counts -- and the weakest one in the moment for me
> does not seem to be the packages themselves, but the buildd setups we
> currently have. So, if you consider unreliable package builds as an RC
> problem, you should also consider the unreliable buildd setup as an RC
> problem.

Ok, I now understand the question, but now I don't understand the
purpose of the question :-)

First of all, I don't see that the buildds are unreliable, or at least
I don't see that they fail randomly 5% of the time.

But in either case, if they were so unreliable, nothing prevents
building the same set of packages in another autobuilder farm not
being the official one.

This is precisely what is done in reproducible builds, what Lucas Nussbaum does,
and what I do as well (in a much smaller scale).

Because we mainly care about the quality of the packages themselves,
which is what we ship to our users, not about the quality of the
official autobuilders, which we don't ship to our users.

In other words, it may be interesting to consider the whole chain
that you mention, but I'm only interested in the packages themselves.

> > We provide software which is free to be modified. If people is going
> > to modify it and then it fails because the package only builds ok in
> > buildd.debian.org, then we are removing one of the essential freedoms,
> > the freedom to modify it, and the package becomes de-facto non-free,
> > even if we still distribute it in main.
> 
> First, the multi-CPU buildd setup is free (as in speech), isn't it? So,
> depending on this does not make anything non-free. I don't see why the
> dependency on a specific build environment would change the DFSG
> freeness at all (as long as the build environment itself is DFSG free).
> 
> Then, we are speaking about random failures. If you use a single-core
> and see a build failure, you can just pragmatically repeat it.
> 
> Sorry, I don't see why this would restrict DFSG freedom here.

The single-core / multi-core issue was just an example of possible
reason why package might build fine in buildd.debian.org and not in my
autobuilders (or the opposite).

But it was just an example. The real problem is when it fails to build
in every autobuilder but buildd.debian.org and people still say
"it builds fine on buildd.debian.org so it's not RC" but *without*
giving the reason why it fails in every other autobuilder.

So this is like having a "build-depends: buildd.debian.org".
Maintainer does not investigate enough and basically says that all
the other autobuilders are wrong "for not being buildd.debian.org".

This is what IMO makes the package non-free, the need to build the package
in some of the official autobuilders for *unknown* reasons.

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#851320: trilinos: FTBFS on single-CPU machines (not enough slots available)

[Santiago Vila]

Well, I should better include the build log in the bug report.
Here it is:

https://people.debian.org/~sanvila/build-logs/trilinos/

The list of failed tests is too long:

The following tests FAILED:
 32 - TeuchosParameterList_FancyOutputting_test_MPI_4 (Failed)
 73 - TeuchosRemainder_SolverFactory_MPI_4 (Failed)
 93 - RTOp_SPMD_apply_op_UnitTests_parallel_MPI_4 (Failed)
 94 - RTOp_SPMD_apply_op_UnitTests_parallel_dump_rtops_MPI_4 (Failed)
 95 - RTOp_testLapackWrappers_0_MPI_4 (Failed)
 96 - RTOp_testLapackWrappers_1_MPI_4 (Failed)
 97 - RTOp_testLapackWrappers_2_MPI_4 (Failed)
 98 - RTOp_testLapackWrappers_3_MPI_4 (Failed)
101 - Sacado_FadCommTests_MPI_4 (Failed)
102 - Sacado_ELRFadCommTests_MPI_4 (Failed)
103 - Sacado_CacheFadCommTests_MPI_4 (Failed)
104 - Sacado_ELRCacheFadCommTests_MPI_4 (Failed)
105 - Sacado_TayCommTests_MPI_4 (Failed)
106 - Sacado_Fad_Kokkos_CommTests_Serial_MPI_4 (Failed)
379 - Triutils_read_test_MPI_4 (Failed)
380 - Triutils_read_test_LL_MPI_4 (Failed)
395 - TpetraTSQR_FullTsqr_Accuracy_MPI_4 (Failed)
396 - TpetraCore_ExpBlockMultiVector_MPI_4 (Failed)
398 - TpetraCore_ExpBlockCrsMatrix_MPI_4 (Failed)
399 - TpetraCore_ExpBlockMap_MPI_4 (Failed)
402 - TpetraCore_BugTests_MPI_4 (Failed)
403 - TpetraCore_BlankRowBugTest_MPI_2 (Failed)
404 - TpetraCore_CompilationTests_MPI_4 (Failed)
405 - TpetraCore_CrsGraph_UnitTests0_MPI_4 (Failed)
406 - TpetraCore_CrsGraph_UnitTests1_MPI_4 (Failed)
407 - TpetraCore_CrsGraph_ReindexColumns_MPI_4 (Failed)
[...]


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#850559: dune-pdelab: FTBFS (not enough slots available)

[Santiago Vila]

Package: src:dune-pdelab
Version: 2.5.0~20161204gdb53a76-3
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel --builddirectory=build
   dh_testdir -i -O--parallel -O--builddirectory=build
   dh_update_autotools_config -i -O--parallel -O--builddirectory=build
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- -DBUILD_SHARED_LIBS=1
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DBUILD_SHARED_LIBS=1
-- The C compiler identification is GNU 6.2.1
-- The CXX compiler identification is GNU 6.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done

[... snipped ...]

Status:FAILED
Output:
   
--
   There are not enough slots available in the system to satisfy the 2 
slots
   that were requested by the application:
 testnonoverlappingsinglephaseflow-ug
   
   Either request fewer slots for your application, or make more slots 
available
   for use.
   
--

==
Name:  testnonoverlappingsinglephaseflow-boilerplate-mpi-2
FullName:  
./dune/pdelab/test/testnonoverlappingsinglephaseflow-boilerplate-mpi-2
Status:FAILED
Output:
   
--
   There are not enough slots available in the system to satisfy the 2 
slots
   that were requested by the application:
 testnonoverlappingsinglephaseflow-boilerplate
   
   Either request fewer slots for your application, or make more slots 
available
   for use.
   
--

==
Name:  testnonoverlapping-mpi-2
FullName:  ./dune/pdelab/test/testnonoverlapping-mpi-2
Status:FAILED
Output:
   
--
   There are not enough slots available in the system to satisfy the 2 
slots
   that were requested by the application:
 testnonoverlapping
   
   Either request fewer slots for your application, or make more slots 
available
   for use.
   
--

/usr/share/dune/dune-debian.mk:16: recipe for target 'override_dh_auto_test' 
failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
debian/rules:6: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is how the build ends, and also the relevant part.

The bug should be reproducible with sbuild on a single CPU virtual machine.

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#802706: slepc: FTBFS: Unable to link with PETSc

[Santiago Vila]

found 802706 3.7.3+dfsg1-3
thanks

Hi.

Sorry for the reopening but this is happening again in stretch.
(I built this package 200 times, and it failed 200 times).

Build logs available here:

https://people.debian.org/~sanvila/build-logs/slepc/

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#848859: FTBFS randomly (failing tests)

[Santiago Vila]

On Wed, Jan 04, 2017 at 07:58:43PM +0100, Anton Gladky wrote:
> 2017-01-04 13:26 GMT+01:00 Santiago Vila <sanv...@unex.es>:
> > No matter how much glitch-free is the autobuilder you use to build the
> > above package, it will fail to build 1 every 147 times on average,
> > mathematically, because the test is wrongly designed.
> 
> That is not always true. If you look in many tests from numerical
> simulation packages, there is usually a "threshold" for test result
> which should not be exceeded. And the test result varies in
> the limits, which are set by upstream authors. This result
> can be different even on the same machine, running the simulation
> several time. And it is normal.
> [...]

I know what you mean. I've seen it several times in statistical packages.

In my opinion, upstream authors may do as they wish, but Debian aims
at having reproducible builds (in some future). Reproducible builds
means each time you build the package, the same .deb is created.

This is of course not policy yet, but I see it as fundamentally
incompatible with packages which FTBFS from time to time. If we want
the end result to be always the same, then failing from time to time
(which is sometimes the end result) should never happen.

In other words, if we don't take deterministic builds seriously
(as in "every time I try to build the package, the build does not fail")
how can we expect to be reproducible in the future?

It is interesting, however, what you mention about thresholds,
statistical packages, and simulations, so here is the math
I do applied to Debian:

Let's say that we have 25000 source packages in stretch, and
I want to build all of them and not have a single failure.

Since, as you point out, there are quite a bunch of statistical
packages with tests based on random numbers, the mathematical
probability that there is some failure will always be > 0.

Ok, then. Let's suppose that I'm happy enough if the expected number
of packages that fail to build is closer to 0 than to 1.

So, let's make the probability of failure for each package to be half
of 1/25000. That would be 0.002%.

Not realistic enough? Let's assume additionally that 24950 source
packages build ok all the time, and only 50 of them have a probability
of failure > 0.

I still want to build all packages and have 0 or 1 failures,
so in this case the probability should be 1/50/2, i.e. 1%.

I think this is still feasible.

> The "fix" for such cases is the increasing of the threshold or disabling
> the test completely. Because you can do nothing with it due to the
> nature of numerical simulations.

I really wish it would always be as simple as that.

But as far as there are people in this project who consider that a
package which FTBFS on single-CPU machines more than 50% of the time
is ok "because it does not usually fail in buildd.debian.org",
we are doomed.

See the FTBFS-randomly bugs open against rygel, libsecret
or libsoup2.4, for example.

> > Really, we need more people doing QA, and not stop doing it "because
> > we are near the freeze".
> 
> If you are maintaining the package several years, fixing most of its
> bugs, hoping to see it in release and trying to escape major changes
> several months before the freeze.. Sure, it will actively be defended
> from maintainers if some pseudo-reasons for its removal appear just
> before the freeze. This fact has to be considered as well.

Well, you will see that I've downgraded all the bugs of this type to
important (btw: please do not call this "pseudo-reasons").

The problem I see with this threshold thing is that every maintainer
seems to have his own threshold, different from the others.

In case we decide about RC-ness depending on probability of failure:
What threshold do you think we should use for a single package and why?

[ I say that 1% of failure is the maximum we should allow, and I've
  explained why, but I would love to hear your opinion on this ].

Thanks a lot.

-- 
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#848859: FTBFS randomly (failing tests)

[Santiago Vila]

On Wed, Jan 04, 2017 at 08:44:17AM +0100, Ole Streicher wrote:

> > It's in Release Policy: Packages *must* autobuild *without* failure.
> > 
> > If a package fails to build from time to time, that's a failure.
> 
> Packages actually *do* fail from time to time, when I look into my
> autobuilder. Not due to the package, but due to glitches within the
> buildd infrastructure. Would you consider this a failure?

If the package is not to blame, of course not.

I'm speaking about packages which intrinsically fail with a
probability p such that 0 < p < 1. Funny example of what
I call "instrinsically":

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838828

No matter how much glitch-free is the autobuilder you use to build the
above package, it will fail to build 1 every 147 times on average,
mathematically, because the test is wrongly designed.

> >> I totally agree that catching random failures
> >> is a good quality measure, but this is IMO severity "important" at maximum.
> > 
> > Well, would you say it's RC if it fails 99% of the time?
> > I guess you would.
> 
> I would consider a bug RC if it actually doesn't build on our buildds.

Aha! But *that* is what is not written in policy anywhere.

Not only it's not written anywhere, it's invalidated by current practice
every day. Examples here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lamby%40debian.org

or here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lucas%40debian.org

or even here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=sanvila%40debian.org


Are you proposing that Lucas Nussbaum, Chris Lamb or myself stop
reporting FTBFS bugs as serious unless we can point to a failed build
log at buildd.debian.org?

That restricted way of reporting bugs surely may not be right.

> [...]
> Doing release QA just before the release leads to quick hacks to keep
> things there, while a continious QA really solves them.

Well, I started doing QA more than a year ago, to check for
"dpkg-buildpackage -A". As a side effect, I started to report each
and every package which FTBFS for whatever reason.

Really, we need more people doing QA, and not stop doing it "because
we are near the freeze".

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#848859: (no subject)

[Santiago Vila]

severity 846116 important
severity 680038 important
severity 828929 important
severity 834686 important
severity 834962 important
severity 842836 important
severity 844083 important
severity 844088 important
severity 844571 important
severity 845164 important
severity 846021 important
severity 846115 important
severity 846300 important
severity 846318 important
severity 848054 important
severity 848055 important
severity 848403 important
severity 849775 important
severity 849217 important
severity 832865 important
severity 837067 important
severity 848063 important
severity 849363 important
severity 846026 important
severity 841904 important
severity 847288 important
severity 848859 important
severity 841098 important
severity 843038 important
severity 848409 important
severity 710696 important
thanks

Hello.

I'm setting the severity of this bug to "important" not because
I don't think it is not RC (as Release Policy still says that
packages must autobuild *without* failure), but because the
Release Managers are considering to decide about RC-ness
of this kind of bugs based on the probability of failure.

We don't know what kind of threshold there will be for stretch, so I
strongly recommend that you act as if this bug was serious and RC,
especially if the failures happen very often on any kind of
autobuilder which is not misconfigured.

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#848859: FTBFS randomly (failing tests)

[Santiago Vila]

On Tue, 27 Dec 2016, Ole Streicher wrote:

> Hi Santiago,

Hello Ole. Thanks for your reply. Please don't forget to Cc: me if you
expect your message to be read.

> > In particular, if something happens 1 every 20 times on average, the
> > fact that it did not happen when you try 10 times does not mean in any
> > way that it may not happen.
> 
> 
> I must however say that I don't see why a package that fails to build
> once in 20 builds would have a release critical problem:

It's in Release Policy: Packages *must* autobuild *without* failure.

If a package fails to build from time to time, that's a failure.

> There is nothing in our policy that requires a reproducible or even a
> always successful build.

Please don't mix "reproducible" with "always successful build".

They are different things and nobody is making "reproducible builds"
policy yet.

But "always successful" has always been release policy:

https://release.debian.org/stretch/rc_policy.txt

Please read the paragraph saying "packages must autobuild without
failure". That paragraph is the very reason FTBFS bugs are serious
since a lng time.

> I totally agree that catching random failures
> is a good quality measure, but this is IMO severity "important" at maximum.

Well, would you say it's RC if it fails 99% of the time?
I guess you would.

Would you say it's RC if it fails 0.001% of the time?
I guess you would not, since you have just said that 0.05% does not
deserve to be serious.

So, you are implicitly saying that packages which FTBFS with a
low probability does not deserve a serious bug.

However, there is no threshold at all in policy, and if you think
about it, any such threshold would be quite arbitrary indeed:
Why would 50% of failure be RC while 49% of failure is not?

[ To me, the mere fact that we are able to *measure* the probability
  of failure already means that it is too high ].


Anyway, there will be plenty of time to discuss about this because I'm
going to downgrade all the FTBFS-randomly bugs I've detected until
Release Managers say something about the subject.

Then I expect most (if not all) of them will become serious and RC
again.

> And it would be nice to have this QA test not just before the release,
> but already early in the release cycle. This would help a lot to avoid
> stressful bugfixes just before the freeze.

Well, if you see my list of FTBFS-randomly bug here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-randomly;users=sanv...@debian.org

you will see that I started to report FTBFS-randomly bugs several
months ago, not last week, and not last month.

What would really help is to have somebody else reporting these bugs,
because apparently very few people want to report them.

Also, you can't seriously "complain" that a bug reporter didn't not
report something earlier! Of course that it would be nice to do this
kind of QA stuff at every point in the release cycle, but as the same
software that we maintain, my bug reports come with no warranty, not
even the warranty that the bug is reported "as soon as it exists"! :-)

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#849574: gtkdataboxmm: FTBFS when built with dpkg-buildpackage -A (Makefile error)

[Santiago Vila]

Package: src:gtkdataboxmm
Version: 0.9.4-4
Severity: serious

Hello Andreas.

I tried to build this package with "dpkg-buildpackage -A"
but it failed:


[...]

Generating dot graphs using 2 parallel threads...
Running dot for graph 1/17
Running dot for graph 2/17
Running dot for graph 3/17
Running dot for graph 4/17
Running dot for graph 5/17
Running dot for graph 6/17
Running dot for graph 7/17
Running dot for graph 8/17
Running dot for graph 9/17
Running dot for graph 10/17
Running dot for graph 11/17
Running dot for graph 12/17
Running dot for graph 13/17
Running dot for graph 14/17
Running dot for graph 15/17
Running dot for graph 16/17
Running dot for graph 17/17
Patching output file 1/13
Patching output file 2/13
Patching output file 3/13
Patching output file 4/13
Patching output file 5/13
Patching output file 6/13
Patching output file 7/13
Patching output file 8/13
Patching output file 9/13
Patching output file 10/13
Patching output file 11/13
Patching output file 12/13
Patching output file 13/13
lookup cache used 875/65536 hits=5229 misses=1330
finished...
/usr/bin/perl -- "/usr/share/mm-common/doctool/doc-postprocess.pl" 
'reference/html/*.html'
/usr/bin/xsltproc --stringparam book_title 'gtkdataboxmm Reference Manual' 
--stringparam book_name 'gtkdataboxmm' --stringparam book_base html -o 
reference/gtkdataboxmm.devhelp2 
"/usr/share/mm-common/doctool/tagfile-to-devhelp2.xsl" 
reference/gtkdataboxmm.tag
make[3]: *** No rule to make target 'reference/html/classGtk_1_1Widget.html', 
needed by 'all-local'.  Stop.
make[3]: Leaving directory '/<>/doc'
Makefile:564: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/<>'
dh_auto_build: make -j1 returned exit code 2
debian/rules:17: recipe for target 'override_dh_auto_build-indep' failed
make[1]: *** [override_dh_auto_build-indep] Error 2
make[1]: Leaving directory '/<>'
debian/rules:7: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


Ii suspect this to be a genuine "dpkg-buildpackage -A" bug, because
it builds ok in reproducible builds (where plain "dpkg-buildpackage"
is still the norm).

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#848859: Lowering the bug`s severity

[Santiago Vila]

On Tue, Dec 27, 2016 at 10:11:56AM +0100, Anton Gladky wrote:
> 2016-12-27 9:50 GMT+01:00 Santiago Vila <sanv...@unex.es>:
> > This means, if you are bad at math, that the error will happen once
> > every 20 tries. If you only built it 5 times, you did not really tried
> > to reproduce it.
> 
> I'm not going to build every package 20 times to catch a "possible" bug,

The build logs I sent prove that there is bug, so it's not a "possible" bug.

> The main source of information for this type of bugs is the
> buildds [1] for me. They are happy at the moment.

The main, maybe, but it should not be the only one.

In particular, if something happens 1 every 20 times on average, the
fact that it did not happen when you try 10 times does not mean in any
way that it may not happen.

This is basic math, and everybody here (debian-science) should be aware of that.

Sorry if you don't like my communication style. Please try not to
dismiss completely the build logs I sent and maybe you will see how my
communication style improves greatly.

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#848859: Lowering the bug`s severity

[Santiago Vila]

On Tue, Dec 27, 2016 at 08:20:54AM +0100, Anton Gladky wrote:
> severity 848859 minor
> tags 848859 +unreproducible
> thanks
> 
> Hi  Santiago,
> 
> thanks for your bugreport! I tried to reproduce the failing
> test, building getfem on barriere.d,o 5 times but in all
> cases it did not failed. Also the last upload of getfem was
> successfully built on all supported platforms.
> 
> Nevertheless I am not closing the bug, but lowering its
> severity for the case if the bug will appear again.

The bug is probably still there, just that you didn't really bother to
reproduce it. I clearly said this in my bug report:

"The failure rate is around 5%, so if you try to reproduce this,
please try a *lot* of times."

This means, if you are bad at math, that the error will happen once
every 20 tries. If you only built it 5 times, you did not really tried
to reproduce it.

And then you didn't bother to Cc:me on this message, which I had to
read from debian-bugs-rc@l.d.o.

For this reason, I consider this downgrade of yours unacceptable and a
bad joke.

I'm going to repeat my tests in unstable, just for the case that some
already-fixed build-dependency was to blame for this, but if I still
reproduce this I will restore the original severity, as packages *must*
build from source *without* failure, this is not an invention of mine,
it's Release Policy.

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#847974: xmds2: FTBFS in stretch

[Santiago Vila]

Package: src:xmds2
Version: 2.2.2+dfsg-2
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2
   dh_testdir -i
   dh_update_autotools_config -i
   dh_auto_configure -i
   dh_auto_build -i
make -j1
make[1]: Entering directory '/<>/xmds2-2.2.2+dfsg'
make[2]: Entering directory '/<>/xmds2-2.2.2+dfsg/xpdeint'
Setting top to   : 
/<>/xmds2-2.2.2+dfsg/xpdeint 
Setting out to   : 
/<>/xmds2-2.2.2+dfsg/xpdeint 
Setting top == out (remember to use "update_outputs")
Checking for the Cheetah python module   : ok 

[... snipped ...]

Copyright 2000-2014 Graham Dennis, Joseph Hope, Mattias Johnsson
and the xmds team
Generating source code...
... done
Compiling simulation...
... done. Type './lorenz' to run.
Segment 1: minimum timestep: 1.296096e-05 maximum timestep: 4.00e-03
  Attempted 9669 steps, 0.00% steps failed.
Generating output for lorenz
xsil2graphics2 from xmds2 version 2.2.2 "XMDS2 is a game of two halves" (Debian 
package 2.2.2+dfsg-2)
Generating output for MATLAB/Octave.
Writing import script for 'lorenz.xsil' to 'lorenz.m'.
octave: X11 DISPLAY environment variable not set
octave: disabling GUI features
warning: the size of octave_hdf5_id is smaller than the size of HDF5 hid_t
warning: called from
lorenz.m at line 2 column 3
HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread 140615878277440:
  #000: ../../../src/H5G.c line 464 in H5Gopen2(): not a location
major: Invalid arguments to routine
minor: Inappropriate type
  #001: ../../../src/H5Gloc.c line 253 in H5G_loc(): invalid object ID
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread 140615878277440:
  #000: ../../../src/H5Gdeprec.c line 796 in H5Gget_num_objs(): not a location 
ID
major: Invalid arguments to routine
minor: Inappropriate type
  #001: ../../../src/H5Gloc.c line 253 in H5G_loc(): invalid object ID
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread 140615878277440:
  #000: ../../../src/H5G.c line 725 in H5Gclose(): not a group
major: Invalid arguments to routine
minor: Inappropriate type
error: structure has no member 't'
error: called from
lorenz.m at line 3 column 8

error: writing file '/sbuild-nonexistent/.octave_hist': No such file or 
directory
error: ignoring octave_execution_exception while preparing to exit
debian/rules:15: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>/xmds2-2.2.2+dfsg'
debian/rules:9: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


The build history I keep is like this:

Status: successful  xmds2_2.2.2+dfsg-2_amd64-20161118T125207Z
Status: successful  xmds2_2.2.2+dfsg-2_amd64-20161123T025916Z
Status: successful  xmds2_2.2.2+dfsg-2_amd64-20161128T001945Z
Status: successful  xmds2_2.2.2+dfsg-2_amd64-20161202T231309Z
Status: failed  xmds2_2.2.2+dfsg-2_amd64-20161207T065906Z
Status: failed  xmds2_2.2.2+dfsg-2_amd64-20161208T214652Z
Status: failed  xmds2_2.2.2+dfsg-2_amd64-20161208T214639Z
Status: failed  xmds2_2.2.2+dfsg-2_amd64-20161208T214702Z

Something happened in stretch between 2016-12-02 and 2016-12-07
that made this package to FTBFS.

Please tell me if you need a full build log, and I will attach it.

(Using sbuild on a single CPU virtual machine, it always fails for me,
on different machines, so it should be easy to reproduce).

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#845742: yade: FTBFS (error: unable to find numeric literal operator)

[Santiago Vila]

Package: src:yade
Version: 2016.06a-5
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --builddirectory=/<>/debian/build --with python2
   dh_testdir -i -O--builddirectory=/<>/debian/build
   dh_update_autotools_config -i 
-O--builddirectory=/<>/debian/build
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- -DruntimePREFIX="/usr" -DCMAKE_INSTALL_PREFIX="/usr" 
-DNOSUFFIX=ON -DLIBRARY_OUTPUT_PATH=lib/x86_64-linux-gnu -DUSE_QT5=ON 
-DENABLE_SPH=ON
cmake ../.. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DruntimePREFIX=/usr 
-DCMAKE_INSTALL_PREFIX=/usr -DNOSUFFIX=ON 
-DLIBRARY_OUTPUT_PATH=lib/x86_64-linux-gnu -DUSE_QT5=ON -DENABLE_SPH=ON
-- The C compiler identification is GNU 6.2.0
-- The CXX compiler identification is GNU 6.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info

[... snipped ...]

 from 
/usr/include/boost/math/special_functions/factorials.hpp:14,
 from /usr/include/boost/math/special_functions/binomial.hpp:14,
 from 
/usr/include/boost/numeric/odeint/stepper/bulirsch_stoer_dense_out.hpp:31,
 from /usr/include/boost/numeric/odeint.hpp:45,
 from 
/<>/pkg/dem/RungeKuttaCashKarp54Integrator.hpp:5,
 from 
/<>/pkg/dem/RungeKuttaCashKarp54Integrator.cpp:2:
/usr/include/boost/math/special_functions/detail/erf_inv.hpp:361:92: error: 
unable to find numeric literal operator 'operator""Q'
boost::math::erfc_inv(static_cast(BOOST_MATH_BIG_CONSTANT(T, 
64, 1e-800)), Policy());

^~~
/usr/include/boost/math/special_functions/detail/erf_inv.hpp:361:92: note: use 
-std=gnu++11 or -fext-numeric-literals to enable more built-in suffixes
In file included from /usr/include/boost/math/special_functions/erf.hpp:1149:0,
 from /usr/include/boost/math/special_functions/gamma.hpp:2070,
 from 
/usr/include/boost/math/special_functions/factorials.hpp:14,
 from /usr/include/boost/math/special_functions/binomial.hpp:14,
 from 
/usr/include/boost/numeric/odeint/stepper/bulirsch_stoer_dense_out.hpp:31,
 from /usr/include/boost/numeric/odeint.hpp:45,
 from 
/<>/pkg/dem/RungeKuttaCashKarp54Integrator.hpp:5,
 from 
/<>/pkg/dem/RungeKuttaCashKarp54Integrator.cpp:2:
/usr/include/boost/math/special_functions/detail/erf_inv.hpp:362:88: error: 
unable to find numeric literal operator 'operator""Q'
 if(is_value_non_zero(static_cast(BOOST_MATH_BIG_CONSTANT(T, 64, 
1e-900

^~ 
/usr/include/boost/math/special_functions/detail/erf_inv.hpp:362:88: note: use 
-std=gnu++11 or -fext-numeric-literals to enable more built-in suffixes
In file included from /usr/include/boost/math/special_functions/erf.hpp:1149:0,
 from /usr/include/boost/math/special_functions/gamma.hpp:2070,
 from 
/usr/include/boost/math/special_functions/factorials.hpp:14,
 from /usr/include/boost/math/special_functions/binomial.hpp:14,
 from 
/usr/include/boost/numeric/odeint/stepper/bulirsch_stoer_dense_out.hpp:31,
 from /usr/include/boost/numeric/odeint.hpp:45,
 from 
/<>/pkg/dem/RungeKuttaCashKarp54Integrator.hpp:5,
 from 
/<>/pkg/dem/RungeKuttaCashKarp54Integrator.cpp:2:
/usr/include/boost/math/special_functions/detail/erf_inv.hpp:363:92: error: 
unable to find numeric literal operator 'operator""Q'
boost::math::erfc_inv(static_cast(BOOST_MATH_BIG_CONSTANT(T, 
64, 1e-900)), Policy());

^~~
/usr/include/boost/math/special_functions/detail/erf_inv.hpp:363:92: note: use 
-std=gnu++11 or -fext-numeric-literals to enable more built-in suffixes
CMakeFiles/yade.dir/build.make:2201: recipe for target 
'CMakeFiles/yade.dir/pkg/dem/RungeKuttaCashKarp54Integrator.cpp.o' failed
make[3]: *** [CMakeFiles/yade.dir/pkg/dem/RungeKuttaCashKarp54Integrator.cpp.o] 
Error 1
make[3]: Leaving directory '/<>/debian/build'
CMakeFiles/Makefile2:174: recipe for target 'CMakeFiles/yade.dir/all' failed
make[2]: *** [CMakeFiles/yade.dir/all] Error 2
make[2]: Leaving directory '/<>/debian/build'
Makefile:130: recipe for target 'all' failed
make[1]: *** [all] 

Bug#844373: closing 844373

[Santiago Vila]

reassign 844373 ros-catkin
affects 844373 src:ros-image-common
thanks

On Tue, 15 Nov 2016, Jochen Sprickerhof wrote:

> close 844373 
> thanks
> 
> Hi,
> 
> the files accidentally ended in there, due to a new install rule in
> the googletest package. This was fixed in #844199 and a rebuild was
> triggered in #844322, so this should be fine again.

So, if I understood correctly, this was really a bug in ros-catkin.

If that's ok, please also merge with whatever other duplicates this
may have.

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#844373: ros-image-common: FTBFS (incompatible build-dependencies)

[Santiago Vila]

Package: librospack-dev,libgtest-dev,src:ros-image-common
Severity: serious

Dear maintainer:

I tried to build ros-image-common in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
Unpacking librospack-dev (2.3.1-1+b1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-dJJuDK/111-librospack-dev_2.3.1-1+b1_amd64.deb (--unpack):
 trying to overwrite '/usr/include/gtest/gtest-death-test.h', which is also in 
package libgtest-dev:amd64 1.7.0-4
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)


(I can provide a full build log if required).

Please do agree on which package is to blame for this...

I see that both librospack-dev and libgtest-dev contain gtest-death-test.h.

If it's ok that they both contain such file, they should conflict at
each other (bug in those packages), but then ros-image-common would
continue to be unbuildable anyway (bug still in ros-image-common).

OTOH, if one of the packages librospack-dev or libgtest-dev should not
contain the file, then please reassign to the package at fault and
also send an "affects" command to the control address, so that we can
still see that this bug affects src:ros-image-common in its BTS web page.

Sorry that I can't tell for sure which one of those cases is the truth,
I just detected this problem by trying to build ros-image-common.

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#842677: Fixed #842677

[Santiago Vila]

On Wed, Nov 02, 2016 at 11:01:26PM +0100, Ruben Undheim wrote:
> Hi Santiago!
> 
> Thanks for reporting the bug.
> 
> I've uploaded the fix, but I completely forgot to add your name to the
> changelog!

Oh, don't worry about that.

You fixed the bug very quickly, which is already a form of appreciation.

Thanks a lot.

-- 
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#842677: libosmocore: FTBFS randomly (failing tests)

[Santiago Vila]

tags 842677 + patch
thanks

The following patch (without debian/changelog entries) disables the
failing tests.

Thanks.diff -Nru libosmocore-0.9.0/debian/patches/0006-Disable-unreliable-tests.patch 
libosmocore-0.9.0/debian/patches/0006-Disable-unreliable-tests.patch
--- libosmocore-0.9.0/debian/patches/0006-Disable-unreliable-tests.patch
1970-01-01 01:00:00.0 +0100
+++ libosmocore-0.9.0/debian/patches/0006-Disable-unreliable-tests.patch
2016-05-10 22:42:43.0 +0200
@@ -0,0 +1,22 @@
+From: Santiago Vila <sanv...@debian.org>
+Subject: Disable unreliable tests
+
+--- a/tests/testsuite.at
 b/tests/testsuite.at
+@@ -141,16 +141,3 @@
+ cat $abs_srcdir/stats/stats_test.ok > expout
+ AT_CHECK([$abs_top_builddir/tests/stats/stats_test], [0], [expout], [ignore])
+ AT_CLEANUP
+-
+-AT_SETUP([bssgp-fc])
+-AT_KEYWORDS([bssgp-fc])
+-cat $abs_srcdir/gb/bssgp_fc_tests.ok > expout
+-cat $abs_srcdir/gb/bssgp_fc_tests.err > experr
+-AT_CHECK([$abs_top_srcdir/tests/gb/bssgp_fc_tests.sh 
$abs_top_builddir/tests/gb], [0], [expout], [experr])
+-AT_CLEANUP
+-
+-AT_SETUP([timer])
+-AT_KEYWORDS([timer])
+-cat $abs_srcdir/timer/timer_test.ok > expout
+-AT_CHECK([$abs_top_builddir/tests/timer/timer_test -s 5], [0], [expout], 
[ignore])
+-AT_CLEANUP
diff -Nru libosmocore-0.9.0/debian/patches/series 
libosmocore-0.9.0/debian/patches/series
--- libosmocore-0.9.0/debian/patches/series 2016-05-10 22:03:29.0 
+0200
+++ libosmocore-0.9.0/debian/patches/series 2016-05-10 22:42:43.0 
+0200
@@ -3,3 +3,4 @@
 0003-Setting-library-version-explicitly.patch
 0004-Patched-structs-for-big-endian-architectures.patch
 0005-Set-HTML_TIMESTAMP-to-NO-to-make-build-reproducible.patch
+0006-Disable-unreliable-tests.patch
-- 
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#841285: freemat: FTBFS (cannot find -lclangTidyReadabilityModule)

[Santiago Vila]

On Wed, 19 Oct 2016, Gianfranco Costamagna wrote:

> Hi, this is because of the llvm transition.
> We switched to unversioned llvm to avoid further issues on the next llvm 
> defaults
> bump.
> 
> In this case, it is true that it fails to build with llvm-3.6, and it is also 
> true that
> llvm-toolchain-3.6 has been removed from unstable/testing (soon), so the bug 
> for sure
> (if a bug is here), can't be serious in any case)

Ok, I could agree that freemat is probably not to be blamed for this.

But this is of course a bug, and it is of course serious, because
packages in testing *must* be buildable in testing (release policy).

So, the bug would be really something like this:

"llvm 3.8 is not the default llvm compiler in stretch yet"

which seems RC enough to me, because we have already packages in
testing requiring llvm 3.8 to be the default.

Simple question: Are there more packages like this one, which fail
to build when llvm 3.8 is not the default?

If not, I'm ok with you closing this one as you already did.

But if yes, it might be worth to reopen, reassign to release.debian.org
and start using "affects" to track all of them.

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#841285: freemat: FTBFS (cannot find -lclangTidyReadabilityModule)

[Santiago Vila]

Package: src:freemat
Version: 4.2+dfsg1-3
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=cmake 
--builddirectory=/<>/freemat-4.2+dfsg1/debian/build --parallel
   dh_testdir -i -O--buildsystem=cmake 
-O--builddirectory=/<>/freemat-4.2\+dfsg1/debian/build -O--parallel
   dh_update_autotools_config -i -O--buildsystem=cmake 
-O--builddirectory=/<>/freemat-4.2\+dfsg1/debian/build -O--parallel
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/freemat-4.2+dfsg1'
dh_auto_configure -- -DCMAKE_INSTALL_PREFIX=/usr 
-DRESOURCEDIR=/usr/share/freemat -DCMAKE_BUILD_TYPE=Release 
-DCMAKE_C_FLAGS="-Wall -g -O2 
-fdebug-prefix-map=/<>/freemat-4.2+dfsg1=. -fstack-protector-strong 
-Wformat -Werror=format-security" -DCMAKE_C_FLAGS_DEBUG="-Wall -g -O2 
-fdebug-prefix-map=/<>/freemat-4.2+dfsg1=. -fstack-protector-strong 
-Wformat -Werror=format-security" -DCMAKE_C_FLAGS_RELEASE="-Wall -g -O2 
-fdebug-prefix-map=/<>/freemat-4.2+dfsg1=. -fstack-protector-strong 
-Wformat -Werror=format-security -DNDEBUG" -DCMAKE_SKIP_RPATH=ON -DUSE_LLVM=ON 
-DFORCE_BUNDLED_PCRE=OFF -DFORCE_BUNDLED_UMFPACK=OFF 
-DFORCE_BUNDLED_PORTAUDIO=OFF -DFORCE_BUNDLED_ZLIB=OFF -DFORCE_BUNDLED_AMD=OFF
cmake ../.. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_INSTALL_PREFIX=/usr 
-DRESOURCEDIR=/usr/share/freemat -DCMAKE_BUILD_TYPE=Release 
"-DCMAKE_C_FLAGS=-Wall -g -O2 
-fdebug-prefix-map=/<>/freemat-4.2+dfsg1=. -fstack-protector-strong 
-Wformat -Werror=format-security" "-DCMAKE_C_FLAGS_DEBUG=-Wall -g -O2 
-fdebug-prefix-map=/<>/freemat-4.2+dfsg1=. -fstack-protector-strong 
-Wformat -Werror=format-security" "-DCMAKE_C_FLAGS_RELEASE=-Wall -g -O2 
-fdebug-prefix-map=/<>/freemat-4.2+dfsg1=. -fstack-protector-strong 
-Wformat -Werror=format-security -DNDEBUG" -DCMAKE_SKIP_RPATH=ON -DUSE_LLVM=ON 
-DFORCE_BUNDLED_PCRE=OFF -DFORCE_BUNDLED_UMFPACK=OFF 
-DFORCE_BUNDLED_PORTAUDIO=OFF -DFORCE_BUNDLED_ZLIB=OFF -DFORCE_BUNDLED_AMD=OFF
-- The CXX compiler identification is GNU 6.2.0
-- The C compiler identification is GNU 6.2.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info

[... snipped ...]

[100%] Linking CXX executable FreeMat
cd /<>/freemat-4.2+dfsg1/debian/build/src && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/FreeMat.dir/link.txt --verbose=1
/usr/bin/c++   -g -O2 -fdebug-prefix-map=/<>/freemat-4.2+dfsg1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -O3 -DNDEBUG   -Wl,-z,relro 
CMakeFiles/FreeMat.dir/application.moc.cpp.o 
CMakeFiles/FreeMat.dir/application.cpp.o 
CMakeFiles/FreeMat.dir/FuncMode.moc.cpp.o 
CMakeFiles/FreeMat.dir/ScriptMode.moc.cpp.o 
CMakeFiles/FreeMat.dir/FuncMode.cpp.o CMakeFiles/FreeMat.dir/ScriptMode.cpp.o 
CMakeFiles/FreeMat.dir/FuncTerminal.cpp.o 
CMakeFiles/FreeMat.dir/MainApp.moc.cpp.o CMakeFiles/FreeMat.dir/MainApp.cpp.o 
CMakeFiles/FreeMat.dir/main.cpp.o CMakeFiles/FreeMat.dir/DumbTerminal.moc.cpp.o 
CMakeFiles/FreeMat.dir/DumbTerminal.cpp.o 
CMakeFiles/FreeMat.dir/Terminal.moc.cpp.o CMakeFiles/FreeMat.dir/Loader.cpp.o 
CMakeFiles/FreeMat.dir/Terminal.cpp.o CMakeFiles/FreeMat.dir/qrc_FreeMat.cxx.o 
CMakeFiles/FreeMat.dir/dummy.f.o  -o FreeMat  -L/usr/lib/llvm-3.6/lib -rdynamic 
../libs/libCore/libCore.a ../libs/libFN/libFN.a ../libs/libGraphics/libGrap
 hics.a ../libs/libFreeMat/libFreeMatlib.a ../libs/libXP/libXP.a 
../libs/libMex/libMex.a ../libs/libMatC/libMatC.a 
../libs/libFN/levmar-2.3/liblevmar.a ../libs/libMath/libLAPACK_C/liblapack_c.a 
../libs/libMath/libDynBlas/libdynblas.a ../libs/libMath/libBLAS_C/libblasref.a 
-lQtCore -lQtGui -lQtNetwork -lQtOpenGL -lQtXml -lQtSvg -lGLU -lGL -lncurses 
-lpcre -lfftw3 -lfftw3f -lz -larpack ../libs/libMath/libLAPACK_C/liblapack_c.a 
-lffi -lportaudio -lboost_math_c99 -lclang -lclangAnalysis 
-lclangApplyReplacements -lclangARCMigrate -lclangAST -lclangASTMatchers 
-lclangBasic -lclangCodeGen -lclangDriver -lclangDynamicASTMatchers -lclangEdit 
-lclangFormat -lclangFrontend -lclangFrontendTool -lclangIndex -lclangLex 
-lclangParse -lclangQuery -lclangRename -lclangRewrite -lclangRewriteFrontend 
-lclangSema -lclangSerialization -lclangStaticAnalyzerCheckers 
-lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend -lclangTidy 
-lclangTidyGoogleModule -lclangTidyLLVMModule -lclangTidyMiscModule -lclan
 gTidyReadabilityModule -lclangTidyUtils -lclang 
/usr/lib/llvm-3.6/lib/libLLVMExecutionEngine.a 
/usr/lib/llvm-3.6/lib/libLLVMOption.a /usr/lib/llvm-3.6/lib/libLLVMIRReader.a 
/usr/lib/llvm-3.6/lib/libLLVMLTO.a 

Bug#838327: dune-pdelab: FTBFS in testing (error: cannot convert 'mem_usage_t*' to 'GlobalLU_t*')

[Santiago Vila]

Package: src:dune-pdelab
Version: 2.4.1-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel
   dh_testdir -i -O--parallel
   dh_update_autotools_config -i -O--parallel
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
/usr/bin/dunecontrol autogen
WARNING: could not find module dune-alugrid,
   module is also unknown to pkg-config.
   Maybe you need to adjust PKG_CONFIG_PATH!
   dune-alugrid is suggested by dune-pdelab
Skipping dune-alugrid!
--- going to build dune-pdelab  ---

[... snipped ...]

libtool: link: g++ -std=c++11 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -fpermissive -pthread 
-pthread -Wl,-z -Wl,relro -o .libs/testgridfunctionspace 
testgridfunctionspace.o -pthread -Wl,-rpath -Wl,/usr/lib/openmpi/lib 
-Wl,--enable-new-dtags  ../../../lib/.libs/libdunepdelab.so -ldunegrid 
-ldunegeometry -ldunecommon -L/usr/lib/openmpi/lib -lmpi -lugS2 -lugS3 -ldevS 
-lm -pthread
g++ -std=c++11 -DHAVE_CONFIG_H -I. -I../../..  -pthread  -I./ -I./  -I./ -I./  
-I./ -I./  -I./ -I./  -I./ -I./  -I./ -I./ -DENABLE_POSIX_CLOCK -I../../.. 
-DGRIDSDIR="\"./grids\"" -DENABLE_UG   -pthread  -I./ -I./  -I./ -I./  -I./ 
-I./  -I./ -I./  -I./ -I./  -I./ -I./ -DENABLE_POSIX_CLOCK 
-I/usr/lib/openmpi/include/openmpi/opal/mca/event/libevent2021/libevent 
-I/usr/lib/openmpi/include/openmpi/opal/mca/event/libevent2021/libevent/include 
-I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi -pthread 
-DMPIPP_H -DENABLE_MPI=1  -I/usr/include/superlu -DENABLE_SUPERLU -Wdate-time 
-D_FORTIFY_SOURCE=2  -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -fpermissive -c -o 
testelasticity-testelasticity.o `test -f 'testelasticity.cc' || echo 
'./'`testelasticity.cc
In file included from /usr/include/dune/istl/paamg/amg.hh:13:0,
 from 
../../../dune/pdelab/backend/istl/seqistlsolverbackend.hh:15,
 from ../../../dune/pdelab/backend/istl/istlsolverbackend.hh:6,
 from ../../../dune/pdelab/backend/istl.hh:7,
 from testelasticity.cc:20:
/usr/include/dune/istl/superlu.hh: In static member function 'static void 
Dune::SuperLUSolveChooser::solve(superlu_options_t*, SuperMatrix*, 
int*, int*, int*, char*, double*, double*, SuperMatrix*, SuperMatrix*, void*, 
int, SuperMatrix*, SuperMatrix*, double*, double*, double*, double*, 
mem_usage_t*, SuperLUStat_t*, int*)':
/usr/include/dune/istl/superlu.hh:172:34: error: cannot convert 'mem_usage_t*' 
to 'GlobalLU_t*' for argument '19' to 'void dgssvx(superlu_options_t*, 
SuperMatrix*, int*, int*, int*, char*, double*, double*, SuperMatrix*, 
SuperMatrix*, void*, int, SuperMatrix*, SuperMatrix*, double*, double*, 
double*, double*, GlobalLU_t*, mem_usage_t*, SuperLUStat_t*, int*)'
  memusage, stat, info);
  ^
Makefile:1646: recipe for target 'testelasticity-testelasticity.o' failed
make[7]: *** [testelasticity-testelasticity.o] Error 1
make[7]: Leaving directory '/<>/dune/pdelab/test'
Makefile:2231: recipe for target 'check-am' failed
make[6]: *** [check-am] Error 2
make[6]: Leaving directory '/<>/dune/pdelab/test'
Makefile:1808: recipe for target 'check-recursive' failed
make[5]: *** [check-recursive] Error 1
make[5]: Leaving directory '/<>/dune/pdelab/test'
Makefile:638: recipe for target 'check-recursive' failed
make[4]: *** [check-recursive] Error 1
make[4]: Leaving directory '/<>/dune/pdelab'
Makefile:620: recipe for target 'check-recursive' failed
make[3]: *** [check-recursive] Error 1
make[3]: Leaving directory '/<>/dune'
Makefile:798: recipe for target 'check-recursive' failed
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory '/<>'
dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2
/usr/share/dune/dune-debian.mk:26: recipe for target 'override_dh_auto_test' 
failed
make[1]: *** [override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'
debian/rules:10: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


Seems a GCC 6 related problem.

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#836452: givaro: FTBFS when built with dpkg-buildpackage -A (chmod: cannot access '[...]/isgenerator.C': No such file or directory)

[Santiago Vila]

Package: src:givaro
Version: 4.0.2-2
Severity: serious
Tags: patch

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with autoreconf 
   dh_testdir -i
   dh_update_autotools_config -i
   dh_autoreconf -i
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'macros'.
libtoolize: copying file 'macros/libtool.m4'
libtoolize: copying file 'macros/ltoptions.m4'
libtoolize: copying file 'macros/ltsugar.m4'
libtoolize: copying file 'macros/ltversion.m4'
libtoolize: copying file 'macros/lt~obsolete.m4'

[... snipped ...]

make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/<>/examples/RecInt'
make[3]: Leaving directory '/<>/examples/RecInt'
make[3]: Entering directory '/<>/examples'
make[4]: Entering directory '/<>/examples'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/<>/examples'
make[3]: Leaving directory '/<>/examples'
make[2]: Leaving directory '/<>/examples'
Making install in benchmarks
make[2]: Entering directory '/<>/benchmarks'
make[3]: Entering directory '/<>/benchmarks'
make[4]: Entering directory '/<>/benchmarks'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/<>/benchmarks'
make[3]: Leaving directory '/<>/benchmarks'
make[2]: Leaving directory '/<>/benchmarks'
make[2]: Entering directory '/<>'
make[3]: Entering directory '/<>'
 /bin/mkdir -p '/<>/debian/tmp/usr/bin'
 /usr/bin/install -c givaro-config givaro-makefile 
'/<>/debian/tmp/usr/bin'
 /bin/mkdir -p '/<>/debian/tmp/usr/include'
 /usr/bin/install -c -m 644 givaro-config.h 
'/<>/debian/tmp/usr/include'
 /bin/mkdir -p '/<>/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig'
 /usr/bin/install -c -m 644 givaro.pc 
'/<>/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig'
make[3]: Leaving directory '/<>'
make[2]: Leaving directory '/<>'
make[1]: Leaving directory '/<>'
   dh_install -i
   dh_installdocs -i
   dh_installchangelogs -i
   debian/rules override_dh_installexamples
make[1]: Entering directory '/<>'
dh_installexamples -XMakefile -XMakefile.am -XMakefile.in
make[1]: Leaving directory '/<>'
   dh_lintian -i
   dh_perl -i
   dh_link -i
   dh_strip_nondeterminism -i
   dh_compress -i
   debian/rules override_dh_fixperms
make[1]: Entering directory '/<>'
dh_fixperms
chmod -x 
debian/libgivaro-dev/usr/share/doc/libgivaro-dev/examples/Polynomial/isgenerator.C
chmod: cannot access 
'debian/libgivaro-dev/usr/share/doc/libgivaro-dev/examples/Polynomial/isgenerator.C':
 No such file or directory
debian/rules:35: recipe for target 'override_dh_fixperms' failed
make[1]: *** [override_dh_fixperms] Error 1
make[1]: Leaving directory '/<>'
debian/rules:41: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


This happens because debian/libgivaro-dev/[...] does not exist,
as we are creating arch-independent packages only and libgivaro-dev
is "Arch: any".

The patch below (trivial but untested) might fix this.

Thanks.

--- a/debian/rules
+++ b/debian/rules
@@ -31,7 +31,7 @@ override_dh_auto_build-indep:
 override_dh_auto_test:
dh_auto_test --max-parallel=1
 
-override_dh_fixperms:
+override_dh_fixperms-arch:
dh_fixperms
chmod -x 
debian/libgivaro-dev/usr/share/doc/libgivaro-dev/examples/Polynomial/isgenerator.C
 

-- 
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#835609: ros-rviz: FTBFS in testing (conversion to non-scalar type requested)

[Santiago Vila]

Package: src:ros-rviz
Version: 1.12.1+dfsg-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel --with=python2 --buildsystem=cmake
   dh_testdir -i -O--parallel -O--buildsystem=cmake
   dh_update_autotools_config -i -O--parallel -O--buildsystem=cmake
   dh_auto_configure -i -O--parallel -O--buildsystem=cmake
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var
-- The C compiler identification is GNU 6.1.1
-- The CXX compiler identification is GNU 6.1.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features

[... snipped ...]


/<>/ros-rviz-1.12.1+dfsg/src/rviz/robot/robot_link.cpp: In 
constructor 'rviz::RobotLink::RobotLink(rviz::Robot*
, const LinkConstPtr&, const string&, bool, bool)':
/<>/ros-rviz-1.12.1+dfsg/src/rviz/robot/robot_link.cpp:265:101: 
error: conversion from 'std::vector::const_iterator {aka __gnu_cxx::__normal_iterator*, std::vector >}' 
to non-scalar type 'std::vector::const_iterator {aka __gnu_cxx::__normal_iterator*, std::vector 
>}' requested
 std::vector::const_iterator child_it = 
link->child_joints.begin();
 
^~


Seems that GCC 6 is even more strict than before.

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#835573: ros-common-msgs: FTBFS in testing (configure fails)

[Santiago Vila]

Package: src:ros-common-msgs
Version: 1.12.4-3
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel --buildsystem=cmake --with python2
   dh_testdir -i -O--parallel -O--buildsystem=cmake
   dh_update_autotools_config -i -O--parallel -O--buildsystem=cmake
   dh_auto_configure -i -O--parallel -O--buildsystem=cmake
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var
-- The C compiler identification is GNU 6.1.1
-- The CXX compiler identification is GNU 6.1.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features

[... snipped ...]

CMAKE_SKIP_INSTALL_RPATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SKIP_RPATH
CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS
CMAKE_STATIC_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_DEBUG
CMAKE_STATIC_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL
CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELEASE
CMAKE_STATIC_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STRIP
CMAKE_STRIP-ADVANCED:INTERNAL=1
//uname command
CMAKE_UNAME:INTERNAL=/bin/uname
//ADVANCED property for variable: CMAKE_VERBOSE_MAKEFILE
CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1
//Details about finding PythonInterp
FIND_PACKAGE_MESSAGE_DETAILS_PythonInterp:INTERNAL=[/usr/bin/python][v2.7.12()]
//Details about finding Threads
FIND_PACKAGE_MESSAGE_DETAILS_Threads:INTERNAL=[TRUE][v()]
GTEST_FROM_SOURCE_FOUND:INTERNAL=TRUE
GTEST_FROM_SOURCE_INCLUDE_DIRS:INTERNAL=/usr/include
GTEST_FROM_SOURCE_LIBRARIES:INTERNAL=gtest
GTEST_FROM_SOURCE_LIBRARY_DIRS:INTERNAL=/<>/obj-x86_64-linux-gnu/gtest
GTEST_FROM_SOURCE_MAIN_LIBRARIES:INTERNAL=gtest_main
//ADVANCED property for variable: GTEST_INCLUDE_DIR
GTEST_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_LIBRARY
GTEST_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_LIBRARY_DEBUG
GTEST_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_MAIN_LIBRARY
GTEST_MAIN_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_MAIN_LIBRARY_DEBUG
GTEST_MAIN_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: PYTHON_EXECUTABLE
PYTHON_EXECUTABLE-ADVANCED:INTERNAL=1
//This needs to be in PYTHONPATH when 'setup.py install' is called.
//  And it needs to match.  But setuptools won't tell us where
// it will install things.
PYTHON_INSTALL_DIR:INTERNAL=lib/python2.7/dist-packages
//CMAKE_INSTALL_PREFIX during last run
_GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX:INTERNAL=/usr

dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var returned 
exit code 1
debian/rules:6: recipe for target 'build-indep' failed
make: *** [build-indep] Error 255
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


Sorry, I have no idea why it fails, but the failure is reproducible easily.

Once you fix this, I would recommend that you try uploading this in
source-only form, then we will get pretty official build logs in
buildd.debian.org.

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#835576: ros-ros-comm-msgs: FTBFS in testing (configure fails)

[Santiago Vila]

Package: src:ros-ros-comm-msgs
Version: 1.11.2-3
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel --buildsystem=cmake --with python2
   dh_testdir -i -O--parallel -O--buildsystem=cmake
   dh_update_autotools_config -i -O--parallel -O--buildsystem=cmake
   dh_auto_configure -i -O--parallel -O--buildsystem=cmake
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var
-- The C compiler identification is GNU 6.1.1
-- The CXX compiler identification is GNU 6.1.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features

[... snipped ...]

CMAKE_SKIP_INSTALL_RPATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SKIP_RPATH
CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS
CMAKE_STATIC_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_DEBUG
CMAKE_STATIC_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL
CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELEASE
CMAKE_STATIC_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STRIP
CMAKE_STRIP-ADVANCED:INTERNAL=1
//uname command
CMAKE_UNAME:INTERNAL=/bin/uname
//ADVANCED property for variable: CMAKE_VERBOSE_MAKEFILE
CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1
//Details about finding PythonInterp
FIND_PACKAGE_MESSAGE_DETAILS_PythonInterp:INTERNAL=[/usr/bin/python][v2.7.12()]
//Details about finding Threads
FIND_PACKAGE_MESSAGE_DETAILS_Threads:INTERNAL=[TRUE][v()]
GTEST_FROM_SOURCE_FOUND:INTERNAL=TRUE
GTEST_FROM_SOURCE_INCLUDE_DIRS:INTERNAL=/usr/include
GTEST_FROM_SOURCE_LIBRARIES:INTERNAL=gtest
GTEST_FROM_SOURCE_LIBRARY_DIRS:INTERNAL=/<>/obj-x86_64-linux-gnu/gtest
GTEST_FROM_SOURCE_MAIN_LIBRARIES:INTERNAL=gtest_main
//ADVANCED property for variable: GTEST_INCLUDE_DIR
GTEST_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_LIBRARY
GTEST_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_LIBRARY_DEBUG
GTEST_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_MAIN_LIBRARY
GTEST_MAIN_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_MAIN_LIBRARY_DEBUG
GTEST_MAIN_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: PYTHON_EXECUTABLE
PYTHON_EXECUTABLE-ADVANCED:INTERNAL=1
//This needs to be in PYTHONPATH when 'setup.py install' is called.
//  And it needs to match.  But setuptools won't tell us where
// it will install things.
PYTHON_INSTALL_DIR:INTERNAL=lib/python2.7/dist-packages
//CMAKE_INSTALL_PREFIX during last run
_GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX:INTERNAL=/usr

dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var returned 
exit code 1
debian/rules:6: recipe for target 'build-indep' failed
make: *** [build-indep] Error 255
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


Sorry, I have no idea why it fails, but the failure is reproducible easily.

Once you fix this, I would recommend that you try uploading this in
source-only form, then we will get pretty official build logs in
buildd.debian.org.

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#835575: ros-pcl-msgs: FTBFS in testing (configure fails)

[Santiago Vila]

Package: src:ros-pcl-msgs
Version: 0.2.0-4
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel --buildsystem=cmake --with python2
   dh_testdir -i -O--parallel -O--buildsystem=cmake
   dh_update_autotools_config -i -O--parallel -O--buildsystem=cmake
   dh_auto_configure -i -O--parallel -O--buildsystem=cmake
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var
-- The C compiler identification is GNU 6.1.1
-- The CXX compiler identification is GNU 6.1.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features

[... snipped ...]

CMAKE_SKIP_INSTALL_RPATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SKIP_RPATH
CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS
CMAKE_STATIC_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_DEBUG
CMAKE_STATIC_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL
CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELEASE
CMAKE_STATIC_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STRIP
CMAKE_STRIP-ADVANCED:INTERNAL=1
//uname command
CMAKE_UNAME:INTERNAL=/bin/uname
//ADVANCED property for variable: CMAKE_VERBOSE_MAKEFILE
CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1
//Details about finding PythonInterp
FIND_PACKAGE_MESSAGE_DETAILS_PythonInterp:INTERNAL=[/usr/bin/python][v2.7.12()]
//Details about finding Threads
FIND_PACKAGE_MESSAGE_DETAILS_Threads:INTERNAL=[TRUE][v()]
GTEST_FROM_SOURCE_FOUND:INTERNAL=TRUE
GTEST_FROM_SOURCE_INCLUDE_DIRS:INTERNAL=/usr/include
GTEST_FROM_SOURCE_LIBRARIES:INTERNAL=gtest
GTEST_FROM_SOURCE_LIBRARY_DIRS:INTERNAL=/<>/obj-x86_64-linux-gnu/gtest
GTEST_FROM_SOURCE_MAIN_LIBRARIES:INTERNAL=gtest_main
//ADVANCED property for variable: GTEST_INCLUDE_DIR
GTEST_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_LIBRARY
GTEST_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_LIBRARY_DEBUG
GTEST_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_MAIN_LIBRARY
GTEST_MAIN_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_MAIN_LIBRARY_DEBUG
GTEST_MAIN_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: PYTHON_EXECUTABLE
PYTHON_EXECUTABLE-ADVANCED:INTERNAL=1
//This needs to be in PYTHONPATH when 'setup.py install' is called.
//  And it needs to match.  But setuptools won't tell us where
// it will install things.
PYTHON_INSTALL_DIR:INTERNAL=lib/python2.7/dist-packages
//CMAKE_INSTALL_PREFIX during last run
_GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX:INTERNAL=/usr

dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var returned 
exit code 1
debian/rules:6: recipe for target 'build-indep' failed
make: *** [build-indep] Error 255
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


Sorry, I have no idea why it fails, but the failure is reproducible easily.

Once you fix this, I would recommend that you try uploading this in
source-only form, then we will get pretty official build logs in
buildd.debian.org.

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#835574: ros-navigation-msgs: FTBFS in testing (configure fails)

[Santiago Vila]

Package: src:ros-navigation-msgs
Version: 1.13.0-3
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel --buildsystem=cmake --with python2
   dh_testdir -i -O--parallel -O--buildsystem=cmake
   dh_update_autotools_config -i -O--parallel -O--buildsystem=cmake
   dh_auto_configure -i -O--parallel -O--buildsystem=cmake
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var
-- The C compiler identification is GNU 6.1.1
-- The CXX compiler identification is GNU 6.1.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features

[... snipped ...]

CMAKE_SKIP_INSTALL_RPATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_SKIP_RPATH
CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS
CMAKE_STATIC_LINKER_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_DEBUG
CMAKE_STATIC_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL
CMAKE_STATIC_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELEASE
CMAKE_STATIC_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO
CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_STRIP
CMAKE_STRIP-ADVANCED:INTERNAL=1
//uname command
CMAKE_UNAME:INTERNAL=/bin/uname
//ADVANCED property for variable: CMAKE_VERBOSE_MAKEFILE
CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1
//Details about finding PythonInterp
FIND_PACKAGE_MESSAGE_DETAILS_PythonInterp:INTERNAL=[/usr/bin/python][v2.7.12()]
//Details about finding Threads
FIND_PACKAGE_MESSAGE_DETAILS_Threads:INTERNAL=[TRUE][v()]
GTEST_FROM_SOURCE_FOUND:INTERNAL=TRUE
GTEST_FROM_SOURCE_INCLUDE_DIRS:INTERNAL=/usr/include
GTEST_FROM_SOURCE_LIBRARIES:INTERNAL=gtest
GTEST_FROM_SOURCE_LIBRARY_DIRS:INTERNAL=/<>/obj-x86_64-linux-gnu/gtest
GTEST_FROM_SOURCE_MAIN_LIBRARIES:INTERNAL=gtest_main
//ADVANCED property for variable: GTEST_INCLUDE_DIR
GTEST_INCLUDE_DIR-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_LIBRARY
GTEST_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_LIBRARY_DEBUG
GTEST_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_MAIN_LIBRARY
GTEST_MAIN_LIBRARY-ADVANCED:INTERNAL=1
//ADVANCED property for variable: GTEST_MAIN_LIBRARY_DEBUG
GTEST_MAIN_LIBRARY_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: PYTHON_EXECUTABLE
PYTHON_EXECUTABLE-ADVANCED:INTERNAL=1
//This needs to be in PYTHONPATH when 'setup.py install' is called.
//  And it needs to match.  But setuptools won't tell us where
// it will install things.
PYTHON_INSTALL_DIR:INTERNAL=lib/python2.7/dist-packages
//CMAKE_INSTALL_PREFIX during last run
_GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX:INTERNAL=/usr

dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None 
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var returned 
exit code 1
debian/rules:6: recipe for target 'build-indep' failed
make: *** [build-indep] Error 255
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


Sorry, I have no idea why it fails, but the failure is reproducible easily.

Once you fix this, I would recommend that you try uploading this in
source-only form, then we will get pretty official build logs in
buildd.debian.org.

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#813951: freefoam: FTBFS with libopenmpi 1.10

[Santiago Vila]

Hi.

Any progress on this? I can't promise to test the resulting packages,
but honestly, the situation can't be worse than this:

https://buildd.debian.org/status/package.php?p=freefoam

So if anybody can check that the patch I posted makes the package to
build again, then an upload of the package which just applies the
patch can only be an improvement over the current status.

(In the unlikely case that the package does not work well enough, we
might better let the actual users (which I'm not yet) to test the new
packages now instead of doing it when we are closer to the freeze).

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#834982: sdformat: FTBFS in testing ('_link' has incomplete type)

[Santiago Vila]

Package: src:sdformat
Version: 4.1.0-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel
   dh_testdir -i -O--parallel
   dh_update_autotools_config -i -O--parallel
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- \
-DUSE_EXTERNAL_URDF:BOOL=True \
-DUSE_UPSTREAM_CFLAGS:BOOL=False \
-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DUSE_EXTERNAL_URDF:BOOL=True 
-DUSE_UPSTREAM_CFLAGS:BOOL=False -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo
-- The C compiler identification is GNU 6.1.1
-- The CXX compiler identification is GNU 6.1.1

[... snipped ...]

 class shared_ptr;
   ^~
/<>/src/parser_urdf.cc: In function 'void 
ReduceSDFExtensionJointFrameReplace(std::vector::iterator, UrdfLinkPtr)':
/<>/src/parser_urdf.cc:3832:17: error: '_link' has incomplete type
 UrdfLinkPtr _link)
 ^
In file included from /usr/include/boost/throw_exception.hpp:42:0,
 from /usr/include/boost/lexical_cast/bad_lexical_cast.hpp:28,
 from /usr/include/boost/lexical_cast.hpp:31,
 from /<>/include/sdf/Param.hh:23,
 from /<>/include/sdf/Element.hh:24,
 from 
/<>/obj-x86_64-linux-gnu/include/sdf/sdf.hh:5,
 from /<>/src/parser_urdf.cc:31:
/usr/include/boost/exception/exception.hpp:148:11: note: declaration of 
'UrdfLinkPtr {aka class boost::shared_ptr}'
 class shared_ptr;
   ^~
In file included from /usr/include/c++/6/bits/stl_algobase.h:67:0,
 from /usr/include/c++/6/bits/char_traits.h:39,
 from /usr/include/c++/6/ios:40,
 from /usr/include/c++/6/istream:38,
 from /usr/include/c++/6/fstream:38,
 from /<>/src/parser_urdf.cc:17:
/usr/include/c++/6/bits/stl_iterator.h: In instantiation of 
'__gnu_cxx::__normal_iterator<_Iterator, _Container>& 
__gnu_cxx::__normal_iterator<_Iterator, _Container>::operator++() [with 
_Iterator = boost::shared_ptr*; _Container = 
std::vector]':
/<>/src/parser_urdf.cc:995:48:   required from here
/usr/include/c++/6/bits/stl_iterator.h:792:2: error: cannot increment a pointer 
to incomplete type 'boost::shared_ptr'
  ++_M_current;
  ^~~~
/usr/include/c++/6/bits/stl_iterator.h: In instantiation of 
'__gnu_cxx::__normal_iterator<_Iterator, _Container>& 
__gnu_cxx::__normal_iterator<_Iterator, _Container>::operator++() [with 
_Iterator = boost::shared_ptr*; _Container = 
std::vector]':
/<>/src/parser_urdf.cc:1110:54:   required from here
/usr/include/c++/6/bits/stl_iterator.h:792:2: error: cannot increment a pointer 
to incomplete type 'boost::shared_ptr'
/usr/include/c++/6/bits/stl_iterator.h: In instantiation of 
'__gnu_cxx::__normal_iterator<_Iterator, _Container>& 
__gnu_cxx::__normal_iterator<_Iterator, _Container>::operator++() [with 
_Iterator = const boost::shared_ptr*; _Container = 
std::vector]':
/<>/src/parser_urdf.cc:2985:9:   required from here
/usr/include/c++/6/bits/stl_iterator.h:792:2: error: cannot increment a pointer 
to incomplete type 'const boost::shared_ptr'
/usr/include/c++/6/bits/stl_iterator.h: In instantiation of 
'__gnu_cxx::__normal_iterator<_Iterator, _Container>& 
__gnu_cxx::__normal_iterator<_Iterator, _Container>::operator++() [with 
_Iterator = const boost::shared_ptr*; _Container = 
std::vector]':
/<>/src/parser_urdf.cc:3107:9:   required from here
/usr/include/c++/6/bits/stl_iterator.h:792:2: error: cannot increment a pointer 
to incomplete type 'const boost::shared_ptr'
/usr/include/c++/6/bits/stl_iterator.h: In instantiation of 
'__gnu_cxx::__normal_iterator<_Iterator, _Container>& 
__gnu_cxx::__normal_iterator<_Iterator, _Container>::operator++() [with 
_Iterator = const boost::shared_ptr*; _Container = 
std::vector]':
/<>/src/parser_urdf.cc:3449:49:   required from here
/usr/include/c++/6/bits/stl_iterator.h:792:2: error: cannot increment a pointer 
to incomplete type 'const boost::shared_ptr'
src/CMakeFiles/sdformat.dir/build.make:209: recipe for target 
'src/CMakeFiles/sdformat.dir/parser_urdf.cc.o' failed
make[3]: *** [src/CMakeFiles/sdformat.dir/parser_urdf.cc.o] Error 1
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
CMakeFiles/Makefile2:1196: recipe for target 'src/CMakeFiles/sdformat.dir/all' 
failed
make[2]: *** [src/CMakeFiles/sdformat.dir/all] Error 2
make[2]: Leaving directory 

Bug#834981: ros-robot-model: FTBFS in testing (no match for 'operator=')

[Santiago Vila]

Package: src:ros-robot-model
Version: 1.12.3-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel --buildsystem=cmake --with python2
   dh_testdir -i -O--parallel -O--buildsystem=cmake
   dh_update_autotools_config -i -O--parallel -O--buildsystem=cmake
   dh_auto_configure -i -O--parallel -O--buildsystem=cmake
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var
-- The C compiler identification is GNU 6.1.1
-- The CXX compiler identification is GNU 6.1.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using CATKIN_DEVEL_PREFIX: /<>/obj-x86_64-linux-gnu/devel
-- Using CMAKE_PREFIX_PATH: 
-- Found PythonInterp: /usr/bin/python (found version "2.7.12") 
-- Using PYTHON_EXECUTABLE: /usr/bin/python
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: 
/<>/obj-x86_64-linux-gnu/test_results
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Found gtest sources under '/usr/src/gtest': gtests will be built
CMake Warning at /usr/share/catkin/cmake/test/nosetests.cmake:98 (message):
  nosetests not found, Python tests can not be run (try installing package
  'python-nose')
Call Stack (most recent call first):
  /usr/share/catkin/cmake/all.cmake:147 (include)
  /usr/share/catkin/cmake/catkinConfig.cmake:20 (include)
  urdf_parser_plugin/CMakeLists.txt:4 (find_package)


-- catkin 0.7.1
-- Boost version: 1.61.0
-- Found the following Boost libraries:
--   thread
--   chrono
--   system
--   date_time
--   atomic
-- Using CATKIN_DEVEL_PREFIX: /<>/obj-x86_64-linux-gnu/devel
-- Using CMAKE_PREFIX_PATH: 
-- Using PYTHON_EXECUTABLE: /usr/bin/python
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: 
/<>/obj-x86_64-linux-gnu/test_results
CMake Warning at /usr/share/catkin/cmake/test/nosetests.cmake:98 (message):
  nosetests not found, Python tests can not be run (try installing package
  'python-nose')
Call Stack (most recent call first):
  /usr/share/catkin/cmake/all.cmake:147 (include)
  /usr/share/catkin/cmake/catkinConfig.cmake:20 (include)
  urdf/CMakeLists.txt:7 (find_package)


-- catkin 0.7.1
-- Found TinyXML: /usr/lib/x86_64-linux-gnu/libtinyxml.so  
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29") 
-- Checking for module 'libpcrecpp'
--   Found libpcrecpp, version 8.39
-- Boost version: 1.61.0
-- Found the following Boost libraries:
--   system
-- Using CATKIN_DEVEL_PREFIX: /<>/obj-x86_64-linux-gnu/devel
-- Using CMAKE_PREFIX_PATH: 
-- Using PYTHON_EXECUTABLE: /usr/bin/python
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: 
/<>/obj-x86_64-linux-gnu/test_results
CMake Warning at /usr/share/catkin/cmake/test/nosetests.cmake:98 (message):
  nosetests not found, Python tests can not be run (try installing package
  'python-nose')
Call Stack (most recent call first):
  /usr/share/catkin/cmake/all.cmake:147 (include)
  /usr/share/catkin/cmake/catkinConfig.cmake:20 (include)
  collada_parser/CMakeLists.txt:6 (find_package)


-- catkin 0.7.1
-- Looking for mkstemps
-- Looking for mkstemps - found
-- Using CATKIN_DEVEL_PREFIX: /<>/obj-x86_64-linux-gnu/devel
-- Using CMAKE_PREFIX_PATH: 
-- Using PYTHON_EXECUTABLE: /usr/bin/python
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: 
/<>/obj-x86_64-linux-gnu/test_results
CMake Warning at /usr/share/catkin/cmake/test/nosetests.cmake:98 (message):
  nosetests not found, Python tests can not be run (try installing package
  'python-nose')
Call Stack (most recent call first):
  /usr/share/catkin/cmake/all.cmake:147 

Bug#811987: fixed in ceres-solver 1.11.0~dfsg0-4

[Santiago Vila]

fixed 811987 1.11.0~dfsg0-4
thanks

On Sun, 14 Aug 2016, Philipp Huebner wrote:

> Hi,
> 
> Am 12.08.2016 um 19:55 schrieb Santiago Vila:
> > Still FTBFS:
> > 
> > https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/ceres-solver_1.11.0~dfsg0-5.rbuild.log
> 
> this appears to be a different bug due to a new eigen3 release and not
> related to the bug you reopened.

You are right, they seem different.

I'll file a different bug, then.

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#811987: fixed in ceres-solver 1.11.0~dfsg0-4

[Santiago Vila]

found 811987 1.11.0~dfsg0-5
thanks

Still FTBFS:

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/ceres-solver_1.11.0~dfsg0-5.rbuild.log

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#831247:

[Santiago Vila]

tags 831247 + patch
thanks

Since I'm unable to merge the bug, I'm tagging both with patch.

Sorry for the noise.

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#813951: freefoam: FTBFS with libopenmpi 1.10

[Santiago Vila]

tags 813951 + patch
thanks

On Sun, 7 Feb 2016, Mattia Rizzolo wrote:

> undefined reference to `yyFlexLexer::yywrap()'

This seems to be a problem with new flex behaviour.

Code written to work with "old" flex need this declaration:

extern "C" int yywrap()

and code written to work with "new" flex need this one:

int yyFlexLexer::yywrap()

The authors combined both things with a preprocessor conditional:

#if YY_FLEX_SUBMINOR_VERSION < 34
 extern "C" int yywrap()
#else
 int yyFlexLexer::yywrap()
#endif
  
but this assumes that flex is 2.5.x where x is YY_FLEX_SUBMINOR_VERSION.

If flex is 2.6.0, which is also the "new" flex, then 0 < 34 is true
and the wrong code is used.

I found the official fix in openfoam here:

http://bugs.openfoam.org/view.php?id=2066

which is to write the condition in this way:

#if YY_FLEX_MINOR_VERSION < 6 && YY_FLEX_SUBMINOR_VERSION < 34

The affected files are the following:

src/surfMesh/surfaceFormats/stl/STLsurfaceFormatASCII.L
src/triSurface/triSurface/interfaces/STL/readSTLASCII.L
src/thermophysicalModels/reactionThermo/chemistryReaders/chemkinReader/chemkinLexer.L
applications/utilities/mesh/conversion/fluentMeshToFoam/fluentMeshToFoam.L
applications/utilities/mesh/conversion/ansysToFoam/ansysToFoam.L
applications/utilities/mesh/conversion/fluent3DMeshToFoam/fluent3DMeshToFoam.L
applications/utilities/mesh/conversion/gambitToFoam/gambitToFoam.L

and the resulting patch is attached (warning: I have not actually
tested it, I have only explained why the patch is required :-).

Since this package is team-maintained, could somebody in the team
verify that the patch works and make an upload? I'd like this package
not to removed from Debian.

Thanks.diff --git a/applications/utilities/mesh/conversion/ansysToFoam/ansysToFoam.L 
b/applications/utilities/mesh/conversion/ansysToFoam/ansysToFoam.L
index 947b069..ca6e7a8 100644
--- a/applications/utilities/mesh/conversion/ansysToFoam/ansysToFoam.L
+++ b/applications/utilities/mesh/conversion/ansysToFoam/ansysToFoam.L
@@ -95,7 +95,7 @@ label currentTypei = -1;
 // Dummy yywrap to keep yylex happy at compile time.
 // It is called by yylex but is not used as the mechanism to change file.
 // See <>
-#if YY_FLEX_SUBMINOR_VERSION < 34
+#if YY_FLEX_MINOR_VERSION < 6 && YY_FLEX_SUBMINOR_VERSION < 34
 extern "C" int yywrap()
 #else
 int yyFlexLexer::yywrap()
diff --git 
a/applications/utilities/mesh/conversion/fluent3DMeshToFoam/fluent3DMeshToFoam.L
 
b/applications/utilities/mesh/conversion/fluent3DMeshToFoam/fluent3DMeshToFoam.L
index 99a4c6d..15c7a9b 100644
--- 
a/applications/utilities/mesh/conversion/fluent3DMeshToFoam/fluent3DMeshToFoam.L
+++ 
b/applications/utilities/mesh/conversion/fluent3DMeshToFoam/fluent3DMeshToFoam.L
@@ -147,7 +147,7 @@ void uniquify(word& name, HashSet& patchNames)
 // Dummy yywrap to keep yylex happy at compile time.
 // It is called by yylex but is not used as the mechanism to change file.
 // See <>
-#if YY_FLEX_SUBMINOR_VERSION < 34
+#if YY_FLEX_MINOR_VERSION < 6 && YY_FLEX_SUBMINOR_VERSION < 34
 extern "C" int yywrap()
 #else
 int yyFlexLexer::yywrap()
diff --git 
a/applications/utilities/mesh/conversion/fluentMeshToFoam/fluentMeshToFoam.L 
b/applications/utilities/mesh/conversion/fluentMeshToFoam/fluentMeshToFoam.L
index 32550da..c2b0f5f 100644
--- a/applications/utilities/mesh/conversion/fluentMeshToFoam/fluentMeshToFoam.L
+++ b/applications/utilities/mesh/conversion/fluentMeshToFoam/fluentMeshToFoam.L
@@ -126,7 +126,7 @@ wordList patchNameIDs(maxZoneID);
 // Dummy yywrap to keep yylex happy at compile time.
 // It is called by yylex but is not used as the mechanism to change file.
 // See <>
-#if YY_FLEX_SUBMINOR_VERSION < 34
+#if YY_FLEX_MINOR_VERSION < 6 && YY_FLEX_SUBMINOR_VERSION < 34
 extern "C" int yywrap()
 #else
 int yyFlexLexer::yywrap()
diff --git a/applications/utilities/mesh/conversion/gambitToFoam/gambitToFoam.L 
b/applications/utilities/mesh/conversion/gambitToFoam/gambitToFoam.L
index 0df85b5..d2baa9e 100644
--- a/applications/utilities/mesh/conversion/gambitToFoam/gambitToFoam.L
+++ b/applications/utilities/mesh/conversion/gambitToFoam/gambitToFoam.L
@@ -99,7 +99,7 @@ label nValuesForPatchFaces = 0;
 // Dummy yywrap to keep yylex happy at compile time.
 // It is called by yylex but is not used as the mechanism to change file.
 // See <>
-#if YY_FLEX_SUBMINOR_VERSION < 34
+#if YY_FLEX_MINOR_VERSION < 6 && YY_FLEX_SUBMINOR_VERSION < 34
 extern "C" int yywrap()
 #else
 int yyFlexLexer::yywrap()
diff --git a/src/surfMesh/surfaceFormats/stl/STLsurfaceFormatASCII.L 
b/src/surfMesh/surfaceFormats/stl/STLsurfaceFormatASCII.L
index c51b738..81283b8 100644
--- a/src/surfMesh/surfaceFormats/stl/STLsurfaceFormatASCII.L
+++ b/src/surfMesh/surfaceFormats/stl/STLsurfaceFormatASCII.L
@@ -50,7 +50,7 @@ int yyFlexLexer::yylex()
 // It is called by yylex but is not used as the mechanism to change file.
 // See <>
 //! @cond dummy
-#if YY_FLEX_SUBMINOR_VERSION < 34
+#if YY_FLEX_MINOR_VERSION < 6 && 

Bug#813951: Trying to merge

[Santiago Vila]

I'm trying to merge this bug with #831247 but I can't.
The BTS says the bug is archived (?).

-- 
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#831247: freefoam: FTBFS: ../../../../lib/FreeFOAM-0.1.0/libtriSurface.so.0.1.0: undefined reference to `yyFlexLexer::yywrap()'

[Santiago Vila]

forcemerge 813951 831247
thanks

On Thu, 14 Jul 2016, Lucas Nussbaum wrote:

> Source: freefoam
> Version: 0.1.0+dfsg+1-3
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20160714 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > /usr/bin/c++   -g -O2 -fstack-protector-strong -Wformat 
> > -Werror=format-security -fpermissive -Wdate-time -D_FORTIFY_SOURCE=2
> > -Wl,-z,relro CMakeFiles/dns.dir/dnsFoam.C.o  -o 
> > ../../../../libexec/FreeFOAM/0.1.0/freefoam-dns -rdynamic 
> > ../../../../lib/FreeFOAM-0.1.0/librandomProcesses.so.0.1.0 
> > ../../../../lib/FreeFOAM-0.1.0/libsampling.so.0.1.0 
> > ../../../../lib/FreeFOAM-0.1.0/libfiniteVolume.so.0.1.0 
> > ../../../../lib/FreeFOAM-0.1.0/libmeshTools.so.0.1.0 
> > ../../../../lib/FreeFOAM-0.1.0/libdecompositionMethods.so.0.1.0 
> > ../../../../lib/FreeFOAM-0.1.0/liblagrangian.so.0.1.0 
> > ../../../../lib/FreeFOAM-0.1.0/libtriSurface.so.0.1.0 
> > ../../../../lib/FreeFOAM-0.1.0/libsurfMesh.so.0.1.0 
> > ../../../../lib/FreeFOAM-0.1.0/libOpenFOAM.so.0.1.0 
> > ../../../../lib/FreeFOAM-0.1.0/libOSspecific.so.0.1.0 -lz -ldl 
> > -Wl,-rpath,/«BUILDDIR»/freefoam-0.1.0+dfsg+1/obj-x86_64-linux-gnu/lib/FreeFOAM-0.1.0:
> >  
> > ../../../../lib/FreeFOAM-0.1.0/libtriSurface.so.0.1.0: undefined reference 
> > to `yyFlexLexer::yywrap()'
> > collect2: error: ld returned 1 exit status

This is the same as Bug #813951.

(You can compare the error messages to see they are the same).

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#822055: maria: Build arch:all+arch:any but is missing build-{arch, indep} targets

[Santiago Vila]

tags 822055 + patch
thanks

I also recommend switching to dh, but in the meantime, the attached
patch should work.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,10 @@ ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
   OPTFLAGS = -O0
 endif
 
+build-arch: build
+
+build-indep: build
+
 build: build-stamp
 
 build-stamp:
@@ -87,4 +91,4 @@ binary-arch: install-arch
dh_builddeb -a
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch install-indep install-arch 
+.PHONY: build build-arch build-indep clean binary-indep binary-arch 
install-indep install-arch
-- 
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#806616: fftw3: FTBFS when built with dpkg-buildpackage -A (build-indep fails)

[Santiago Vila]

Greetings.

I have the ok from the Release Managers to consider this issue as RC
for stretch. I'm going to wait at least one week before raising
this to "serious".

If you need help to fix this bug, please tag it as "help".

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#806100: pyviennacl: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

Greetings.

I have the ok from the Release Managers to consider this issue as RC
for stretch. I'm going to wait at least one week before raising
this to "serious".

If you need help to fix this bug, please tag it as "help".

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

Re: Bug#806873: roboptim-core: FTBFS when built with dpkg-buildpackage -A (24 tests failed out of 24)

[Santiago Vila]

Greetings.

I have the ok from the Release Managers to consider this issue as RC
for stretch. I'm going to wait at least one week before raising
this to "serious".

There is a patch available for this bug. If you need someone to make
an upload, please ask for a sponsor in debian-mentors.

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

Re: Bug#806198: siscone: FTBFS when built with dpkg-buildpackage -A (dh_testroot in build-indep)

[Santiago Vila]

Greetings.

I have the ok from the Release Managers to consider this issue as RC
for stretch. I'm going to wait at least one week before raising
this to "serious".

There is a patch available for this bug. If you need someone to make
an upload, please ask for a sponsor in debian-mentors.

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

Re: freefoam: FTBFS with libopenmpi 1.10

[Santiago Vila]

On Sun, 7 Feb 2016, Mattia Rizzolo wrote:

> undefined reference to `yyFlexLexer::yywrap()'

Ok, since I'm planning to use this program myself, I searched for a fix.
This seems to be a problem with new flex behaviour.

Code written to work with "old" flex need this declaration:

extern "C" int yywrap()

and code written to work with "new" flex need this one:

int yyFlexLexer::yywrap()

The authors combined both things with a preprocessor conditional:

#if YY_FLEX_SUBMINOR_VERSION < 34
 extern "C" int yywrap()
#else
 int yyFlexLexer::yywrap()
#endif

but this assumes that flex is 2.5.x where x is YY_FLEX_SUBMINOR_VERSION.

If flex is 2.6.0, which is also the "new" flex, then 0 < 34 is true and the 
wrong
code is used.

I found the official fix in openfoam here:

http://bugs.openfoam.org/view.php?id=2066

which is to write the condition in this way:

#if YY_FLEX_MINOR_VERSION < 6 && YY_FLEX_SUBMINOR_VERSION < 34

The affected files are the following:

src/surfMesh/surfaceFormats/stl/STLsurfaceFormatASCII.L
src/triSurface/triSurface/interfaces/STL/readSTLASCII.L
src/thermophysicalModels/reactionThermo/chemistryReaders/chemkinReader/chemkinLexer.L
applications/utilities/mesh/conversion/fluentMeshToFoam/fluentMeshToFoam.L
applications/utilities/mesh/conversion/ansysToFoam/ansysToFoam.L
applications/utilities/mesh/conversion/fluent3DMeshToFoam/fluent3DMeshToFoam.L
applications/utilities/mesh/conversion/gambitToFoam/gambitToFoam.L

and the resulting patch is attached (warning: I have not actually
tested it, I have only explained why the patch is required :-).

BTW: freefoam seems to be dead, why aren't we packaging openfoam instead?

Thanks.diff --git a/applications/utilities/mesh/conversion/ansysToFoam/ansysToFoam.L 
b/applications/utilities/mesh/conversion/ansysToFoam/ansysToFoam.L
index 947b069..ca6e7a8 100644
--- a/applications/utilities/mesh/conversion/ansysToFoam/ansysToFoam.L
+++ b/applications/utilities/mesh/conversion/ansysToFoam/ansysToFoam.L
@@ -95,7 +95,7 @@ label currentTypei = -1;
 // Dummy yywrap to keep yylex happy at compile time.
 // It is called by yylex but is not used as the mechanism to change file.
 // See <>
-#if YY_FLEX_SUBMINOR_VERSION < 34
+#if YY_FLEX_MINOR_VERSION < 6 && YY_FLEX_SUBMINOR_VERSION < 34
 extern "C" int yywrap()
 #else
 int yyFlexLexer::yywrap()
diff --git 
a/applications/utilities/mesh/conversion/fluent3DMeshToFoam/fluent3DMeshToFoam.L
 
b/applications/utilities/mesh/conversion/fluent3DMeshToFoam/fluent3DMeshToFoam.L
index 99a4c6d..15c7a9b 100644
--- 
a/applications/utilities/mesh/conversion/fluent3DMeshToFoam/fluent3DMeshToFoam.L
+++ 
b/applications/utilities/mesh/conversion/fluent3DMeshToFoam/fluent3DMeshToFoam.L
@@ -147,7 +147,7 @@ void uniquify(word& name, HashSet& patchNames)
 // Dummy yywrap to keep yylex happy at compile time.
 // It is called by yylex but is not used as the mechanism to change file.
 // See <>
-#if YY_FLEX_SUBMINOR_VERSION < 34
+#if YY_FLEX_MINOR_VERSION < 6 && YY_FLEX_SUBMINOR_VERSION < 34
 extern "C" int yywrap()
 #else
 int yyFlexLexer::yywrap()
diff --git 
a/applications/utilities/mesh/conversion/fluentMeshToFoam/fluentMeshToFoam.L 
b/applications/utilities/mesh/conversion/fluentMeshToFoam/fluentMeshToFoam.L
index 32550da..c2b0f5f 100644
--- a/applications/utilities/mesh/conversion/fluentMeshToFoam/fluentMeshToFoam.L
+++ b/applications/utilities/mesh/conversion/fluentMeshToFoam/fluentMeshToFoam.L
@@ -126,7 +126,7 @@ wordList patchNameIDs(maxZoneID);
 // Dummy yywrap to keep yylex happy at compile time.
 // It is called by yylex but is not used as the mechanism to change file.
 // See <>
-#if YY_FLEX_SUBMINOR_VERSION < 34
+#if YY_FLEX_MINOR_VERSION < 6 && YY_FLEX_SUBMINOR_VERSION < 34
 extern "C" int yywrap()
 #else
 int yyFlexLexer::yywrap()
diff --git a/applications/utilities/mesh/conversion/gambitToFoam/gambitToFoam.L 
b/applications/utilities/mesh/conversion/gambitToFoam/gambitToFoam.L
index 0df85b5..d2baa9e 100644
--- a/applications/utilities/mesh/conversion/gambitToFoam/gambitToFoam.L
+++ b/applications/utilities/mesh/conversion/gambitToFoam/gambitToFoam.L
@@ -99,7 +99,7 @@ label nValuesForPatchFaces = 0;
 // Dummy yywrap to keep yylex happy at compile time.
 // It is called by yylex but is not used as the mechanism to change file.
 // See <>
-#if YY_FLEX_SUBMINOR_VERSION < 34
+#if YY_FLEX_MINOR_VERSION < 6 && YY_FLEX_SUBMINOR_VERSION < 34
 extern "C" int yywrap()
 #else
 int yyFlexLexer::yywrap()
diff --git a/src/surfMesh/surfaceFormats/stl/STLsurfaceFormatASCII.L 
b/src/surfMesh/surfaceFormats/stl/STLsurfaceFormatASCII.L
index c51b738..81283b8 100644
--- a/src/surfMesh/surfaceFormats/stl/STLsurfaceFormatASCII.L
+++ b/src/surfMesh/surfaceFormats/stl/STLsurfaceFormatASCII.L
@@ -50,7 +50,7 @@ int yyFlexLexer::yylex()
 // It is called by yylex but is not used as the mechanism to change file.
 // See <>
 //! @cond dummy
-#if YY_FLEX_SUBMINOR_VERSION < 34
+#if YY_FLEX_MINOR_VERSION < 6 && YY_FLEX_SUBMINOR_VERSION < 34
 extern "C" int 

Bug#829430: sfepy: FTBFS in testing (LaTeX Error: File `iftex.sty' not found)

[Santiago Vila]

Package: src:sfepy
Version: 2016.2-1
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious

Dear maintainer:

This package currently fails to build in stretch:


[...]
make[3]: Entering directory '/build/sfepy-2016.2/doc/_build/latex'
pdflatex  'SfePy.tex'
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) 
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./SfePy.tex
LaTeX2e <2016/03/31> patch level 1
Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
(./sphinxmanual.cls
Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))

! LaTeX Error: File `iftex.sty' not found.


A full build log is available here:

https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/sfepy_2016.2-1.rbuild.log

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#829352: yade: FTBFS in testing (LaTeX Error: File `iftex.sty' not found)

[Santiago Vila]

Package: src:yade
Version: 1.20.0-10
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious

Dear maintainer:

This package currently fails to build in stretch:


[...]
writing toc.ncx file...
writing Yade.epub file...
build succeeded, 72 warnings.
This is XeTeX, Version 3.14159265-2.6-0.6 (TeX Live 2016/Debian) (preloaded 
format=xelatex)
 restricted \write18 enabled.
entering extended mode
(./Yade.tex
LaTeX2e <2016/03/31> patch level 1
Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
(./sphinxmanual.cls
Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))

! LaTeX Error: File `iftex.sty' not found.


A full build log is available here:

https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/yade_1.20.0-10.rbuild.log

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#829077: pytables: FTBFS in testing (LaTeX Error: File `iftex.sty' not found)

[Santiago Vila]

Package: src:pytables
Version: 3.2.2-2
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious

Dear maintainer:

This package currently fails to build in stretch:


[...]
Running LaTeX files through pdflatex...
/usr/bin/make -C build/latex all-pdf
make[3]: Entering directory '/<>/doc/build/latex'
pdflatex  'usersguide-3.2.2.tex'
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) 
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./usersguide-3.2.2.tex
LaTeX2e <2016/03/31> patch level 1
Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
(./sphinxmanual.cls
Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))

! LaTeX Error: File `iftex.sty' not found.


A full build log will be available here:

https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/pytables_3.2.2-2.rbuild.log

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#829034: slepc: FTBFS in testing (ERROR: Unable to link with PETSc)

[Santiago Vila]

Package: src:slepc
Version: 3.6.3.dfsg1-6
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious

Dear maintainer:

This package currently fails to build in stretch:


[...]
 fakeroot debian/rules binary
dh binary --with python2
   dh_testroot
   dh_prep
   debian/rules override_dh_auto_install
make[1]: Entering directory '/build/slepc-3.6.3.dfsg1'
PETSC_DIR=/usr/lib/petscdir/3.6-real \
  ./configure --prefix=/usr/lib/slepcdir/3.6.3/x86_64-linux-gnu-real  \
--with-arpack=1 \
--shared-library-extension=_real
Checking environment... done
Checking PETSc installation... 
ERROR: Unable to link with PETSc
ERROR: See "installed-x86_64-linux-gnu-real/lib/slepc/conf/configure.log" file 
for details
debian/rules:128: recipe for target 'override_dh_auto_install' failed
make[1]: *** [override_dh_auto_install] Error 1
make[1]: Leaving directory '/build/slepc-3.6.3.dfsg1'
debian/rules:88: recipe for target 'binary' failed
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2


A full build log is available here:

https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/slepc_3.6.3.dfsg1-6.rbuild.log

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#828917: pysph: FTBFS in testing (other math package is already loaded)

[Santiago Vila]

Package: src:pysph
Version: 0~20160514.git91867dc-3
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious

Dear maintainer:

This package currently fails to build in stretch:


[...]
make doc
make[2]: Entering directory '/<>'
cd docs; make html
make[3]: Entering directory '/<>/docs'
sphinx-build -b html -d build/doctrees   source build/html
Running Sphinx v1.4.4
making output directory...
WARNING: sphinx.ext.pngmath has been deprecated. Please use sphinx.ext.imgmath 
instead.

Extension error:
sphinx.ext.mathjax: other math package is already loaded
Makefile:45: recipe for target 'html' failed
make[3]: *** [html] Error 1


A full build log is available here:

https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/pysph_0~20160514.git91867dc-3.rbuild.log

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

Re: Bug#806864: mlpack: FTBFS when built with dpkg-buildpackage -A (can't cd to debian/mlpack-bin/usr/bin)

[Santiago Vila]

Version: 2.0.1-1

This seems fixed because I have a successful build for this version.

I guess it was commit 507024ba6b9914265b5424c295363f72be9736db which fixed this.

mlpack (2.0.0-1) unstable; urgency=medium

  * debian/rules
- remove code to prefix binaries with mlpack_, as this is now done upstream

Because there was not a Close statement there, I'm closing this report
by hand with this message.

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#825816: slepc: FTBFS when built with dpkg-buildpackage -A (dh_install: missing files, aborting)

[Santiago Vila]

Package: src:slepc
Version: 3.6.3.dfsg1-4
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2
   dh_testdir -i
   dh_update_autotools_config -i
 fakeroot debian/rules binary-indep
dh binary-indep --with python2
   dh_testroot -i
   dh_prep -i
   debian/rules override_dh_auto_install
make[1]: Entering directory '/<>'
PETSC_DIR=/usr/lib/petscdir/3.6.4/x86_64-linux-gnu-real \
  ./configure --prefix=/usr/lib/slepcdir/3.6.3/x86_64-linux-gnu-real  \

[... snipped ...]

xxx=xxx

dh_auto_build -plibslepc-complex-3.6.3-dev  --  \
  PETSC_DIR=/usr/lib/petscdir/3.6.4/x86_64-linux-gnu-complex
dh_auto_build: No packages to build.
dh_auto_install -plibslepc-complex-3.6.3-dev 
--destdir=debian/tmp/slepc3.6.3-complex//usr/lib/slepcdir/3.6.3/x86_64-linux-gnu-complex
 --  \
  SLEPC_INSTALLDIR=/usr/lib/slepcdir/3.6.3/x86_64-linux-gnu-complex \
  
SLEPC_DESTDIR=debian/tmp/slepc3.6.3-complex//usr/lib/slepcdir/3.6.3/x86_64-linux-gnu-complex
 \
  PETSC_DIR=/usr/lib/petscdir/3.6.4/x86_64-linux-gnu-complex
dh_auto_install: No packages to build.
echo Note: standard SLEPc built-time tests only cover real number 
configurations, not complex numbers.
Note: standard SLEPc built-time tests only cover real number configurations, 
not complex numbers.
make[1]: Leaving directory '/<>'
   debian/rules override_dh_install
make[1]: Entering directory '/<>'
dh_install -plibslepc3.6.3 --sourcedir debian/tmp/slepc3.6.3-real 
--exclude=*html  
/usr/lib/slepcdir/3.6.3/x86_64-linux-gnu-real/lib/libslepc_real.so.3.6.3  
usr/lib/x86_64-linux-gnu
dh_install: No packages to build.
dh_install -plibslepc3.6.3-dev --sourcedir debian/tmp/slepc3.6.3-real 
--autodest --exclude=*html --exclude=libslepc_real.so.3.6.3  usr
dh_install: No packages to build.
dh_link -plibslepc3.6.3-dev  usr/lib/x86_64-linux-gnu/libslepc_real.so.3.6.3  
/usr/lib/slepcdir/3.6.3/x86_64-linux-gnu-real/lib/libslepc_real.so.3.6.3
dh_link: No packages to build.
dh_install -plibslepc-complex-3.6.3 --sourcedir debian/tmp/slepc3.6.3-complex 
--exclude=*html  
/usr/lib/slepcdir/3.6.3/x86_64-linux-gnu-complex/lib/libslepc_complex.so.3.6.3  
usr/lib/x86_64-linux-gnu
dh_install: No packages to build.
dh_install -plibslepc-complex-3.6.3-dev --sourcedir 
debian/tmp/slepc3.6.3-complex --autodest --exclude=*html 
--exclude=libslepc_complex.so.3.6.3  usr
dh_install: No packages to build.
dh_link -plibslepc-complex-3.6.3-dev  
usr/lib/x86_64-linux-gnu/libslepc_complex.so.3.6.3  
/usr/lib/slepcdir/3.6.3/x86_64-linux-gnu-complex/lib/libslepc_complex.so.3.6.3
dh_link: No packages to build.
make[1]: Leaving directory '/<>'
   debian/rules override_dh_installdocs
make[1]: Entering directory '/<>'
dh_installdocs
dh_install -pslepc3.6.3-doc --sourcedir debian/tmp/slepc3.6.3-real --autodest 
/usr/lib/slepcdir/3.6.3/x86_64-linux-gnu-real/include/*html
dh_install: Cannot find (any matches for) 
"/usr/lib/slepcdir/3.6.3/x86_64-linux-gnu-real/include/*html" (tried in 
"debian/tmp/slepc3.6.3-real" and "debian/tmp")
dh_install: slepc3.6.3-doc missing files: 
/usr/lib/slepcdir/3.6.3/x86_64-linux-gnu-real/include/*html
dh_install: missing files, aborting
debian/rules:167: recipe for target 'override_dh_installdocs' failed
make[1]: *** [override_dh_installdocs] Error 2
make[1]: Leaving directory '/<>'
debian/rules:90: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


The previous version (3.6.3.dfsg1-3) worked ok, so this is surely the result
of the changes in debian/rules made in 3.6.3.dfsg1-4.

In cases like this (changes to debian/rules) it is always a good idea to
check that "dpkg-buildpackage -A" and "dpkg-buildpackage -B" still work.

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#818990: Is it really a flint problem?

[Santiago Vila]

On Sat, May 21, 2016 at 08:47:06AM +0200, Julien Puydt wrote:
> Hi,
> 
> On 21/05/2016 01:46, Santiago Vila wrote:
> > It still fails on reproducible builds on the "armhf" architecture, but
> > only in testing, and the way it fails is now completely different than
> > the way it failed on amd64 in the initial report.
> 
> But it doesn't fail on armhf in not-reproducible buildd:
> https://buildd.debian.org/status/package.php?p=flint

Exactly, so IMHO, this seems like a toolchain bug for which the fix is
in unstable but it has not propagated to testing yet.

In either case, a completely different bug, apparently, than the one
it was reported here.

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#818990: Is it really a flint problem?

[Santiago Vila]

It still fails on reproducible builds on the "armhf" architecture, but
only in testing, and the way it fails is now completely different than
the way it failed on amd64 in the initial report.

-- 
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#824459: tango: FTBFS in testing

[Santiago Vila]

Package: src:tango
Version: 8.1.2c+dfsg-7
Severity: serious

Dear maintainer:

This package currently fails to build from source in stretch:


In file included from ../../../../lib/cpp/server/w_attribute.cpp:61:0:
../../../../lib/cpp/server/w_attribute.cpp: In member function 'virtual bool 
Tango::WAttribute::check_rds_ala
rm()':
../../../../lib/cpp/server/tango_config.h:201:38: error: expected 
unqualified-id before '(' token
 #define Tango_isnan(A)  std::isnan(A)
  ^
../../../../lib/cpp/server/w_attribute.cpp:3421:11: note: in expansion of macro 
'Tango_isnan'
  if ( Tango_isnan(double_array_val[0]) || Tango_isnan(tmp_db[0]) )


The full build log is attached.

Thanks.

tango_8.1.2c+dfsg-7_amd64-20160516-1227.gz
Description: application/gzip
-- 
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#823462: flint: FTBFS in testing with LaTeX error (i.e. please make an upload for unstable)

[Santiago Vila]

Package: src:flint
Version: 2.5.2-3
Severity: serious

Dear maintainer: This package FTBFS in stretch:

---
! Argument of \zap@to@space has an extra }.

\par
l.4164 \left
|\frac{a_1}{a_n}\right|^{\frac{1}{n-1}},
?
! Emergency stop.

\par
l.4164 \left
|\frac{a_1}{a_n}\right|^{\frac{1}{n-1}},
!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on flint-manual.log.
---

Please make an upload for unstable to fix the bug in unstable
(as I see that it's already fixed in experimental).

This is one of the packages I check for "dpkg-buildpackage -A",
and I would like to help with "unreproducible" Bug #818990, but
this is currently impossible for me because I can't get past the
LaTeX error (I only build on testing and sometimes on unstable).

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

Re: Bug#806873: roboptim-core: FTBFS when built with dpkg-buildpackage -A (24 tests failed out of 24)

[Santiago Vila]

> <>/obj-x86_64-linux-gnu/tests/Development/visualization-gnuplot-differentiable-function
> Unable to find executable: 
> /<>/obj-x86_64-linux-gnu/tests/visualization-gnuplot-differentiable-function
> 24/24 Test #24: visualization-gnuplot-differentiable-function ...***Not Run   
> 0.00 sec
> 
> 0% tests passed, 24 tests failed out of 24

If the executables are not available because we are only building
arch-independent stuff, the easy fix would be to disable the tests
for arch-independent builds.

Patch attached.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -38,3 +38,5 @@ override_dh_strip:
 
 override_dh_makeshlibs:
dh_makeshlibs -Xroboptim-core-plugin-
+
+override_dh_auto_test-indep:
-- 
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#806108: singular: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

severity 806108 important
thanks

Hi. I *really* appreciate that you consider this has a greater severity
than "important", but I prefer to keep it important for two reasons:

* I don't have the "blessing" (so to speak) from the release managers
  to make these bugs RC yet.

* If this is serious, all the other similar bugs should be serious too.
  Here is the complete list of similar bugs:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=binary-indep;users=sanv...@debian.org


Well, those are my reasons, but of course if you insist that this must
be serious, go ahead. I promise that I will not downgrade it again,
otherwise it would be a very odd severity war indeed: Maintainer
raises severity and reporter downgrades it :-)

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#806198: siscone: FTBFS when built with dpkg-buildpackage -A (dh_testroot in build-indep)

[Santiago Vila]

tags 806198 + patch
thanks

As explained in the previous message, this is the patch I would apply
if this were my package. Now "dpkg-buildpackage -A" works again.

This is of course a lot better than not working at all, but be careful
because now "dpkg-buildpackage -A" creates a siscone-doc-html package
slightly different than the one it's created without using -A:

Files in first .deb but not in second
-
-rw-r--r--  root/root   
/usr/share/doc/siscone-doc-html/html/devel/config_8h_source.html

This would be a reproducibility issue for which I don't have a fix
and should probably be reported separately.

In either case, please feel free to close this report after
"dpkg-buildpackage -A" works again.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -54,14 +54,11 @@ clean:
dh_clean
 
 configure-stamp:
-   dh_testdir
dh_autoreconf
dh_auto_configure -- --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
touch $@
 
 doxygen-stamp:
-   dh_testdir
-   dh_testroot
doxygen
touch doxygen-stamp
 
-- 
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#817033: FTBFS randomly. Missing build-depends on python-matplotlib

[Santiago Vila]

retitle 817033 sumo: FTBFS randomly. Missing build-depends on python-matplotlib
user sanv...@debian.org
usertags 817033 - binary-indep
severity 817033 serious
tags 817033 + patch
thanks

Dear maintainer: Because this error happens in the build stage, not in
the package creation stage, this is not really a "FTBFS when using
dpkg-buildpackage -A" bug, but a normal FTBFS bug. I'm therefore
raising the severity accordingly.

There are actually two different bugs here. One of them is that some
documentation seems to require the matplotlib library being present
to be built.

The other is that the Makefile does not properly check for errors.
This is a violation of Policy 4.6, "Error trapping in makefiles".

I believe the attached patch might fix both bugs, but I have not
tested it. Please give it a try.

BTW: You might want to forward this bug upstream as it is an upstream bug
in the Makefile.

Thanks.
diff --git a/Makefile.am b/Makefile.am
index 9eb89c2..38be892 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -7,10 +7,7 @@ doc: pydoc doxygen userdoc javadoc
 pydoc:
rm -rf docs/pydoc
mkdir docs/pydoc
-   cd docs/pydoc && \
-   for i in `find ../../tools/traci ../../tools/sumolib -name "*.py" -not 
-executable | sed 's,../../tools/,,;s,/,.,g;s,.py,,;s,.__init__,,'`; do \
-   PYTHONPATH="../../tools" python -c "import $$i, pydoc; 
pydoc.writedoc($$i)"; \
-   done
+   cd docs/pydoc && sh ../../mk-pydoc
 
 doxygen:
rm -rf docs/doxygen
diff --git a/debian/control b/debian/control
index fe25e87..ae31a21 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,8 @@ Build-Depends: autotools-dev,
libxerces-c-dev,
libxrandr-dev
 Build-Depends-Indep: doxygen,
- python
+ python,
+ python-matplotlib
 Standards-Version: 3.9.6
 Vcs-Browser: https://anonscm.debian.org/cgit/debian-science/packages/sumo.git
 Vcs-Git: git://anonscm.debian.org/debian-science/packages/sumo.git
diff --git a/mk-pydoc b/mk-pydoc
new file mode 100644
index 000..739e3e0
--- /dev/null
+++ b/mk-pydoc
@@ -0,0 +1,5 @@
+#!/bin/sh
+set -e
+for i in `find ../../tools/traci ../../tools/sumolib -name "*.py" -not 
-executable | sed 's,../../tools/,,;s,/,.,g;s,.py,,;s,.__init__,,'`; do
+  PYTHONPATH="../../tools" python -c "import $i, pydoc; pydoc.writedoc($i)"
+done
-- 
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#817167: slepc: FTBFS when built with dpkg-buildpackage -A (dh_install: missing files)

[Santiago Vila]

Package: src:slepc
Version: 3.6.1.dfsg1-2
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2
   dh_testdir -i
   dh_update_autotools_config -i
 fakeroot debian/rules binary-indep
dh binary-indep --with python2
   dh_testroot -i
   dh_prep -i
   debian/rules override_dh_auto_install
make[1]: Entering directory '/<>'
PETSC_DIR=/usr/lib/petscdir/3.6.2/x86_64-linux-gnu-real \
  ./configure --prefix=/usr/lib/slepcdir/3.6.1/x86_64-linux-gnu-real  \

[... snipped ...]

dh_auto_install: No packages to build.
make[1]: Leaving directory '/<>'
   debian/rules override_dh_install
make[1]: Entering directory '/<>'
dh_install -plibslepc3.6 --sourcedir debian/tmp/slepc3.6.1-real --exclude=*html 
 /usr/lib/slepcdir/3.6.1/x86_64-linux-gnu-real/lib/libslepc_real.so.3.6.1  
usr/lib/x86_64-linux-gnu
dh_install: No packages to build.
dh_install -plibslepc3.6.1-dev --sourcedir debian/tmp/slepc3.6.1-real 
--autodest --exclude=*html --exclude=libslepc_real.so.3.6.1  usr
dh_install: No packages to build.
dh_link -plibslepc3.6.1-dev  usr/lib/x86_64-linux-gnu/libslepc_real.so.3.6.1  
/usr/lib/slepcdir/3.6.1/x86_64-linux-gnu-real/lib/libslepc_real.so.3.6.1
dh_link: No packages to build.
dh_link -plibslepc3.6  usr/lib/x86_64-linux-gnu/libslepc_real.so.3.6.1  
usr/lib/x86_64-linux-gnu/libslepc_real.so.3.6
dh_link: No packages to build.
dh_link -plibslepc3.6.1-dev  usr/lib/x86_64-linux-gnu/libslepc_real.so.3.6.1  
usr/lib/x86_64-linux-gnu/libslepc_real.so
dh_link: No packages to build.
dh_install -plibslepc3.6.1-dbg --sourcedir debian/tmp/slepc3.6.1-real-debug 
--autodest --exclude=*html  usr
dh_install: No packages to build.
dh_install -plibslepc-complex-3.6 --sourcedir debian/tmp/slepc3.6.1-complex 
--exclude=*html  
/usr/lib/slepcdir/3.6.1/x86_64-linux-gnu-complex/lib/libslepc_complex.so.3.6.1  
usr/lib/x86_64-linux-gnu
dh_install: No packages to build.
dh_install -plibslepc-complex-3.6.1-dev --sourcedir 
debian/tmp/slepc3.6.1-complex --autodest --exclude=*html 
--exclude=libslepc_complex.so.3.6.1  usr
dh_install: No packages to build.
dh_link -plibslepc-complex-3.6.1-dev  
usr/lib/x86_64-linux-gnu/libslepc_complex.so.3.6.1  
/usr/lib/slepcdir/3.6.1/x86_64-linux-gnu-complex/lib/libslepc_complex.so.3.6.1
dh_link: No packages to build.
dh_link -plibslepc-complex-3.6  
usr/lib/x86_64-linux-gnu/libslepc_complex.so.3.6.1  
usr/lib/x86_64-linux-gnu/libslepc_complex.so.3.6
dh_link: No packages to build.
dh_link -plibslepc-complex-3.6.1-dev  
usr/lib/x86_64-linux-gnu/libslepc_complex.so.3.6.1  
usr/lib/x86_64-linux-gnu/libslepc_complex.so
dh_link: No packages to build.
dh_install -plibslepc-complex-3.6.1-dbg --sourcedir 
debian/tmp/slepc3.6.1-complex-debug --autodest --exclude=*html  usr
dh_install: No packages to build.
make[1]: Leaving directory '/<>'
   debian/rules override_dh_installdocs
make[1]: Entering directory '/<>'
dh_installdocs
dh_install -pslepc3.6.1-doc --sourcedir debian/tmp/slepc3.6.1-real-debug 
--autodest /usr/lib/slepcdir/3.6.1/x86_64-linux-gnu-real-debug/include/*html
dh_install: slepc3.6.1-doc missing files: 
/usr/lib/slepcdir/3.6.1/x86_64-linux-gnu-real-debug/include/*html
dh_install: missing files, aborting
debian/rules:218: recipe for target 'override_dh_installdocs' failed
make[1]: *** [override_dh_installdocs] Error 2
make[1]: Leaving directory '/<>'
debian/rules:101: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one. The common hints are:

* If the only architecture-independent packages are dummy transitional
ones and they were released with jessie, the easy fix is to drop them
now.

* When using "dh", it is allowed to use (independently)
optional targets override_dh_foo-arch and override_dh_foo-indep
(for several values of "foo").


Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, the package would be suitable to be uploaded in source-only
form if you wish.

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#817165: petsc: FTBFS when built with dpkg-buildpackage -A (dh_install: missing files)

[Santiago Vila]

Package: src:petsc
Version: 3.6.2.dfsg1-3
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2
   dh_testdir -i
   dh_update_autotools_config -i
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -plibpetsc3.6.2-dbg --  \
  --with-debugging=1  \
  --shared-library-extension=_real \
  --with-hypre=1 --with-hypre-dir=/usr --with-clanguage=C++ 
--with-c-support \
  --with-shared-libraries --useThreads 0 --with-fortran-interfaces=1 
--with-mpi-dir=/usr/lib/openmpi --with-blas-lib=-lblas 
--with-lapack-lib=-llapack --with-blacs=1 
--with-blacs-lib="-lblacsCinit-openmpi -lblacs-openmpi" --with-scalapack=1 
--with-scalapack-lib=-lscalapack-openmpi --with-mumps=1 --with-mumps-include=[] 
--with-mumps-lib="-ldmumps -lzmumps -lsmumps -lcmumps -lmumps_common -lpord" 
--with-suitesparse=1 --with-suitesparse-include=/usr/include/suitesparse 
--with-suitesparse-lib="-lumfpack -lamd -lcholmod -lklu" --with-spooles=1 
--with-spooles-include=/usr/include/spooles --with-spooles-lib=-lspooles 
--with-ptscotch=1 --with-ptscotch-include=/usr/include/scotch 
--with-ptscotch-lib="-lptesmumps -lptscotch -lptscotcherr" --with-fftw=1 
--with-fftw-include=[] --with-fftw-lib="-lfftw3 -lfftw3_mpi" --with-superlu=1 
--with-superlu-include=/usr/include/superlu --with-superlu-lib=-lsuperlu  
--CXX_LINKER_FLAGS="-Wl,--no-as-needed"  \
  --prefix=/usr/lib/petscdir/3.6.2/x86_64-linux-gnu-real-debug  \

[... snipped ...]

dh_auto_install: No packages to build.
make[1]: Leaving directory '/<>'
   debian/rules override_dh_install
make[1]: Entering directory '/<>'
dh_install -plibpetsc3.6 --sourcedir debian/tmp/petsc3.6.2-real --exclude=*html 
 /usr/lib/petscdir/3.6.2/x86_64-linux-gnu-real/lib/libpetsc_real.so.3.6.2  
usr/lib/x86_64-linux-gnu
dh_install: No packages to build.
dh_install -plibpetsc3.6.2-dev --sourcedir debian/tmp/petsc3.6.2-real 
--autodest --exclude=*html --exclude=libpetsc_real.so.3.6.2  usr
dh_install: No packages to build.
dh_link -plibpetsc3.6.2-dev  usr/lib/x86_64-linux-gnu/libpetsc_real.so.3.6.2  
/usr/lib/petscdir/3.6.2/x86_64-linux-gnu-real/lib/libpetsc_real.so.3.6.2
dh_link: No packages to build.
dh_link -plibpetsc3.6  usr/lib/x86_64-linux-gnu/libpetsc_real.so.3.6.2  
usr/lib/x86_64-linux-gnu/libpetsc_real.so.3.6
dh_link: No packages to build.
dh_link -plibpetsc3.6.2-dev  usr/lib/x86_64-linux-gnu/libpetsc_real.so.3.6.2  
usr/lib/x86_64-linux-gnu/libpetsc_real.so
dh_link: No packages to build.
dh_install -plibpetsc3.6.2-dbg --sourcedir debian/tmp/petsc3.6.2-real-debug 
--autodest --exclude=*html  usr
dh_install: No packages to build.
dh_install -plibpetsc-complex-3.6 --sourcedir debian/tmp/petsc3.6.2-complex 
--exclude=*html  
/usr/lib/petscdir/3.6.2/x86_64-linux-gnu-complex/lib/libpetsc_complex.so.3.6.2  
usr/lib/x86_64-linux-gnu
dh_install: No packages to build.
dh_install -plibpetsc-complex-3.6.2-dev --sourcedir 
debian/tmp/petsc3.6.2-complex --autodest --exclude=*html 
--exclude=libpetsc_complex.so.3.6.2  usr
dh_install: No packages to build.
dh_link -plibpetsc-complex-3.6.2-dev  
usr/lib/x86_64-linux-gnu/libpetsc_complex.so.3.6.2  
/usr/lib/petscdir/3.6.2/x86_64-linux-gnu-complex/lib/libpetsc_complex.so.3.6.2
dh_link: No packages to build.
dh_link -plibpetsc-complex-3.6  
usr/lib/x86_64-linux-gnu/libpetsc_complex.so.3.6.2  
usr/lib/x86_64-linux-gnu/libpetsc_complex.so.3.6
dh_link: No packages to build.
dh_link -plibpetsc-complex-3.6.2-dev  
usr/lib/x86_64-linux-gnu/libpetsc_complex.so.3.6.2  
usr/lib/x86_64-linux-gnu/libpetsc_complex.so
dh_link: No packages to build.
dh_install -plibpetsc-complex-3.6.2-dbg --sourcedir 
debian/tmp/petsc3.6.2-complex-debug --autodest --exclude=*html  usr
dh_install: No packages to build.
make[1]: Leaving directory '/<>'
   debian/rules override_dh_installdocs
make[1]: Entering directory '/<>'
dh_installdocs
dh_install -ppetsc3.6.2-doc --sourcedir debian/tmp/petsc3.6.2-real-debug 
--autodest /usr/lib/petscdir/3.6.2/x86_64-linux-gnu-real-debug/include/*html
dh_install: petsc3.6.2-doc missing files: 
/usr/lib/petscdir/3.6.2/x86_64-linux-gnu-real-debug/include/*html
dh_install: missing files, aborting
debian/rules:229: recipe for target 'override_dh_installdocs' failed
make[1]: *** [override_dh_installdocs] Error 2
make[1]: Leaving directory '/<>'
debian/rules:106: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one. The common hints are:

* If the only 

Bug#817058: sketch: FTBFS in stretch (TeX error)

[Santiago Vila]

Package: src:sketch
Version: 1:0.3.7-1
Severity: serious

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed.

The error, however, seems to happen with ordinary "dpkg-buildpackage"
as well, which is why I'm using "serious" severity here. See

https://reproducible.debian.net/rbuild/testing/amd64/sketch_0.3.7-1.rbuild.log

for the build log from the reproducible builds effort.


[...]
 debian/rules build-indep
dh build-indep
   dh_testdir -i
   dh_update_autotools_config -i
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
perl makever.pl

[... snipped ...]

Transcript written on mfput.log.
grep: ecrm1440.log: No such file or directory
mktextfm: `mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; input 
ecrm1440' failed to make ecrm1440.tfm.
kpathsea: Appending font creation commands to missfont.log.

./sketch.texi:3327: Font \thisecfont=ecrm1440 at 14.0pt not loadable: Metric (T
FM) file not found.
 
   \thisecfont 
\indexlbrace ->{\ifmonospace \else \ecfont 
   \fi \char 123}
 ... \kern -0.05em \secbf {\indexlbrace 
  }
\leftline #1->\line {#1
   \hss }
\initialx ...e {\secfonts \kern -0.05em \secbf #1}
  \nobreak \vskip .33\baseli...

\thisline ->\initial {{\indexlbrace }}
   
...
l.3327 @printindex sx
 
? 
./sketch.texi:3327: Emergency stop.
 
   \thisecfont 
\indexlbrace ->{\ifmonospace \else \ecfont 
   \fi \char 123}
 ... \kern -0.05em \secbf {\indexlbrace 
  }
\leftline #1->\line {#1
   \hss }
\initialx ...e {\secfonts \kern -0.05em \secbf #1}
  \nobreak \vskip .33\baseli...

\thisline ->\initial {{\indexlbrace }}
   
...
l.3327 @printindex sx
 
Output written on sketch.dvi (44 pages, 150420 bytes).
Transcript written on sketch.log.
/usr/bin/texi2dvi: etex exited with bad status, quitting.
Died at make.pl line 87,  line 3335.
debian/rules:27: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
debian/rules:21: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2



Apparently, this happened to work in the past and it does no longer
because of some new texlive package being used, it seems.

[ So I'll omit the standard blurb I add to these kind of bugs ]

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#817033: sumo: FTBFS when built with dpkg-buildpackage -A (in a random way)

[Santiago Vila]

Hi. Found this:

Makefile.am says:

pydoc:
rm -rf docs/pydoc
mkdir docs/pydoc
cd docs/pydoc && \
for i in `find ../../tools/traci ../../tools/sumolib -name "*.py" -not 
-executable | sed 's,../../tools/,,;s,/,.,g;s,.py,,;s,.__init__,,'`; do \
PYTHONPATH="../../tools" python -c "import $$i, pydoc; 
pydoc.writedoc($$i)"; \
done

so the order in which the different "python -c" commands are executed
depends on the order in which "find" outputs its result, but this can be
anything because there is no canonical filesystem ordering.

In the end, the build fails or it does not depending on the *last*
executed command.

For example, this simple Makefile will fail:

all:
true; false
echo Hi

and this one will succeed:

all:
false; true
echo Hi


If we are going to forgive failure in any of the "python -c" commands,
maybe adding "|| true" at the end will do.

OTOH, if every "python -c" command should work flawlessly, the
current Makefile does not correctly express such condition.

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#817033: sumo: FTBFS when built with dpkg-buildpackage -A (in a random way)

[Santiago Vila]

On Mon, Mar 07, 2016 at 11:48:40AM +, Santiago Vila wrote:
> The following trivial patch disables parallel building. I have not tested it
> but I have the strong feeling that this should fix this issue.

Unfortunately, it was just a feeling.

I actually tested the patch and it didn't work on the machine where it usually 
fails.

So this needs to be investigated.

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#817033: sumo: FTBFS when built with dpkg-buildpackage -A (in a random way)

[Santiago Vila]

Package: src:sumo
Version: 0.25.0+dfsg1-2
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel --with autoreconf
   dh_testdir -i -O--parallel
   dh_update_autotools_config -i -O--parallel
   dh_autoreconf -i -O--parallel
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
libtoolize: 'AC_PROG_RANLIB' is rendered obsolete by 'LT_INIT'
configure.ac:37: installing './compile'
configure.ac:10: installing './missing'
src/Makefile.am: installing './depcomp'
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/sumo-0.25.0+dfsg1'
dh_auto_configure -- --prefix=/usr
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu 
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode 
--disable-dependency-tracking --prefix=/usr
configure: WARNING: unrecognized options: --disable-maintainer-mode
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '924' is supported by ustar format... yes
checking whether GID '924' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... none
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for ranlib... ranlib
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu 
format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... 
func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... (cached) ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for ANSI C header files... no
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc 

Bug#816997: gmsh: FTBFS in stretch, build dependencies not in stretch

[Santiago Vila]

Package: src:gmsh
Version: 2.11.0+dfsg1-2
Severity: serious

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed.

But the failure is build-depends related, so it has nothing to do
with the fact that I was doing "dpkg-buildpackage -A", hence
the serious severity.


[...]
Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  sbuild-build-depends-core-dummy
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/770 B of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 file:/<>/resolver-7fGrLz/apt_archive ./ 
sbuild-build-depends-core-dummy 0.invalid.0 [770 B]
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package sbuild-build-depends-core-dummy.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 14575 files and directories currently installed.)
Preparing to unpack .../sbuild-build-depends-core-dummy.deb ...
Unpacking sbuild-build-depends-core-dummy (0.invalid.0) ...
Setting up sbuild-build-depends-core-dummy (0.invalid.0) ...
W: No sandbox user '_apt' on the system, can not drop privileges
Merged Build-Depends: chrpath, cmake, debhelper (>= 9), default-jdk, 
freeglut3-dev, gfortran, javahelper, libann-dev, libblas-dev, libcgns-dev (>= 
3.1.3.2), libfltk1.3-dev, libgl1-mesa-dev, libgl2ps-dev, libglu1-mesa-dev, 
libjpeg-dev, liblapack-dev, libmed-dev, libmedc-dev, liboce-modeling-dev, 
liboce-ocaf-dev, liboce-visualization-dev, libpng-dev, libtet1.5-dev, 
mpi-default-bin, mpi-default-dev, oce-draw, python-dev, swig2.0, texinfo, 
texlive, zlib1g-dev
Filtered Build-Depends: chrpath, cmake, debhelper (>= 9), default-jdk, 
freeglut3-dev, gfortran, javahelper, libann-dev, libblas-dev, libcgns-dev (>= 
3.1.3.2), libfltk1.3-dev, libgl1-mesa-dev, libgl2ps-dev, libglu1-mesa-dev, 
libjpeg-dev, liblapack-dev, libmed-dev, libmedc-dev, liboce-modeling-dev, 
liboce-ocaf-dev, liboce-visualization-dev, libpng-dev, libtet1.5-dev, 
mpi-default-bin, mpi-default-dev, oce-draw, python-dev, swig2.0, texinfo, 
texlive, zlib1g-dev
dpkg-deb: building package 'sbuild-build-depends-gmsh-dummy' in 
'/<>/resolver-y1NavE/apt_archive/sbuild-build-depends-gmsh-dummy.deb'.
OK
Get:1 file:/<>/resolver-y1NavE/apt_archive ./ InRelease
Ign:1 file:/<>/resolver-y1NavE/apt_archive ./ InRelease
Get:2 file:/<>/resolver-y1NavE/apt_archive ./ Release [2119 B]
Get:2 file:/<>/resolver-y1NavE/apt_archive ./ Release [2119 B]
Get:3 file:/<>/resolver-y1NavE/apt_archive ./ Release.gpg [299 B]
Get:3 file:/<>/resolver-y1NavE/apt_archive ./ Release.gpg [299 B]
Get:4 file:/<>/resolver-y1NavE/apt_archive ./ Sources [394 B]
Get:5 file:/<>/resolver-y1NavE/apt_archive ./ Packages [719 B]
Reading package lists...
W: No sandbox user '_apt' on the system, can not drop privileges
Reading package lists...

+--+
| Install gmsh build dependencies (apt-based resolver) |
+--+

Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 sbuild-build-depends-gmsh-dummy : Depends: swig2.0 but it is not installable
E: Unable to correct problems, you have held broken packages.
apt-get failed.
Package installation failed
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be REMOVED:
  sbuild-build-depends-core-dummy*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%

Bug#806876: visp: FTBFS when built with dpkg-buildpackage -A (143 tests failed out of 143)

[Santiago Vila]

On Thu, Dec 03, 2015 at 02:05:26PM +0100, Fabien Spindler wrote:
> On 02/12/2015 16:50, Santiago Vila wrote:
> >So, maybe a target "override_dh_auto_test-indep" that does not do anything
> >would fix this. Thanks.
> Doesn't work if I rename "override_dh_auto_test" into
> "override_dh_auto_test-indep".

That's really the opposite of what we want. We want the tests not to
run at all when we are creating the arch-independent packages.

> Doesn't work if I introduce "override_dh_auto_test-indep" that does nothing
> and keep "override_dh_auto_test" as it is.

That's because the mere existence of override_dh_auto_test-indep,
apparently, does not invalidate override_dh_auto_test.
(I have just done a few tests with an almost dummy package).

> The solution I found is to rename "override_dh_auto_test" into
> "override_dh_auto_test-arch" to make testing arch dependent.
> 
> override_dh_auto_test-arch:
> export VISP_INPUT_IMAGE_PATH=/usr/share/visp-images-data/ \
> && dh_auto_test --max-parallel=1 || ${DH_AUTOTEST_CAN_FAIL}
> 
> I'm not expert, so I don't know if this is the right way to disable testing
> using dpkg-buildpackage -A

As far as it works as intended, it would be right.

But to be safe, I would drop the current override_dh_auto_test, as you
did, and would put both -arch and -indep to replace them:

override_dh_auto_test-indep:

override_dh_auto_test-arch:
your current code

If you only use override_dh_auto_test-arch, it will do dh_auto_test
anyway when building arch-independent packages, since it's not
overridden. It will not do anything because VISP_INPUT_IMAGE_PATH
is not defined, but I think it's better that it does not even try,
hence my suggestion to put an empty override_dh_auto_test-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#806876: visp: FTBFS when built with dpkg-buildpackage -A (143 tests failed out of 143)

[Santiago Vila]

On Wed, Dec 02, 2015 at 04:41:30PM +0100, Fabien Spindler wrote:
> I was able to reproduce.
> 
> Your issue comes from "dpkg-buildpackage -A" that run the tests
> before building the package.
> If I comment debian/rules override_dh_auto_test rule
> "dpkg-buildpackage -A" is working.
> 
> I don't find an additional option to "-A" to turn off the tests.

An additional option to "-A" would not help here.

When a source-only upload is made, normal autobuilders do
"dpkg-buildpackage -B" and a special "Arch: all" autobuilder would do
"dpkg-buildpackage -A" to create the arch-independent packages.

There is no way to tell the autobuilder "hi, please pass an
additional option, because otherwise my package fails".

What we want here is to not run the tests, by design,
when only the architecture-independent packages are created.


I see that you are using "dh" and several override_* targets.

So, maybe a target "override_dh_auto_test-indep" that does not do
anything would fix this.

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#806873: roboptim-core: FTBFS when built with dpkg-buildpackage -A (24 tests failed out of 24)

[Santiago Vila]

Package: src:roboptim-core
Version: 2.0-7.1
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh  build-indep --parallel
   dh_testdir -i -O--parallel
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
dh_auto_configure -- \
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu \
-DCMAKE_INSTALL_DOCDIR=share/doc/libroboptim-core-doc
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DCMAKE_INSTALL_DOCDIR=share/doc/libroboptim-core-doc
-- The C compiler identification is GNU 5.2.1
-- The CXX compiler identification is GNU 5.2.1
-- Check for working C compiler: /usr/bin/cc

[... snipped ...]

<>/obj-x86_64-linux-gnu/tests/Development/visualization-gnuplot-differentiable-function
Unable to find executable: 
/<>/obj-x86_64-linux-gnu/tests/visualization-gnuplot-differentiable-function
24/24 Test #24: visualization-gnuplot-differentiable-function ...***Not Run   
0.00 sec

0% tests passed, 24 tests failed out of 24

Total Test time (real) =   0.04 sec

The following tests FAILED:
  1 - interval (Not Run)
  2 - util (Not Run)
  3 - result (Not Run)
  4 - function (Not Run)
  5 - derivable-function (Not Run)
  6 - twice-derivable-function (Not Run)
  7 - quadratic-function (Not Run)
  8 - linear-function (Not Run)
  9 - problem-cc (Not Run)
 10 - numeric-linear-function (Not Run)
 11 - numeric-quadratic-function (Not Run)
 12 - n-times-derivable-function (Not Run)
 13 - parametrized-function (Not Run)
 14 - derivable-parametrized-function (Not Run)
 15 - plugin (Not Run)
 16 - plugin-laststate (Not Run)
 17 - finite-difference-gradient (Not Run)
 18 - identity-function (Not Run)
 19 - constant-function (Not Run)
 20 - cached-function (Not Run)
 21 - split (Not Run)
 22 - visualization-gnuplot-simple (Not Run)
 23 - visualization-gnuplot-function (Not Run)
 24 - visualization-gnuplot-differentiable-function (Not Run)
Errors while running CTest
Makefile:152: recipe for target 'test' failed
make[1]: *** [test] Error 8
make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
dh_auto_test: make -j1 test ARGS+=-j1 returned exit code 2
debian/rules:26: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one. The common hints are:

* If the only architecture-independent packages are dummy transitional
ones and they were released with jessie, the easy fix is to drop them
now.

* When using "dh", it is allowed to use (independently)
optional targets override_dh_foo-arch and override_dh_foo-indep
(for several values of "foo").


Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, the package would be suitable to be uploaded in source-only
form if you wish.

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#806876: visp: FTBFS when built with dpkg-buildpackage -A (143 tests failed out of 143)

[Santiago Vila]

Package: src:visp
Version: 2.10.0+dfsg-1
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh  build-indep --parallel
   dh_testdir -i -O--parallel
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/visp-2.10.0+dfsg'
# Copy monkey images to replace lena 
cp debian/new-images/img-monkey* doc/image
cp debian/new-images/monkey.* tutorial/image
# Continue with dh_auto_configure
dh_auto_configure -- -DCMAKE_INSTALL_LIBDIR:STRING="lib/x86_64-linux-gnu" 
-DCMAKE_BUILD_TYPE=Release -DBUILD_DEMOS=ON -DBUILD_TESTS=ON 
-DBUILD_EXAMPLES=ON -DBUILD_TUTORIALS=ON -DBUILD_SHARED_LIBS=ON 
-DUSE_FFMPEG=OFF -DUSE_OPENCV=ON -DUSE_COIN=ON -DUSE_LAPACK=ON -DUSE_GSL=ON 
-DUSE_OGRE=ON -DUSE_XML2=ON -DUSE_GTK2=ON -DUSE_LIBJPEG=ON -DUSE_LIBPNG=ON 
-DUSE_X11=ON -DUSE_ZBAR=ON -DUSE_DMTX=ON -DUSE_DC1394=ON -DUSE_V4L2=ON 
-DUSE_OIS=ON -DUSE_LIBFREENECT=ON
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var 
-DCMAKE_INSTALL_LIBDIR:STRING=lib/x86_64-linux-gnu -DCMAKE_BUILD_TYPE=Release 
-DBUILD_DEMOS=ON -DBUILD_TESTS=ON -DBUILD_EXAMPLES=ON -DBUILD_TUTORIALS=ON 
-DBUILD_SHARED_LIBS=ON -DUSE_FFMPEG=OFF -DUSE_OPENCV=ON -DUSE_COIN=ON 
-DUSE_LAPACK=ON -DUSE_GSL=ON -DUSE_OGRE=ON -DUSE_XML2=ON -DUSE_GTK2=ON 
-DUSE_LIBJPEG=ON -DUSE_LIBPNG=ON -DUSE_X11=ON -DUSE_ZBAR=ON -DUSE_DMTX=ON 
-DUSE_DC1394=ON -DUSE_V4L2=ON -DUSE_OIS=ON -DUSE_LIBFREENECT=ON
-- The C compiler identification is GNU 5.2.1

[... snipped ...]

114 - templateTrackerPyramidal-SSDESM-SRT (Not Run)
115 - templateTrackerPyramidal-SSDESM-Translation (Not Run)
116 - templateTrackerPyramidal-SSDForwardAdditional-Affine (Not Run)
117 - templateTrackerPyramidal-SSDForwardAdditional-Homography (Not Run)
118 - templateTrackerPyramidal-SSDForwardAdditional-HomographySL3 (Not 
Run)
119 - templateTrackerPyramidal-SSDForwardAdditional-SRT (Not Run)
120 - templateTrackerPyramidal-SSDForwardAdditional-Translation (Not 
Run)
121 - templateTrackerPyramidal-SSDForwardCompositional-Affine (Not Run)
122 - templateTrackerPyramidal-SSDForwardCompositional-Homography (Not 
Run)
123 - templateTrackerPyramidal-SSDForwardCompositional-HomographySL3 
(Not Run)
124 - templateTrackerPyramidal-SSDForwardCompositional-SRT (Not Run)
125 - templateTrackerPyramidal-SSDForwardCompositional-Translation (Not 
Run)
126 - templateTrackerPyramidal-SSDInverseCompositional-Affine (Not Run)
127 - templateTrackerPyramidal-SSDInverseCompositional-Homography (Not 
Run)
128 - templateTrackerPyramidal-SSDInverseCompositional-HomographySL3 
(Not Run)
129 - templateTrackerPyramidal-SSDInverseCompositional-SRT (Not Run)
130 - templateTrackerPyramidal-SSDInverseCompositional-Translation (Not 
Run)
131 - templateTrackerPyramidal-ZNCCForwardAdditional-Affine (Not Run)
132 - templateTrackerPyramidal-ZNCCForwardAdditional-Homography (Not 
Run)
133 - templateTrackerPyramidal-ZNCCForwardAdditional-HomographySL3 (Not 
Run)
134 - templateTrackerPyramidal-ZNCCForwardAdditional-SRT (Not Run)
135 - templateTrackerPyramidal-ZNCCForwardAdditional-Translation (Not 
Run)
136 - templateTrackerPyramidal-ZNCCInverseCompositional-Affine (Not Run)
137 - templateTrackerPyramidal-ZNCCInverseCompositional-Homography (Not 
Run)
138 - templateTrackerPyramidal-ZNCCInverseCompositional-HomographySL3 
(Not Run)
139 - templateTrackerPyramidal-ZNCCInverseCompositional-SRT (Not Run)
140 - templateTrackerPyramidal-ZNCCInverseCompositional-Translation 
(Not Run)
141 - videoReader (Not Run)
142 - imageSequenceReader (Not Run)
143 - wireframeSimulator (Not Run)
Errors while running CTest
Makefile:119: recipe for target 'test' failed
make[2]: *** [test] Error 8
make[2]: Leaving directory '/<>/visp-2.10.0+dfsg/obj-x86_64-linux-gnu'
dh_auto_test: make -j1 test ARGS+=-j1 returned exit code 2
debian/rules:107: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>/visp-2.10.0+dfsg'
debian/rules:70: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one. The common hints are:

* If the only architecture-independent packages are dummy transitional
ones and they were released with jessie, the easy fix is to drop them
now.

* 

Bug#806864: mlpack: FTBFS when built with dpkg-buildpackage -A (can't cd to debian/mlpack-bin/usr/bin)

[Santiago Vila]

Package: src:mlpack
Version: 1.0.12-5
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel
   dh_testdir -i -O--parallel
   dh_auto_configure -i -O--parallel
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var
-- The C compiler identification is GNU 5.2.1
-- The CXX compiler identification is GNU 5.2.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features

[... snipped ...]

-- Installing: /<>/debian/tmp/usr/bin/nca
-- Removed runtime path from "/<>/debian/tmp/usr/bin/nca"
-- Installing: /<>/debian/tmp/usr/bin/allknn
-- Removed runtime path from "/<>/debian/tmp/usr/bin/allknn"
-- Installing: /<>/debian/tmp/usr/bin/allkfn
-- Removed runtime path from "/<>/debian/tmp/usr/bin/allkfn"
-- Installing: /<>/debian/tmp/usr/bin/nmf
-- Removed runtime path from "/<>/debian/tmp/usr/bin/nmf"
-- Installing: /<>/debian/tmp/usr/bin/pca
-- Removed runtime path from "/<>/debian/tmp/usr/bin/pca"
-- Installing: /<>/debian/tmp/usr/bin/perceptron
-- Removed runtime path from "/<>/debian/tmp/usr/bin/perceptron"
-- Installing: /<>/debian/tmp/usr/bin/radical
-- Removed runtime path from "/<>/debian/tmp/usr/bin/radical"
-- Installing: /<>/debian/tmp/usr/bin/range_search
-- Removed runtime path from "/<>/debian/tmp/usr/bin/range_search"
-- Installing: /<>/debian/tmp/usr/bin/allkrann
-- Removed runtime path from "/<>/debian/tmp/usr/bin/allkrann"
-- Installing: /<>/debian/tmp/usr/bin/sparse_coding
-- Removed runtime path from "/<>/debian/tmp/usr/bin/sparse_coding"
make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
   debian/rules override_dh_install
make[1]: Entering directory '/<>'
dh_install
for d in\
  debian/mlpack-bin/usr/bin \
  debian/mlpack-bin/usr/share/man/man1; \
do  \
  (cd $d && \
  for f in *; do\
mv --verbose ${f} mlpack_${f};  \
  done);\
done
/bin/sh: 5: cd: can't cd to debian/mlpack-bin/usr/bin
/bin/sh: 5: cd: can't cd to debian/mlpack-bin/usr/share/man/man1
debian/rules:23: recipe for target 'override_dh_install' failed
make[1]: *** [override_dh_install] Error 2
make[1]: Leaving directory '/<>'
debian/rules:10: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one. The common hints are:

* If the only architecture-independent packages are dummy transitional
ones and they were released with jessie, the easy fix is to drop them
now.

* When using "dh", it is allowed to use (independently)
optional targets override_dh_foo-arch and override_dh_foo-indep
(for several values of "foo").


Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, the package would be suitable to be uploaded in source-only
form if you wish.

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#806871: qtiplot: FTBFS when built with dpkg-buildpackage -A (pdflatex failed)

[Santiago Vila]

Package: src:qtiplot
Version: 0.9.8.9-10
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel --with python2
   dh_testdir -i -O--parallel
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
rm -f build.conf
cp build.conf.example build.conf
mkdir -p icons/48x48
mkdir -p icons/128x128
cp qtiplot_logo.png icons/128x128/qtiplot.png
convert qtiplot_logo.png -resize 48x48 icons/48x48/qtiplot.png
dh_auto_configure

[... snipped ...]

index.docbook.tex:5960: Paragraph ended before \GTS@TestRightLabel was complete.
index.docbook.tex:5960: leading text: \caption\label
index.docbook.tex:5960: Undefined control sequence \GTS@Nil.
index.docbook.tex:5960: leading text: \caption\label
index.docbook.tex:5960: Undefined control sequence \@nil.
index.docbook.tex:5960: leading text: \caption\label
index.docbook.tex:5960: Paragraph ended before \GTS@TestRightSpace was complete.
index.docbook.tex:5960: leading text: \caption\label
index.docbook.tex:5960: Undefined control sequence \GTS@Nil.
index.docbook.tex:5960: leading text: \caption\label
index.docbook.tex:5960: Undefined control sequence \GTS@Nil.
index.docbook.tex:5960: leading text: \caption\label
index.docbook.tex:5960: Undefined control sequence \@nil.
index.docbook.tex:5960: leading text: \caption\label
index.docbook.tex:5960: Argument of \label has an extra }.
index.docbook.tex:5960: leading text: \caption\label
index.docbook.tex:5960: Paragraph ended before \label was complete.
index.docbook.tex:5960: leading text: \caption\label
index.docbook.aux:1360: Paragraph ended before \newlabel was complete.
index.docbook.aux:1360: leading text: \newlabel{}{{5.56}{130}{\par
index.docbook.aux:1360: Extra }, or forgotten \endgroup.
index.docbook.aux:1360: leading text: \newlabel{}{{5.56}{130}{\par }
index.docbook.aux:1360: Extra }, or forgotten \endgroup.
index.docbook.aux:1360: leading text: ...bel{}{{5.56}{130}{\par 
}{figure.5.56}{}}
index.docbook.aux:1366: Paragraph ended before \newlabel was complete.
index.docbook.aux:1366: leading text: \newlabel{}{{5.57}{131}{\par
index.docbook.aux:1366: Extra }, or forgotten \endgroup.
index.docbook.aux:1366: leading text: \newlabel{}{{5.57}{131}{\par }
index.docbook.aux:1366: Extra }, or forgotten \endgroup.
index.docbook.aux:1366: leading text: ...bel{}{{5.57}{131}{\par 
}{figure.5.57}{}}
Unexpected error occured
Error: pdflatex compilation failed
Makefile:13: recipe for target 'pdf' failed
make[2]: *** [pdf] Error 1
make[2]: Leaving directory '/<>/manual'
debian/rules:34: recipe for target 'override_dh_auto_build-indep' failed
make[1]: *** [override_dh_auto_build-indep] Error 2
make[1]: Leaving directory '/<>'
debian/rules:13: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one. The common hints are:

* If the only architecture-independent packages are dummy transitional
ones and they were released with jessie, the easy fix is to drop them
now.

* When using "dh", it is allowed to use (independently)
optional targets override_dh_foo-arch and override_dh_foo-indep
(for several values of "foo").


Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, the package would be suitable to be uploaded in source-only
form if you wish.

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#806876: visp: FTBFS when built with dpkg-buildpackage -A (143 tests failed out of 143)

[Santiago Vila]

On Wed, Dec 02, 2015 at 02:12:29PM +0100, Fabien Spindler wrote:

> Tests use visp-images package that seems not installed. That's why
> they fail.

If you refer to visp-images-data, it was installed indeed.
Otherwise dpkg-buildpackage would fail with "missing build-depends".

Please try "dpkg-buildpackage -A" and see it for yourself.

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#806616: fftw3: FTBFS when built with dpkg-buildpackage -A (build-indep fails)

[Santiago Vila]

Package: src:fftw3
Version: 3.3.4-2
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
(cd doc ; /usr/bin/make -j1 -k clean)
make[1]: Entering directory '/<>/doc'
make[1]: *** No rule to make target 'clean'.
make[1]: Leaving directory '/<>/doc'
debian/rules:104: recipe for target 'build-indep' failed
make: [build-indep] Error 2 (ignored)
rm -f doc/*.info* doc/rfftwnd.png doc/html/*
cd doc/FAQ && /usr/bin/make -j1 fftw-faq.html fftw-faq.ascii
make[1]: Entering directory '/<>/doc/FAQ'
make[1]: Nothing to be done for 'fftw-faq.html'.
make[1]: Nothing to be done for 'fftw-faq.ascii'.
make[1]: Leaving directory '/<>/doc/FAQ'
cd doc && /usr/bin/make -j1 && /usr/bin/make -j1 html
make[1]: Entering directory '/<>/doc'
make[1]: *** No targets specified and no makefile found.  Stop.
make[1]: Leaving directory '/<>/doc'
debian/rules:104: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one. The common hints are:

* If the only architecture-independent packages are dummy transitional
ones and they were released with jessie, the easy fix is to drop them
now.

* When using "dh", it is allowed to use (independently)
optional targets override_dh_foo-arch and override_dh_foo-indep
(for several values of "foo").


Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, the package would be suitable to be uploaded in source-only
form if you wish.

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#806619: gmp-ecm: FTBFS when built with dpkg-buildpackage -A (dh_install: libecm0-dev-common missing files)

[Santiago Vila]

Package: src:gmp-ecm
Version: 6.4.4+ds-4
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh build-indep --with autoreconf --builddirectory=_build --parallel
   dh_testdir -i -O--builddirectory=_build -O--parallel
   dh_autoreconf -i -O--builddirectory=_build -O--parallel
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
libtoolize: copying file `build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
configure.ac:11: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are 
deprecated.  For more info, see:
configure.ac:11: 
http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
configure.ac:8: installing 'build-aux/compile'
configure.ac:14: installing 'build-aux/config.guess'
configure.ac:14: installing 'build-aux/config.sub'
configure.ac:10: installing 'build-aux/install-sh'
configure.ac:10: installing 'build-aux/missing'
Makefile.am: installing './INSTALL'
Makefile.am: installing 'build-aux/depcomp'
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/gmp-ecm-6.4.4+ds'
dh_auto_configure -a -- --enable-shared --enable-maintainer-mode
dh_auto_configure: No packages to build.
make[1]: Leaving directory '/<>/gmp-ecm-6.4.4+ds'
   dh_auto_build -i -O--builddirectory=_build -O--parallel
   dh_auto_test -i -O--builddirectory=_build -O--parallel
 fakeroot debian/rules binary-indep
dh binary-indep --with autoreconf --builddirectory=_build --parallel
   dh_testroot -i -O--builddirectory=_build -O--parallel
   dh_prep -i -O--builddirectory=_build -O--parallel
   dh_auto_install -i -O--builddirectory=_build -O--parallel
   dh_install -i -O--builddirectory=_build -O--parallel
dh_install: libecm0-dev-common missing files (usr/include/*.h), aborting
debian/rules:7: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one. The common hints are:

* If the only architecture-independent packages are dummy transitional
ones and they were released with jessie, the easy fix is to drop them
now.

* When using "dh", it is allowed to use (independently)
optional targets override_dh_foo-arch and override_dh_foo-indep
(for several values of "foo").


Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, the package would be suitable to be uploaded in source-only
form if you wish.

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#806198: siscone: FTBFS when built with dpkg-buildpackage -A (dh_testroot in build-indep)

[Santiago Vila]

Package: src:siscone
Version: 2.0.6-1.1
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh_testdir
dh_testroot
dh_testroot: You must run this as root (or use fakeroot).
debian/rules:63: recipe for target 'doxygen-stamp' failed
make: *** [doxygen-stamp] Error 255
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


In this case, debian/rules tries to ensure that you are root in a
target which is not supposed to be executed as root, and it fails.

The way to fix this is up to you, but my own personal preference,
which I would also recommend, is to get rid of each and every
dh_testdir and dh_testroot call.

After all, dpkg-buildpackage already takes care of being root
(or fakeroot) when required, and of course, it does also take care of
being in the right directory. Both things happen by design, so removing
those checks just make debian/rules shorter and easier to understand
without any loss of functionality. It would also make debian/rules
a little bit closer to the minimalistic style that "dh" allows.

Once this issue with dh_testroot is fixed, please ensure that both
"dpkg-buildpackage -A" and "dpkg-buildpackage -B" work. After that,
the package will be suitable to be uploaded in source-only form if you
wish.

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#806080: mpich: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

Package: src:mpich
Version: 3.1-6
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 fakeroot debian/rules binary-indep
dh binary-indep  --parallel --with autoreconf
   dh_testroot -i -O--parallel
   dh_prep -i -O--parallel
   dh_auto_install -i -O--parallel
make -j1 install DESTDIR=/<>/debian/tmp 
AM_UPDATE_INFO_DIR=no
make[1]: Entering directory '/<>'
make  install-recursive
make[2]: Entering directory '/<>'
Making install in /<>/src/mpl
make[3]: Entering directory '/<>/src/mpl'
make[4]: Entering directory '/<>/src/mpl'
 /bin/mkdir -p '/<>/debian/tmp/usr/lib/x86_64-linux-gnu'
 /bin/bash ./libtool   --mode=install /usr/bin/install -c   libmpl.la 
'/<>/debian/tmp/usr/lib/x86_64-linux-gnu'
libtool: install: /usr/bin/install -c .libs/libmpl.so.1.0.0 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/libmpl.so.1.0.0
libtool: install: (cd /<>/debian/tmp/usr/lib/x86_64-linux-gnu && { 
ln -s -f libmpl.so.1.0.0 libmpl.so.1 || { rm -f libmpl.so.1 && ln -s 
libmpl.so.1.0.0 libmpl.so.1; }; })
libtool: install: (cd /<>/debian/tmp/usr/lib/x86_64-linux-gnu && { 
ln -s -f libmpl.so.1.0.0 libmpl.so || { rm -f libmpl.so && ln -s 
libmpl.so.1.0.0 libmpl.so; }; })
libtool: install: /usr/bin/install -c .libs/libmpl.lai 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/libmpl.la
libtool: install: /usr/bin/install -c .libs/libmpl.a 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/libmpl.a
libtool: install: chmod 644 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/libmpl.a
libtool: install: ranlib 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/libmpl.a
libtool: install: warning: remember to run `libtool --finish 
/usr/lib/x86_64-linux-gnu'

[... snipped ...]

   dh_compress -i -O--parallel
   dh_fixperms -i -O--parallel
   debian/rules override_dh_installdeb
make[1]: Entering directory '/<>'
dh_installdeb
sed -i 's:TRIPLET:x86_64-linux-gnu:g' debian/libmpich-dev/DEBIAN/postinst
sed: can't read debian/libmpich-dev/DEBIAN/postinst: No such file or directory
debian/rules:69: recipe for target 'override_dh_installdeb' failed
make[1]: *** [override_dh_installdeb] Error 2
make[1]: Leaving directory '/<>'
debian/rules:3: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one, but I can give some general hints:

* If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now.
 
* If not, debian/rules should be modified so that the binary-indep
target works in all cases, even when binary-arch is not used (this is
what the "Architecture: all" autobuilder does). For that:

* If you are using debhelper, you might want to use options -a and -i
for dh_* commands so that they do not act on packages they do not
have to act.

* Also, if you are using dh, the (independently) optional targets
override_dh_foo-arch and override_dh_foo-indep (for several values
of "foo") may be useful to write a debian/rules which behaves exactly
as desired.


After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B"
work properly, this package will be suitable to be uploaded in
source-only form if you wish (you might want to try it).

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#806108: singular: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

Package: src:singular
Version: 4.0.2-p2+ds-3
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 fakeroot debian/rules binary-indep
dh binary-indep --with autoreconf --parallel
   dh_testroot -i -O--parallel
   dh_prep -i -O--parallel
   debian/rules override_dh_auto_install-indep
make[1]: Entering directory '/<>/singular-4.0.2-p2+ds'
make -C dox install-html TOPSRCDIR=/<>/singular-4.0.2-p2+ds 
DESTDIR=/<>/singular-4.0.2-p2+ds/debian/tmp
make[2]: Entering directory '/<>/singular-4.0.2-p2+ds/dox'
/bin/mkdir -p 
/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html
cp -rp -t 
/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html 
html/search
cp -p -t 
/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html 
html/*.html html/*.png
cp -p -t 
/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html 
html/doxygen.css html/stylesheet.css html/tabs.css
cp -p -t 
/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html 
html/dynsections.js html/svgpan.js
rdfind -outputname /dev/null -removeidentinode false -makesymlinks true 
/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html
Now scanning 
"/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html", 
found 2756 files.
Now have 2756 files in total.
Now removing files with zero size from list...removed 0 files
Total size is 241745107 bytes or 231 Mib
Now sorting on size:removed 2374 files due to unique sizes from list.382 files 
left.
Now eliminating candidates based on first bytes:removed 50 files from list.332 
files left.
Now eliminating candidates based on last bytes:removed 0 files from list.332 
files left.
Now eliminating candidates based on md5 checksum:removed 330 files from list.2 
files left.
It seems like you have 2 files that are not unique
Totally, 21 kib can be reduced.
Now making results file /dev/null
Now making symbolic links. creating 
Making 1 links.
symlinks -r -c -s -v 
/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html
absolute: 
/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html/search/functions_1b.js
 -> 
/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html/search/all_1b.js
changed:  
/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html/search/functions_1b.js
 -> all_1b.js
rdfind -outputname /dev/null -removeidentinode false -makesymlinks true 
/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html/search
Now scanning 
"/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html/search",
 found 518 files.
Now have 518 files in total.
Now removing files with zero size from list...removed 0 files
Total size is 4849569 bytes or 5 Mib
Now sorting on size:removed 233 files due to unique sizes from list.285 files 
left.
Now eliminating candidates based on first bytes:removed 30 files from list.255 
files left.
Now eliminating candidates based on last bytes:removed 0 files from list.255 
files left.
Now eliminating candidates based on md5 checksum:removed 255 files from list.0 
files left.
It seems like you have 0 files that are not unique
Totally, 0 b can be reduced.
Now making results file /dev/null
Now making symbolic links. creating 
Making 0 links.
symlinks -r -c -s -v 
/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html/search
relative: 
/<>/singular-4.0.2-p2+ds/debian/tmp/usr/share/doc/singular/html/search/functions_1b.js
 -> all_1b.js
make[2]: Leaving directory '/<>/singular-4.0.2-p2+ds/dox'
make[1]: Leaving directory '/<>/singular-4.0.2-p2+ds'
   dh_install -i -O--parallel
cp: cannot stat 'debian/tmp/usr/include/singular/': No such file or directory
dh_install: cp --reflink=auto -a debian/tmp/usr/include/singular/ 
debian/libsingular4-dev-common//usr/include/ returned exit code 1
debian/rules:12: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one, but I can give some general hints:

* If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now.
 
* If not, debian/rules should be modified so that the binary-indep
target works in all cases, even when binary-arch is not used (this is
what the "Architecture: all" autobuilder does). For that:

* If you are using debhelper, you might want to use options -a and -i
for dh_* commands so that they do not act on packages they do not
have to act.

* Also, if you are using dh, the (independently) optional targets
override_dh_foo-arch and override_dh_foo-indep (for several values
of "foo") may be useful to 

Bug#806115: tachyon: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

Package: src:tachyon
Version: 0.99~b6+dsx-2
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 fakeroot debian/rules binary-indep
dh binary-indep  --with autoreconf --parallel
   dh_testroot -i -O--parallel
   dh_prep -i -O--parallel
   debian/rules override_dh_auto_install-indep
make[1]: Entering directory '/<>/tachyon-0.99~b6+dsx'
/usr/bin/make -C docs install TOPSRCDIR=/<>/tachyon-0.99~b6+dsx 
DESTDIR=/<>/tachyon-0.99~b6+dsx/debian/tmp
make[2]: Entering directory '/<>/tachyon-0.99~b6+dsx/docs'
mkdir -p /<>/tachyon-0.99~b6+dsx/debian/tmp/usr/share/doc/tachyon
mkdir -p /<>/tachyon-0.99~b6+dsx/debian/tmp/usr/share/doc/tachyon/html
mkdir -p 
/<>/tachyon-0.99~b6+dsx/debian/tmp/usr/share/doc/tachyon/examples
mkdir -p 
/<>/tachyon-0.99~b6+dsx/debian/tmp/usr/share/doc/tachyon/examples/scenes
mkdir -p 
/<>/tachyon-0.99~b6+dsx/debian/tmp/usr/share/doc/tachyon/examples/demosrc
cp -p /<>/tachyon-0.99~b6+dsx/unix/README 
/<>/tachyon-0.99~b6+dsx/debian/tmp/usr/share/doc/tachyon/README.unix
cp -p -t /<>/tachyon-0.99~b6+dsx/debian/tmp/usr/share/doc/tachyon 
tachyon.pdf
cp -p -t 
/<>/tachyon-0.99~b6+dsx/debian/tmp/usr/share/doc/tachyon/html 
tachyon/tachyon.css tachyon/*.html tachyon/*.png
cp -pr -t 
/<>/tachyon-0.99~b6+dsx/debian/tmp/usr/share/doc/tachyon/examples/scenes
 /<>/tachyon-0.99~b6+dsx/scenes/*
cp -p -t 
/<>/tachyon-0.99~b6+dsx/debian/tmp/usr/share/doc/tachyon/examples/demosrc
 /<>/tachyon-0.99~b6+dsx/demosrc/glwin.h 
/<>/tachyon-0.99~b6+dsx/demosrc/glwin.c 
/<>/tachyon-0.99~b6+dsx/demosrc/mainanim.c 
/<>/tachyon-0.99~b6+dsx/demosrc/animspheres.c 
/<>/tachyon-0.99~b6+dsx/demosrc/animspheres2.c 
/<>/tachyon-0.99~b6+dsx/demosrc/hypertex.c 
/<>/tachyon-0.99~b6+dsx/demosrc/fire.c 
/<>/tachyon-0.99~b6+dsx/demosrc/animskull.c 
/<>/tachyon-0.99~b6+dsx/demosrc/tgatoyuv.c
cp -p -t 
/<>/tachyon-0.99~b6+dsx/debian/tmp/usr/share/doc/tachyon/examples/scenes
 /<>/tachyon-0.99~b6+dsx/debian/adhoc/scenes/action.sh
cp: cannot stat 
'/<>/tachyon-0.99~b6+dsx/debian/adhoc/scenes/action.sh': No such file 
or directory
Makefile:71: recipe for target 'install' failed
make[2]: *** [install] Error 1
make[2]: Leaving directory '/<>/tachyon-0.99~b6+dsx/docs'
debian/rules:119: recipe for target 'override_dh_auto_install-indep' failed
make[1]: *** [override_dh_auto_install-indep] Error 2
make[1]: Leaving directory '/<>/tachyon-0.99~b6+dsx'
debian/rules:61: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one, but I can give some general hints:

* If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now.
 
* If not, debian/rules should be modified so that the binary-indep
target works in all cases, even when binary-arch is not used (this is
what the "Architecture: all" autobuilder does). For that:

* If you are using debhelper, you might want to use options -a and -i
for dh_* commands so that they do not act on packages they do not
have to act.

* Also, if you are using dh, the (independently) optional targets
override_dh_foo-arch and override_dh_foo-indep (for several values
of "foo") may be useful to write a debian/rules which behaves exactly
as desired.


After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B"
work properly, this package will be suitable to be uploaded in
source-only form if you wish (you might want to try it).

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#806100: pyviennacl: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

Package: src:pyviennacl
Version: 1.0.2+dfsg-1
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 fakeroot debian/rules binary-indep
dh binary-indep --with python2,python3 --buildsystem=pybuild
   dh_testroot -i -O--buildsystem=pybuild
   dh_prep -i -O--buildsystem=pybuild
   debian/rules override_dh_auto_install-indep
make[1]: Entering directory '/<>/pyviennacl-1.0.2+dfsg'
PYTHONPATH=debian/python-pyviennacl/usr/lib/python2.7/dist-packages python 
doc/build-doc.py
Running Sphinx v1.3.1
making output directory...

Exception occurred:
  File "conf.py", line 81, in 
from pyviennacl import __version__ as version
ImportError: No module named pyviennacl
The full traceback has been saved in /tmp/sphinx-err-c_X_Wx.log, if you want to 
report the issue to the developers.
Please also report this if it was a user error, so that a better error message 
can be provided next time.
A bug report can be filed in the tracker at 
. Thanks!
debian/rules:39: recipe for target 'override_dh_auto_install-indep' failed
make[1]: *** [override_dh_auto_install-indep] Error 1
make[1]: Leaving directory '/<>/pyviennacl-1.0.2+dfsg'
debian/rules:18: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one, but I can give some general hints:

* If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now.
 
* If not, debian/rules should be modified so that the binary-indep
target works in all cases, even when binary-arch is not used (this is
what the "Architecture: all" autobuilder does). For that:

* If you are using debhelper, you might want to use options -a and -i
for dh_* commands so that they do not act on packages they do not
have to act.

* Also, if you are using dh, the (independently) optional targets
override_dh_foo-arch and override_dh_foo-indep (for several values
of "foo") may be useful to write a debian/rules which behaves exactly
as desired.


After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B"
work properly, this package will be suitable to be uploaded in
source-only form if you wish (you might want to try it).

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#806039: gnuplot5: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

Package: src:gnuplot5
Version: 5.0.1+dfsg1-3
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 fakeroot debian/rules binary-indep
dh binary-indep --parallel --with autoreconf
   dh_testroot -i -O--parallel
   dh_prep -i -O--parallel
   debian/rules override_dh_auto_install
make[1]: Entering directory '/<>/gnuplot5-5.0.1+dfsg1'
/usr/bin/make -C /<>/gnuplot5-5.0.1+dfsg1/debian/build-nox install 
DESTDIR=/<>/gnuplot5-5.0.1+dfsg1/debian/tmp/NOX/ \
pkglibexecdir='$(libexecdir)'
make[2]: Entering directory 
'/<>/gnuplot5-5.0.1+dfsg1/debian/build-nox'
Making install in config
make[3]: Entering directory 
'/<>/gnuplot5-5.0.1+dfsg1/debian/build-nox/config'
make[4]: Entering directory 
'/<>/gnuplot5-5.0.1+dfsg1/debian/build-nox/config'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory 
'/<>/gnuplot5-5.0.1+dfsg1/debian/build-nox/config'
make[3]: Leaving directory 
'/<>/gnuplot5-5.0.1+dfsg1/debian/build-nox/config'
Making install in m4
make[3]: Entering directory 
'/<>/gnuplot5-5.0.1+dfsg1/debian/build-nox/m4'
make[4]: Entering directory 
'/<>/gnuplot5-5.0.1+dfsg1/debian/build-nox/m4'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory 
'/<>/gnuplot5-5.0.1+dfsg1/debian/build-nox/m4'

[... snipped ...]

make[3]: Leaving directory '/<>/gnuplot5-5.0.1+dfsg1/debian/build-qt'
make[2]: Leaving directory '/<>/gnuplot5-5.0.1+dfsg1/debian/build-qt'
mv /<>/gnuplot5-5.0.1+dfsg1/debian/tmp/QT/usr/bin/gnuplot 
/<>/gnuplot5-5.0.1+dfsg1/debian/tmp/QT/usr/bin/gnuplot5-qt
mv 
/<>/gnuplot5-5.0.1+dfsg1/debian/tmp/QT/usr/share/man/man1/gnuplot.1 
/<>/gnuplot5-5.0.1+dfsg1/debian/tmp/QT/usr/share/man/man1/gnuplot5-qt.1
mv 
/<>/gnuplot5-5.0.1+dfsg1/debian/tmp/QT/usr/share/gnuplot5/gnuplot.gih 
/<>/gnuplot5-5.0.1+dfsg1/debian/tmp/QT/usr/share/gnuplot5/gnuplot5-qt.gih
make[1]: Leaving directory '/<>/gnuplot5-5.0.1+dfsg1'
   dh_install -i -O--parallel
   dh_installdocs -i -O--parallel
cp: cannot stat 'debian/build-x11/tutorial/tutorial.dvi': No such file or 
directory
dh_installdocs: cp --reflink=auto -a debian/build-x11/tutorial/tutorial.dvi 
debian/gnuplot5-doc/usr/share/doc/gnuplot5-doc returned exit code 1
debian/rules:4: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one, but I can give some general hints:

* If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now.
 
* If not, debian/rules should be modified so that the binary-indep
target works in all cases, even when binary-arch is not used (this is
what the "Architecture: all" autobuilder does). For that:

* If you are using debhelper, you might want to use options -a and -i
for dh_* commands so that they do not act on packages they do not
have to act.

* Also, if you are using dh, the (independently) optional targets
override_dh_foo-arch and override_dh_foo-indep (for several values
of "foo") may be useful to write a debian/rules which behaves exactly
as desired.


After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B"
work properly, this package will be suitable to be uploaded in
source-only form if you wish (you might want to try it).

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#748347: r-cran-deldir: New upstream release available

[Santiago Vila]

Package: r-cran-deldir
Version: 0.0-22-1
Severity: wishlist

Hello Andreas et al. This package is more current here:

deb-src http://ppa.launchpad.net/marutter/c2d4u/ubuntu trusty main

but I would prefer to take the source from Debian (I need it for a
small local repository of R packages backported to wheezy).

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