Hi all
while working on HDF5 I'm considering to move MPI support to use mpi-default-dev
and mpi-default-bin. That would imply providing a single reference platform
support
(openmpi or lam, completely dropping mpich AFAIK) which is quite different from
what
done until today. I wonder if it would
ts. They are supported via forks, so one
would have to package a MPICH2 version for each interconnect.
Mpi-defaults was supposed to support package who need MPI support, and
give it to them in an easy way. I was not designed to be a full-blown
solution. it definitely worth for such a solution but sever
ed by MPICH2 which noone ever packaged.
> I do not know the details but as I check last, MPICH2 seems to not have
> support for modern inter-conntects. They are supported via forks, so one
> would have to package a MPICH2 version for each interconnect.
>
Therefore, it seems to me appropriate
Am Montag, den 16.03.2009, 13:43 +0100 schrieb Francesco P. Lovergine:
> A disclaimer: I'm no more a MPI user currently, so take my opinions with
> a grain of salt.
No worries. My point of view is biased by my Open MPI maintainership.
Any input is welcome if we want to resolve the MPI issues in De
On Mon, Mar 16, 2009 at 02:09:06PM +0100, Manuel Prinz wrote:
> Also, we should decide (as a project) how to deal with MPI
> implementations in general, meaning if we "support" only one, meaning
> that packages build against one we chose, and the others are installed
> as libraries, or if we build
There's been an update of mpi-defaults in preparation for some time now,
to demote lam in favour of mpich2.
What is the status of this update?
Drew
--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
so IMO
> it would be really helpful to [finally] get some movement on the LAM to
> MPICH2 change in mpi-defaults. Can we please try to do this sooner
> rather than later?
>
> I notice nobody responded to my last email about this [6], and if we
> just sit and wait for Godot to f
sh and petsc (and almost
> > certainly salome when we get our act together on that package), so IMO
> > it would be really helpful to [finally] get some movement on the LAM to
> > MPICH2 change in mpi-defaults. Can we please try to do this sooner
> > rather than later?
> >
> &
On Fri, Apr 15, 2011 at 11:21:55AM -0500, Steve M. Robbins wrote:
> This message is reaching all the listed maintainers of mpi-defaults.
> I'd suggest one of you go ahead and make the upload! (If you prefer,
> I can do it)
I'm preparing an upload of a new mpi-defaults just now
On Thu, 2011-05-19 at 22:19 +0200, Manuel Prinz wrote:
> On Fri, Apr 15, 2011 at 11:21:55AM -0500, Steve M. Robbins wrote:
> > This message is reaching all the listed maintainers of mpi-defaults.
> > I'd suggest one of you go ahead and make the upload! (If you prefer,
>
d be great if it could get some testing before an unstable upload,
> > which should be coordinated with the release team anyway.
> Does any autobuilding take place with experimental?
It does. See:
https://buildd.debian.org/status/package.php?p=mpi-defaults&suite=experimental
Sylvestr
MPICH.
notes = "https://lists.debian.org/debian-release/2023/11/msg00379.html";;
Ben file:
title = "mpi-defaults";
is_affected = .build-depends ~ /mpi-default-dev/;
is_good = .depends ~ /libmpich.*/;
is_bad = .depends ~ /libopenmpi.*/;
architectures = [ "armhf","armel","i386" ];
ignored = [ ];
mpi-defaults current makes a number of architectures broken [1] because
they have the default mpi implementation set to lam (where openmpi is
not available)
A patch changing the default mpi from lam to mpich has been stagnating
in git for more than a year, and missed the release of squeeze.
I
Hi Alastair,
I've noticed that you did two mpi-defaults upload, but you haven't
pushed the relevant git tags to the repository. Could you please push
them?
Also, to prevent further missings like these, I'd like to share you a
recent git configuration that always push tags for
Hi,
I've just done a team upload of mpi-defaults to add ia64 support, and did a bit
of cleanup at the same time (optional->extra, compat and standards version,
Vcs-*, etc). I noticed however that the debian/1.9 tag currently points to the
debian/1.8 commit, as op
Hi,
As asked during yesterday's release team meeting, I did a partial
archive rebuild on amd64 with a modified mpi-defaults pointing to mpich2
instead of openmpi. The goal is to detect issues that will show up when
the slower arches are switched to mpich2. (I know the plan is not to
switch
Lucas Nussbaum writes:
[test builds for mpi-default switch to mpich2]
> The following 11 packages failed to build:
> apbs looks for mpi.h in the wrong place
> blacs-mpi missing target 'build-mpich2' in debian/rules
> gdcm ?
> igstk No rule to make target `/usr/lib/libmpi_cxx.so' (?)
> kwwidgets No
gt;
> I would propose that all (or at least) most of these bugs should be
> fixed before we actually do the switch in unstable. Manuel, does that
> seem OK to you?
Erm. I'm very reluctant to filing bugs that can't easily be reproduced
in unstable. At this point, you need a
nt to filing bugs that can't easily be reproduced
> in unstable. At this point, you need a custom mpi-defaults package to
> reproduce them. Also, it is possible that some of them will not be
> fixable before the new mpi-defaults is in unstable (= you can't upload a
> fixed pack
switch in unstable. Manuel, does that
>>> seem OK to you?
>> Erm. I'm very reluctant to filing bugs that can't easily be reproduced
>> in unstable. At this point, you need a custom mpi-defaults package to
>> reproduce them. Also, it is possible that some of the
Apr 2011, Drew Parsons wrote:
> mpi-defaults current makes a number of architectures broken [1] because
> they have the default mpi implementation set to lam (where openmpi is
> not available)
> A patch changing the default mpi from lam to mpich has been stagnating
> in git for more t
On 07/04/11 at 10:25 -0400, Yaroslav Halchenko wrote:
> Hi Drew,
>
> just make it clear -- you are talking about
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=mpi-default-dev_conflict_other_implementations.diff;att=1;bug=575259
> right?
>
> was it tested with packages being rebuil
On Thu, 2011-04-07 at 20:14 +0200, Lucas Nussbaum wrote:
> On 07/04/11 at 10:25 -0400, Yaroslav Halchenko wrote:
> > Hi Drew,
> >
> > just make it clear -- you are talking about
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=mpi-default-dev_conflict_other_implementations.diff;att=
to replace a library did
always bother me and I think this is broken. We should consider modifying
the packages in a way so that mpi-defaults would provide libmpi.so. I did
not check how a migration path would look like, though.
My preferred way of action would be to update openmpi (ABI
library did
>always bother me and I think this is broken. We should consider modifying
>the packages in a way so that mpi-defaults would provide libmpi.so. I did
>not check how a migration path would look like, though.
>
> My preferred way of action would be to update openm
On 10/04/11 at 17:13 +1000, Drew Parsons wrote:
> This sounds reasonable to me. My only question is, what timeframe could
> we expect the openmpi updates (armel, mips[el] [s390?]) to take? Should
> we set some deadline at which point we say we can't wait any longer, and
> then
TSc with HDF5 support and gmsh to name two).
FWIW, my "vote" would be to go ahead and replace LAM with MPICH2 on the
non-OpenMPI arches now, and remove LAM and MPICH1 from the archive. Or
if we decide MPICH2 is better than OpenMPI, default to that everywhere.
Either way, let's
On Thu, Apr 07, 2011 at 02:58:42PM +1000, Drew Parsons wrote:
> mpi-defaults current makes a number of architectures broken [1] because
> they have the default mpi implementation set to lam (where openmpi is
> not available)
>
> A patch changing the default mpi from lam to
On 10/05/11 at 20:16 -0700, Nicholas Breen wrote:
> On Thu, Apr 07, 2011 at 02:58:42PM +1000, Drew Parsons wrote:
> > mpi-defaults current makes a number of architectures broken [1] because
> > they have the default mpi implementation set to lam (where openmpi is
> > not
verywhere.
> Either way, let's get rid of LAM and MPICH1, and switch mpi-defaults,
> sooner rather than later.
This seems reasonable and we should go that route. The proposed plan (as
I understand it) would be:
LAM removal:
- Update mpi-defaults to use MPICH2 (in progress). binNMU all p
Hi Nicolas!
Thank you very much for investigating and your patches!
On Tue, May 10, 2011 at 08:16:52PM -0700, Nicholas Breen wrote:
> The second category are packages that still Build-Depend directly on LAM or
> MPICH1, part of the list at [1]. There are only six of them left! I've
> submitted
On Thu, 2011-05-19 at 22:31 +0200, Manuel Prinz wrote:
>
> So these are basically two orthogonal changes, and the new mpi-defaults
> helps the LAM removal. I will upload a fixed mpi-defaults soon so that
> the LAM removal can take place ASAP.
>
Hi Manuel, thanks for uploading
Drew Parsons writes:
> 1) why is the experimental buildd not using the latest experimental
> package?
Typically because the build dependencies weren't strict enough to force
it to, as experimental autobuilders otherwise favor versions from
unstable. I haven't checked whether that applies to thi
I think that it is the case indeed since the migration is
unavoidable and versioning the dependency on mpi-defaults is not
appropriate for this case, why not simply upload mpi-defaults 1.0
directly to unstable?
On Sun, 19 Jun 2011, Aaron M. Ucko wrote:
> Drew Parsons writes:
> >
On Mon, 2011-06-20 at 00:51 -0400, Yaroslav Halchenko wrote:
> I think that it is the case indeed since the migration is
> unavoidable and versioning the dependency on mpi-defaults is not
> appropriate for this case, why not simply upload mpi-defaults 1.0
> directly to unstabl
Hi Mattia,
Done. My tags failed to get pushed properly originally as I hadn't
annotated them, which the hooks require.
regards
Alastair
On 29/08/2017 14:02, Mattia Rizzolo wrote:
> Hi Alastair,
>
> I've noticed that you did two mpi-defaults upload, but you haven't
&
On Tue, Aug 29, 2017 at 03:02:57PM +0200, Mattia Rizzolo wrote:
> Also, to prevent further missings like these, I'd like to share you a
> recent git configuration that always push tags for commits you are
> pushing:
> push.followTags = true
I added this into my ~/.gitconfig but this did not pu
On Thu, Aug 31, 2017 at 11:21:17PM +0200, Andreas Tille wrote:
> I added this into my ~/.gitconfig but this did not pushed tags
> automatically.
mh, really? In gitconfig it should be something like
```
[push]
followTags = true
```
What it does is (git-config(1)):
push.followTags
Hi Mattia,
On Thu, Aug 31, 2017 at 11:50:27PM +0200, Mattia Rizzolo wrote:
> On Thu, Aug 31, 2017 at 11:21:17PM +0200, Andreas Tille wrote:
> > I added this into my ~/.gitconfig but this did not pushed tags
> > automatically.
>
> mh, really? In gitconfig it should be something like
>
> ```
> [p
On Thu, Aug 31, 2017 at 11:58:20PM +0200, Andreas Tille wrote:
…
> This is exactly what I did.
>
> > the behaviour I'm seeing is: if you are pushing a branch "foo", and that
> > branch "foo" contains a commit that is tagged, then that tag will also
> > be pushed.
>
> I did a git push on master b
Hi,
Deleted the 1.9 tag on salsa.
I think we also need to change powerpc and ppc64 to mpich, as of openmpi3:
"
configure: error: Big endian PPC is no longer supported.
"
regards
Alastair
On 05/02/2018 12:42, James Clarke wrote:
> Hi,
> I've just done a team upload of mpi
On 5 Feb 2018, at 12:48, Alastair McKinstry wrote:
> On 05/02/2018 12:42, James Clarke wrote:
>> Hi,
>> I've just done a team upload of mpi-defaults to add ia64 support, and did a
>> bit
>> of cleanup at the same time (optional->extra, compat and standards
On Mon, Feb 05, 2018 at 12:48:31PM +, Alastair McKinstry wrote:
> I think we also need to change powerpc and ppc64 to mpich, as of openmpi3:
Remember that switching a default mpi requires a library transition, and
an ordered rebuild of all rdeps.
I've added a README.source with such info.
--
On 05/02/2018 16:18, Mattia Rizzolo wrote:
> On Mon, Feb 05, 2018 at 12:48:31PM +, Alastair McKinstry wrote:
>> I think we also need to change powerpc and ppc64 to mpich, as of openmpi3:
> Remember that switching a default mpi requires a library transition, and
> an ordered rebuild of all rdep
Hello,
I've just finished re-doing the blacs and scalapack packages using
mpi-defaults. The results are in http://lyre.mit.edu/~powell/mumps/
(since I'm using them for my not-yet-finished MUMPS package). They are
NMUs approved by the maintainer to close bugs 491028 and 491105.
If yo
Package: wnpp
Severity: wishlist
Package name: mpi-defaults
Version: 0.1
Author: Debian Science Team <[EMAIL PROTECTED]>
License: Undetermined
This new source package will produce two binary meta-packages:
default-mpi-dev and default-mpi-bin which depend on libopenmpi-dev and
openm
On 19 November 2008 at 09:40, Adam C Powell IV wrote:
| Package: wnpp
| Severity: wishlist
|
| Package name: mpi-defaults
| Version: 0.1
| Author: Debian Science Team <[EMAIL PROTECTED]>
| License: Undetermined
|
| This new source package will produce two binary meta-packages:
| defau
Am Mittwoch, den 19.11.2008, 09:05 -0600 schrieb Dirk Eddelbuettel:
> I think we should put either debian or mpi first. How about
>
> mpi-default-{dev,bin}
>
> or even
>
> mpi-debian-default-{dev,bin}
>
> to make it even clearer that it is just 'us' (ie Debian) defining a d
On Thu, Nov 20, 2008 at 11:14 AM, Manuel Prinz <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, den 19.11.2008, 09:05 -0600 schrieb Dirk Eddelbuettel:
>> I think we should put either debian or mpi first. How about
>>
>> mpi-default-{dev,bin}
>>
>> or even
>>
>> mpi-debian-default-{dev,
Hi again, and sorry for causing accidental posts to
[EMAIL PROTECTED] -- I don't know how to do X-Debbugs-CC in
Evolution.
On Thu, 2008-11-20 at 12:35 +0100, Ondrej Certik wrote:
> On Thu, Nov 20, 2008 at 11:14 AM, Manuel Prinz <[EMAIL PROTECTED]> wrote:
> > Am Mittwoch, den 19.11.2008, 09:05 -060
Am Donnerstag, den 20.11.2008, 09:45 -0500 schrieb Adam C Powell IV:
> It uses the PETSc system, which Build-Depends on an arch-dependent MPI
> implementation, then rules uses readlink to determine which one is the
> default alternative, and sets substvars appropriately, whether openmpi,
> lam, or
On Thu, 2008-11-20 at 16:48 +0100, Manuel Prinz wrote:
> Am Donnerstag, den 20.11.2008, 09:45 -0500 schrieb Adam C Powell IV:
> > Feedback anyone?
>
> I was just wondering why you depend on debhelper >= 3, while compat is
> set to 5. Souldn't you depend on >= 5 then?
Not sure. My reasoning was t
On Thu, 2008-11-20 at 09:45 -0500, Adam C Powell IV wrote:
> On Thu, 2008-11-20 at 12:35 +0100, Ondrej Certik wrote:
> > On Thu, Nov 20, 2008 at 11:14 AM, Manuel Prinz
> wrote:
> > > Am Mittwoch, den 19.11.2008, 09:05 -0600 schrieb Dirk
> Eddelbuettel:
> > >> I think we should put either debian or
Now I can put dependencies of the newer release of my packages against
mpi-default-*. Actually, I even would prefer this as a permanent
solution instead of a temporary one. No bothering anymore about openmpi/
lam/mpich or whatsoever.
Gerber
On Fri, 2008-12-26 at 01:01 -0500, Adam C Powell IV wrot
54 matches
Mail list logo
