Emilio Pozuelo Monfort a écrit , Le 24/07/2014 09:00: > On 21/07/14 23:59, Gilles Filippini wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian.org@packages.debian.org >> Usertags: transition >> >> Dear Release Team, >> >> The last hdf5 release package in experimental (1.8.13+docs-2) >> introduced a soname bump (7 -> 8) due to the MPIPOSIX API removal, plus >> significant path changes to allow the co-installation of the different >> flavors (serial, mpich, openmpi) of the library. >> >> Almost all affected source packages need to be adapted to acknowledge >> the new paths for the hdf5 headers and libraries, depending on the >> flavor of the library used for the build. For most of them the >> fix is trivial and consists in adding proper --with-hdf5 configure >> option or setting C[PP]FLAGS and LDFLAGS at configure step. >> >> For example, with cmake build system: >> include /usr/share/mpi-default-dev/debian_defaults >> export CMAKE_INCLUDE_PATH=/usr/include/hdf5/$(ARCH_DEFAULT_MPI_IMPL) >> export CMAKE_LIBRARY_PATH=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/$(ARCH_DEFAULT_MPI_IMPL) >> >> With configure scripts: >> --with-hdf5=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial >> or >> --with-hdf5-include=/usr/include/hdf5/serial >> --with-hdf5-lib=/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial >> >> Other trivial cases: >> export CPPFLAGS += -I/usr/include/hdf5/serial >> export LDFLAGS += -Wl,-L/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial >> >> >> Affected packages are: >> adios >> armadillo >> aster >> cdo >> cmor >> code-saturne >> dolfin (not in testing) >> exodusii >> flann >> gdal >> getdp (not in testing) >> gmsh >> gnudatalanguage (not in testing) >> gpiv >> gpivtools >> grads >> h5py >> h5utils >> hdf-eos5 >> insighttoolkit4 >> jhdf >> libcgns >> libgpiv >> libmatio >> libpdl-io-hdf5-perl (not in testing) >> libvigraimpex >> magics++ >> mathgl >> med-fichier >> meep >> meep-lam4 >> meep-mpich2 >> meep-mpi-default >> meep-openmpi >> minc >> mpb >> ncl >> netcdf >> nexus >> oasis3 >> octave >> octave-bim >> octave-msh >> ovito >> paraview >> petsc >> pygpiv >> pytables >> python-shogun >> r-cran-hdf5 >> ruby-hdfeos5 >> salome-kernel >> scilab >> shogun >> silo-llnl >> slepc (not in testing) >> stimfit >> syrthes >> tessa (not in testing) >> vtk >> vtk6 >> xdmf >> xmds2 (not in testing) >> yorick-hdf5 >> >> I've tested a build against hdf5 1.8.13+docs-2 for all of them. Here are >> the cases where the fix is not trivial: >> >> FTBFS in sid: >> gnudatalanguage (blocked by plplot which is in a really bad state) >> cmor (missing build-deps in debian/control) >> >> Use deprecated MPIPOSIX API: >> h5py >> silo-llnl >> >> Minor patch to the build system needed: >> hdf-eos5 >> jhdf >> libpdl-io-hdf5-perl >> r-cran-hdf5 >> ruby-hdfeos5 >> scilab >> syrthes >> >> Really weird build system (ymake) >> ncl >> >> There are also some cases where the build dependency on libhdf5-*dev >> seems useless: >> magics++ >> oasis3 >> slepc >> >> >> Now that I've achieved all these test builds I think it is time to >> request a transition slot. > > Have you filed bugs for the packages that need changes? Can those changes to the > build system happen *before* the new hdf5 is uploaded, or do they need to happen > after that? I filed bugs for useless build dependency on hdf5 (#755180, #755681, #755709) and one unrelated FTBFS against cmor (#755167). But the other requested changes should happen *after* the hdf5 upload, so I didn't report them yet. BTW, my last upload to experimental fixes the support for the cmake HDF5 macro. Then a bunch of affected package will need binNMUing only. I am currently rebuilding every affected package to prepare debdiff patches. I'll need a week or so to complete this task. Thanks, _g.
Attachment:
signature.asc
Description: OpenPGP digital signature