Control: reassign -1 src:thunarx-python 0.5.2-2
Control: affects -1 + rabbitvcs-thunar
Control: retitle -1 thunarx-python: fails to discover SONAME of libpython,
tries to load /usr/lib/MULTIARCH/lib.so.1.0
Control: severity -1 grave
On Sun, 20 Apr 2025 at 22:24:22 +0300, Norbert X wrote:
(thunar:4430): thunarx-python-WARNING **: 22:23:20.094: g_module_open libpython
failed: /usr/lib/x86_64-linux-gnu/lib.so.1.0: cannot open shared object file:
No such file or directory
This looks as though the wrong path to a library has been compiled in to
thunarx-python: presumably it was meant to be dlopen'ing libpython3.13.so.1.0
or something more like that.
Looking at buildd logs, I see that thunarx-python's build system failed
to determine the name of libpython, but continued anyway, which suggests
that there is a bug in its error handling and it should be failing to
build from source instead:
checking for headers required to compile python extensions... found
checking for libraries required to embed python... Traceback (most recent call
last):
File "<string>", line 1, in <module>
from distutils.sysconfig import get_python_inc; print(get_python_inc())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ModuleNotFoundError: No module named 'distutils'
basename: missing operand
Try 'basename --help' for more information.
yes
Perhaps adding a Build-Depends on python3-setuptools (which provides
legacy backward compatibility with distutils) would help its build
system to discover the Python library correctly?
(But, anyway, why is it dlopening libpython, and not linked to it with
DT_NEEDED like most embedders of Python are?)
smcv
