After upgrading Qt 5.3 -> 5.4 alpha, KF5 stuff installed to /usr/lib64/qt5/plugins segfaults, which is solved by rebuilding the affected packages. Not sure if this is some problem with the alpha or KF5.
Other errors too: /usr/lib64/libKF5KDELibs4Support.so.5.2.0: undefined reference to `qMessageFormatString(QtMsgType, QMessageLogContext const&, QString const&)'
I suppose these plugins use the private API of one or more Qt modules, right? There's no API/ABI guarantee on that, source and/or binary incompatibilities can be introduced even between patch releases (e.g. 5.3.1 -> 5.3.2). We can have SLOT="5/${PV}" in every qt5 package if you guys think it can help. But please use subslot operators only in reverse deps that really need it.
Can I have some feedback on comment #2 please?
I haven't personally experienced this yet as I'm still on 5.3.2, I just filed to track some users reports. Regarding the specific error in comment #1, it's known upstream (https://git.reviewboard.kde.org/r/119604/) but I'm not sure what we can do about it. I'm not sure of other uses. Is there an easy way to scan for them? I didn't see any explicit private header includes, even for qMessageFormatString.
(In reply to Michael Palimaka (kensington) from comment #4) > I'm not sure of other uses. Is there an easy way to scan for them? I didn't > see any explicit private header includes, even for qMessageFormatString. I'm not sure. In a qmake-based build system, the project file would have to do e.g. QT += core-private in order to get the include paths (-I) for QtCore private headers, so it should be fairly easy to spot. I don't know if it's 100% accurate though. Dunno about cmake either.
I grepped through my old build logs looking for private include paths without success.
I see. I guess this was a bit of a corner case then, the kde devs ended up using a private API by accident. It's probably not worthwhile to add a subslot to qt5 packages then (not because of this isolated episode at least).
Removing qt from CC... add us again if you need something else.
Problem from comment #2 was solved by patch from link in comment #4 that is applied to versions v5.2.0+ (commit ebb47c58). According to the author, this 'undefined reference' error should be gone. The only problem that left is migration from older Qt version to Qt 5.4.x. The easiest option would be to enforce Qt >=5.4 for KDELibs4Support 5.2 and newer. However Qt 5.4 beta release is planned next week and official release date is unknown.
If just one or a small number of kde packages are affected by this, you can maintain two revisions, one requiring =qt*-5.3*, the other requiring >=qt*-5.4, and unmask the latter when qt 5.4 enters the tree (probably with 5.4.0_rc in November). I don't think 5.3.2 will ever be stabilized anyway.
I'll add the revbumps and pin the deps when 5.4.0 is in the tree (very soon).
Qt 5.4.0 is now in the tree and kdelibs4support & frameworkintegration-5.4.0 are pinned to 5.3.0. frameworks-5.5.0 with >=5.4.0 Qt dep will be in the tree soon.
It turns out that frameworkintegration is still using qpa which can potentially break compat with every release. Not sure how to handle.
As I said in comment #2, we can add a subslot SLOT="5/${PV}" to all qt5 modules. Or we can just ignore the issue and deal with the occasional breakage by telling users to rebuild affected revdeps (which I'm assuming are very few).
qtbase-opensource-src-5.4.0/bin/uic: /usr/lib/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/lib/libQt5Core.so.5) Any one got an answer to this. Using gcc-4.9.2
So, should we add a subslot to qt5?
(In reply to Davide Pesavento from comment #16) > So, should we add a subslot to qt5? I really don't want to if at all possible. Maybe we could wait for the next Qt release to see if there's further breakage.
I would welcome it to have subslots for Qt 5.(In reply to Michael Palimaka (kensington) from comment #17) > (In reply to Davide Pesavento from comment #16) > > So, should we add a subslot to qt5? > > I really don't want to if at all possible. Maybe we could wait for the next > Qt release to see if there's further breakage. +1 for susblots Better to have subslots available and rebuild per package decision like kde-frameworks/frameworkintegration than have broken systems.
I hit this again with 5.5.0 final, but not _rc. What about a subslot of major version instead of PV as a compromise?
I guess you mean ${major}.${minor}? i.e. 5.4, 5.5, ecc... without the third component? I'd be fine with that.
(In reply to Davide Pesavento from comment #20) > I guess you mean ${major}.${minor}? i.e. 5.4, 5.5, ecc... without the third > component? > > I'd be fine with that. Correct.
I added the operator in the overlay in (hopeful) preparation. https://gitweb.gentoo.org/proj/kde.git/commit/?id=239fb3d980bb05abfc0180e11e0b62bd6a1d8cce
Qt 5.6.0 is now in the tree with a subslot, so this should no longer be an issue.
