Re: Maps within Debian
On Tue, Jun 16, 2009 at 22:51, Alastair McKinstry wrote: > Hi, > > I am working on some packages for Debian Meteorology > (http://wiki.debian.org/DebianScience/Meteorology): > magics++ , a plotting / graphics library / scripting system , and zyGrib, a > GRIB (met. format) file viewer. > They both include some coastline maps from "gshhs" > (http://www.ngdc.noaa.gov/mgg/shorelines/gshhs.html), > the "Global Self-Consistent Heirarchical High-Resolution Shoreline database. > This data is GPL'd, > created by the same people as "gmt". I'm interested in the outcome of this discussion, since I'm considering packaging basemap[1] matplotlib's toolkit, that contains gshhs data too. [1] http://matplotlib.sf.net/basemap/doc/html So please keep me in the loop :) Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
maps / coastline files within Debian
Hi, I am working on some packages for Debian Meteorology (http://wiki.debian.org/DebianScience/Meteorology): magics++ , a plotting / graphics library / scripting system , and zyGrib, a GRIB (met. format) file viewer. They both include some coastline maps from "gshhs" (http://www.ngdc.noaa.gov/mgg/shorelines/gshhs.html), the "Global Self-Consistent Heirarchical High-Resolution Shoreline database. This data is GPL'd, created by the same people as "gmt". zyGrib contains 23M of "low-res" maps, with an additional package of 101 MB optional high-res maps. magics++ has 21 MB in one file from this set; the files are in their own .b format. It makes sense to build these files into their own shared package. Now, it appears that these are the same data files in 'gmt' (Generic Mapping Tools) a lower-res version of the coast files are provided in netCDF format in gmt-coast-low (5.5 MB worth). There was a higher-resolution package gmt-coast-high, but this was removed as it took up too much space in Debian. Does anyone know this code? It appears as though the gmt-coast-low is not sufficient for zyGrib and magics++, and I'm not familiar with the history of "gmt" beyond the README. Any ideas or recommendations as to how to proceed? Regards Alastair McKinstry -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Maps within Debian
Hi, I am working on some packages for Debian Meteorology (http://wiki.debian.org/DebianScience/Meteorology): magics++ , a plotting / graphics library / scripting system , and zyGrib, a GRIB (met. format) file viewer. They both include some coastline maps from "gshhs" (http://www.ngdc.noaa.gov/mgg/shorelines/gshhs.html), the "Global Self-Consistent Heirarchical High-Resolution Shoreline database. This data is GPL'd, created by the same people as "gmt". zyGrib contains 23M of "low-res" maps, with an additional package of 101 MB optional high-res maps. magics++ has 21 MB in one file from this set; the files are in their own .b format. It makes sense to build these files into their own shared package. Now, it appears that these are the same data files in 'gmt' (Generic Mapping Tools) a lower-res version of the coast files are provided in netCDF format in gmt-coast-low (5.5 MB worth). There was a higher-resolution package gmt-coast-high, but this was removed as it took up too much space in Debian. Does anyone know this code? It appears as though the gmt-coast-low is not sufficient for zyGrib and magics++, and I'm not familiar with the history of "gmt" beyond the README. Any ideas or recommendations as to how to proceed? Regards Alastair McKinstry **
Re: OpenMPI transition
On Tue, 2009-06-16 at 20:10 +0200, Luk Claes wrote: > Adam C Powell IV wrote: > > On Mon, 2009-06-01 at 19:00 -0400, Adam C Powell IV wrote: > >> Hi, > >> > >> Last week OpenMPI transitioned to a new shared library package, > >> reflecting an ABI change to version 1.3.x (which wasn't reflected in the > >> shared lib package name of 1.3-2). > > > > From what I can see, it looks like there are at least three things > > holding up this transition: the alpha build of openmpi, the hppa build > > of petsc, and the alpha upload of suitesparse (built last week). There > > may of course be others I'm not seeing. > > There are quite some others [1]. Ah, never knew about that, thanks! > > It doesn't look like there's been any attempt to build openmpi, which is > > odd, because the alpha buildd has built a bunch of other stuff. The > > alpha upload of suitesparse is also odd: it seemed to build just fine > > last Wednesday, but is just sitting there without upload. > > openmpi given back and suitesparse scheduled for upload Good, thank you. > > HPPA and petsc is two issues: the first two attempts failed due to a > > stochastic failure to make a file (succeeded in one out of three tries, > > very odd, bug 529485), the next three due to failed Java dependencies. > > > > The Java deps are not working in petsc now, so I could just disable them > > by removing the babel-1.2.0 build-dep. But that would impose another > > ten-day delay on this transition. > > Please upload a fix with urgency medium. Just did, thanks again! -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: OpenMPI transition
Adam C Powell IV wrote: > On Mon, 2009-06-01 at 19:00 -0400, Adam C Powell IV wrote: >> Hi, >> >> Last week OpenMPI transitioned to a new shared library package, >> reflecting an ABI change to version 1.3.x (which wasn't reflected in the >> shared lib package name of 1.3-2). > > From what I can see, it looks like there are at least three things > holding up this transition: the alpha build of openmpi, the hppa build > of petsc, and the alpha upload of suitesparse (built last week). There > may of course be others I'm not seeing. There are quite some others [1]. > It doesn't look like there's been any attempt to build openmpi, which is > odd, because the alpha buildd has built a bunch of other stuff. The > alpha upload of suitesparse is also odd: it seemed to build just fine > last Wednesday, but is just sitting there without upload. openmpi given back and suitesparse scheduled for upload > HPPA and petsc is two issues: the first two attempts failed due to a > stochastic failure to make a file (succeeded in one out of three tries, > very odd, bug 529485), the next three due to failed Java dependencies. > > The Java deps are not working in petsc now, so I could just disable them > by removing the babel-1.2.0 build-dep. But that would impose another > ten-day delay on this transition. Please upload a fix with urgency medium. Cheers Luk [1] build failures for the openmpi and petsc transition can be seen at https://buildd.debian.org/transitions/summary.html -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-scicomp-devel] MPICH2 in Debian
Hi,
On Wed, Jun 17, 2009 at 9:16 AM, Pavan Balaji wrote:
>
> These emails seem to have been broken across two email chains; merging them
> here.
>
> Lucas: thanks for offering to help. I don't have a preference with who
> packages MPICH2. Either you or Muammar, or if needed I can package it
> (though I might need some help if I'm doing it). Also, if either one of you
> wants to do it, I can help with source code issues and even absorb patches
> upstream for the upcoming 1.1.1 release, so the build goes through cleanly.
>
> Muammar: since you have the priority on this, can you let us know how you
> want to proceed?
>
I have been working on it for some time. I started packaging it from
the work who other did (requesting his permission of using it
previously).
The package compiles, but it has a _bunch_ of lintian warnings. Look at them:
muam...@obey:~/src/main/libs/mpich2$ lintian -i mpich2_1.0.7-1_amd64.changes
W: mpich2 source: debian-watch-file-missing-version
N:
N:The debian/watch file in this package doesn't start a version= line. The
N:first non-comment line of debian/watch should be a version= declaration.
N:This may mean that this is an old version one watch file that should be
N:updated to the current version.
N:
N:Refer to the uscan(1) manual page for details.
N:
N:Severity: normal, Certainty: certain
N:
W: mpich2 source: debhelper-but-no-misc-depends mpich2
N:
N:The source package uses debhelper but it does not use ${misc:Depends} in
N:the given binary package's debian/control entry. This is required so the
N:dependencies are set correctly in case the result of a call to any of
N:the dh_ commands cause the package to depend on another package.
N:
N:Refer to the debhelper(7) manual page for details.
N:
N:Severity: normal, Certainty: certain
N:
W: mpich2 source: debhelper-but-no-misc-depends libmpich2-1.0-dev
W: mpich2 source: debhelper-but-no-misc-depends libmpich2-1.0
W: mpich2 source: debhelper-but-no-misc-depends mpich2-mpd
W: mpich2 source: debhelper-but-no-misc-depends mpich2-doc
W: mpich2 source: debhelper-but-no-misc-depends mpich2-mpe
E: mpich2 source: build-depends-on-obsolete-package build-depends: x-dev
N:
N:The package build-depends on a package that has been superseded. If the
N:superseded package is part of an ORed group, it should not be the first
N:package in the group.
N:
N:Severity: important, Certainty: possible
N:
E: mpich2 source: ancient-autotools-helper-file
src/mpi/romio/confdb/config.sub 2003-07-17
N:
N:The referenced file has a time stamp older than year 2004 and the
N:package does not build-depend on autotools-dev or automake and therefore
N:apparently does not update it. This usually means that the source
N:package will not build correctly on all currently released
N:architectures.
N:
N:Read /usr/share/doc/autotools-dev/README.Debian.gz (from the
N:autotools-dev package) for information on how to fix this problem. cdbs
N:will automatically update these files if autotools-dev is installed
N:during build, but the build dependency on autotools-dev is still
N:necessary.
N:
N:Severity: important, Certainty: possible
N:
E: mpich2 source: ancient-autotools-helper-file
src/mpi/romio/confdb/config.guess 2003-07-02
W: mpich2 source: outdated-autotools-helper-file confdb/config.sub 2005-02-10
N:
N:The referenced file has a time stamp older than June of 2006 and the
N:package does not build-depend on autotools-dev or automake and therefore
N:apparently does not update it. This usually means that the source
N:package will not build correctly on AVR32, for which a Debian port is
N:currently in progress, and may not support other newer architectures.
N:
N:Read /usr/share/doc/autotools-dev/README.Debian.gz (from the
N:autotools-dev package) for information on how to fix this problem. cdbs
N:will automatically update these files if autotools-dev is installed
N:during build, but the build dependency on autotools-dev is still
N:necessary.
N:
N:Severity: normal, Certainty: possible
N:
W: mpich2 source: outdated-autotools-helper-file confdb/config.guess 2005-03-24
W: libmpich2-1.0: non-dev-pkg-with-shlib-symlink
usr/lib/libfmpich.so.1.1 usr/lib/libfmpich.so
N:
N:Although this package is not a "-dev" package, it installs a
N:"libsomething.so" symbolic link referencing the corresponding shared
N:library. When the link doesn't include the version number, it is used by
N:the linker when other programs are built against this shared library.
N:
N:Shared libraries are supposed to place such symbolic links in their
N:respective "-dev" packages, so it is a bug to include it with the main
N:library package.
N:
N:However, if this is a small package which includes the runtime and the
N:development libraries, this is not a bug. In the latter case, please
N:override this warning.
N:
N:Refer to Debian Policy Ma
Re: MPICH2 packaging
On Tue, 16 Jun 2009 18:10:06 +0200, Lucas Nussbaum wrote: > On 16/06/09 at 11:57 -0400, Michael S. Gilbert wrote: > > On Tue, 16 Jun 2009 10:06:34 +0200, Lucas Nussbaum wrote: > > > This raises an interesting question: if we package mpich2, couldn't we > > > drop mpich(1) and LAM from Debian? Are there cases where it's more > > > interesting to use mpich v1 or LAM than mpich2 or OpenMPI? > > > > yes, there are many scientific tools that are mpich1-only, so debian > > should continue to support both versions for as long as it is feasible. > > Why are they mpich1-only? (What's blocking?) i'm referring to external tools (not necessarily debian-packaged tools). legacy (if it ain't broke, don't fix it) and lack of funding are the primary blockers for transitioning to mpich2. mike -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: MPICH2 packaging
On 16/06/09 at 11:57 -0400, Michael S. Gilbert wrote: > On Tue, 16 Jun 2009 10:06:34 +0200, Lucas Nussbaum wrote: > > This raises an interesting question: if we package mpich2, couldn't we > > drop mpich(1) and LAM from Debian? Are there cases where it's more > > interesting to use mpich v1 or LAM than mpich2 or OpenMPI? > > yes, there are many scientific tools that are mpich1-only, so debian > should continue to support both versions for as long as it is feasible. Why are they mpich1-only? (What's blocking?) -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: MPICH2 packaging
On Tue, 16 Jun 2009 10:06:34 +0200, Lucas Nussbaum wrote: > This raises an interesting question: if we package mpich2, couldn't we > drop mpich(1) and LAM from Debian? Are there cases where it's more > interesting to use mpich v1 or LAM than mpich2 or OpenMPI? yes, there are many scientific tools that are mpich1-only, so debian should continue to support both versions for as long as it is feasible. regards, mike -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: MPICH2 packaging
On 16 June 2009 at 16:28, Lucas Nussbaum wrote: | On 16/06/09 at 09:24 -0500, Dirk Eddelbuettel wrote: | > | > On 16 June 2009 at 10:06, Lucas Nussbaum wrote: | > | On 15/06/09 at 18:32 -0400, Adam C Powell IV wrote: | > | > Hello Pavan, | > | > | > | > Thank you for the inquiry. I've somewhat left MPICH for now (focusing | > | > on OpenMPI, which I don't maintain but use), and assigned its | > | > maintenance to the Debian Scientific Computing team. But I think there | > | > are others very interested in MPICH2, and am copying the debian-science | > | > list to gauge interest. | > | | > | (Adding Camm Maguire, the LAM maintainer as Cc) | > | > That address has been out of commission for a while; Camm used to work there | > but AFAIK no longer does. I don't have the replacement address handy though. [ I do now, thanks to a bounce analyser at @enhanced.com / @intech.com -- c...@maguirefamily.org it is and this time I made sure I wrote it down in ~/.bbdb ] | > | This raises an interesting question: if we package mpich2, couldn't we | > | drop mpich(1) and LAM from Debian? Are there cases where it's more | > | interesting to use mpich v1 or LAM than mpich2 or OpenMPI? | > | > As a former Open MPI co-maintainer: yes, LAM is to be deprecated one day as | > Open MPI is actively developed whereas LAM is dead. On the other hand, Open | > MPI is available on only a subset of architectures. It's tricky. | > | > That said, getting good MPICH2 in would be super too! | | Would you want to co-maintain it? I already offered Pavan my help, but I would at this point prefer to keep this informal. I have >> 100 packages and simply not that much capacity left. Plus, my own MPI needs are (at least for now) fulfilled by Rmpi using Open MPI. Dirk -- Three out of two people have difficulties with fractions. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: MPICH2 packaging
| > Thank you for the inquiry. I've somewhat left MPICH for now (focusing | > on OpenMPI, which I don't maintain but use), and assigned its | > maintenance to the Debian Scientific Computing team. But I think there | > are others very interested in MPICH2, and am copying the debian-science | > list to gauge interest. | | (Adding Camm Maguire, the LAM maintainer as Cc) That address has been out of commission for a while; Camm used to work there but AFAIK no longer does. I don't have the replacement address handy though. Got a bounced email from Camm's address. Cc'ing the newer one. | This raises an interesting question: if we package mpich2, couldn't we | drop mpich(1) and LAM from Debian? Are there cases where it's more | interesting to use mpich v1 or LAM than mpich2 or OpenMPI? As a former Open MPI co-maintainer: yes, LAM is to be deprecated one day as Open MPI is actively developed whereas LAM is dead. On the other hand, Open MPI is available on only a subset of architectures. It's tricky. That said, getting good MPICH2 in would be super too! MPICH2 has all features that MPICH-1 has (and more), except for heterogeneity support (using it across different architectures simultaneously). Though not many (any?) people use that feature, if it's not too much work it is still useful to have it in there. Another important issue is that I noticed several packages that are integrated with MPICH-1 in the Debian packages list (scalapack-mpich, etc.). So, they might break if we drop out MPICH-1, though it should be fairly trivial to get them to use MPICH-2. In any case, I think the easiest thing to do will be to add in MPICH-2, encourage everyone to migrate from MPICH-1 to MPICH-2, and eventually drop out MPICH-1 after a few years. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: MPICH2 packaging
On 16/06/09 at 09:24 -0500, Dirk Eddelbuettel wrote: > > On 16 June 2009 at 10:06, Lucas Nussbaum wrote: > | On 15/06/09 at 18:32 -0400, Adam C Powell IV wrote: > | > Hello Pavan, > | > > | > Thank you for the inquiry. I've somewhat left MPICH for now (focusing > | > on OpenMPI, which I don't maintain but use), and assigned its > | > maintenance to the Debian Scientific Computing team. But I think there > | > are others very interested in MPICH2, and am copying the debian-science > | > list to gauge interest. > | > | (Adding Camm Maguire, the LAM maintainer as Cc) > > That address has been out of commission for a while; Camm used to work there > but AFAIK no longer does. I don't have the replacement address handy though. > > | This raises an interesting question: if we package mpich2, couldn't we > | drop mpich(1) and LAM from Debian? Are there cases where it's more > | interesting to use mpich v1 or LAM than mpich2 or OpenMPI? > > As a former Open MPI co-maintainer: yes, LAM is to be deprecated one day as > Open MPI is actively developed whereas LAM is dead. On the other hand, Open > MPI is available on only a subset of architectures. It's tricky. > > That said, getting good MPICH2 in would be super too! Would you want to co-maintain it? -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: MPICH2 packaging
On 16 June 2009 at 10:06, Lucas Nussbaum wrote: | On 15/06/09 at 18:32 -0400, Adam C Powell IV wrote: | > Hello Pavan, | > | > Thank you for the inquiry. I've somewhat left MPICH for now (focusing | > on OpenMPI, which I don't maintain but use), and assigned its | > maintenance to the Debian Scientific Computing team. But I think there | > are others very interested in MPICH2, and am copying the debian-science | > list to gauge interest. | | (Adding Camm Maguire, the LAM maintainer as Cc) That address has been out of commission for a while; Camm used to work there but AFAIK no longer does. I don't have the replacement address handy though. | This raises an interesting question: if we package mpich2, couldn't we | drop mpich(1) and LAM from Debian? Are there cases where it's more | interesting to use mpich v1 or LAM than mpich2 or OpenMPI? As a former Open MPI co-maintainer: yes, LAM is to be deprecated one day as Open MPI is actively developed whereas LAM is dead. On the other hand, Open MPI is available on only a subset of architectures. It's tricky. That said, getting good MPICH2 in would be super too! Dirk -- Three out of two people have difficulties with fractions. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: OpenMPI transition
On Mon, 2009-06-01 at 19:00 -0400, Adam C Powell IV wrote: > Hi, > > Last week OpenMPI transitioned to a new shared library package, > reflecting an ABI change to version 1.3.x (which wasn't reflected in the > shared lib package name of 1.3-2). From what I can see, it looks like there are at least three things holding up this transition: the alpha build of openmpi, the hppa build of petsc, and the alpha upload of suitesparse (built last week). There may of course be others I'm not seeing. It doesn't look like there's been any attempt to build openmpi, which is odd, because the alpha buildd has built a bunch of other stuff. The alpha upload of suitesparse is also odd: it seemed to build just fine last Wednesday, but is just sitting there without upload. HPPA and petsc is two issues: the first two attempts failed due to a stochastic failure to make a file (succeeded in one out of three tries, very odd, bug 529485), the next three due to failed Java dependencies. The Java deps are not working in petsc now, so I could just disable them by removing the babel-1.2.0 build-dep. But that would impose another ten-day delay on this transition. So the question is: should I make this change in PETSc in the hopes that it will un-stick stuff as soon as the alpha buildd gets its act together, or leave it, and ... hope that other intervention from on high makes the transition go through in less than ten days? -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: [Pkg-scicomp-devel] MPICH2 in Debian
These emails seem to have been broken across two email chains; merging them here. Lucas: thanks for offering to help. I don't have a preference with who packages MPICH2. Either you or Muammar, or if needed I can package it (though I might need some help if I'm doing it). Also, if either one of you wants to do it, I can help with source code issues and even absorb patches upstream for the upcoming 1.1.1 release, so the build goes through cleanly. Muammar: since you have the priority on this, can you let us know how you want to proceed? Thanks, -- Pavan On 06/16/2009 12:41 AM, Lucas Nussbaum wrote: On 15/06/09 at 16:32 -0500, Pavan Balaji wrote: Hello, I'm one of the developers of MPICH at Argonne National Laboratory. As some of you might be aware, our current focus is mainly on the second generation of MPICH, i.e., MPICH2. I noticed that currently Debian only contains MPICH-1. So, we'd like to work closely with you guys to get MPICH2 packaged into Debian as well. Would someone be able to help us with this? I have contacted the package maintainer for MPICH-1, as well, to find out what we need to do for this. Hi Pavan, I'm willing to help with that. How would you like to proceed? Do you want to maintain the package yourself, and only need a sponsor or backup maintainer, or do you want me to maintain the package and refer to you for issues? Also, there was an ITP (Intent to Package) bug opened about mpich2 (http://bugs.debian.org/420638) a long time ago. I'm Ccing the bug and the submitter, since he might want to step in, and technically has priority over packaging mpich2. -- Pavan Balaji http://www.mcs.anl.gov/~balaji -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: MPICH2 packaging
Hello Pavan, The best starting point for the mpich package is: http://packages.qa.debian.org/m/mpich.html . There you can get the .diff.gz file (labeled ".diff" under Source package), which has all of the "control" files in the debian/ directory, and subscribe to receive emails about package changes. For more information about Debian packages, the best starting point is probably http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html . -Adam On Mon, 2009-06-15 at 22:19 -0500, Pavan Balaji wrote: > Thanks Adam. Btw, can you send me the control files for MPICH-1? I can > try to modify them to work with MPICH2 (I don't know much about debian > binary package creation, but am somewhat familiar with spec files, so a > link to get me started on this would be useful as well). > > All: If anyone is interested in maintaining MPICH2 for Debian, please > let me know. We'd like to work closely with you to make sure MPICH2 is > well supported for Debian. > > Thanks, > > -- Pavan > > On 06/15/2009 05:32 PM, Adam C Powell IV wrote: > > Hello Pavan, > > > > Thank you for the inquiry. I've somewhat left MPICH for now (focusing > > on OpenMPI, which I don't maintain but use), and assigned its > > maintenance to the Debian Scientific Computing team. But I think there > > are others very interested in MPICH2, and am copying the debian-science > > list to gauge interest. > > > > -Adam > > > > On Mon, 2009-06-15 at 16:28 -0500, Pavan Balaji wrote: > >> Hello, > >> > >> I'm one of the MPICH2 developers at Argonne National Laboratory. I > >> noticed that you were the package maintainer for MPICH-1 for Debian. As > >> you might know, most of our current effort is towards MPICH2. We just > >> released v1.1 a few days ago > >> (http://www.mcs.anl.gov/research/projects/mpich2). > >> > >> We wanted to see if we can help get MPICH2 packaged into Debian. Since > >> you have been maintaining MPICH-1, I thought I should just check with > >> you first to see if you can help us with this. > >> > >> Please let us know. > >> > >> Thanks, > >> > >> -- Pavan -- 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: MPICH2 packaging
On 15/06/09 at 18:32 -0400, Adam C Powell IV wrote: > Hello Pavan, > > Thank you for the inquiry. I've somewhat left MPICH for now (focusing > on OpenMPI, which I don't maintain but use), and assigned its > maintenance to the Debian Scientific Computing team. But I think there > are others very interested in MPICH2, and am copying the debian-science > list to gauge interest. (Adding Camm Maguire, the LAM maintainer as Cc) This raises an interesting question: if we package mpich2, couldn't we drop mpich(1) and LAM from Debian? Are there cases where it's more interesting to use mpich v1 or LAM than mpich2 or OpenMPI? -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
