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
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
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
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
ba056d82b4e2d9c359dbbd9893a92929571934bf Mon Sep 17 00:00:00 2001
From: Bradley M. Froehle brad.froe...@gmail.com
Date: Mon, 21 May 2012 17:02:32 -0700
Subject: [PATCH 1/2] Build using dh_python2
---
debian/changelog |6 ++
debian/control |6 ++
debian/python-mpi4py.install |4
debian
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
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
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
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!
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
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
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
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
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=mpi4pyfield.status_filter=publishedfield.series_filter=precise
Lastly, I was overly specific in the debian/*.install files. It suffices to
Package: environment-modules
Version: 3.2.9c-2
Severity: normal
Tags: patch
Bash completion is currently broken:
$ module show tabtab
-bash:
directory
file
No
or
such
/usr/share/modules/3.2.9/bin/modulecmd:
Instead of the expected:
$ module show tabtab
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
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
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
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.
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
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
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:
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
-- System
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,
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
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
.
Bradley M. Froehle wrote:
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 hdf5.h // sets OMPI_SKIP_MPICXX 1
#include mpi.h // MPI C++ namespace now is NOT available
Note
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
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 brad.froe...@gmail.com Tue, 16 Apr 2013 10:26:06
-0700
Since uploading to launchpad I did realize
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 hdf5.h // sets OMPI_SKIP_MPICXX 1
#include mpi.h // MPI C++ namespace now is NOT available
Note that even trying to unset
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
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
32 matches
Mail list logo
