Subject: Including hdf5.h disables MPI C++ bindings
Package: libhdf5-openmpi-dev
Version: 1.8.9-1~exp3
Severity: normal
As reported in lp:1165504 [1] and discussed in bug 686926 [2],
including "hdf5.h" from the libhdf5-openmpi-dev package
completely disables the MPI C++ bindings. This leads to wei
I suspect, but haven't had time to confirm, that this bug would be fixed by
the proposed patch in 714583.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714583
Essentially BLACS internally needs to convert MPI Communicator handles
between C and Fortran. Many MPI implementations, like OpenMPI,
I've attached a patch which can be applied to the current
blacs-mpi_1.1-31 source.
I have verified this solves the issue I was having (namely processes hanging
when calling pdgemr2d non-collectively).
Thanks,
Brad
blacs-mpi_1.1-31_DUseMpi2.diff
Description: Binary data
Source: blacs-mpi
Version: 1.1-31
Severity: normal
As recommended by the OpenMPI project [1], please build BLACS with the
-DUseMpi2 flag, i.e., by adding `TRANSCOMM = -DUseMpi2` to Bmake.inc.
This allows BLACS to use the MPI2 MPI_Comm_f2c command replacing a
fragile and blocking backup implementat
for test failures on filesystems without
unicode support.
* patches/cpython33_reference_leak.patch:
- Backport upstream patch for a reference leak in Python 3.3.
-- Bradley M. Froehle Tue, 16 Apr 2013 10:26:06
-0700
Since uploading to launchpad I did realize that I forgot to add `rm
> More practically, and more importantly, Octave users who are compiling
> extensions from within Octave are yet another step removed from both the
> compiler and the HDF5 library. They may not even be aware of HDF5 but
> the compilation and linking of their oct-file will be affected.
> Mkoctfile s
Hi Mike:
Sorry that you'll get this twice. The first time around I accidentally
replied only to you. Please read on for responses inline.
On Sun, Mar 31, 2013 at 4:08 PM, Mike Miller wrote:
> CC'ing pkg-octave-devel since this impacts Octave packaging as well.
Thanks.
I've looked into this bug a bit today and I'd suggest that instead the
`mkoctfile-mpi.diff` patch in src:octave (from bug #598227) be modified to
be something more like:
-: ${XTRA_CXXFLAGS=%OCTAVE_CONF_XTRA_CXXFLAGS%}
+: ${XTRA_CXXFLAGS=-I/usr/include/mpi -DOMPI_SKIP_MPICXX=1
-DMPICH_SKIP_MPICXX=1
The fix for this bug provided in 1.8.9-1~exp2 has cause me a good deal of
headache today.
For me, the issue is triggered as some C++ code containing:
#include// sets OMPI_SKIP_MPICXX 1
#include // MPI C++ namespace now is NOT available
Note that even trying to unset OMPI_SKIP_MPICXX before
Package: environment-modules
Version: 3.2.9c-2
Severity: normal
Tags: patch
Bash completion is currently broken:
$ module show
-bash:
directory
file
No
or
such
/usr/share/modules/3.2.9/bin/modulecmd:
Instead of the expected:
$ module show
3.2.9m
Source: cython
Version: 0.17~beta3-1
The current `cython` / `cython3` executable split is a little
uncomfortable, especially since each should be functionally
equivalent. I suggest instead that we name the executables
`cython.py2` and `cython.py3` and use `update-alternatives` to
manage a symlink
The question of how to divide Cython up between different packages is an
interesting one. Fundamentally Cython is both a set of python modules
(Cython, cython, pyximport) and a very simple entrance script (/usr/bin/cython).
In addition, the Debian package adds a man page and some docs.
It's clear
Hi Kouhei & Barry,
I've done a quick preliminary package for tox 1.4. There are a few issues:
* I have no interest or ability to maintain this package in the long term.
* There is no man page for /usr/bin/tox.
You can grab my work with:
dget -x http://highorder.berkeley.edu/~bfroehle/tox/tox_1
Great! I (force) pushed the change to the branches at
https://github.com/bfroehle/debian-mpi4py
I think I'm still against including the python-mpi binaries, but if we
wanted to use that branch we would also need to write up a quick man page.
-Brad
Letting python2 build with the default does regenerate cython bindings
which then do get picked up by the python3 build. Smart :) I've updated
https://github.com/bfroehle/debian-mpi4py
I still think we do not need to include the python-mpi binaries. From the
install.rst file:
Some MPI-1 im
What is the benefit of running the system wide cython? I do see that some
other cython-based packages do choose to run cython (or at least
build-depend on cython). Unfortunately the current lack of a
python3-cython package would prevent us from running cython on the
python3-mpi4py build anyway. :
The buildd status page for mpi4py shows some failed builds (
https://buildd.debian.org/status/package.php?p=mpi4py). While none of
these are new (i.e., they also failed for 1.2.2-3), I think many of these
are caused by a mismatch between the control & rules.
In particular, the package build depen
Source: mpi4py
Severity: wishlist
Dear Maintainer,
I have begun to work on packaging a new upstream version -- mpi4py-1.3.
You can see the progress online at https://github.com/bfroehle/debian-mpi4py
So far it builds correctly, and debdiff on the resulting packages show
only expected changes in
Great! I'll do some testing today but don't expect any issues.
In fact I just recompiled (on Ubuntu 12.04) from the latest in master and
everything
came back binary equivalent (except for changelog.Debian.gz and one instance
of the build date in the docs) to the build I've been using for the past
Unfortunately I don't have a Debian installation handy to test the build there.
The error is quite puzzling, as AFAIK there should already be a dependency
chain:
python3-all-dev -> python3.2-dev -> python3.2 -> python3.2-minimal -> libffi5
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ
For what it's worth it did build successfully in Ubuntu Precise on Launchpad.
https://launchpad.net/~brad-froehle/+archive/3dg/+packages?field.name_filter=mpi4py&field.status_filter=published&field.series_filter=precise
Lastly, I was overly specific in the debian/*.install files. It suffices to
Yes, the lack of an entry for the CDBS -> dh change is a big oversight. That
will certainly need to be remedied.
Attached are the output of debdiff for the resulting deb files for cython and
cython-dbg from 0.15.1-2 (quantal) to 0.15.1-3 (local build on precise). Maybe
you can peek at them quickly
To get the discussion started I've attached two patches which apply to the
current 0.15.1-2 package. Or if it is more convenient you can just grab it
from http://github.com/bfroehle/debian-cython.
The attached patches name the Python 3 packages 'cython3' and 'cython3-dbg'.
In addition, the 'c
Package: cython
Version: 0.15.1-1ubuntu1
Severity: wishlist
Dear Maintainer,
I'm considering working on packaging a Python 3 version of Cython, but before
doing so I think it'd be prudent to discuss the overall framework.
Rationale
=
The 'cython' script provided in the 'cython' package
1. Good catch noticing that we lost mpi.cfg:
This can be fixed by adding to python-mpi4py.install:
```
usr/lib/python2*/*-packages/*/*.cfg
```
An analogous fix is required in python3-mpi4py.install.
See
https://github.com/bfroehle/debian-mpi4py/commit/b6fae77320f2d64ba18d749251d7311d146c3c8d
2
Yes. Alternatively we could (and should) upgrade the package to version 1.3.
See https://github.com/bfroehle/debian-mpi4py/commits/, where I've squashed the
bug fixes in the previous posts.
Thanks!
Aha, good catch. Unfortunately we cannot just add $(PY3VERS) to the list of
versions to test, as Python 3.2 has additional failures in
test_mem.testMemory(1|2).
In this case the tests are incorrect, but they've already been fixed upstream.
(The tests fail when attempting to allocate a 0-byte chun
Wow, of course I really meant
$ readlink /usr/include/python3.2/mpi4py
../../lib/python3.2/dist-packages/mpi4py/include/mpi4py
Clearly I noticed this impacted python3-numpy (=1.6.1-6ubuntu1) as well,
although it has been fixed in unstable. Quick patch (to be amended into the
previous serie
One immediate problem I encountered was a dangling symlink
$ readlink /usr/include/python3.2/numpy
/usr/include/python3.2/numpy ->
../../lib/python3.2/dist-packages/numpy/core/include/numpy
That should be …../python3/.… instead.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.d
F-8)
Shell: /bin/sh linked to /bin/dash
>From ba056d82b4e2d9c359dbbd9893a92929571934bf Mon Sep 17 00:00:00 2001
From: "Bradley M. Froehle"
Date: Mon, 21 May 2012 17:02:32 -0700
Subject: [PATCH 1/2] Build using dh_python2
---
debian/changelog |6 ++
debian/control |6 ++--
Package: llvm-dev
Version: 2.9-7~oneirc1
Severity: normal
llvm-dev provides a symlink::
/usr/lib/libLLVMgold.so -> /usr/lib/llvm-2.9/lib/libLLVMgold.so
However this file name has apparently changed to LLVMgold.so in llvm-2.9 and
later::
$ dpkg -S LLVMgold.so
llvm-dev: /usr/lib/lib
Package: mpi4py
Version: 1.2.2-2
Severity: normal
A symbolic link in /usr/include to the mpi4py header directory
(/usr/share/pyshared/mpi4py/include/mpi4py) should be provided.
For example:
$ echo "usr/share/pyshared/mpi4py/include/mpi4py usr/include/mpi4py" >
debian/python-mpi4py.links
-- Syst
32 matches
Mail list logo
