python3-openvdb: build against the default python3 version

[Mathieu Malaterre]

Hi all,

Could anyone point me at a Debian package (possibly using dh) where
multiple compilation are done (one against python3.7 and one against
python3.8). I'd like to avoid re-inventing the wheel for building a
cmake package (c++) which ships a single python module (so I need to
do one configure+build+install per python version).

Thanks,

On Fri, Mar 27, 2020 at 12:57 PM Emilio Pozuelo Monfort
 wrote:
>
> Control: reopen -1 7.0.0-1
> Control: retitle -1 python3-openvdb: build against the default python3 version
>
> On Mon, 24 Feb 2020 11:10:49 +0100 Mathieu Malaterre  wrote:
> > Control: tags -1 + patch
> > Control: retitle -1 replace python3-all-dev with python3.7-dev
>
> Err, that's not really the solution.
>
> The not ideal solution was to build for the default python version, i.e.
> build-depend on python3-dev and use python3. That would have built against
> python3.7 when that was the default, and against python3.8 now that it has
> changed. And with a binNMU from the release team, you wouldn't have even 
> noticed.
>
> The ideal solution is to build against python3-all-dev and build for *all*
> supported python versions. So that when python3.7 and python3.8 are both
> supported, you build the python extension for both of them.
>
> Cheers,
> Emilio

c++ package with both python2 and python3 binding

[Mathieu Malaterre]

[CC me please]

Could someone please point me to a c++ based package which provides
both a python2 and python3 binding. I'd like to start working toward
#849426 (new upstream is now using cmake as possible build system
instead of the old Makefile based one).

Thanks

Re: Salvaging pylibtiff to Debian Python team or removing it from Debian?

[Mathieu Malaterre]

On Fri, Oct 21, 2016 at 9:36 AM, Andreas Tille  wrote:
[...]
> So if anybody in the Python team would like to take over from here on
> I'd be really happy.  Otherwise I consider either orphaning the package
> or ask ftpmaster for removal.
[...]

Orphan bug report was sent in April 2013:

https://bugs.debian.org/705208

2cts

Can't create directory '/svn/python-modules/db/transactions/32752-1.txn': Permission denied

[Mathieu Malaterre]

[CC me please]

Has anyone seen this lately:

$ svn ci -mprepare package
Sendingdebian/changelog
Sendingdebian/control
Sendingdebian/rules
Sendingdebian/watch
Transmitting file data svn: E13: Commit failed (details follow):
svn: E13: Can't create directory
'/svn/python-modules/db/transactions/32752-1.txn': Permission denied

Who should I get in touch with ?


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ca+7wusyhwnvz7fr_j07pecwzcq0xov8pagsp1wj7ssfwjmv...@mail.gmail.com

Re: Can't create directory '/svn/python-modules/db/transactions/32752-1.txn': Permission denied

[Mathieu Malaterre]

On Thu, May 21, 2015 at 12:08 PM, Ansgar Burchardt ans...@debian.org wrote:
 Hi,

 On 05/21/2015 11:59 AM, Mathieu Malaterre wrote:
 Has anyone seen this lately:

 $ svn ci -mprepare package
 Sendingdebian/changelog
 Sendingdebian/control
 Sendingdebian/rules
 Sendingdebian/watch
 Transmitting file data svn: E13: Commit failed (details follow):
 svn: E13: Can't create directory
 '/svn/python-modules/db/transactions/32752-1.txn': Permission denied

 Who should I get in touch with ?

 The permissions for the directory look correct to me, but malat is not
 a member of the scm_python-modules group, nor of the python-modules
 group on Alioth.

 I assume you need join the Alioth project to get commit permissions.

