Am Sonntag, den 21.03.2010, 12:49 +0100 schrieb Thibaut Paumard:
I am about to upload a new package which build-depends on mpi-default-
dev (it will need to be checked by a sponsor and then go through NEW).
It it ok to do so in the next couple of days or should I wait for the
new
Hi,
I am about to upload a new package which build-depends on mpi-default-
dev (it will need to be checked by a sponsor and then go through NEW).
It it ok to do so in the next couple of days or should I wait for the
new mpi-default-dev?
Regards, Thibaut.
--
To UNSUBSCRIBE, email to
tags 563705 +patch
thanks
Hi and apologies for the long delay...
On Fri, 2010-02-26 at 14:55 -0500, Adam C Powell IV wrote:
On Fri, 2010-02-26 at 20:22 +0100, Lucas Nussbaum wrote:
On 26/02/10 at 10:46 -0500, Adam C Powell IV wrote:
On Thu, 2010-02-25 at 20:49 +0100, Lucas Nussbaum wrote:
Le vendredi 26 février 2010 à 09:54 +, Alastair McKinstry a écrit :
Perhaps using pkg-config (an mpi.pc file) would be a better solution to
this; it is more
standard: the mpicc, etc. approach isn't very scalable, you can't wrap
every complex
library. Use mpi.pc to point to where
On Thu, 2010-02-25 at 20:49 +0100, Lucas Nussbaum wrote:
On 25/02/10 at 14:22 -0500, Adam C Powell IV wrote:
On Thu, 2010-02-25 at 18:10 +0100, Lucas Nussbaum wrote:
There is not much progress so far with respect to changing
mpi-defaults
to use MPICH2 instead of LAM on the
On Fri, 2010-02-26 at 11:21 +0100, Sylvestre Ledru wrote:
Le vendredi 26 février 2010 à 09:54 +, Alastair McKinstry a écrit :
Perhaps using pkg-config (an mpi.pc file) would be a better solution to
this; it is more
standard: the mpicc, etc. approach isn't very scalable, you can't
On 26/02/10 at 10:46 -0500, Adam C Powell IV wrote:
On Thu, 2010-02-25 at 20:49 +0100, Lucas Nussbaum wrote:
On 25/02/10 at 14:22 -0500, Adam C Powell IV wrote:
On Thu, 2010-02-25 at 18:10 +0100, Lucas Nussbaum wrote:
There is not much progress so far with respect to changing
Hi all,
this is a short status update on this topic.
Am Montag, den 09.11.2009, 16:47 -0800 schrieb Nicholas Breen:
* should we start filing wishlist bugs asking packagers not to build against
MPICH (1) and LAM?
I (finally) got around to file bugs against all packages build-depending
on
On Thu, 2010-02-25 at 18:10 +0100, Lucas Nussbaum wrote:
There is not much progress so far with respect to changing mpi-defaults
to use MPICH2 instead of LAM on the architectures where Open MPI is not
available yet. This needs a round of binNMUs. Marc Brockschmidt said he
will look at
On Mon, 2010-01-04 at 15:46 +0100, Manuel Prinz wrote:
Am Montag, den 28.12.2009, 14:08 +0100 schrieb Lucas Nussbaum:
OK, let's do that. We can always revisit this decision after the squeeze
release, but it's important to have something sane for squeeze.
Sylvestre, can you take the lead
Am Sonntag, den 03.01.2010, 23:26 +0100 schrieb Michael Banck:
If one still wants to have a non-MPI package as well, is there a
preferred suffix for the mpi package using the default? foo-mpi?
There is no policy on that (yet) but your suggestion seems very
reasonable.
Best regards
Manuel
--
On Mon, Nov 30, 2009 at 10:11:49PM -0800, Nicholas Breen wrote:
If you just want one MPI package, it should be enough to Build-Depend on
mpi-default-dev and perform a build of your package with whatever flags are
necessary -- which ideally should be something simple like configure
--enable-mpi
On Tue, 2009-12-01 at 11:31 +0100, Manuel Prinz wrote:
Am Montag, den 30.11.2009, 22:11 -0800 schrieb Nicholas Breen:
On Tue, Dec 01, 2009 at 03:49:20PM +1100, Drew Parsons wrote:
From the point of view of a client package, what is now best practice
for working with MPI? Is there a
Am Montag, den 30.11.2009, 22:11 -0800 schrieb Nicholas Breen:
On Tue, Dec 01, 2009 at 03:49:20PM +1100, Drew Parsons wrote:
From the point of view of a client package, what is now best practice
for working with MPI? Is there a website/wiki/document explaining how
to set up an MPI-using
Am Montag, den 09.11.2009, 16:47 -0800 schrieb Nicholas Breen:
* should we start filing wishlist bugs asking packagers not to build against
MPICH (1) and LAM?
If noone objects by the end of the week, I will file the bugs then. The
number of affected packages is really low and the severity
On 01/12/09 at 11:33 +0100, Manuel Prinz wrote:
Am Montag, den 09.11.2009, 16:47 -0800 schrieb Nicholas Breen:
* should we start filing wishlist bugs asking packagers not to build
against
MPICH (1) and LAM?
If noone objects by the end of the week, I will file the bugs then. The
Le mardi 01 décembre 2009 à 21:20 +0100, Lucas Nussbaum a écrit :
On 01/12/09 at 11:33 +0100, Manuel Prinz wrote:
Am Montag, den 09.11.2009, 16:47 -0800 schrieb Nicholas Breen:
* should we start filing wishlist bugs asking packagers not to build
against
MPICH (1) and LAM?
If
On Tue, Dec 01, 2009 at 11:31:02AM +0100, Manuel Prinz wrote:
Am Montag, den 30.11.2009, 22:11 -0800 schrieb Nicholas Breen:
On Tue, Dec 01, 2009 at 03:49:20PM +1100, Drew Parsons wrote:
From the point of view of a client package, what is now best practice
for working with MPI? Is there
On Wed, 2009-12-02 at 00:48 +0100, Manuel Prinz wrote:
Am Dienstag, den 01.12.2009, 21:20 +0100 schrieb Lucas Nussbaum:
While I would be fine with that, there are other possible plans:
(2) use MPICH2 as default everywhere (it is supported on all release
archs). Clearly, the package
I understand the final state of the modern Debian infrastructure for MPI
is now in place (modulo the questions around deprecating MPICH and LAM).
That is, the disruptive Open MPI transition is now complete, correct?
From the point of view of a client package, what is now best practice
for working
On Tue, Dec 01, 2009 at 03:49:20PM +1100, Drew Parsons wrote:
I understand the final state of the modern Debian infrastructure for MPI
is now in place (modulo the questions around deprecating MPICH and LAM).
That is, the disruptive Open MPI transition is now complete, correct?
Yes, so far as I
Gee, I should stop posting past a certain hour of the day… ;)
On Tue, 2009-11-10 at 18:08 -0500, Adam C Powell IV wrote:
The .so alternatives symlinks only require that the libraries be
API-compatible, which they are (or if not, it's a bug, since they're
supposed to follow the MPI standard).
On Tue, Nov 10, 2009 at 09:19:11AM -0500, Adam C Powell IV wrote:
On Mon, 2009-11-09 at 16:47 -0800, Nicholas Breen wrote:
* is it too late in the release cycle to propose this as a release goal?
should squeeze+1 be the target instead? squeeze+2?
I think it's too late for squeeze, but
On Tue, 2009-11-10 at 16:27 +0100, Michael Banck wrote:
On Tue, Nov 10, 2009 at 09:19:11AM -0500, Adam C Powell IV wrote:
On Mon, 2009-11-09 at 16:47 -0800, Nicholas Breen wrote:
* is it too late in the release cycle to propose this as a release goal?
should squeeze+1 be the target
Am Dienstag, den 10.11.2009, 09:19 -0500 schrieb Adam C Powell IV:
* in mpi-defaults, should MPICH2 replace LAM for architectures not
supported
by OpenMPI?
I think that would make a lot of sense since LAM is end-of-life.
Filed as bug #555653, so we won't forget about that. We should
I generally agree, just a quick nit-pick/clarification:
On Tue, 2009-11-10 at 20:56 +0100, Manuel Prinz wrote:
* Alternatives need to be fixed. Besides what the bugs that
Nicholas referenced say, there are two other issues with those:
First, the priorities do not match
With the recent upload of MPICH2, we now have four separate MPI implementations
in the archive: two with active upstreams and maintainers (MPICH2, OpenMPI) and
two on terminal life support (MPICH, LAM).
There's been some preliminary discussion before about dropping the latter two
[1], though
On Mon, Nov 09, 2009 at 04:47:27PM -0800, Nicholas Breen wrote:
[3] build-deps on: lam4-devlibmpich1.0-dev libopenmpi-dev
...
tree-puzzle yes no no
Just uploaded tree-puzzle builded agianst libopenmpi-dev.
Kind regards
Andreas.
--
28 matches
Mail list logo
