Re: ongoing slepc/petsc transition
On Sat, Feb 25, 2012 at 23:51:12 -0500, Adam C Powell IV wrote: In particular, it's impossible to install hdf5-tools and libhdf5-*mpi-dev at the same time, as is required to build a handful of reverse-depends [3]. This should be fixed now in hdf5 1.8.8-9. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120308172201.ga9...@crater2.logilab.fr
Re: ongoing slepc/petsc transition
On Wed, 2012-02-29 at 11:42 +0100, Julien Cristau wrote: On Mon, Feb 13, 2012 at 15:05:00 -0500, Adam C Powell IV wrote: Ready to transition: mumps, petsc, slepc, hdf5 -- not sure why these didn't go into testing this past weekend, they should all be ready. mumps and hdf5 have now transitioned. For petsc/slepc, they either need to build again on armel and kfreebsd-*, or the out of date binaries on those architectures need to be removed, by filing a bug against the ftp.debian.org pseudo-package. The bug against ftp.debian.org has been filed and closed (661936), but petsc and slepc and their reverse-depends have not transitioned. What more needs to happen? I see a transition page for slepc at http://release.debian.org/transitions/html/slepc.html , does feel++ need to build for any of these other packages to go in? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
On Mon, Mar 5, 2012 at 16:28:25 -0500, Adam C Powell IV wrote: On Wed, 2012-02-29 at 11:42 +0100, Julien Cristau wrote: On Mon, Feb 13, 2012 at 15:05:00 -0500, Adam C Powell IV wrote: Ready to transition: mumps, petsc, slepc, hdf5 -- not sure why these didn't go into testing this past weekend, they should all be ready. mumps and hdf5 have now transitioned. For petsc/slepc, they either need to build again on armel and kfreebsd-*, or the out of date binaries on those architectures need to be removed, by filing a bug against the ftp.debian.org pseudo-package. The bug against ftp.debian.org has been filed and closed (661936), but petsc and slepc and their reverse-depends have not transitioned. What more needs to happen? I see a transition page for slepc at http://release.debian.org/transitions/html/slepc.html , does feel++ need to build for any of these other packages to go in? The bug you reference seems to be about petsc. slepc has the same issue. Cheers, Julien signature.asc Description: Digital signature
Re: ongoing slepc/petsc transition
On Mon, 2012-03-05 at 22:40 +0100, Julien Cristau wrote: On Mon, Mar 5, 2012 at 16:28:25 -0500, Adam C Powell IV wrote: On Wed, 2012-02-29 at 11:42 +0100, Julien Cristau wrote: On Mon, Feb 13, 2012 at 15:05:00 -0500, Adam C Powell IV wrote: Ready to transition: mumps, petsc, slepc, hdf5 -- not sure why these didn't go into testing this past weekend, they should all be ready. mumps and hdf5 have now transitioned. For petsc/slepc, they either need to build again on armel and kfreebsd-*, or the out of date binaries on those architectures need to be removed, by filing a bug against the ftp.debian.org pseudo-package. The bug against ftp.debian.org has been filed and closed (661936), but petsc and slepc and their reverse-depends have not transitioned. What more needs to happen? I see a transition page for slepc at http://release.debian.org/transitions/html/slepc.html , does feel++ need to build for any of these other packages to go in? The bug you reference seems to be about petsc. slepc has the same issue. Oh dear. Do we need to do this for every reverse-depends package in order for the whole thing to transition? PETSc is the one with the build trouble on these architectures... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
On Mon, Mar 5, 2012 at 17:03:51 -0500, Adam C Powell IV wrote: Oh dear. Do we need to do this for every reverse-depends package in order for the whole thing to transition? Yes. If you have a list of debs a single bug probably works though. Cheers, Julien signature.asc Description: Digital signature
Re: ongoing slepc/petsc transition
On Mon, Feb 27, 2012 at 09:20:44 -0500, Adam C Powell IV wrote:
On Mon, 2012-02-27 at 11:15 +0100, Julien Cristau wrote:
On Sat, Feb 25, 2012 at 23:51:12 -0500, Adam C Powell IV wrote:
That said, the HDF5 transition seems a bit premature. There are some
fundamental changes which have broken a couple of its reverse-depends,
which is one reason so many packages needed to be removed from testing
in order to transition it.
I'm sorry but I wasn't going to hold testing hostage of hdf5 for much
longer than a month...
This is a new regression that happened since January 21 and broke at
least med-fichier, with several rdeps of its own. But I understand, it
had to go in at some point.
That would be the fix for #658491 in hdf5 1.8.8-7 I guess. This should
fix it to do what you want, I'm not quite sure why the dep was hardcoded in the
first place:
diff --git a/debian/control b/debian/control
index 77c7256..da9b914 100644
--- a/debian/control
+++ b/debian/control
@@ -220,7 +220,7 @@ Description: Hierarchical Data Format 5 (HDF5) - Helper
tools
Package: hdf5-tools
Section: science
Architecture: any
-Depends: libhdf5-7 (= ${binary:Version}), ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Hierarchical Data Format 5 (HDF5) - Runtime tools
HDF5 is a file format and library for storing scientific data.
HDF5 was designed and implemented to address the deficiencies of
diff --git a/debian/control.in b/debian/control.in
index 499db35..4c84c76 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -220,7 +220,7 @@ Description: Hierarchical Data Format 5 (HDF5) - Helper
tools
Package: hdf5-tools
Section: science
Architecture: any
-Depends: libhdf5-@SONAME@ (= ${binary:Version}), ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Hierarchical Data Format 5 (HDF5) - Runtime tools
HDF5 is a file format and library for storing scientific data.
HDF5 was designed and implemented to address the deficiencies of
Cheers,
Julien
--
Julien Cristau julien.cris...@logilab.fr
Logilab http://www.logilab.fr/
Informatique scientifique gestion de connaissances
--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120229094853.ga24...@crater1.logilab.fr
Re: ongoing slepc/petsc transition
On Mon, Feb 13, 2012 at 15:05:00 -0500, Adam C Powell IV wrote: Ready to transition: mumps, petsc, slepc, hdf5 -- not sure why these didn't go into testing this past weekend, they should all be ready. mumps and hdf5 have now transitioned. For petsc/slepc, they either need to build again on armel and kfreebsd-*, or the out of date binaries on those architectures need to be removed, by filing a bug against the ftp.debian.org pseudo-package. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120229104222.gb24...@crater1.logilab.fr
Re: ongoing slepc/petsc transition
On Sat, Feb 25, 2012 at 23:51:12 -0500, Adam C Powell IV wrote: That said, the HDF5 transition seems a bit premature. There are some fundamental changes which have broken a couple of its reverse-depends, which is one reason so many packages needed to be removed from testing in order to transition it. I'm sorry but I wasn't going to hold testing hostage of hdf5 for much longer than a month... In particular, it's impossible to install hdf5-tools and libhdf5-*mpi-dev at the same time, as is required to build a handful of reverse-depends [3]. There's no reason the MPI and non-MPI shared libs should conflict. Well there's no way they can be installed together as long as they ship the same files, this is not a new issue AFAICT... [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586149 And this bug is almost 2 years old, I don't see that it has anything to do with the recent changes? Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120227101513.ga8...@crater2.logilab.fr
Re: ongoing slepc/petsc transition
On Mon, 2012-02-27 at 11:15 +0100, Julien Cristau wrote: On Sat, Feb 25, 2012 at 23:51:12 -0500, Adam C Powell IV wrote: That said, the HDF5 transition seems a bit premature. There are some fundamental changes which have broken a couple of its reverse-depends, which is one reason so many packages needed to be removed from testing in order to transition it. I'm sorry but I wasn't going to hold testing hostage of hdf5 for much longer than a month... This is a new regression that happened since January 21 and broke at least med-fichier, with several rdeps of its own. But I understand, it had to go in at some point. In particular, it's impossible to install hdf5-tools and libhdf5-*mpi-dev at the same time, as is required to build a handful of reverse-depends [3]. There's no reason the MPI and non-MPI shared libs should conflict. Well there's no way they can be installed together as long as they ship the same files, this is not a new issue AFAICT... Of course. I'll post a patch hopefully sometime today which resolves the conflict. [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586149 And this bug is almost 2 years old, I don't see that it has anything to do with the recent changes? Because it's the same issue: inability to install multiple versions of the HDF5 libraries simultaneously. Then again, the new issue, the regression, is that hdf5-tools and libhdf5-mpi-dev can't be installed simultaneously, so perhaps this is a different issue. But resolving the shared library conflict fixes this new problem. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
Le samedi 25 février 2012 à 23:51 -0500, Adam C Powell IV a écrit : In particular, it's impossible to install hdf5-tools and libhdf5-*mpi-dev at the same time, as is required to build a handful of reverse-depends [3]. There's no reason the MPI and non-MPI shared libs should conflict. Unfortunately, there is a reason. MPI non-MPI HDF5 library are named the same way but present different API/ABI... A fix would be to rename the HDF5/MPI libraries but, as you can imagine, it is not a small step ... Sylvestre -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1330250027.10648.307.ca...@pomegues.inria.fr
Re: ongoing slepc/petsc transition
Adam C Powell IV wrote: I think the first step is to complete the mumps transition [1] for which coinor-ipopt seems to be the main obstacle, with an RC bug [2]. [1] http://release.debian.org/transitions/html/mumps.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659898 I am a bit confused. According to http://release.debian.org/transitions/html/mumps.html petsc 3.2.dfsg-5 is not built on i386. But according to https://buildd.debian.org/status/package.php?p=petsc https://buildd.debian.org/status/fetch.php?pkg=petscarch=i386ver=3.2.dfsg-5stamp=1327613489 there were no problems in building it. Same goes for other architectures as well. What am I missing? thanks -- Kamaraju S Kusumanchi http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jidt37$iu9$1...@dough.gmane.org
Re: ongoing slepc/petsc transition
Hello, is there a chance to get petsc in testing in a near future? gmsh was removed from wheezy because of petsc. Thanks. Anton -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALF6qJ=xog3i4jyzjs-ippjtjtryve2-dc8oq8myyjg8w5t...@mail.gmail.com
Re: ongoing slepc/petsc transition
Hi, Anton Gladky gladky.an...@gmail.com (25/02/2012): is there a chance to get petsc in testing in a near future? gmsh was removed from wheezy because of petsc. as explained by Julien in [1], we had to remove it to let hdf5 go forward. If you need any help to get petsc back into testing, please let us (debian-release) know. 1. http://lists.debian.org/debian-qa-packages/2012/02/msg00221.html Mraw, KiBi. signature.asc Description: Digital signature
Re: ongoing slepc/petsc transition
Hello Anton, On Sat, 2012-02-25 at 15:41 +0100, Cyril Brulebois wrote: Hi, Anton Gladky gladky.an...@gmail.com (25/02/2012): is there a chance to get petsc in testing in a near future? gmsh was removed from wheezy because of petsc. as explained by Julien in [1], we had to remove it to let hdf5 go forward. If you need any help to get petsc back into testing, please let us (debian-release) know. 1. http://lists.debian.org/debian-qa-packages/2012/02/msg00221.html I think the first step is to complete the mumps transition [1] for which coinor-ipopt seems to be the main obstacle, with an RC bug [2]. [1] http://release.debian.org/transitions/html/mumps.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659898 When MUMPS goes in, then petsc and slepc go right in, along with elmerfem, and a couple of others. That said, the HDF5 transition seems a bit premature. There are some fundamental changes which have broken a couple of its reverse-depends, which is one reason so many packages needed to be removed from testing in order to transition it. In particular, it's impossible to install hdf5-tools and libhdf5-*mpi-dev at the same time, as is required to build a handful of reverse-depends [3]. There's no reason the MPI and non-MPI shared libs should conflict. [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586149 Sorry I've been MIA for the past week, busy week at work. I'll try to get together patches for 586149 and 659898 so these things can move forward. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
On Mon, 2012-02-13 at 22:41 +0100, Anton Gladky wrote: A new gmsh was just uploaded, not sure how it will affect things... petsc is not in BD of the last 2 uploads of gmsh. There is a FTBFS, requires fixing. I just tried on amd64. Newest gmsh builds fine with petsc/slepc 3.2 By the way, gmsh is now using oce instead of opencascade. Anton -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1329215805.11283.2.ca...@calcul8.lcmi.local
Re: ongoing slepc/petsc transition
Adam C Powell IV hazel...@debian.org (13/02/2012): Writing in with an update: Thanks. Ready to transition: mumps, petsc, slepc, hdf5 -- not sure why these didn't go into testing this past weekend, they should all be ready. Not quite: http://release.debian.org/transitions/html/hdf5.html http://release.debian.org/transitions/html/mumps.html I didn't follow very closely, but there was a new hdf5 upload this morning, which should fix a few bugs: http://packages.qa.debian.org/h/hdf5/news/20120214T104759Z.html Mraw, KiBi. signature.asc Description: Digital signature
Re: ongoing slepc/petsc transition
Le mardi 14 février 2012 à 12:15 +0100, Cyril Brulebois a écrit : Adam C Powell IV hazel...@debian.org (13/02/2012): Writing in with an update: Thanks. Ready to transition: mumps, petsc, slepc, hdf5 -- not sure why these didn't go into testing this past weekend, they should all be ready. Not quite: http://release.debian.org/transitions/html/hdf5.html I am planning to use the BSP of this week end in Paris to take care of this. BTW, it would be nice to see you there Cyril! ;) Sylvestre -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1329218454.594.59.ca...@korcula.inria.fr
Re: ongoing slepc/petsc transition
On Tue, 2012-02-14 at 12:15 +0100, Cyril Brulebois wrote: Adam C Powell IV hazel...@debian.org (13/02/2012): Writing in with an update: Thanks. Ready to transition: mumps, petsc, slepc, hdf5 -- not sure why these didn't go into testing this past weekend, they should all be ready. Not quite: http://release.debian.org/transitions/html/hdf5.html http://release.debian.org/transitions/html/mumps.html Thanks, these are a lot more helpful than the Excuses pages! But I don't understand the mumps transition page -- does this mean that coinor-ipopt and freefem++ need binNMUs? Hmm, trying to build coinor-ipopt, the ipopt library builds fine, but the build fails during the doxygen step, which is called even with dpkg-buildpackage -B (just filed bug 659898 on this). I didn't follow very closely, but there was a new hdf5 upload this morning, which should fix a few bugs: http://packages.qa.debian.org/h/hdf5/news/20120214T104759Z.html Okay, thanks! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
Writing in with an update: On Thu, 2012-01-26 at 14:59 +0100, Cyril Brulebois wrote: Adam C Powell IV hazel...@debian.org (26/01/2012): On Tue, 2012-01-24 at 00:51 +0100, Cyril Brulebois wrote: That means one “OK-able” package, one “oops-broken-for-a-long-while” package, and several “unknown-status” packages. To keep everyone as testing candidates until this transition is ready, maybe re-uploading petsc 3.1 would do the trick? (Either with an epoch or with the 3.2-is-really-3.1-like dirty version.) This way, all packages can stay in testing and be updated through unstable w/o having to be entangled? I think we're closer than that, we've been active for the past couple of weeks to make this happen. The only unknown at this point is feel++. Stuff to do looks like: * Upload a new petsc to fix some bugs (me, probably today) * Upload a new slepc with a tiny patch to add a header file (me, probably today) * Upload mpich2 from alioth to fix an RC bug (me, today or tomorrow) * Update to deal.II 7.1.0 (me, within a week) * Patch gmsh to work with petsc/slepc 3.2 (Christophe Trophime with my help, probably within a week) * Update DOLFIN (Johannes Ring, within a week) * Test/update feel++ (?? If nobody else I'll take a stab at it) Only in unstable anyway, so it can migrate later AFAICT. * Remove illuminator from testing (release team) dak rm seems happy with it, so it can be hinted out when the rest is ready. * Close the RC bug against mpi-defaults (which is pointless anyway because it transitioned just before I filed it, I'll do this today) It looks like there's a clear path to success, and this can all happen within a week or two, then we can transition a bunch of stuff at once including HDF5. Otherwise we're stuck trying to do two transitions which will take at least 4 weeks... This looks much better than my previous summary. :) And thanks for the details. Of these packages (and some of their dependencies), hypre transitioned this past weekend. Ready to transition: mumps, petsc, slepc, hdf5 -- not sure why these didn't go into testing this past weekend, they should all be ready. Following later: elmerfem, deal.ii, feel++, dolfin, none of which is in testing now anyway, all are currently broken in some way. A new gmsh was just uploaded, not sure how it will affect things... Needs removal from testing: illuminator I think we're near the finish line... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
A new gmsh was just uploaded, not sure how it will affect things... petsc is not in BD of the last 2 uploads of gmsh. There is a FTBFS, requires fixing. By the way, gmsh is now using oce instead of opencascade. Anton 2012/2/13 Adam C Powell IV hazel...@debian.org: Writing in with an update: On Thu, 2012-01-26 at 14:59 +0100, Cyril Brulebois wrote: Adam C Powell IV hazel...@debian.org (26/01/2012): On Tue, 2012-01-24 at 00:51 +0100, Cyril Brulebois wrote: That means one “OK-able” package, one “oops-broken-for-a-long-while” package, and several “unknown-status” packages. To keep everyone as testing candidates until this transition is ready, maybe re-uploading petsc 3.1 would do the trick? (Either with an epoch or with the 3.2-is-really-3.1-like dirty version.) This way, all packages can stay in testing and be updated through unstable w/o having to be entangled? I think we're closer than that, we've been active for the past couple of weeks to make this happen. The only unknown at this point is feel++. Stuff to do looks like: * Upload a new petsc to fix some bugs (me, probably today) * Upload a new slepc with a tiny patch to add a header file (me, probably today) * Upload mpich2 from alioth to fix an RC bug (me, today or tomorrow) * Update to deal.II 7.1.0 (me, within a week) * Patch gmsh to work with petsc/slepc 3.2 (Christophe Trophime with my help, probably within a week) * Update DOLFIN (Johannes Ring, within a week) * Test/update feel++ (?? If nobody else I'll take a stab at it) Only in unstable anyway, so it can migrate later AFAICT. * Remove illuminator from testing (release team) dak rm seems happy with it, so it can be hinted out when the rest is ready. * Close the RC bug against mpi-defaults (which is pointless anyway because it transitioned just before I filed it, I'll do this today) It looks like there's a clear path to success, and this can all happen within a week or two, then we can transition a bunch of stuff at once including HDF5. Otherwise we're stuck trying to do two transitions which will take at least 4 weeks... This looks much better than my previous summary. :) And thanks for the details. Of these packages (and some of their dependencies), hypre transitioned this past weekend. Ready to transition: mumps, petsc, slepc, hdf5 -- not sure why these didn't go into testing this past weekend, they should all be ready. Following later: elmerfem, deal.ii, feel++, dolfin, none of which is in testing now anyway, all are currently broken in some way. A new gmsh was just uploaded, not sure how it will affect things... Needs removal from testing: illuminator I think we're near the finish line... -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ -- debian-science-maintainers mailing list debian-science-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALF6qJnStCOmg5Da=eowiprncnvb9youkje9zhnzhxbkult...@mail.gmail.com
Re: ongoing slepc/petsc transition
On Tue, 2012-01-24 at 00:51 +0100, Cyril Brulebois wrote: Adam C Powell IV hazel...@debian.org (23/01/2012): deal.II detects the PETSc version and acts accordingly, I believe 7.1.0 will work through 3.2. I need to work on upgrading from 7.0.0 to 7.1.0. […] Illuminator has major problems -- the PETSc object on which all of illuminator is based has changed drastically. This will require major upstream surgery, and the new version will not be data-compatible with the old. Since upstream is me, I can tell you I will not have time for the foreseeable future (couple of months at least) to port illuminator to PETSc 3.2. It will need to come out of testing when PETSc transitions. :-( […] Can't speak for the others (dolfin, feel++, gmsh). That means one “OK-able” package, one “oops-broken-for-a-long-while” package, and several “unknown-status” packages. To keep everyone as testing candidates until this transition is ready, maybe re-uploading petsc 3.1 would do the trick? (Either with an epoch or with the 3.2-is-really-3.1-like dirty version.) This way, all packages can stay in testing and be updated through unstable w/o having to be entangled? I think we're closer than that, we've been active for the past couple of weeks to make this happen. The only unknown at this point is feel++. Stuff to do looks like: * Upload a new petsc to fix some bugs (me, probably today) * Upload a new slepc with a tiny patch to add a header file (me, probably today) * Upload mpich2 from alioth to fix an RC bug (me, today or tomorrow) * Update to deal.II 7.1.0 (me, within a week) * Patch gmsh to work with petsc/slepc 3.2 (Christophe Trophime with my help, probably within a week) * Update DOLFIN (Johannes Ring, within a week) * Test/update feel++ (?? If nobody else I'll take a stab at it) * Remove illuminator from testing (release team) * Close the RC bug against mpi-defaults (which is pointless anyway because it transitioned just before I filed it, I'll do this today) It looks like there's a clear path to success, and this can all happen within a week or two, then we can transition a bunch of stuff at once including HDF5. Otherwise we're stuck trying to do two transitions which will take at least 4 weeks... Makes sense? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
Adam C Powell IV hazel...@debian.org (26/01/2012): On Tue, 2012-01-24 at 00:51 +0100, Cyril Brulebois wrote: That means one “OK-able” package, one “oops-broken-for-a-long-while” package, and several “unknown-status” packages. To keep everyone as testing candidates until this transition is ready, maybe re-uploading petsc 3.1 would do the trick? (Either with an epoch or with the 3.2-is-really-3.1-like dirty version.) This way, all packages can stay in testing and be updated through unstable w/o having to be entangled? I think we're closer than that, we've been active for the past couple of weeks to make this happen. The only unknown at this point is feel++. Stuff to do looks like: * Upload a new petsc to fix some bugs (me, probably today) * Upload a new slepc with a tiny patch to add a header file (me, probably today) * Upload mpich2 from alioth to fix an RC bug (me, today or tomorrow) * Update to deal.II 7.1.0 (me, within a week) * Patch gmsh to work with petsc/slepc 3.2 (Christophe Trophime with my help, probably within a week) * Update DOLFIN (Johannes Ring, within a week) * Test/update feel++ (?? If nobody else I'll take a stab at it) Only in unstable anyway, so it can migrate later AFAICT. * Remove illuminator from testing (release team) dak rm seems happy with it, so it can be hinted out when the rest is ready. * Close the RC bug against mpi-defaults (which is pointless anyway because it transitioned just before I filed it, I'll do this today) It looks like there's a clear path to success, and this can all happen within a week or two, then we can transition a bunch of stuff at once including HDF5. Otherwise we're stuck trying to do two transitions which will take at least 4 weeks... This looks much better than my previous summary. :) And thanks for the details. Mraw, KiBi. signature.asc Description: Digital signature
Re: ongoing slepc/petsc transition
Hello Julian, On Sat, 2012-01-21 at 16:49 +0100, Julien Cristau wrote: Hi, it seems there's currently a move from petsc and slepc 3.1 to 3.2 in sid. In addition to the library package names changing, presumably because the new versions are not binary-compatible, the devel package were also renamed, from libpetsc3.1-dev and libslepc3.1-dev to libpetsc3.2-dev and libslepc3.2-dev. Which is a problem, because it means every single reverse dependency would need debian/control changes. Is the new petsc/slepc API really completely incompatible with 3.1, such that all reverse dependencies need source changes to cope with 3.2? If not, what's the reason for changing the -dev package names? If yes, was the change coordinated with the reverse deps so things don't stay broken for too long? I announced it to debian-science a month ago, but didn't coordinate beyond that. :-( Sorry! Is anyone willing to take care of making this happen? I'm working on this for my packages (see below). FWIW the affected packages seem to be: - deal.ii deal.II detects the PETSc version and acts accordingly, I believe 7.1.0 will work through 3.2. I need to work on upgrading from 7.0.0 to 7.1.0. - dolfin - feel++ - gmsh - illuminator Illuminator has major problems -- the PETSc object on which all of illuminator is based has changed drastically. This will require major upstream surgery, and the new version will not be data-compatible with the old. Since upstream is me, I can tell you I will not have time for the foreseeable future (couple of months at least) to port illuminator to PETSc 3.2. It will need to come out of testing when PETSc transitions. :-( - libmesh Should be okay like deal.II, though I haven't touched libMesh in a long time... Can't speak for the others (dolfin, feel++, gmsh). -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: ongoing slepc/petsc transition
On Mon, Jan 23, 2012 at 11:49 PM, Adam C Powell IV hazel...@debian.org wrote: Can't speak for the others (dolfin, feel++, gmsh). DOLFIN 1.0.0 works with PETSc/SLEPc 3.2, only minor changes are needed in the Debian files. I can make a new upload soon. Johannes -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALjQY_H2GOtjdx13Crs=CtqFr45ZqcT_76NRUnKXBy1z=w7...@mail.gmail.com
