On Wed, Mar 14, 2012 at 21:34:45 +0100, Julien Cristau wrote:
On Fri, Mar 2, 2012 at 00:35:12 +0100, Julien Cristau wrote:
Reverse-dependencies of lam left in testing:
- apbs; binNMUs scheduled
mips failed, the rest are ok.
Filed a bug for the mips FTBFS (#663894)
Maintainer
On Fri, Mar 2, 2012 at 00:35:12 +0100, Julien Cristau wrote:
Reverse-dependencies of lam left in testing:
- apbs; binNMUs scheduled
mips failed, the rest are ok.
Filed a bug for the mips FTBFS (#663894)
- cctools; fixed in unstable, but FTBFS (#661658)
Still unfixed.
-
On Wed, Feb 29, 2012 at 01:18:06 +0100, Julien Cristau wrote:
The new mpi-defaults was uploaded to sid in December, here's the current
state.
Reverse-dependencies of lam left in testing:
- apbs; binNMUs scheduled
mips failed, the rest are ok.
- cctools; fixed in unstable, but FTBFS
On Wed, Jun 2, 2010 at 19:06:06 +0100, Adam D. Barratt wrote:
Hi,
On Tue, 2010-03-09 at 17:52 +0100, Manuel Prinz wrote:
The current plan is to EOL MPICH and LAM by removing all reverse
dependencies on those packages. One big step in this direction would be
via mpi-defaults. The
Hi,
On Tue, 2010-03-09 at 17:52 +0100, Manuel Prinz wrote:
The current plan is to EOL MPICH and LAM by removing all reverse
dependencies on those packages. One big step in this direction would be
via mpi-defaults. The current version depends on LAM/MPI for arches
where Open MPI is not
On 08/04/10 at 18:22 -0500, Pavan Balaji wrote:
Manuel Prinz wrote:
The problem is that a lot of build systems of MPI-using software want
the headers in $prefix/include and the libs in $prefix/lib, and on can
often only use $prefix to point to the location of MPI-relevant files.
The Debian
Am Donnerstag, den 08.04.2010, 18:22 -0500 schrieb Pavan Balaji:
If we choose to do the first approach, what exactly needs to change in
the mpich2 source? It looks like this is more of a packaging issue for
Debian?
As Lucas already said, we're already happy with what MPICH2 provides.
But
Manuel Prinz wrote:
Am Donnerstag, den 08.04.2010, 18:22 -0500 schrieb Pavan Balaji:
We were having a discussion about a common ABI in the context of MPI-3.
But that working group fizzled out. I'll check on what exactly happened
with it in the next meeting (in May). Even if the MPI standard
Manuel Prinz wrote:
The problem is that a lot of build systems of MPI-using software want
the headers in $prefix/include and the libs in $prefix/lib, and on can
often only use $prefix to point to the location of MPI-relevant files.
The Debian package of MPICH2 uses $prefix/lib and
On 06/04/10 at 21:01 -0500, Pavan Balaji wrote:
Sorry, never mind my previous email.
Lucas Nussbaum wrote:
We would like to switch to using mpich2 on the arches where openmpi is
not supported, but some packages fail to build from source when using
mpich2. It seems that for some of them,
Lucas Nussbaum wrote:
On 06/04/10 at 21:01 -0500, Pavan Balaji wrote:
By default, mpi.h should installed in $prefix/include, which seems
to be what you need (prefix = /usr/lib/mpich2). So, unless you give
an --includedir option to configure, this should work the way you
expect it to. Maybe I'm
Am Mittwoch, den 07.04.2010, 13:12 -0500 schrieb Pavan Balaji:
Ok, this is the part I didn't understand fully. Is MPICH2's build
failing when includedir is specified as a different location? (I just
tried that on my machine and it seems to work correctly for me.) Or did
you mean some other
Am Montag, den 05.04.2010, 17:22 +0200 schrieb Marc 'HE' Brockschmidt:
So, did you spend this time on doing fixes already? :-)
Yes, I indeed did. Not as much as I'd liked too, but nevertheless.
It would be great to see at least a few patches for the breaking
packages before the new defaults
Hi Pavan,
Could you take a look at http://bugs.debian.org/573187 and at the
message below?
We would like to switch to using mpich2 on the arches where openmpi is
not supported, but some packages fail to build from source when using
mpich2. It seems that for some of them, it is caused by build
Hi Lucas,
I'm a little lost trying to find the platform where the build is
failing. Can you point me to the exact output?
Thanks,
-- Pavan
Lucas Nussbaum wrote:
Hi Pavan,
Could you take a look at http://bugs.debian.org/573187 and at the
message below?
We would like to switch to using
Sorry, never mind my previous email.
Lucas Nussbaum wrote:
We would like to switch to using mpich2 on the arches where openmpi is
not supported, but some packages fail to build from source when using
mpich2. It seems that for some of them, it is caused by build systems
expecting to find mpi.h
Manuel Prinz man...@debian.org writes:
Am Dienstag, den 23.03.2010, 19:30 +0100 schrieb Lucas Nussbaum:
Fixing that my providing symlinks might cause subtle failures later,
when the package is actually used and thinks that the libs are in some
place while they aren't.
I do not see why it
Am Samstag, den 20.03.2010, 14:01 +0100 schrieb Marc 'HE' Brockschmidt:
Manuel Prinz man...@debian.org writes:
This would enable to fix these in a timely fashion. I could start
doing that tomorrow night. How does that sound to you?
Sounds good. Sorry for my delayed answer :-/
No problem,
On 23/03/10 at 19:11 +0100, Manuel Prinz wrote:
Am Samstag, den 20.03.2010, 14:01 +0100 schrieb Marc 'HE' Brockschmidt:
Manuel Prinz man...@debian.org writes:
This would enable to fix these in a timely fashion. I could start
doing that tomorrow night. How does that sound to you?
Am Dienstag, den 23.03.2010, 19:30 +0100 schrieb Lucas Nussbaum:
Given the low number of packages that FTBFS with mpich2 as mpi-default,
I would say that this could be fixed in the failing packages' build
system, no?
Sure. It might need some severe patching, though.
Fixing that my providing
Manuel Prinz man...@debian.org writes:
Am Mittwoch, den 17.03.2010, 13:24 +0100 schrieb Lucas Nussbaum:
On 17/03/10 at 09:49 +0100, Marc 'HE' Brockschmidt wrote:
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
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 amd64
Lucas Nussbaum lu...@lucas-nussbaum.net 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
On 17/03/10 at 09:49 +0100, Marc 'HE' Brockschmidt wrote:
Lucas Nussbaum lu...@lucas-nussbaum.net 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
Am Mittwoch, den 17.03.2010, 13:24 +0100 schrieb Lucas Nussbaum:
On 17/03/10 at 09:49 +0100, Marc 'HE' Brockschmidt wrote:
Lucas Nussbaum lu...@lucas-nussbaum.net writes:
So, it looks like it is mostly build system bugs, and it should not be
too hard to fix.
Good to know, thanks for
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Dear release team,
as requested by Marc Brockschmidt in 87ocj81kt4@solon.marcbrockschmidt.de,
I file this bug for the mpi-defaults transition.
As discussed on the Debian Science
26 matches
Mail list logo
