Created attachment 541192 [details]
TestFromQPixmap.test_sanity_1 ... Cannot mix incompatible Qt library (version 0x50904) with this library (version 0x50906)
I'm in middle of world upgrade, and only some qt libraries upgraded so far.
$ equery l 'dev-qt/*'
* Searching for * in dev-qt ...
[IP-] [ ] dev-qt/designer-5.9.4:5/5.9
[IP-] [ ] dev-qt/linguist-tools-5.9.4:5/5.9
[IP-] [ ] dev-qt/qdbus-5.9.4:5/5.9
[IP-] [M ] dev-qt/qt3support-4.8.7:4
[IP-] [ ] dev-qt/qtbluetooth-5.9.4:5/5.9
[IP-] [ ] dev-qt/qtchooser-0_p20170803:0
[IP-] [ ] dev-qt/qtconcurrent-5.9.6:5/5.9
[IP-] [M ] dev-qt/qtcore-4.8.7-r4:4
[IP-] [ ] dev-qt/qtcore-5.9.6:5/5.9
[IP-] [ ] dev-qt/qtdbus-5.9.4:5/5.9
[IP-] [ ] dev-qt/qtdeclarative-5.9.4:5/5.9
[IP-] [ ] dev-qt/qtgraphicaleffects-5.9.4:5/5.9
[IP-] [M ] dev-qt/qtgui-4.8.7:4
[IP-] [ ] dev-qt/qtgui-5.9.4-r3:5/5.9
[IP-] [ ] dev-qt/qtimageformats-5.9.4:5/5.9
[IP-] [ ] dev-qt/qtmultimedia-5.9.4-r1:5/5.9
[IP-] [ ] dev-qt/qtnetwork-5.9.6:5/5.9
[IP-] [ ] dev-qt/qtopengl-5.9.4:5/5.9
[IP-] [ ] dev-qt/qtpaths-5.9.6:5/5.9
[IP-] [ ] dev-qt/qtprintsupport-5.9.4:5/5.9
[IP-] [ ] dev-qt/qtquickcontrols-5.9.4:5/5.9
[IP-] [ ] dev-qt/qtquickcontrols2-5.9.4:5/5.9
[IP-] [M ] dev-qt/qtscript-4.8.7:4
[IP-] [ ] dev-qt/qtscript-5.9.4:5/5.9
[IP-] [ ] dev-qt/qtsensors-5.9.4:5/5.9
[IP-] [M ] dev-qt/qtsql-4.8.7-r1:4
[IP-] [ ] dev-qt/qtsql-5.9.6-r1:5/5.9.6
[IP-] [ ] dev-qt/qtsvg-5.9.4-r2:5/5.9
[IP-] [ ] dev-qt/qttest-5.9.6:5/5.9
[IP-] [M ] dev-qt/qttranslations-4.8.7:4
[IP-] [ ] dev-qt/qtvirtualkeyboard-5.9.4:5/5.9
[IP-] [ ] dev-qt/qtwayland-5.9.4-r1:5/5.9
[IP-] [ ] dev-qt/qtwebchannel-5.9.4:5/5.9
[IP-] [ ] dev-qt/qtwebengine-5.9.4:5/5.9
[IP-] [ ] dev-qt/qtwebkit-5.9.1:5/5.9
[IP-] [ ] dev-qt/qtwidgets-5.9.4-r1:5/5.9
[IP-] [ ] dev-qt/qtx11extras-5.9.4:5/5.9
[IP-] [ ] dev-qt/qtxml-5.9.6:5/5.9
[IP-] [ ] dev-qt/qtxmlpatterns-5.9.6:5/5.9
If I have to disable test of dev-python/pillow every time during upgrades, it makes test of dev-python/pillow not any useful.
Created attachment 541194 [details]
It's the first time I notice the existence of the ImageQt compatibility layer. It's not part of the build-time flags and is dynamically enabled at runtime depending on whether Qt is installed or not. The ImageQt-related tests are skipped based on the same criterias, which is what leads to your test failure.
I'm thinking that the proper fix would be to add support for the "qt5" flag which would properly document qt-related dependencies to avoid this kind of failure. Unsetting this flag would patch the source to forcibly disable ImageQt support.
The bug has been referenced in the following commit(s):
Author: Virgil Dupras <firstname.lastname@example.org>
AuthorDate: 2018-08-04 19:10:23 +0000
Commit: Virgil Dupras <email@example.com>
CommitDate: 2018-08-04 19:11:32 +0000
dev-python/pillow: add qt5 USE flag
Pillow has a Qt compatibility layer that is enabled depending on whether
PyQt is installed or not. Letting this happen can lead to unexpected
problems, so we add support for the qt5 flag to explicitly enable Qt
support. When the flag is disabled, we forcibly disable Qt support
Package-Manager: Portage-2.3.44, Repoman-2.3.10
dev-python/pillow/files/pillow-4.3.0-no-qt.patch | 30 +++++++
dev-python/pillow/pillow-4.3.0-r3.ebuild | 106 +++++++++++++++++++++++
2 files changed, 136 insertions(+)
I can't apply the same fix for pillow 5.2.0 because it supports py37 and PyQt5 doesn't yet. Opening appropriate bugs...
Thanks, but it doesn't fix the case when qt5 is enabled, which is the default in default/linux/amd64/17.0/desktop/plasma. Would the right solution for that be forcibly enable support?
Though it would still probably fail because of mismatch between Qt libs...
I don't see the concept of "forcibly enabling qt support" making sense here. It has no meaning. The problem is really that pillow inserts itself in the middle of a qt modules update. I thought that explicitly specifying dependencies would fix this problem, but it seems that the mere presence of modules unused by pillow (qtnetwork, qtprintsupport, qtopengl, etc) and of a different version is enough to make our test fail.
I'm CCing qt team here to check if they have a clue. How could a package that depends on some qt modules ensure that qt is usable (that is, not in the middle of an update) before it builds itself?