Bug 2693

yes, this is a known issue (at least to me).
bug 2030 seems to report the same problem as well and syggest a temporary workaround (which may or may not work, I have not tested it yet).

ruby support is also broken (see bug 266).

perhaps it is time to put this in the list of things to do for R14.1.0 (which is getting longer and longer, since the active developers are few and ofter busy :-( ).
Slavek, what do you think about it?

Created attachment 2696 [details]
python-tqt: add Trinity-specific paths in examples

sip4-tqt as well as python-qt are now installed as modules - to avoid collisions with original sip4 and python-qt. This patch adds these modules into import paths.

Great, I can confirm the patch fixed the issue. Thanks for the quick and prompt fix.

To be honest, the patch looks more like a workaround to me. I find quite strange that each python script needs to detect the location of the modules it wants to use. Within a python script it should be as simple as "import package-I-want-to-use".

Slavek, let's discuss this in more detail over IRC during the weekend.

I have done some work on this and found a different workaround, which does not require any modification to python files.
It is sufficient to add the sip4_tqt and python_tqt location to the PYTHONPATH variable, for example like that:

export PYTHONPATH=/usr/lib/python2.7/dist-packages/sip4_tqt/:/usr/lib/python2.7/dist-packages/python_tqt/:$PYTHONPATH

Then the scripts can be run normally, without any change.

This is still a workaround but much less introsive. Clearly there is a problem with "informing" python where those modules are.

Slavek and I have come up with a better patch ready to be pushed (I think Slavek will push later today).
This only requires minimum changes to the python scripts (from import qt to import python_tqt.qt).

Fixed in commits 0b2f1c47, e790d083 (master) and d6f45445, f303e4dc (r14.0.x).

I discovered a major problem with the new __init__.py in python-tqt: 
building python-trinity ends on Segmentation fault when building 'dbg' 
variant. I tested it, because I had unfinished patch for python-trinity - 
see attachment.

When I give in the comment line: "from python_qt import *", the building 
is without problem. I tried that just a mere "import qt" and building 
ended on segfault. So far I have not found any other way than to give 
import into comment.

Just testing a patch now ;-) Will push soon if ok.

Created attachment 2702 [details]
new module_init file

Slavek,
I did some more work on this problem. Attached is the new module-init file use to generate __init__.py.
Using this file, I can build python_trinity locally using dpkg-buildsource.
But when I try a build using pbuilder in a clean chroot environment, it fails again with segmentation fault.
Now I need to go to sleep. If you have time feel free to continue from where I stop, as usual ;-)

By the way, in the debug section do not include the _d modules, the import fails saying there is no init function declared for those. So don't waste time on that part.

Created attachment 2703 [details]
new module_init file (1)

Based on your edit I made minor tweaking. Because for 'dbg' it is critical to use 'import' I gave conditional just only import. And now it works well! Please test it also on your builder.

Incidentally, I have added to the optional modules also pyqtconfig.

Created attachment 2706 [details]
further version of module-init

Hi Slavek, I tried your patch and everything builds ok.
Nevertheless we are missing out on the "_d" modules.
Attached is a further edit of your patch which includes the debug modules as well. Using this patch also builds ok. What do you think?

(In reply to Michele Calgaro from comment #12)
> Created attachment 2706 [details]
> further version of module-init
> 
> Hi Slavek, I tried your patch and everything builds ok.
> Nevertheless we are missing out on the "_d" modules.
> Attached is a further edit of your patch which includes the debug modules as
> well. Using this patch also builds ok. What do you think?

There are a few comments:

1) In the draft you are adding '_d' only in the first two modules - all others are just duplicated existing. This is just an oversight?

2) It seems impractical to copy the same list twice. Handier would be to add '_d' variants in the loop.

3) There is no added '_d' option for optional modules.

4) When building python-trinity, packages python_tqt_dbg* are not installed ==  modules '_d' are not available.

> 1) In the draft you are adding '_d' only in the first two modules - all others 
> are just duplicated existing. This is just an oversight?
Sorry, definitely an oversight. I prepared that patch during a quick work breaktime and I missed that. Will correct, test again and report back

> 2) It seems impractical to copy the same list twice. Handier would be to add 
> '_d' variants in the loop.
Again, should have been only _d

> 3) There is no added '_d' option for optional modules.
if you include the _d for optional modules, you get an error taht says the init function for those modules does not exist and build would fail

>4) When building python-trinity, packages python_tqt_dbg* are not installed ==  
>modules '_d' are not available.
This reaise the question: do we need to include normal modules AND debug modules?

Let's continue on IRC since we are both there right now ;-)

Created attachment 2709 [details]
new module_init file (2)

Modifications in the sense of the previous comments.

(In reply to Michele Calgaro from comment #14)
> >4) When building python-trinity, packages python_tqt_dbg* are not installed ==  
> >modules '_d' are not available.
> This reaise the question: do we need to include normal modules AND debug
> modules?
> 
> Let's continue on IRC since we are both there right now ;-)

I've done more testing and I have a very simple results:

1) The modules '_d' are as addition to normal modules.

2) However, it is not need to add '_d' modules to the list of modules.

3) When is used python-dbg but the modules '_d' are missing, on import qt* modules always occurs Segmentation fault.

4) For python-trinity is sufficient to add python-tqt-dbg into Build-Depends.

This means that it requires no modifications of the  __inity__.py in python-tqt, that was discussed above. Hooray :)

> 4) For python-trinity is sufficient to add python-tqt-dbg into Build-Depends.
Tested again and all builds ok.

This also explained what I observed in comment 10, where I could build the package locally but not on a clean chroot environment with pbuilder. Locally I had the debug package installed while in pbuilder is was not installed because of teh missing dependency.

I think the bug can be closed again now ;-)

(In reply to Michele Calgaro from comment #18)
> I think the bug can be closed again now ;-)

Yes, the remaining parts of the puzzle has been also pushed to GIT - additional fix for python-tqt, python-trinity, pytdeextensions and tde-guidance.

*** Bug 2030 has been marked as a duplicate of this bug. ***