Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 550782 - kde-base/pykde4-4.14.3 fails to build
Summary: kde-base/pykde4-4.14.3 fails to build
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] KDE (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo KDE team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-29 22:45 UTC by Giulio De Pasquale
Modified: 2015-06-17 17:48 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emergeinfo,6.31 KB, text/plain)
2015-05-29 22:45 UTC, Giulio De Pasquale
Details
build.log (8230fae75b3e.txt,27.22 KB, text/plain)
2015-05-29 22:51 UTC, Ben Kohler
Details
emerge info x86_64 (emerge.inf,55 bytes, text/plain)
2015-06-06 03:52 UTC, Geoff Madden
Details
environment file x86-intel-64 (environment-pykde4.tar.bz2,36 bytes, application/x-bzip2)
2015-06-06 04:24 UTC, Geoff Madden
Details
build log x86-intel-64 (build.log,21.96 KB, text/plain)
2015-06-06 04:28 UTC, Geoff Madden
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Giulio De Pasquale 2015-05-29 22:45:06 UTC
Created attachment 404308 [details]
emerge --info

The build log is located here: https://bpaste.net/show/8230fae75b3e

The system is a full ~amd64, no multilib.
Comment 1 Ben Kohler gentoo-dev 2015-05-29 22:51:18 UTC
Created attachment 404310 [details]
build.log
Comment 2 Johannes Huber (RETIRED) gentoo-dev 2015-05-30 11:16:10 UTC
Please try to rebuild dev-python/sip.
Comment 3 Giulio De Pasquale 2015-05-30 11:21:34 UTC
Already done. No luck.
Comment 4 Kenton Groombridge 2015-05-30 11:57:32 UTC
I also have this issue.  I also tried to rebuild the pykde4 chain with emerge -e pykde4 with no joy.
Comment 5 André Terpstra 2015-06-02 18:16:00 UTC
Same problem here.
Comment 6 Michael Palimaka (kensington) gentoo-dev 2015-06-02 18:17:17 UTC
Which version of qt is instaled?
Comment 7 Andreas Sturmlechner gentoo-dev 2015-06-03 07:50:42 UTC
On my system that happens since the qt-4.8.7 upgrade.
Comment 8 email200202 2015-06-03 08:00:42 UTC
Same problem here on ~amd64 and ~x86 machines.
Comment 9 email200202 2015-06-03 08:04:22 UTC
Looking into the build directory, the generated files have 0 size. 

ls -l /var/tmp/portage/kde-base/pykde4-4.14.3/work/pykde4-4.14.3-python3_4/sip/ktexteditor/

-rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart0.cpp 
-rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart1.cpp 
-rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart2.cpp 
-rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart3.cpp 
-rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart4.cpp 
-rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart5.cpp 
-rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart6.cpp 
-rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart7.cpp
Comment 10 André Terpstra 2015-06-04 11:40:05 UTC
(In reply to Michael Palimaka (kensington) from comment #6)
> Which version of qt is instaled?

Both qt4 and qt5; removing qt5 doesn't help. In fact, I stumbled upon this bug when downgrading from KDE 5; right now I am unable to finish installing KDE 4 due to this error so I would appreciate a quick solution.

It is a strange error. I have another system where I kept to KDE 4 and this setup has been present for some time (or so it seems; I haven't investigated it deeply). Downgrading pykde4 or sip doesn't help either.
Comment 11 Michael Palimaka (kensington) gentoo-dev 2015-06-04 11:56:19 UTC
(In reply to Andreas Sturmlechner from comment #7)
> On my system that happens since the qt-4.8.7 upgrade.

Quite possibly related to bug #551000 then.
Comment 12 email200202 2015-06-05 08:19:08 UTC
qt version is 5.4.1.

I tried to install dev-python/qscintilla-python-2.9. It failed with this error:

./sipQsciQsciLexerAVS.cpp: In member function ‘void sipQsciLexerAVS::disconnectNotify(const QMetaMethod&)’:
./sipQsciQsciLexerAVS.cpp:186:42: error: no matching function for call to ‘sipQsciLexerAVS::disconnectNotify(const QMetaMethod&)’
         QsciLexerAVS::disconnectNotify(a0);
                                          ^
./sipQsciQsciLexerAVS.cpp:186:42: note: candidate is:
In file included from /usr/include/qt4/QtCore/qiodevice.h:46:0,
                 from /usr/include/qt4/QtCore/qdatastream.h:46,
                 from /usr/include/qt4/QtCore/qmetatype.h:49,
                 from /usr/include/qt4/QtCore/QMetaType:1,
                 from sipAPIQsci.h:30,
                 from sipQsciQsciLexerAVS.cpp:24:
/usr/include/qt4/QtCore/qobject.h:291:18: note: virtual void QObject::disconnectNotify(const char*)
     virtual void disconnectNotify(const char *signal);
Comment 13 Geoff Madden 2015-06-06 03:52:39 UTC
Created attachment 404634 [details]
emerge info x86_64
Comment 14 Geoff Madden 2015-06-06 04:24:20 UTC
Created attachment 404636 [details]
environment file x86-intel-64
Comment 15 Geoff Madden 2015-06-06 04:28:21 UTC
Created attachment 404638 [details]
build log x86-intel-64
Comment 16 Greg Turner 2015-06-10 03:37:40 UTC
(In reply to email200202 from comment #9)
> Looking into the build directory, the generated files have 0 size. 
> 
> ls -l
> /var/tmp/portage/kde-base/pykde4-4.14.3/work/pykde4-4.14.3-python3_4/sip/
> ktexteditor/
> 
> -rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart0.cpp 
> -rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart1.cpp 
> -rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart2.cpp 
> -rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart3.cpp 
> -rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart4.cpp 
> -rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart5.cpp 
> -rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart6.cpp 
> -rw-r--r-- 1 portage portage     0 Jun  3 14:26 sipktexteditorpart7.cpp

I think this might be explained by the makefile touching these files deliberately en masse ... that is, at a glance, it looks like an expected part of the build process which would have been corrected had sip not failed subsequently in the build.
Comment 17 Greg Turner 2015-06-10 03:41:26 UTC
I'm not sure if the results would be degenerate, or not, but, I notice I'm able to get further and further in the build by issuing "ebuild compile" over and over.

To me it looks like, with MAKEOPTS=-j1, after a couple of hundred re-tries or so, it would probably finish "successfully" although I haven't investigated what sort of binaries, if any, this would generate.
Comment 18 Greg Turner 2015-06-10 03:42:23 UTC
(In reply to Gregory Turner from comment #17)
> I'm not sure if the results would be degenerate, or not, but, I notice I'm
> able to get further and further in the build by issuing "ebuild compile"
> over and over.
> 
> To me it looks like, with MAKEOPTS=-j1, after a couple of hundred re-tries
> or so, it would probably finish "successfully" although I haven't
> investigated what sort of binaries, if any, this would generate.

Perhaps this is just because those zero-byte cpp files are getting created and then compiled into vapor-libs with no actual content.
Comment 19 Ross Hayward 2015-06-11 01:30:43 UTC
(In reply to Michael Palimaka (kensington) from comment #11)
> (In reply to Andreas Sturmlechner from comment #7)
> > On my system that happens since the qt-4.8.7 upgrade.
> 
> Quite possibly related to bug #551000 then.

I finally managed to emerge pykde4, but with some effort. This is not a fix, but might help.

I have 2 systems, both using qt-4.8.7. One system happily emerged pykde4, while the other wouldn't. The difference between the two was that (on the working one) sip always executed with '-t Qt_4_8_6' while on the broken one sip executed with '-t Qt_4_8_7'.  I'm not sure where the Qt_4_8_6 is coming from, but it seems this bug is keeping the thing working.

I managed to get the broken one working by using ebuild to compile, and whenever sip failed, I replaced '-t Qt_4_8_7' with '-t Qt_4_8_6' and executed sip again. After about 4 iterations I was able to merge.

I'm guessing that something in PyQt4 is not quite right?
Comment 20 Davide Pesavento gentoo-dev 2015-06-11 01:50:46 UTC
(In reply to Ross Hayward from comment #19)
> I have 2 systems, both using qt-4.8.7. One system happily emerged pykde4,
> while the other wouldn't. The difference between the two was that (on the
> working one) sip always executed with '-t Qt_4_8_6' while on the broken one
> sip executed with '-t Qt_4_8_7'.  I'm not sure where the Qt_4_8_6 is coming
> from, but it seems this bug is keeping the thing working.

Same version of PyQt4 on both systems?

What's the output of `qmake -query` on the system with '-t Qt_4_8_6' (i.e. where pykde4 works)?
Comment 21 Ross Hayward 2015-06-11 10:30:13 UTC
> Same version of PyQt4 on both systems?
Yes.
[IP-] [  ] dev-python/PyQt4-4.11.3:0

> 
> What's the output of `qmake -query` on the system with '-t Qt_4_8_6' (i.e.
> where pykde4 works)?

$qmake -query
QT_INSTALL_PREFIX:/usr
QT_INSTALL_DATA:/usr/share/qt4
QT_INSTALL_DOCS:/usr/share/doc/qt-4.8.7
QT_INSTALL_HEADERS:/usr/include/qt4
QT_INSTALL_LIBS:/usr/lib64/qt4
QT_INSTALL_BINS:/usr/lib64/qt4/bin
QT_INSTALL_PLUGINS:/usr/lib64/qt4/plugins
QT_INSTALL_IMPORTS:/usr/lib64/qt4/imports
QT_INSTALL_TRANSLATIONS:/usr/share/qt4/translations
QT_INSTALL_CONFIGURATION:/etc/qt4
QT_INSTALL_EXAMPLES:/usr/share/qt4/examples
QT_INSTALL_DEMOS:/usr/share/qt4/demos
QMAKE_MKSPECS:/usr/share/qt4/mkspecs
QMAKE_VERSION:2.01a
QT_VERSION:4.8.7
Comment 22 Ross Hayward 2015-06-11 10:56:47 UTC
(In reply to Ross Hayward from comment #21)

> > 
> > What's the output of `qmake -query` on the system with '-t Qt_4_8_6' (i.e.
> > where pykde4 works)?
> 


Also, after a configure of pykde4 and looking at the environment variables with cmake:

PYQT4_SIP_FLAGS    -t WS_X11 -t Qt_4_8_6
PYQT4_VERSION      040b03
PYQT4_VERSION_STR  4.11.3
PYQT4_VERSION_TAG  Qt_4_8_6
QT_QMAKE_EXECUTABLE  /usr/bin/qmake
...

but, the output during the configure gives:

--Found Qt-Version 4.8.7 (using /usr/bin/qmake)
Comment 23 Greg Turner 2015-06-11 21:11:49 UTC
<NONCONSTRUCTIVE RANT>
Thank god for {c,q}make.  Remember the bad old days of autotools, with all those terrible configuration snippets written in an obscure and ugly, but well-documented and sufficiently powerful macro language?

Back then you had to read all those weird snippets of scripty code to figure out what was going on, but now, we've all been freed of the terrible burden of any such knowledge.

Instead of attempting to understand our problems, we can simply ask Google how to solve them, which very often works.

And, on the rare occasions when Google doesn't know, we can just dink around randomly in fun, exploratory environment of occult causes and effects until some poor soul stumbles upon a way to pile up additional hacks in there to make the problem go away :)

That, or run our build-configuration framework executable under the GNU debugger, slowly teaching ourselves to decipher its infuriatingly low-level code-base until we invariably discover the problem is rooted in some kludge that was jammed in there six months ago, because some obvious feature was not only missing, but an architectural near-impossibility, which perhaps two or three people in the world would have any hope of implementing before they went insane or decided to migrate their build infrastructure to a pile of hand-coded python scripts.
</NONCONSTRUCTIVE RANT>

Sorry, had to take drastic procrastinatory action there, as I almost found myself debugging qmake there for a second...
Comment 24 Ross Hayward 2015-06-12 04:53:23 UTC
(In reply to Gregory Turner from comment #23)
> <NONCONSTRUCTIVE RANT>
> </NONCONSTRUCTIVE RANT>
> 
> Sorry, had to take drastic procrastinatory action there, as I almost found
> myself debugging qmake there for a second...

You took the more sensible approach. I enjoyed your rant too.
Comment 25 André Terpstra 2015-06-12 15:46:38 UTC
In view of the last couple of comments and my desire to complete this emerge: is downgrading qt a workaround? If so, how?

I am not an expert but since the introduction of kde-frameworks I seem to have a mixture of qt4 and qt5.
Comment 26 André Terpstra 2015-06-13 07:15:01 UTC
This adds to my confusion: I just discovered that on an older system which I haven't updated for months, kde-meta-4.14.3 is running but neither sip nor pykde4 are installed. Python versions installed are 2.7 3.3 and 3.4.
Comment 27 Davide Pesavento gentoo-dev 2015-06-14 14:14:22 UTC
Please try with sip-4.16.8 + PyQt4-4.11.4
Comment 28 André Terpstra 2015-06-14 17:29:19 UTC
This seems to solve the problem for me, at last. However I noticed that these updates were not pulled in by the kde-meta merge. I do not understand what is going on...
Comment 29 Greg Turner 2015-06-15 00:55:43 UTC
(In reply to Davide Pesavento from comment #27)
> Please try with sip-4.16.8 + PyQt4-4.11.4

Yeah, W4M.  Hey, that was just the inexplicable miracle I was Googling for, Thank you!
Comment 30 Ross Hayward 2015-06-15 08:35:48 UTC
(In reply to Davide Pesavento from comment #27)
> Please try with sip-4.16.8 + PyQt4-4.11.4

Successfully emerged pykde4 with these upgrades. Thanks Davide et. al.
Comment 31 Andreas Sturmlechner gentoo-dev 2015-06-15 17:12:57 UTC
Confirm fixed, thx!
Comment 32 Davide Pesavento gentoo-dev 2015-06-17 17:48:32 UTC
Closing then.

Stable qt + stable pyqt4 works.
Testing qt + testing pyqt4 works.
Mixing stable and testing is not supported.