Emilio Pozuelo Monfort a écrit , Le 29/07/2014 00:16: > Hi, > > On 27/07/14 01:12, Gilles Filippini wrote: >> Emilio Pozuelo Monfort a écrit , Le 25/07/2014 09:22: >>> On 24/07/14 20:10, Gilles Filippini wrote: >>>> I am currently rebuilding every affected package to prepare debdiff >>>> patches. I'll need a week or so to complete this task. >>> >>> Let us know when that's done. >> >> It took less time than I thought. Here is the new status of affected >> packages: >> >> No action required: >> magics++ >> octave-bim >> octave-msh >> python-shogun >> vtk >> >> Useless bin dependency on hdf5: >> getdp #755973 >> insighttoolkit4 #756015 >> oasis3 #755681 >> slepc #755180 >> >> binNMU required: >> armadillo >> dolfin >> mathgl >> ovito (blocked by #756108) >> paraview (blocked by #756108) >> shogun >> vtk6 (blocked by #756108) > > Can't #756108 be fixed before the transition starts? (If not, why not?)
Sure it could. It's an easy one. But I'm not sure how welcome could be an NMU for a bug which have severity=normal. I you think it's fine I can NMU it with delay=2. >> Fix required (patch proposal ready): >> adios >> aster >> cdo >> cmor >> code-saturne >> exodusii >> flann >> gdal >> gmsh >> gpiv >> gpivtools >> grads >> h5utils >> hdf-eos5 >> jhdf >> libcgns >> libgpiv >> libmatio >> libpdl-io-hdf5-perl >> libvigraimpex >> med-fichier >> meep >> meep-lam4 >> meep-mpich2 >> meep-mpi-default >> meep-openmpi >> minc >> mpb >> ncl >> netcdf >> nexus >> octave >> petsc >> pygpiv >> pytables >> r-cran-hdf5 >> ruby-hdfeos5 >> salome-kernel >> scilab >> stimfit >> syrthes >> tessa >> xdmf >> xmds2 >> yorick-hdf5 > > Can't these be fixed before the transition starts? If not, why not? Are all > the > patches similar? Can you put the patches somewhere (e.g. people.debian.org) so > we can take a look? The fixes are mostly easy ones but should occur after the transition starts because they are related to paths changes in the libhdf5*-dev packages. I've put the patches there: <https://people.debian.org/~pini/hdf5-transition/patches/> > BTW I'd expect bugs to be filed before the transition starts. Would it be acceptable that I file these bugs with the patches attached plus a blocker on this transition bug? >> Depends on deprecated hdf5 mpi-posix API: >> h5py >> silo-llnl > > What does that mean? Is that API deprecated but not removed, so these still > work? Do they need binNMUs then? Or is that API removed? If so, what's the > plan > here? The mpi-posix API was *removed*: <http://www.hdfgroup.org/newsletters/newsletter140.html> The fix for h5py is really easy: just remove the python bindings for this API. It should be easy for silo-llnl too but I'm not at ease with this application so I don't have a patch proposal at hand. I've opened a bug upstream: <http://visitbugs.ornl.gov/issues/1915> > With so many packages needing sourceful uploads after the transition starts, Because of the installation paths changes needed to allow the co-installation of libhdf5*-dev (see below). < I'm > unsure this is a good idea this close to the transition freeze. Also, you > haven't explained why you want this update in Jessie. I see this is just a > point > release. Is there something new in 1.8.13 that we really want that isn't in > 1.8.12? This is an upstream point release indeed. But on the package side this release introduces a long awaited major feature: it is now possible to co-install the different flavors (serial, mpich, openmpi) of the library; they were conflicting before that, leading to recurrent problems: #703439, #721202, #746955. It would really be great to have this solved for Jessie. Thanks, _g. > > Cheers, > Emilio > >> Others: >> gnudatalanguage FTBFS blocked by plplot
signature.asc
Description: OpenPGP digital signature
