Bug#755539: transition: hdf5
block 749395 by 760125 block 749395 by 760162 thanks Hi, shogun did not build on all architectures, please see these two bugs with patches / suggestions. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755539: transition: hdf5
Steven Chamberlain a écrit , Le 01/09/2014 14:38: block 749395 by 760125 block 749395 by 760162 thanks Hi, shogun did not build on all architectures, please see these two bugs with patches / suggestions. Hrm... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760120 Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#755539: transition: hdf5
# in DELAYED/1 close 760125 3.2.0-7.2 unblock 749395 by 760125 unblock 749395 by 760162 # still an issue in shogun packaging severity 760162 important clone 760162 -1 retitle 760162 shogun: builds docs in binary-arch target # also an issue in graphviz reassign -1 src:graphviz found -1 graphviz/2.38.0-5 retitle -1 graphviz: [kfreebsd] multithreaded dot hangs sometimes affects -1 shogun thanks On 01/09/14 14:08, Gilles Filippini wrote: Hrm... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760120 I didn't see any RC bugs filed against shogun and didn't notice that one... Ah well! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755539: transition: hdf5
Control: tags -1 confirmed On 21/07/14 23:59, Gilles Filippini wrote: 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. Go ahead. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755539: transition: hdf5
Emilio Pozuelo Monfort a écrit , Le 26/08/2014 22:25: Control: tags -1 confirmed On 21/07/14 23:59, Gilles Filippini wrote: 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. Go ahead. Uploaded. Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#755539: transition: hdf5
Gilles Filippini a écrit , Le 20/08/2014 19:50: Gilles Filippini a écrit , Le 15/08/2014 20:59: = Package ready = cmor flann gnuplot-iostream gpiv gpivtools magics++ octave-bim octave-msh pktools pygpiv python-shogun syrthes vtk = Useless build depends on hdf5 (package ready anyway) = getdp #755973 insighttoolkit4 #756015 oasis3 #755681 slepc #755180 = binNMU required = adios armadillo aster cdo code-saturne dolfin (not in testing) dynare (after octave) exodusii feel++ (not in testing) gdal gmsh grads h5py h5utils hdf-eos5 jhdf libcgns libgpiv libmatio libpdl-io-hdf5-perl (not in testing) libvigraimpex mathgl med-fichier meep meep-lam4 meep-mpich2 meep-mpi-default meep-openmpi minc mlpack mpb ncl netcdf nexus nifti2dicom (after vtk6) nip2 (after vips) octave ovito paraview petsc pytables r-cran-hdf5 ruby-hdfeos5 salome-kernel scilab shogun silo-llnl stimfit tessa(not in testing) vips (after libmatio) vtk6 xdmf xmds2 yorick-hdf5 = Others - Not in testing anyway = gnudatalanguage FTBFS blocked by plplot openmeeg FTBFS on sid - #730904 plplot FTBFS on sid - #713309 and more Looking at the packages listed on the auto-hdf5 transition page I realize that I missed two affected packages: These two packages were uploaded to unstable with a fix. Their status are now: = binNMU required = octave-communications = Others - Not in testing anyway = mapsempler2 unrelated FTBFS on sid - the version in testing doesn't depend on HDF5 Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#755539: transition: hdf5
Le vendredi 22 août 2014 à 10:03 +0200, Gilles Filippini a écrit : = binNMU required = octave-communications Note that this binNMU needs to be done after octave's binNMU. -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Bug#755539: transition: hdf5
Gilles Filippini a écrit , Le 15/08/2014 20:59: = Package ready = cmor flann gnuplot-iostream gpiv gpivtools magics++ octave-bim octave-msh pktools pygpiv python-shogun syrthes vtk = Useless build depends on hdf5 (package ready anyway) = getdp #755973 insighttoolkit4 #756015 oasis3 #755681 slepc #755180 = binNMU required = adios armadillo aster cdo code-saturne dolfin(not in testing) dynare(after octave) exodusii feel++(not in testing) gdal gmsh grads h5py h5utils hdf-eos5 jhdf libcgns libgpiv libmatio libpdl-io-hdf5-perl (not in testing) libvigraimpex mathgl med-fichier meep meep-lam4 meep-mpich2 meep-mpi-default meep-openmpi minc mlpack mpb ncl netcdf nexus nifti2dicom (after vtk6) nip2 (after vips) octave ovito paraview petsc pytables r-cran-hdf5 ruby-hdfeos5 salome-kernel scilab shogun silo-llnl stimfit tessa (not in testing) vips (after libmatio) vtk6 xdmf xmds2 yorick-hdf5 = Others - Not in testing anyway = gnudatalanguage FTBFS blocked by plplot openmeeg FTBFS on sid - #730904 plplotFTBFS on sid - #713309 and more Looking at the packages listed on the auto-hdf5 transition page I realize that I missed two affected packages: mapsempler2 #758730 patch on its way octave-communications #758733 patch on its way as well These two packages will need binNMU only afterward. Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#755539: transition: hdf5
Hi, Gilles Filippini a écrit , Le 01/08/2014 02:38: Emilio Pozuelo Monfort a écrit , Le 31/07/2014 00:34: To be honest, the big number of packages that need sourceful uploads concerns me, this close to the freeze. Other RT members have expressed me their concern as well. Can't you find a way to make the rdeps work with both the current and the new packages? See e.g. the perl 5.20 transition, where the paths are changing and the rdeps need fixing, but those fixes are being done *beforehand* and they work with the old and new perl. Then when the transition starts, we'll only need binNMUs. So if you care so much about this, one possibility would be to forget about the new upstream release to avoid the SONAME bump, and to get the rdeps fixed beforehand. After most have been fixed, you change the paths as needed and NMU the rdeps that didn't get fixed. If I have understood things correctly, no packages will need binNMUs, so there won't be a transition needed for this. You just need to file the bugs and at some point do the switch and NMU what's left. If you file the bugs now at severity important, ping the unfixed bugs in a month, then in 1.5 or 2 months you change the paths and NMU the rest of the fixes, you can get this done by mid-October. Hope what I said makes some sense; it is late and I am tired. But if you ask me about your current proposal, I'd honestly say it is too late for jessie. Thanks for sharing your views. I'd like to take my chance anyway since AIUI you're not giving a definitive NO-GO. To ease the transition I've updated (and tested) my patches so that they support both releases of hdf5. This way, once all the fixes are done, only binNMUs should remain to do. I've now filed bugs against all the packages requesting a fix. See the updated status below. All these packages are now fixed and uploaded to unstable, so that the transition should require binNMUs only. I hope this new status will void your previous concerns :) Thanks in advance, _g. = Package ready = cmor flann gnuplot-iostream gpiv gpivtools magics++ octave-bim octave-msh pktools pygpiv python-shogun syrthes vtk = Useless build depends on hdf5 (package ready anyway) = getdp #755973 insighttoolkit4 #756015 oasis3 #755681 slepc #755180 = binNMU required = adios armadillo aster cdo code-saturne dolfin (not in testing) dynare (after octave) exodusii feel++ (not in testing) gdal gmsh grads h5py h5utils hdf-eos5 jhdf libcgns libgpiv libmatio libpdl-io-hdf5-perl (not in testing) libvigraimpex mathgl med-fichier meep meep-lam4 meep-mpich2 meep-mpi-default meep-openmpi minc mlpack mpb ncl netcdf nexus nifti2dicom (after vtk6) nip2(after vips) octave ovito paraview petsc pytables r-cran-hdf5 ruby-hdfeos5 salome-kernel scilab shogun silo-llnl stimfit tessa (not in testing) vips(after libmatio) vtk6 xdmf xmds2 yorick-hdf5 = Others - Not in testing anyway = gnudatalanguage FTBFS blocked by plplot openmeegFTBFS on sid - #730904 plplot FTBFS on sid - #713309 and more signature.asc Description: OpenPGP digital signature
Bug#755539: transition: hdf5
Emilio Pozuelo Monfort a écrit , Le 31/07/2014 00:34: On 30/07/14 20:09, Gilles Filippini wrote: Hi, Please find an updated status below. I've filed a few more bugs for fixes to build systems which don't need any hint about the new hdf5 paths. I've uploaded a fix for #756108 to DELAYED/2. I've added a usertag HDF5-transition [1] to the bugs related to this transition, but not for bugs related to useless build depends, because they're not in our way. [1] https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=HDF5-transitionuser=pini%40debian.org I'll start tomorrow to file bugs with severity=wishlist + patches for the other packages. Please tell me what more could be needed. I've spent *many* hours these last weeks to prepare this transition (which is my first one BTW). And I'm committed to spent more hours to NMU as needed after the transition starts. I would be very disappointed in case it couldn't happen before the transition freeze. To be honest, the big number of packages that need sourceful uploads concerns me, this close to the freeze. Other RT members have expressed me their concern as well. Anyway... It seems to me like you're entangling two different transitions: - The new upstream release with a SONAME bump - The changes to -dev packages to make the co-installable It seems to me like it's the second one (changes in -dev packages) that requires so many packages to be patched. Is that right? This is also what you care most about and what you want to do before the freeze. Can't you find a way to make the rdeps work with both the current and the new packages? See e.g. the perl 5.20 transition, where the paths are changing and the rdeps need fixing, but those fixes are being done *beforehand* and they work with the old and new perl. Then when the transition starts, we'll only need binNMUs. So if you care so much about this, one possibility would be to forget about the new upstream release to avoid the SONAME bump, and to get the rdeps fixed beforehand. After most have been fixed, you change the paths as needed and NMU the rdeps that didn't get fixed. If I have understood things correctly, no packages will need binNMUs, so there won't be a transition needed for this. You just need to file the bugs and at some point do the switch and NMU what's left. If you file the bugs now at severity important, ping the unfixed bugs in a month, then in 1.5 or 2 months you change the paths and NMU the rest of the fixes, you can get this done by mid-October. Hope what I said makes some sense; it is late and I am tired. But if you ask me about your current proposal, I'd honestly say it is too late for jessie. Thanks for sharing your views. I'd like to take my chance anyway since AIUI you're not giving a definitive NO-GO. To ease the transition I've updated (and tested) my patches so that they support both releases of hdf5. This way, once all the fixes are done, only binNMUs should remain to do. I've now filed bugs against all the packages requesting a fix. See the updated status below. Thanks, _g. = Package ready = cmor magics++ octave-bim octave-msh python-shogun syrthes vtk = Useless build depends on hdf5 (package ready anyway) = getdp #755973 insighttoolkit4 #756015 oasis3 #755681 slepc #755180 = binNMU required = armadillo dolfin mathgl nifti2dicom (after vtk6) nip2(after vips) ovito (blocked by #756108) paraview(blocked by #756108) shogun vips(after libmatio) vtk6(blocked by #756108) = Fix required - patch proposal ready = adios #756647 aster #756659 cdo #756660 code-saturne#756661 dynare #756704 exodusii#756421 feel++ #756435 flann #756471 gdal#756662 gmsh#756472 gnuplot-iostream#756705 gpiv#756663 gpivtools #756665 grads #75 h5utils #756670 hdf-eos5#756671 jhdf#756672 libcgns #756673 libgpiv #756674 libmatio#756675 libpdl-io-hdf5-perl #756676 libvigraimpex #756677 med-fichier #756678 meep#756679 meep-lam4 #756680 meep-mpich2 #756681 meep-mpi-default#756682 meep-openmpi#756683 minc#756684 mlpack #756706 mpb #756685 ncl #756686 netcdf #756687 nexus #756688 octave #756689 petsc #756690 pktools #756707 pygpiv #756692 pytables#756694 r-cran-hdf5 #756695 ruby-hdfeos5#756696
Bug#755539: transition: hdf5
Hi, Please find an updated status below. I've filed a few more bugs for fixes to build systems which don't need any hint about the new hdf5 paths. I've uploaded a fix for #756108 to DELAYED/2. I've added a usertag HDF5-transition [1] to the bugs related to this transition, but not for bugs related to useless build depends, because they're not in our way. [1] https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=HDF5-transitionuser=pini%40debian.org I'll start tomorrow to file bugs with severity=wishlist + patches for the other packages. Please tell me what more could be needed. I've spent *many* hours these last weeks to prepare this transition (which is my first one BTW). And I'm committed to spent more hours to NMU as needed after the transition starts. I would be very disappointed in case it couldn't happen before the transition freeze. Thanks, _g. = No action required = cmor magics++ octave-bim octave-msh python-shogun vtk = Useless build depends on hdf5 (no action required for transition) = getdp #755973 insighttoolkit4 #756015 oasis3 #755681 slepc #755180 = binNMU required = armadillo dolfin mathgl nifti2dicom (after vtk6) nip2(after vips) ovito (blocked by #756108) paraview(blocked by #756108) shogun vips(after libmatio) vtk6(blocked by #756108) = Fix required - patch proposal ready = adios aster cdo cmor code-saturne dynare exodusii(#756421) feel++ (#756435) flann (#756471) gdal gmsh(#756472) gnuplot-iostream 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 mlpack mpb ncl netcdf nexus octave petsc pktools pygpiv pytables r-cran-hdf5 ruby-hdfeos5 salome-kernel scilab stimfit syrthes tessa xdmf xmds2 yorick-hdf5 = Depends on the removed hdf5 mpi-posix API = h5pyeasy to fix - working on a patch silo-llnl not so easy but very low popcon (80) = Others - Not in testing anyway = gnudatalanguage FTBFS blocked by plplot openmeegFTBFS on sid - #730904 plplot FTBFS on sid - #713309 and more signature.asc Description: OpenPGP digital signature
Bug#755539: transition: hdf5
On 30/07/14 20:09, Gilles Filippini wrote: Hi, Please find an updated status below. I've filed a few more bugs for fixes to build systems which don't need any hint about the new hdf5 paths. I've uploaded a fix for #756108 to DELAYED/2. I've added a usertag HDF5-transition [1] to the bugs related to this transition, but not for bugs related to useless build depends, because they're not in our way. [1] https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=HDF5-transitionuser=pini%40debian.org I'll start tomorrow to file bugs with severity=wishlist + patches for the other packages. Please tell me what more could be needed. I've spent *many* hours these last weeks to prepare this transition (which is my first one BTW). And I'm committed to spent more hours to NMU as needed after the transition starts. I would be very disappointed in case it couldn't happen before the transition freeze. To be honest, the big number of packages that need sourceful uploads concerns me, this close to the freeze. Other RT members have expressed me their concern as well. Anyway... It seems to me like you're entangling two different transitions: - The new upstream release with a SONAME bump - The changes to -dev packages to make the co-installable It seems to me like it's the second one (changes in -dev packages) that requires so many packages to be patched. Is that right? This is also what you care most about and what you want to do before the freeze. Can't you find a way to make the rdeps work with both the current and the new packages? See e.g. the perl 5.20 transition, where the paths are changing and the rdeps need fixing, but those fixes are being done *beforehand* and they work with the old and new perl. Then when the transition starts, we'll only need binNMUs. So if you care so much about this, one possibility would be to forget about the new upstream release to avoid the SONAME bump, and to get the rdeps fixed beforehand. After most have been fixed, you change the paths as needed and NMU the rdeps that didn't get fixed. If I have understood things correctly, no packages will need binNMUs, so there won't be a transition needed for this. You just need to file the bugs and at some point do the switch and NMU what's left. If you file the bugs now at severity important, ping the unfixed bugs in a month, then in 1.5 or 2 months you change the paths and NMU the rest of the fixes, you can get this done by mid-October. Hope what I said makes some sense; it is late and I am tired. But if you ask me about your current proposal, I'd honestly say it is too late for jessie. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755539: transition: hdf5
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
Bug#755539: transition: hdf5
Gilles Filippini a écrit , Le 27/07/2014 01:12: 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) 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 Depends on deprecated hdf5 mpi-posix API: h5py silo-llnl Others: gnudatalanguage FTBFS blocked by plplot I've also checked the packages having an indirect build dependency on hdf5, and found a few more ones which will require an action: binNMU: vips (after libmatio) nifti2dicom (after vtk6) nip2 (after vips) Fix required (patch proposal ready): dynare feel++ gnuplot-iostream mlpack pktools Others: openmeeg (not in testing - FTBFS on sid - #730904) plplot (not in testing - FTBFS on sid - #713309 and more) With these packages processed, I think I'm now ready to upload hdf5 1.8.13 to unstable, at your will. Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#755539: transition: hdf5
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?) 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? BTW I'd expect bugs to be filed before the transition starts. 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? With so many packages needing sourceful uploads after the transition starts, 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? Cheers, Emilio Others: gnudatalanguage FTBFS blocked by plplot Thanks, _g. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755539: transition: hdf5
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) 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 Depends on deprecated hdf5 mpi-posix API: h5py silo-llnl Others: gnudatalanguage FTBFS blocked by plplot Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#755539: transition: hdf5
On 24/07/14 20:10, Gilles Filippini wrote: BTW, my last upload to experimental fixes the support for the cmake HDF5 macro. Then a bunch of affected package will need binNMUing only. That's great. 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. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755539: transition: hdf5
On 21/07/14 23:59, Gilles Filippini wrote: Package: release.debian.org Severity: normal User: release.debian@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? Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755539: transition: hdf5
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@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. signature.asc Description: OpenPGP digital signature
Bug#755539: transition: hdf5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. Ben file proposal: title = hdf5; is_affected = .build-depends ~ /libhdf5-((mpi|mpich|mpich2|openmpi|serial)-)?dev/ | .depends ~ /libhdf5-((cpp|mpich|mpich2|openmpi)-)?7/ | .depends ~ /libhdf5-((cpp|mpich|openmpi)-)?8/; is_good = .depends ~ /libhdf5-((cpp|mpich|openmpi)-)?8/; is_bad = .depends ~ /libhdf5-((cpp|mpich|mpich2|openmpi)-)?7/; Please tell me when I can upload to unstable. Many thanks in advance, _g. - -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.14-1-486 Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJTzY0vAAoJEO/obGx//s+Dl/sH/2Y7e/0TQBf4nWo/xu1QS2jD X7l8APZAJxw6YX65K78EHY3NTkqXQVEoZ5gxDFJjPNVYYZnlLyEawYBP0SjuHc/w MnLnoyaN2qddi1zS3/aARG7gdpwMROQDxEFoSTGL60rxpr1kExHmsHgutqF++A8r rWBOMdrdPdhsz5aMyTdKKxh2YMvXU5HngsI5RJED1NBpGthKQpdzPGGJZTB3z3C4 XYAQISV5hB/4ICypmbsAxSO93bCr1rcHulLgGBeoo2gTJz37UId+i0CLcJr3xi2l p1keIS46vErr509RQV/9+3xk7rOM1Btm3rAU+YKCVApoGx9QPAwnP+rGsNoQSEY= =uNM7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
