Bug 415918

Created attachment 124916 [details]
a sample kpy external script to test agains this bug report

This is just a sample file.  Even an empty file should demonstrate the bug

Works fine here. Is your kig compiled with python 3?

Resolved (almost)!

in a Fedora environment in order to make the *internal* python scripting to work with mathematical functions it is required to first define LD_PRELOAD to point to the libpython library.

It turns out that a working (for me at least) definition still requires python2:

   export LD_PRELOAD=/usr/lib64/libpython2.7.so.1.0

however this turns out to be *incompatible* with the present state of pykig.py,
leading to the failing assertion stated in my original bug report.
A workaround is then (at least in a Fedora environment) the followint:

$ export LD_PRELOAD=
$ pykig.py -o sample.kig sample.kpy
$ export LD_PRELOAD=/usr/lib64/libpython2.7.so.1.0
$ kig sample.kig

of course, if the construction in sample.kpy does not require internal python scripting or if the internal python scripting does not make use of mathematical functions, then this would not be required.

(In reply to Antonio Rojas from comment #2)
> Works fine here. Is your kig compiled with python 3?

This is an interesting question: I *thought* my kig was compiled with python3,
What I have now installed is the result with the latest git HEAD in a Fedora 31 updated box.
an 'ldd /usr/bin/kig' does not show any reference to python libraries

(In reply to Maurizio Paolini from comment #4)
> (In reply to Antonio Rojas from comment #2)
> > Works fine here. Is your kig compiled with python 3?
> 
> This is an interesting question: I *thought* my kig was compiled with
> python3,
> What I have now installed is the result with the latest git HEAD in a Fedora
> 31 updated box.
> an 'ldd /usr/bin/kig' does not show any reference to python libraries

You need to look at ldd output for kigpart.so, the kig binary itself doesn't link to python

LD_PRELOADing Python 2 into the current Fedora kig is definitely not supported. If you have to do that, something is very wrong.

(In reply to Kevin Kofler from comment #6)
> LD_PRELOADing Python 2 into the current Fedora kig is definitely not
> supported. If you have to do that, something is very wrong.

Actually at the moment I have kig compiled from latest git sources.  This is
because of the recent struggle for the "assert" problem (https://bugs.kde.org/show_bug.cgi?id=415918).
I will test everything against the latest 'rpm' of kig in a moment.

(In reply to Kevin Kofler from comment #6)
> LD_PRELOADing Python 2 into the current Fedora kig is definitely not
> supported. If you have to do that, something is very wrong.

It is because of #335965, I think.

(In reply to Antonio Rojas from comment #5)
> (In reply to Maurizio Paolini from comment #4)
> > (In reply to Antonio Rojas from comment #2)
> > > Works fine here. Is your kig compiled with python 3?
> > 
> > This is an interesting question: I *thought* my kig was compiled with
> > python3,
> > What I have now installed is the result with the latest git HEAD in a Fedora
> > 31 updated box.
> > an 'ldd /usr/bin/kig' does not show any reference to python libraries
> 
> You need to look at ldd output for kigpart.so, the kig binary itself doesn't
> link to python

ok, I ran " ldd /usr/lib64/qt5/plugins/kigpart.so | grep python" and got

        libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f2d91c44000)
        libboost_python27.so.1.69.0 => /lib64/libboost_python27.so.1.69.0 (0x00007f2d91c00000)

(After a "git pull; make; make install" of the kig project).  I do not know
if this is the result of a messy situation: I actually loss control of the status of the transition to python2.7.

I just tried to recompile from scratch and the output of cmake produces:

[...]
-- Found BoostPython: /usr/lib64/libpython2.7.so;/usr/lib64/libboost_python.so  
[...]

so I guess that there is some reminiscence of python2

I had a symbolic link to /usr/lib64/libpython2* instead of the (presumably correct) version 3.  I guess this is a leftover of my recent bug-chasing effort... so now I recompiled from scratch and it seems that now everything is fine.  I still need the "export LD_PRELOAD=/usr/lib64/libpython3.7m.so.1.0" though, even if I do not use any math function in the python script.

The Fedora package has this patch:
https://src.fedoraproject.org/rpms/kig/blob/master/f/0001-explicitly-use-QLibrary-to-load-libpython-like-pykde.patch
for bug #335965.

Should the Plasma platform plugin call QIconLoader::updateSystemTheme()?

Oops, sorry, I commented into the wrong bug, please disregard that last comment.

(In reply to Kevin Kofler from comment #11)
> The Fedora package has this patch:
> https://src.fedoraproject.org/rpms/kig/blob/master/f/0001-explicitly-use-
> QLibrary-to-load-libpython-like-pykde.patch
> for bug #335965.

Right.  Actually bug #335965 just got into the way and confused me somewhat.
Now everything is fine.
Thank you (David and Kevin) for helping me out and sorry for opening a nonexistent bug!

(In reply to Kevin Kofler from comment #11)
> The Fedora package has this patch:
> https://src.fedoraproject.org/rpms/kig/blob/master/f/0001-explicitly-use-
> QLibrary-to-load-libpython-like-pykde.patch
> for bug #335965.

Update: after cleaning up things properly on my box it turns out that the
"export LD_PRELOAD=..." workaround is no longer necessary, so that the mentioned patch seems no longer required! It seems that this is related to the transition from python2 to python3.