On 28-07-15 18:20, Sebastiaan Couwenberg wrote: > To followup on the rebuilds done by Ross, I've also started a round of > rebuilds.
I sent the above a bit earlier than I had planned, so here's the followup with additional results. There are a couple of easy to solve FTBFS that cannot find the hdf5 library that will need a patch add the HDF5 variant specific library path. For those issues bugs haven't been filed yet, for all other bugs related to the netcdf transition see: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=netcdf-split-c-f-cxx;[email protected] ncview (2.1.5+ds1-1) FTBFS because the mpicc that was used to compile netcdf is missing: checking for nc-config... yes Netcdf library version: netCDF 4.4.0-rc2 Netcdf library has version 4 interface present: yes Netcdf library was compiled with C compiler: /usr/bin/mpicc checking for /usr/bin/mpicc... no configure: error: in `/tmp/buildd/ncview-2.1.5+ds1': configure: error: no acceptable C compiler found in $PATH Because netcdf is built with the openmpi HDF5 variant, it needs to pull in libopenmpi-dev for its mpicc. I've changed the (build) dependencies to libhdf5-mpi-dev in netcdf (1:4.4.0~rc2-1~exp3). libhdf5-mpi-dev depends on libhdf5-openmpi-dev & mpi-default-dev, the latter is required for its dependency on libopenmpi-dev whose mpicc was used to build netcdf. Unfortunately despite having /usr/bin/mpicc available, ncview still refuses to accept it. I've filed the issue in #793902. netcdf4-python (1.1.8-2) FTBFS because it needs to be adapted for the HDF5 openmpi variant. I've uploaded a fixed version (1.1.8-3~exp1) to experimental, but it unfortunately FTBFS on most architectures due to a missing version constraint on the libnetcdf-dev version. That's fix in netcdf4-python (1.1.8-3~exp2). oasis3 (3.mct+dfsg.121022-3 / 3.mct+dfsg.121022-4) both FTBFS because they're missing the build dependency on libnetcdff-dev. The -4 revision in experimental is missing it too. I've forwarded the patch in #793920. octave-octcdf (1.1.8-1) FTBFS just like gnudatalanguage: g++ -shared -Wl,-Bsymbolic -o netcdf.oct ov-netcdf.o ov-ncfile.o \ ov-ncvar.o ov-ncatt.o ov-ncdim.o -Wl,-z,relro -Wl,--as-needed \ -L/usr/lib -lnetcdf -lhdf5_hl -lhdf5 -lz -ldl -lm -lcurl \ -L/usr/lib/x86_64-linux-gnu/octave/4.0.0 \ -L/usr/lib/x86_64-linux-gnu -loctinterp -loctave -Wl,-z,relro \ -Wl,--as-needed /usr/bin/ld: cannot find -lhdf5_hl /usr/bin/ld: cannot find -lhdf5 collect2: error: ld returned 1 exit status It looks like these are easily fixed by adding the HDF5 openmpi library path with -L/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/openmpi. r-cran-ncdf4 (1.13-1) FTBFS just like gnudatalanguage & octave-octcdf: gcc -std=gnu99 -shared -L/usr/lib/R/lib -Wl,-z,relro -o ncdf4.so \ ncdf.o ncdf2.o ncdf3.o src_ncdf4.o -L/usr/lib -lnetcdf -lhdf5_hl \ -lhdf5 -lz -ldl -lm -lcurl -L/usr/lib/R/lib -lR /usr/bin/ld: cannot find -lhdf5_hl /usr/bin/ld: cannot find -lhdf5 collect2: error: ld returned 1 exit status /usr/share/R/share/make/shlib.mk:6: recipe for target 'ncdf4.so' failed We could probably avoid these if we'd stuck to the HDF5 serial variant which supports pkgconfig unlike the mpi variants. I'm starting to doubt if it's wise to only provide NetCDF built with HDF5 MPI. Most if not all our packages use only the HDF5 serial variant. ruby-netcdf (0.6.6-2) FTBFS because it cannot find main() in -lnetcdf. This may be related to the HDF5 MPI variant. I've filed the issue in #793976. ruby-netcdf (0.7.1.1-1) was quickly uploaded in response, but that still fails to build due to the common hdf5 linking problem. vtk (5.8.0-17.5) FTBFS because it's missing a build dependency on libnetcdf-cxx-legacy-dev: [ 24%] Building CXX object IO/CMakeFiles/vtkIO.dir/vtkMPASReader.cxx.o In file included from /tmp/buildd/vtk-5.8.0/IO/vtkMPASReader.cxx:89:0: /tmp/buildd/vtk-5.8.0/Utilities/vtk_netcdfcpp.h:21:23: fatal error: netcdfcpp.h: No such file or directory #include <netcdfcpp.h> ^ compilation terminated. IO/CMakeFiles/vtkIO.dir/build.make:1526: recipe for target 'IO/CMakeFiles/vtkIO.dir/vtkMPASReader.cxx.o' failed make[3]: *** [IO/CMakeFiles/vtkIO.dir/vtkMPASReader.cxx.o] Error 1 Adding the build dependency is suffient to allow both versions to build successfully. I've forwarded them in #794010. gmt (5.1.2+dfsg1-1) FTBFS because it couldn't find the HDF5 libraries either, but that was easily solved in gmt (5.1.2+dfsg1-2~exp1). metview (4.5.6-3 & 4.5.6-4exp1) FTBFS because they're missing a build dependency on libnetcdf-cxx-legacy-dev, with those build dependencies added the builds succeed. The patches are forwarded in #794027. vtk6 (6.2.0+dfsg1-1) is pretty much the same story as for vtk (5.8.0-17.5 / 5.10.1+dfsg-1). Patch forwarded in #794040. Transition: netcdf libnetcdfc7 (1:4.1.3-7.2) -> libnetcdf7 (1:4.4.0~rc2-1~exp3) libnetcdfc++4 (1:4.1.3-7.2) -> libnetcdf-c++4-1 (4.2.1-1~exp3) [cxx4] libnetcdfc++4 (1:4.1.3-7.2) -> libnetcdf-c++4 (4.2-1~exp3) [legacy] libnetcdff5 (1:4.1.3-7.2) -> libnetcdff6 (4.4.2-1~exp4) The status of the most recent rebuilds is as follows. adios (1.8.0-2 / 1.8.0-3) OK / OK cdftools (3.0-1 / 3.0-2~exp1) FTBFS / OK cmor (2.9.1-5 / 2.9.1-6) OK / OK dx (1:4.4.4-7) OK etsf-io (1.0.3-4 / 1.0.4-1~exp1) OK / OK [+] exodusii (6.02.dfsg.1-5 / 6.02.dfsg.1-6) OK / OK ferret-vis (6.9.3-1 / 6.9.3-2~exp1) FTBFS / OK gdal (1.10.1+dfsg-9 / 1.11.2+dfsg-1~exp4) OK / OK gnudatalanguage (0.9.5-2) FTBFS grace (1:5.1.25-1) OK grads (2:2.0.2-5 / 2:2.0.2-6) OK / OK gri (2.12.23-8) FTBFS kst (2.0.3-4) OK libpdl-netcdf-perl (4.20-1) OK [+] magics++ (2.24.7-3) OK [+] minc (2.2.00-6) OK [+] nco (4.5.1-1) FTBFS ncview (2.1.5+ds1-1) FTBFS netcdf4-python (1.1.8-2 / 1.1.8-3~exp2) FTBFS / OK oasis3 (3.mct+dfsg.121022-3 / 3.mct+dfsg.121022-4) OK / OK [+] octave-octcdf (1.1.8-1) FTBFS ovito (2.3.3+dfsg1-1) OK python-scientific (2.9.4-3) OK r-cran-ncdf4 (1.13-1) FTBFS r-cran-rnetcdf (1.6.3-1-1) OK ruby-netcdf (0.7.1.1-1) FTBFS v-sim (3.7.2-1) OK vtk (5.8.0-17.5 / 5.10.1+dfsg-1) OK / OK [+] cdo (1.6.6+dfsg.1-3 / 1.6.6+dfsg.1-4) OK / OK gmt (5.1.2+dfsg1-1 / 5.1.2+dfsg1-2~exp1) FTBFS / OK metview (4.5.6-3 / 4.5.6-4exp1) OK / OK [+] ncl (6.3.0-3~exp1 / 6.3.0-3) OK / OK vtk6 (6.2.0+dfsg1-1) OK [+] Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
