On August 8, 2015 10:13:04 AM Piotr Ożarowski wrote:
[Steve M. Robbins, 2015-08-08]
I went looking for the most recent sources and found out that you
can easily get pyvtk via pip.
`sudo pip install ...` is the same as `rm -rf /` to me.
I see.
Please don't suggest it!
In my
On Wed, May 20, 2015 at 06:36:33PM +0200, dktrkr...@debian.org wrote:
Source: pyvtk
Version: 0.4.74-3
I haven't uploaded pyvtk since 2011. So while looking to fix this
bug, I went looking for the most recent sources and found out that you
can easily get pyvtk via pip.
Since I don't use pyvtk
Hello,
The Debian Python Policy documents [1] the rtupdate script for dealing with
default runtime changes. Is this documentation still valid? Will rtupdate be
used when the default runtime changes to python 3 or later?
Thanks,
-Steve
[1]
Hi,
Boost 1.46.1 fails to build with Python 3.2 on linux (Debian). The
build fails with:
error: cannot convert -F?PyObject*? to ?PyUnicodeObject*? for argument ?1? to
?Py_ssize_t PyUnicodeUCS4_AsWideChar(PyUnicodeObject*, wchar_t*, Py_ssize_t)?-A
at this code:
static std::wstring
===
--- debian/control (revision 14598)
+++ debian/control (working copy)
@@ -4,9 +4,10 @@
Priority: optional
Maintainer: Debian Boost Team pkg-boost-de...@lists.alioth.debian.org
Uploaders: Steve M. Robbins s...@debian.org, Domenico Andreoli
ca...@debian.org
-Build-Depends: debhelper (= 7
Hi,
Recently, Mathieu Malaterre wrote to say that having a SOVERSION on a
python module is wrong, with reference to an oblique comment from
Josselin Mouette [1].
Is this true? What is the rationale for not versioning these shared
objects?
Is there any more official document that mandates this?
On Sun, Mar 08, 2009 at 05:27:33AM +0100, Josselin Mouette wrote:
Le samedi 07 mars 2009 ? 22:17 -0600, Steve M. Robbins a ?crit :
OK. I'm certainly in favour of avoiding complexity. However, I
thought I was following the python policy [1] where B.1 says:
This document is incorrect
On Mon, Feb 23, 2009 at 04:16:50PM +0100, Josselin Mouette wrote:
the insighttoolkit rules file contains the following:
PYMODDIR = usr/share/python-support/$(pkg_python)
PYEXTDIR = usr/lib/python-support/$(pkg_python)/$(PYVERS)
...
install/$(pkg_python)::
dh_install -p$(pkg_python)
On Thu, May 01, 2008 at 10:30:32AM -0400, David Abrahams wrote:
on Thu Mar 13 2008, Steve M. Robbins steve-AT-sumost.ca wrote:
Actually, the only thing about Boost that causes grief to packagers is
that the toolset name (e.g. gcc42) is embedded in the library
filename. I just wrote
On Sat, Apr 05, 2008 at 02:23:21AM +0200, Josselin Mouette wrote:
On ven, 2008-04-04 at 19:08 -0500, Steve M. Robbins wrote:
On the other hand, I???m not sure such symbolic links are necessary for
debugging libraries; at least they are not for usual libraries.
The debug library names
For the debian-python readers just joining in: the recent modification
of Boost to support multiple Python runtimes has some unintended
consequences; see bug #473973. Below are some questions for your
consideration.
On Wed, Apr 02, 2008 at 06:11:34PM +0200, Sune Vuorela wrote:
If I ask
On Mon, Mar 24, 2008 at 05:52:47PM +, Dominic Hargreaves wrote:
However, it looks to be like the shlibs file needs updating.
Yes, and thanks for the bug report. Upload is being prepared now.
-Steve
signature.asc
Description: Digital signature
On Fri, Mar 21, 2008 at 03:59:30PM -0400, Aaron M. Ucko wrote:
I do, however, see a couple of concrete issues with your script:
if [ $1 = -d ]; then
debug=-d
shift
fi
Shouldn't you fix that at build time à la $version?
You noticed a complication I was avoiding. There are
Hello,
I wrote about three weeks ago [1] that I'm trying to get Boost's
Python extension helper library building with multiple Python
versions. Several very helpful suggestions were made, for which I am
grateful.
I have been plugging away, very slowly, ever since. I'm hoping to
upload it later
On Wed, Mar 12, 2008 at 09:11:25PM -0400, David Abrahams wrote:
on Sat Feb 23 2008, Steve M. Robbins steve-AT-sumost.ca wrote:
[...]
This produces pairs of library files such as
bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a
bin.v2/.../link-static/python-2.5
On Wed, Feb 27, 2008 at 08:43:43AM -0500, Stefan Seefeld wrote:
(I still don't see the problem: Source packages don't depend on binary
packages, only binary packages do.
Source packages *do*, in fact, depend on binary packages. Each source
package describes exactly the packages required to
On Tue, Feb 26, 2008 at 11:15:24PM -0500, Stefan Seefeld wrote:
Steve M. Robbins wrote:
Hi,
Thanks to Steve, Bernd, and Josselin for ideas.
On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:
Decorate only the shared library names with the python versions
Hi,
I'm part of the Debian Boost packaging team, seeking some guidance on
how to build and install Boost.Python so that it is usable with all
Python versions shipped in Debian. Debian currently ships Python 2.4
and 2.5.
When reading the following, keep in mind that Boost.Python is not a
Python
Howdy,
This sounds like a good initiative. I'd like to add the
python-modules-team as uploader of pyvtk, a package I maintain.
Do I understand correctly that this implies I should put pyvtk into
the alioth subversion repository? If so: sign up user 'smr' for this.
Cheers,
-Steve
--
To
severity 170711 critical
thanks
Hi,
I ran into coredumps when using python-vtk, see bug #170498.
I believe the coredumps are due to python moving from tcl/tk 8.3 to
tcl/tk 8.4. Other python extenion modules are still built with the
older tcl/tk, so you end up with both 8.3 and 8.4 loaded.
I
Howdy,
I've just finished my first attempt at packaging a python module.
This module (people.debian.org/~smr/pyvtk) is purely python.
I followed the python policy outlined in /usr/share/doc/python, and
also looked at a couple of example packages.
One thing I noticed in the packages (that isn't
21 matches
Mail list logo
