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.
Created attachment 404310 [details] build.log
Please try to rebuild dev-python/sip.
Already done. No luck.
I also have this issue. I also tried to rebuild the pykde4 chain with emerge -e pykde4 with no joy.
Same problem here.
Which version of qt is instaled?
On my system that happens since the qt-4.8.7 upgrade.
Same problem here on ~amd64 and ~x86 machines.
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
(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.
(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.
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);
Created attachment 404634 [details] emerge info x86_64
Created attachment 404636 [details] environment file x86-intel-64
Created attachment 404638 [details] build log x86-intel-64
(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.
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.
(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.
(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?
(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)?
> 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
(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)
<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...
(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.
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.
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.
Please try with sip-4.16.8 + PyQt4-4.11.4
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...
(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!
(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.
Confirm fixed, thx!
Closing then. Stable qt + stable pyqt4 works. Testing qt + testing pyqt4 works. Mixing stable and testing is not supported.