Thanks Ansgar, that was obvious :(

-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ca+7wuszv0+shj57fetmw+khyqx4dhfspfweh+hbtrpslc+v...@mail.gmail.com

package-installs-python-bytecode

[Mathieu Malaterre]

[Please CC me]

I am reviewing some python packages. On my jessie machine here is what
I am seeing:

$ dget -u 
http://mentors.debian.net/debian/pool/main/p/python-udiskie/python-udiskie_1.1.2-1.dsc
$ cd python-udiskie*
$ dpkg-buildpackage -rfakeroot -us -uc
$ lintian -I ../python-udiskie_1.1.2-1_amd64.changes
E: python-udiskie: package-installs-python-bytecode
usr/lib/python2.7/dist-packages/udiskie/__init__.pyc
E: python-udiskie: package-installs-python-bytecode
usr/lib/python2.7/dist-packages/udiskie/automount.pyc
[...]
$ dpkg -c ../python-udiskie_1.1.2-1_all.deb | grep pyc | wc
 14  841413


from any other jessie machine I've access to this warning is not
present. What do I have on my setup which makes dpkg-buildpackage
generates *.pyc (or not remove them...).

Thanks !


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ca+7wuszczc9oi8nkgwafdn3ytnnhisfqiwontj6qethm8ap...@mail.gmail.com

Cannot find installed package that provides pillow. Using python-pillow as package name.

[Mathieu Malaterre]

[CC me please]

Dear all,

I am starring at #744748. I do not understand how ${python:Depends}
get changed into `python-pillow` for dh_python2. The bug is not really
that annoying except that it prevent a backport of python-openslide
(python 2.x) to wheezy, since python-pillow is only in jessie (I would
need to have `python-imaging` instead).

Comments ?

Thanks.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUsxPH=e7uj6cdcu+dpvru4-n0u_0ywtkntjsaubr4fo...@mail.gmail.com

Re: Cannot find installed package that provides pillow. Using python-pillow as package name.

[Mathieu Malaterre]

On Wed, Jun 11, 2014 at 9:09 AM, Mathieu Malaterre ma...@debian.org wrote:
 [CC me please]

 Dear all,

 I am starring at #744748. I do not understand how ${python:Depends}
 get changed into `python-pillow` for dh_python2. The bug is not really
 that annoying except that it prevent a backport of python-openslide
 (python 2.x) to wheezy, since python-pillow is only in jessie (I would
 need to have `python-imaging` instead).

Sorry for the noise, I needed a grep -i pillow (case sensitive) to
discover where the dep was coming from. I think I know how to fix it,
since jessie also provide a virtual python-imaging package.

thx


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUszOJsGe5cGde9Rbysp=n_k_vv5vc_jish6bh_2y1j7...@mail.gmail.com

Re: Cannot find installed package that provides pillow. Using python-pillow as package name.

[Mathieu Malaterre]

On Wed, Jun 11, 2014 at 9:54 AM, Piotr Ożarowski pi...@debian.org wrote:
 [Mathieu Malaterre, 2014-06-11]
 On Wed, Jun 11, 2014 at 9:09 AM, Mathieu Malaterre ma...@debian.org wrote:
  I am starring at #744748. I do not understand how ${python:Depends}
  get changed into `python-pillow` for dh_python2. The bug is not really
  that annoying except that it prevent a backport of python-openslide
  (python 2.x) to wheezy, since python-pillow is only in jessie (I would
  need to have `python-imaging` instead).

 Sorry for the noise, I needed a grep -i pillow (case sensitive) to
 discover where the dep was coming from. I think I know how to fix it,
 since jessie also provide a virtual python-imaging package.

 python-imaging is a transitional package. If your package works without
 it, please don't change the dependency dh_python2 generates from
 requires.txt file.

 PS please note that you should not use package generated in Jessie on
 Wheezy (different list of supported Python versions) and dh_python2 on
 Wheezy will generate python-imaging dependency

Hum, here is what I have on my side:

$ dpkg -S /usr/bin/dh_python2
diversion by dh-python from: /usr/bin/dh_python2
diversion by dh-python to: /usr/bin/dh_python2.real
dh-python, python: /usr/bin/dh_python2

$ apt-cache policy dh-python
dh-python:
  Installed: 1.20131021-1~bpo70+1
  Candidate: 1.20131021-1~bpo70+1
  Version table:
 1.20140511-1 0
200 http://ftp.fr.debian.org/debian/ testing/main amd64 Packages
100 http://ftp.fr.debian.org/debian/ unstable/main amd64 Packages
 *** 1.20131021-1~bpo70+1 0
600 http://ftp.fr.debian.org/debian/ wheezy-backports/main
amd64 Packages
100 /var/lib/dpkg/status

Which explains why I needed:

http://anonscm.debian.org/viewvc/debian-med/trunk/packages/openslide-python/trunk/debian/pydist-overrides?view=markup

I'll revert my changes, thanks for your help.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ca+7wuswvldmvabeffg4+bsdwxpv2vuhm5rhj448ds2-5nun...@mail.gmail.com

Selecting python-flask vs python3-flask

[Mathieu Malaterre]

[CC me please]

Hi,

  I am trying to work on :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740907

  Basically I have an example package (dh_installexamples) which needs
to depends on python-flask. Depending whether my users installed
python3-openslide or python-openslide, I need to Recommends on
python3-flask or (exclusive) python-flask.

  I have not figure out how to do that. I could not find anything like
this in the doc.

Thanks for help,
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUsyWCYd2qkjy=koSz241PRyrsis2CKQQV-tEv-10=dt...@mail.gmail.com

pybuild: python2,python3 and dh_installexamples

[Mathieu Malaterre]

[CC me please]

Dear all,

  I am trying to build a python3 package from an existing package:
openslide-python.
  After following recommendations from:

https://wiki.debian.org/Python/LibraryStyleGuide

  Here is what I get:

http://packages.debian.org/sid/all/python3-openslide/filelist

clearly it is missing the examples files:

http://packages.debian.org/sid/all/python-openslide/filelist

  The rules file simply reads:

[...]
override_dh_installexamples:
  dh_installexamples -Xjquery.js examples/*
  dh_link usr/share/javascript/jquery/jquery.js
usr/share/doc/python-openslide/examples/deepzoom/static/jquery.js
[...]

  I understand that the dh_link line is incomplete, however I do not
understand why dh_installexamples did not work.


Thanks for comments,

Ref:
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/openslide-python/trunk/debian/rules?view=markup


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wuswpsjlxklutemighsdbhqxoq_vwuyhevk-mwkgikn-...@mail.gmail.com

warning: package python-gdcm: unused substitution variable ${python:Versions}

[Mathieu Malaterre]

[CC me pls]

Hi there,

  I am starring at the following warning:

warning: package python-gdcm: unused substitution variable ${python:Versions}

  My package reads as:


$ cat d/control
Source: gdcm
...
X-Python-Version: 2.7
...
Package: python-gdcm
Section: python
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends},
libgdcm2.2 (= ${binary:Version})
Provides: ${python:Provides}


Should I explicitly uses ${python:Versions} somewhere ? It seems it is
working out of the box nicely:

$ dpkg -I ../python-gdcm_2.2.0-12_amd64.deb
...
 Provides: python2.7-gdcm


Thanks


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusxpahu-xgzomvfjg4jayfspcoxqnu-zyyamhopqa-y...@mail.gmail.com

W: dh_python2:427: public extension linked with libpython2.7: libvtkgdcmPython.so

[Mathieu Malaterre]

[CC me please]

Hi there,

  I am looking for more information about [1] and [2]. Here is my
current issue. GDCM ships a python module which in turn links to a
shared libs. It looks like this:

$ readelf -d /usr/lib/pyshared/python2.7/libvtkgdcmPython.so

Dynamic section at offset 0x1de0 contains 26 entries:
  TagType Name/Value
 0x0001 (NEEDED) Shared library:
[libvtkgdcmPythonD.so.2.2]
 0x0001 (NEEDED) Shared library: [libpython2.7.so.1.0]
 0x0001 (NEEDED) Shared library: [libstdc++.so.6]
 0x0001 (NEEDED) Shared library: [libc.so.6]

As one can see above, there is no *explicit* linking to
libpythonX.Y.so as per python module policy in debian. However it
turns nasty when one look at libvtkgdcmPythonD.so.2.2:

$ readelf -d /usr/lib/libvtkgdcmPythonD.so.2.2

Dynamic section at offset 0x37d38 contains 34 entries:
  TagType Name/Value
 0x0001 (NEEDED) Shared library: [libvtkgdcm.so.2.2]
 0x0001 (NEEDED) Shared library: [libpython2.7.so.1.0]
 0x0001 (NEEDED) Shared library:
[libvtkCommonPythonD.so.5.8]
 0x0001 (NEEDED) Shared library:
[libvtkIOPythonD.so.5.8]
 0x0001 (NEEDED) Shared library:
[libvtkImagingPythonD.so.5.8]
 0x0001 (NEEDED) Shared library:
[libvtkFilteringPythonD.so.5.8]
 0x0001 (NEEDED) Shared library:
[libvtkPythonCore.so.5.8]
 0x0001 (NEEDED) Shared library: [libvtkCommon.so.5.8]
 0x0001 (NEEDED) Shared library: [libstdc++.so.6]
 0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
 0x0001 (NEEDED) Shared library: [libc.so.6]
 0x000e (SONAME) Library soname:
[libvtkgdcmPythonD.so.2.2]


dh_python2 is obviously looking into transitive linking and reports
that libvtkgdcmPython.so actually links to libpython2.7.so.1.0 which
is a illegal as per policy.

Reading the policy this is not clear how bad this linking is. What are
the possible issues in doing so ? Please note that, I cannot simply
remove the linking to libpython2.7.so.1.0, since
libvtkgdcmPythonD.so.2.2  is a shared lib and thus required full
resolution of all symbols including those:

$ nm -D /usr/lib/libvtkgdcmPythonD.so.2.2
 U PyFloat_FromDouble
 U PyInt_FromLong
 U PyLong_FromLongLong
 U PyLong_FromUnsignedLong
 U PyString_FromString
 U Py_FatalError
 U Py_InitModule4_64
 U _Py_NoneStruct

does anyone in which case this could be causing some troubles ?
multi-arch python install ? multi-python installation ?...

thanks much for inputs !

[1] 
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html
[2] http://bugs.debian.org/592414


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsxRnok5JQpHHbS=pkwu5yepbjskb0807hdzbdu0ze1...@mail.gmail.com

Re: W: dh_python2:427: public extension linked with libpython2.7: libvtkgdcmPython.so

[Mathieu Malaterre]

On Tue, May 8, 2012 at 9:28 AM, Mathieu Malaterre ma...@debian.org wrote:
...
 $ readelf -d /usr/lib/pyshared/python2.7/libvtkgdcmPython.so

 Dynamic section at offset 0x1de0 contains 26 entries:
  Tag        Type                         Name/Value
  0x0001 (NEEDED)             Shared library:
 [libvtkgdcmPythonD.so.2.2]
  0x0001 (NEEDED)             Shared library: [libpython2.7.so.1.0]

I actually did not realize cmake would put on the link line any
dependant shared libs. Therefore the module *itself* ended up being
link explicitely to the libpython2.7.so...

I fixed this with the proper cmake incantation.

Sorry for the noise,


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsxLDJj5=-kpuom1benzrcjib6n3a2dhs6ofvczp_wf...@mail.gmail.com

Re: warning: symbol PyLong_FromUnsignedLong...

[Mathieu Malaterre]

On Thu, Apr 12, 2012 at 7:42 PM, Jakub Wilk jw...@debian.org wrote:
 * Mathieu Malaterre ma...@debian.org, 2012-04-12, 12:32:

 Since every single python module suffer from this, I thought there would
 be something very simple.

 No, most of Python extension modules don't suffer from it.


 I am not pointing finger at anyone, but this issue is present in other
 package.

 $ find /usr/lib/pyshared/python2.6/ -name \*.so -exec readelf -d {} \;
 | grep SONAME | wc
    73     365    5333

 After all this is a great that it was added to PTS :)


 The latest lintian4python (0+20120412) will emit a pedantic tag for such
 packages.

Cool !

 BTW, does anybody know how to stop libtool from adding SONAME? I would
 expect that -module -avoid-version does that, but it's not the case.

Same question for cmake [1]. I am tempted to simply fill a bug against
cmake/debian package. CMake supports the notion of module, but still
add the -Wl,-soname switch to those.

 Or, alternatively: is there a way to remove SONAME from an existing library?

I have been searching for such tool also. I found chrpath which use
the low level read_elf() API to manipulate .so, but I could not find
anything else.

-M
[1] http://www.cmake.org/pipermail/cmake/2012-April/049874.html


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusy5dsvwsp0cnabbjpuedq7a13ks8gi-rf3q_0e-ybk...@mail.gmail.com

Re: warning: symbol PyLong_FromUnsignedLong...

[Mathieu Malaterre]

Paul,

On Wed, Apr 11, 2012 at 11:52 PM, Paul Wise p...@debian.org wrote:
 On Wed, Apr 11, 2012 at 11:43 PM, Mathieu Malaterre wrote:

  I am trying to remove the remaining warnings from the gdcm/python
 package. They can be seen here:

 That is pretty normal for plugins on Linux; the symbols are provided
 by the program that loads the plugins and the plugins do not reference
 where they get those symbols from.

I am trying to remove the annoying 'todo' section of the gdcm package page:

http://packages.qa.debian.org/g/gdcm.html

If this was a lintian false positive, one would use
*.lintian-overrides file. However in this case I did not know what I
need to do. Since every single python module suffer from this, I
thought there would be something very simple.

Regards,
-M


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusxfy3kmf2igtzxas+8gpb+v512pi3n0xsay3ryomn0...@mail.gmail.com

Re: warning: symbol PyLong_FromUnsignedLong...

[Mathieu Malaterre]

Jakub,

On Thu, Apr 12, 2012 at 12:20 PM, Jakub Wilk jw...@debian.org wrote:
 * Mathieu Malaterre ma...@debian.org, 2012-04-11, 17:43:
 dpkg-shlibdeps: warning:
 debian/python-gdcm/usr/lib/python2.7/dist-packages/_gdcmswig.so
 contains an unresolvable reference to symbol PyObject_IsTrue: it's
 probably a plugin.
 dpkg-shlibdeps: warning: 86 other similar warnings have been skipped
 (use -v to see them all).


 This one is easy. _gdcmswig.so has a SONAME. This is unusual (and almost
 always unnecessary) for Python extension modules and confuses
 dpkg-shlibdeps. Quoting the manual page: “The indicated symbol has not been
 found in the libraries linked with the binary. The binary is most likely a
 plugin and the symbol is probably provided by the program that loads this
 plugin. In theory a plugin doesn't have any SONAME but this binary does have
 one and as such it could not be clearly identified as such. However the fact
 that the binary is stored in a non-public directory is a strong indication
 that's it's not a normal shared library.”

 Get rid of the SONAME and they'll go away.

D'oh ! I was not looking at the right error message. Thanks for spotting this !

 dpkg-shlibdeps: warning: Can't extract name and version from library
 name `libKitware.mummy.Runtime.Unmanaged.so'
 dpkg-shlibdeps: warning: Can't extract name and version from library
 name `libKitware.mummy.Runtime.Unmanaged.so'


 I suppose these are about CLI stuff, not about Python stuff.

This is a different issue (or maybe exactly the same). Anyway I'll
deal with it ASAP.

 dpkg-shlibdeps: warning: symbol PyLong_FromUnsignedLong used by
 debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of
 the libraries.
 dpkg-shlibdeps: warning: symbol Py_InitModule4 used by
 debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of
 the libraries.


 What is the purpose of this library? I see that
 package-name-doesnt-match-sonames and shlib-without-versioned-soname were
 overridden without a comment.

 It doesn't directly address your problem, but:
 - If it's a general-purposed library that is supposed to be used by other
 packages, then it should be versioned, put into a package with versioned
 name, and linked to all the libraries it uses symbols from.
 - Otherwise, it should be moved to a private directory.

The real issue is about SONAME -hopefully- I can then cleanup this file.

thanks much !


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUswfW=hkgj12t59hrt6jr_f1lln8vnypogcmr8mvh...@mail.gmail.com

Re: warning: symbol PyLong_FromUnsignedLong...

[Mathieu Malaterre]

On Thu, Apr 12, 2012 at 12:23 PM, Jakub Wilk jw...@debian.org wrote:
 * Mathieu Malaterre ma...@debian.org, 2012-04-12, 09:04:

 I am trying to remove the annoying 'todo' section of the gdcm package
 page:

 http://packages.qa.debian.org/g/gdcm.html

 If this was a lintian false positive, one would use *.lintian-overrides
 file. However in this case I did not know what I need to do.


 Build log checks is a tool with great potential, but IMO adding it to PTS
 was premature.


 Since every single python module suffer from this, I thought there would
 be something very simple.


 No, most of Python extension modules don't suffer from it.

I am not pointing finger at anyone, but this issue is present in other package.

$ find /usr/lib/pyshared/python2.6/ -name \*.so -exec readelf -d {} \;
| grep SONAME | wc
 73 3655333

After all this is a great that it was added to PTS :)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUswE1CNsV2ugASVOLN_PF=_u915S_Q=_kcyct3l2k1e...@mail.gmail.com

warning: symbol PyLong_FromUnsignedLong...

[Mathieu Malaterre]

[CC me please]

Hi there,

  I am trying to remove the remaining warnings from the gdcm/python
package. They can be seen here:

https://buildd.debian.org/status/fetch.php?pkg=gdcmarch=powerpcver=2.2.0-10stamp=1334158394

copied here for convenience:

...
dpkg-shlibdeps: warning:
debian/python-gdcm/usr/lib/python2.7/dist-packages/_gdcmswig.so
contains an unresolvable reference to symbol PyObject_IsTrue: it's
probably a plugin.
dpkg-shlibdeps: warning: 86 other similar warnings have been skipped
(use -v to see them all).
dpkg-shlibdeps: warning: Can't extract name and version from library
name `libKitware.mummy.Runtime.Unmanaged.so'
dpkg-shlibdeps: warning: Can't extract name and version from library
name `libKitware.mummy.Runtime.Unmanaged.so'
dpkg-shlibdeps: warning: symbol PyLong_FromUnsignedLong used by
debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of
the libraries.
dpkg-shlibdeps: warning: symbol Py_InitModule4 used by
debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of
the libraries.
dpkg-shlibdeps: warning: symbol PyInt_FromLong used by
debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of
the libraries.
dpkg-shlibdeps: warning: symbol _Py_NoneStruct used by
debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of
the libraries.
dpkg-shlibdeps: warning: symbol PyErr_Occurred used by
debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of
the libraries.
dpkg-shlibdeps: warning: symbol PyString_FromString used by
debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of
the libraries.
dpkg-shlibdeps: warning: symbol PyFloat_FromDouble used by
debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of
the libraries.
dpkg-shlibdeps: warning: symbol PyModule_GetDict used by
debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of
the libraries.
dpkg-shlibdeps: warning: symbol PyDict_SetItemString used by
debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of
the libraries.
dpkg-shlibdeps: warning: symbol Py_FatalError used by
debian/python-vtkgdcm/usr/lib/libvtkgdcmPythonD.so found in none of
the libraries.
...

  I could not figure out what I was missing in my package for remove
those false positive.

Thanks much,


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusypvjcxmn7x5btjhchhmm3gsqa7z7dwes-ec9tjr6b...@mail.gmail.com

Re: Bug #649904: running install_data

[Mathieu Malaterre]

On Tue, Nov 29, 2011 at 10:44 AM, Piotr Ożarowski pi...@debian.org wrote:
 [Mathieu Malaterre, 2011-11-29]
   I am trying to fix bug #649904. I have been talking with upstream,
 and apparently the install process on debian is doing something weird
 after the line running install_data, see for instance :

 https://buildd.debian.org/status/fetch.php?pkg=pylibtiffarch=i386ver=0.3.0~svn78-1stamp=1321830785

 the weird part is that it installs directly into dist-packages and
 not to dist-packages/libtiff/, right?

 if that's the case, then removeextralicense.patch is why (you're missing
 a comma after 'libtiff')

Thanks so much ! That was it !

-- 
Mathieu


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusygh5ymwtnckmjp1ntqvaocnx5qgnbu+zddrkzykbu...@mail.gmail.com

Re: ImportError: No module named multiarray (is back)

[Mathieu Malaterre]

[CC me please]

hi all,

2011/11/22 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl:
[...]
 Hi Mathieu,

 I don't think that your problem can be solved in any simple way, apart from
 physically moving the script or providing a second helper script.

 This is a very unfortunate interaction between Python semantics (prepend
 realpath of script to sys.path) and the Debian way of installing modules
 (symlink farm between Python versions). Nevertheless, I think that Python is
 wrong, and Debian is right. What Python does means that it is not possible
 to run a Python script from /tmp or any other directory writeable by other
 users securely. Even if this is by design, it is not advertised well (or
 maybe even at all?) and is thus a big security hole.

Just like everything in computer, just add another extra layer of
indirection. However this is exaclty that layer of indirection that I
need help to get working.

[Copy pasted from http://lists.debian.org/debian-python/2011/11/msg00059.html]
Jakub Wilk jw...@debian.org:
 It'd tad easier for us to help you if you explained what you were trying to 
 do.

Short answer: trying to package the cellprofiler application. That is all.

I can get the application working from my $HOME or /tmp no problem.
However as soon as I move the CellProfiler.py within some know python
location things behave differently.

Package is at:
http://mentors.debian.net/package/cellprofiler

However it wont be very usefull as it wont work from the installed path.

Thanks
-- 
Mathieu


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsz5ioRp153BJv5DGKz_o=fPxXH+QV=zg9mvsgjecjy...@mail.gmail.com

ImportError: No module named multiarray (is back)

[Mathieu Malaterre]

[CC me please]

Hi all,

  The issue with multiarray came back. I manage to get things working
for the tifffile package installing the tifffile.py into
/usr/bin/tiffile (removing the py extension). However another package
is now failing: CellProfiler. Symptoms are:


$ python /usr/lib/python2.7/dist-packages/CellProfiler.py
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/CellProfiler.py, line 17, in module
import numpy as np
  File /usr/share/pyshared/numpy/__init__.py, line 136, in module
import add_newdocs
  File /usr/share/pyshared/numpy/add_newdocs.py, line 9, in module
from numpy.lib import add_newdoc
  File /usr/share/pyshared/numpy/lib/__init__.py, line 4, in module
from type_check import *
  File /usr/share/pyshared/numpy/lib/type_check.py, line 8, in module
import numpy.core.numeric as _nx
  File /usr/share/pyshared/numpy/core/__init__.py, line 5, in module
import multiarray
ImportError: No module named multiarray


Now if I do:

$ cp /usr/lib/python2.7/dist-packages/CellProfiler.py /tmp
$ python /tmp/CellProfiler.py
Traceback (most recent call last):
  File /tmp/CellProfiler.py, line 193, in module
os.chdir(os.path.join(root, script_path))
OSError: [Errno 2] No such file or directory: '/tmp/cellprofiler/cpmath'

Could someone please point me to some documentation get rid definitely
of this kind of issues. I'd like to keep as much as the original
package as possible, therefore I would like to keep the
/usr/lib/python2.7/dist-packages/CellProfiler.py (or pyshared
equivalent). But how do I load this file ?

Thanks very much.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUswQVDddJJiXaJFk8gNmYMW9L4W_3GtSWKDV9LAL=sa...@mail.gmail.com

ImportError: No module named multiarray

[Mathieu Malaterre]

[CC me please]

Hi all,

  I am trying to package a tiny python module:

http://mentors.debian.net/debian/pool/main/t/tifffile/tifffile_2012-1.dsc

  I thought I did it right, but I cannot load the python module
properly when installed, it fails with:

$ python /usr/share/pyshared/tifffile.py
Traceback (most recent call last):
  File /usr/share/pyshared/tifffile.py, line 117, in module
import numpy
  File /usr/share/pyshared/numpy/__init__.py, line 132, in module
import add_newdocs
  File /usr/share/pyshared/numpy/add_newdocs.py, line 9, in module
from lib import add_newdoc
  File /usr/share/pyshared/numpy/lib/__init__.py, line 4, in module
from type_check import *
  File /usr/share/pyshared/numpy/lib/type_check.py, line 8, in module
import numpy.core.numeric as _nx
  File /usr/share/pyshared/numpy/core/__init__.py, line 5, in module
import multiarray
ImportError: No module named multiarray


  However doing the following works nicely:

$ cd /tmp
$ cp /usr/share/pyshared/tifffile.py .
$ python tifffile.py --version
tifffile.py 2011.11.12

Thanks for suggestion,
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusy4azc5lsgqpbcypr7sb3w8nur8tep4m+1nwvdrs36...@mail.gmail.com

Dependencies with cType

[Mathieu Malaterre]

Dear all,

  [Please CC me as I am not subscribed]

  I am trying to package a python module which load the real C library
using cType. I am using dh_python2 but I seem to be missing something
as the dependencies is still not quite right.

$ apt-cache show python-openslide
...
Depends: python2.6 | python2.7, python (= 2.6.6-7~), python ( 2.8)

While looking at the source:

$ cat lowlevel.py
from ctypes import *
[...]
_lib = cdll.LoadLibrary('libopenslide.so.0')


The full debian/* package can be found at:

http://anonscm.debian.org/viewvc/debian-med/trunk/packages/python-openslide/trunk/

Does anyone knows what I am missing ?

Thanks
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsz=7da+-btsqcs6byowpra7ammgakde+iyuhocaksj...@mail.gmail.com

Re: Dependencies with cType

[Mathieu Malaterre]

On Mon, Oct 3, 2011 at 9:11 PM, Mathieu Malaterre
mathieu.malate...@gmail.com wrote:
 The full debian/* package can be found at:

 http://anonscm.debian.org/viewvc/debian-med/trunk/packages/python-openslide/trunk/

Sorry I meant:

http://anonscm.debian.org/viewvc/debian-med/trunk/packages/openslide-python/trunk/

Thanks,
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsxp9kMsmrw9oMSxyGH43OKNpPBXwxkpAx+Jc=bit0h...@mail.gmail.com

Re: Dependencies with cType

[Mathieu Malaterre]

On Mon, Oct 3, 2011 at 9:56 PM, Jakub Wilk jw...@debian.org wrote:
 I am trying to package a python module which load the real C library using
 cType. I am using dh_python2 but I seem to be missing something as the
 dependencies is still not quite right.

 $ apt-cache show python-openslide
 ...
 Depends: python2.6 | python2.7, python (= 2.6.6-7~), python ( 2.8)

 While looking at the source:

 $ cat lowlevel.py
 from ctypes import *
 [...]
 _lib = cdll.LoadLibrary('libopenslide.so.0')

 dh_python2 doesn't read your source code, except maybe for the first line
 (looking for shebang). You need to add dependency on libopenslide0 manually.

ok

 BTW, I'm slightly disturbed by the fact, that so many people believe that a
 Python helper does code inspection (or maybe use some magical means...) to
 generate python:Depends. It seems to be a new phenomenon, I don't recall any
 questions like that a year ago or so.

Sorry if this sound naive. there has been quite some change in the
java world (it was capable of doing all dependencies for me), so I
thought I was doing something wrong.

So how do people track dependencies needed for python packages ? There
is no test shipped with my current package, so all I can do is `grep
-r import` at the moment.

Thanks again,
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUswG4mDkspTh3Ct0+E1z3qq=byWbNYymOdqRkGON=ri...@mail.gmail.com

Re: SONAME for python modules is bad?

[Mathieu Malaterre]

On Wed, Jul 22, 2009 at 8:47 AM, Steve M. Robbinsst...@sumost.ca wrote:
 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?  For
 example, the python policy?

This issue was raised by Denis Barbier. This makes particular sense
for the C#/Java target language since one setup a proper
LD_LIBRARY_PATH and then an internal mechanism load the internal glue
lib. The version of the glue lib is not very important in this case
and furhtermore cannot even be expressed AFAIK. For instance, in Java:

 static {
   try {
   System.loadLibrary(gdcmjni);
   } catch (UnsatisfiedLinkError e) {
 System.err.println(Native code library failed to load. \n + e);
 System.exit(1);
   }
 }


In C#:

[DllImport(gdcmsharpglue, EntryPoint=CSharp_ImageWriterUpcast)]


It would be extremely nice too if all wrap language would adopt the
same convention. So that toolkit such as VTK/ITK/GDCM wrapping their
interface into multiple languages (namely: Tcl, Python, Java, C#)
could simply decide:
(1) Allow SONAME
(2) Use a directory convention libfoo-$SOVERSION/$NAME.so

for packaging mutiple modules.

I know that Python had some other convention such as preprending
underscore, but I have never seen any need for SONAME on modules.

2cts,
-- 
Mathieu
http://mathieumalaterre.com


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org