[Users] Schedule for Ubuntu PPA Update

[Holger Berndt]

Hello Barry,

On Di, 14.05.2013 17:15, Barry Warsaw wrote:

>>Building succeeds apart on 13.04 Raring, an issue that I'll have to
>>deal with later. i386 builders are done, x86-64 not yet.
>
>Did you have any problems with the Python plugin?

yes, there are problems with the Python plugin during the search for
libpython.so.

>The reason for this is that CM's configure.ac doesn't look for libpython.so in
>a multiarch location.

Indeed, it just looks in hardcoded lib and lib64 directories.

I was hoping to be able to fix the issue by asking Python itself where
that library is installed, by using something along the lines of

python -c 'import sysconfig, os.path; print os.path.join(sysconfig.get_config_var("LIBDIR"),sysconfig.get_config_var("LDLIBRARY"))'

However, this has two problems: The sysconfig module is only availble
from Python 2.7 onwards, so it would raise the dependency to that version.
Second, Colin reported that this doesn't work on new Ubuntu anyways (it returns
/usr/lib/ which seems wrong to me). If you have experience in Python and Ubuntu
packaging, maybe you can shed some light on this.

>In any case, see below for the patch.  Maybe upstream CM can incorporate this
>for a 3.9.2 release?

Thanks, but that's Debian/Ubuntu specific, so the patch can't be applied
as is upstream.

In fact, I'm still trying to find out whether the locating of libpython.so
is necessary at all in the first place. I'll take the opportunity to talk
to a Python overloard and elaborate a bit - maybe you have a hint on that,
too.

The Python plugin incorporates an interactive Python console in a gtk
window, accessible via "Tools -> Show Python console". The code for
this console is stolen from gtkparasite [1].

This stolen code does a dlopen() on libpython.so at runtime. I understood
this is (was?) necessary to prevent symbol resolution errors such as
  "undefined symbol: PyExc_ImportError"
when trying to load Python extension modules written in C.

Python issue http://bugs.python.org/issue4434 seemed related. I can 
reproduce the test case attached to that report with Python 2.7.3 -
the original reporter in that bug claimed it's been fixed in the
meantime though.

However, I am not able to reproduce the problem in the Python plugin
for Claws Mail, so I wonder if that dlopen() call is necessary at all.
Being able to get rid of that search for libpython.so would be the
best solution.

Holger

[1] http://chipx86.github.com/gtkparasite
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.claws-mail.org/pipermail/users/attachments/20130515/7bf172bc/attachment.sig>