Created attachment 496768 [details] full build log USE="X -debug -doc -gles2 -test +wayland", current qt5 (qtcore-5.7.1-r3), ~amd64 with binutils 2.29.1 just installed, forcing a gcc-6.4.0 rebuild in the same update session kde-frameworks/plasma-9999 failed, so it's a real fresh system. =:^) Error (full build log attached): /tmp/portage/kde-frameworks/plasma-9999/work/plasma-9999/src/declarativeimports/core/framesvgitem.cpp: In member function 'void Plasma::FrameSvgItem::doUpdate()': /tmp/portage/kde-frameworks/plasma-9999/work/plasma-9999/src/declarativeimports/core/framesvgitem.cpp:468:9: error: 'sceneGraphBackend' is not a member of 'QQuickWindow' if (QQuickWindow::sceneGraphBackend() == QLatin1String("software")) { ^~~~~~~~~~~~ make[2]: *** [src/plasmaquick/CMakeFiles/KF5PlasmaQuick.dir/build.make:327: src/plasmaquick/CMakeFiles/KF5PlasmaQuick.dir/__/declarativeimports/core/framesvgitem.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs.... Previous successfull update with head at (upstream) Saturday's 8aebae257. Five commits since (thru 6df656252), but due to where the error is, it's almost certainly upstream commit from a few hours ago: commit daef5c8b6 Author: David Edmundson <kde@davidedmundson.co.uk> Date: Wed Sep 27 15:50:49 2017 +0100 Fix FrameSVGItem with the software renderer Summary: Software rendering (at time of writing Qt5.10) doesn't seem to like our tiling/stretching in the 9-tiles. Also when using QPainter it's arguably faster to create and cache pixmaps of the whole frame, which is what the slow path of FrameSVGItem does. Test Plan: Ran FrameSVG test then plasma shell with scene device set Reviewers: #plasma, broulik Reviewed By: #plasma, broulik Subscribers: plasma-devel, #frameworks Tags: #plasma, #frameworks Differential Revision: https://phabricator.kde.org/D8013 --- src/declarativeimports/core/framesvgitem.cpp | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/declarativeimports/core/framesvgitem.cpp b/src/declarativeimports/core/framesvgitem.cpp index 61dd74f07..af7e4beab 100644 --- a/src/declarativeimports/core/framesvgitem.cpp +++ b/src/declarativeimports/core/framesvgitem.cpp @@ -462,6 +462,12 @@ void FrameSvgItem::doUpdate() bool hasComposeOverBorder = m_frameSvg->hasElement(prefix % QLatin1String("hint-compose-over-border")) && m_frameSvg->hasElement(QLatin1String("mask-") % prefix % QLatin1String("center")); m_fastPath = !hasOverlay && !hasComposeOverBorder; + + //software rendering (at time of writing Qt5.10) doesn't seem to like our tiling/stretching in the 9-tiles. + //also when using QPainter it's arguably faster to create and cache pixmaps of the whole frame, which is what the slow path does + if (QQuickWindow::sceneGraphBackend() == QLatin1String("software")) { + m_fastPath = false; + } m_textureChanged = true; update();
If you'd prefer I back off and wait a couple days before filing to see if upstream catches it, or would like me to file these upstream instead, just say so.
FWIW similar "'sceneGraphBackend' is not a member of 'QQuickWindow'" error attempting to build plasma-workspace. I'd guess the fix for plasma-framework will fix plasma-workspace too, so I won't file a separate bug for it unless the framework's fixed and I still get the workspace error.
We'll see if upstream is going to raise minimum Qt to 5.9 or not.
(In reply to Andreas Sturmlechner from comment #3) > We'll see if upstream is going to raise minimum Qt to 5.9 or not. Looks like they're reverting, as a kde admin (bcooksley) pointed out it kills the CI because they don't have 5.9 and it won't build on the 5.7.1 they have. Meanwhile, with that 5.9 hint and based on a report from another gentooer on the kde-general list that 5.9.1 is working for him, I added the qt overlay via layman once again, and just rebooted after finishing building the update. Nothing broken so far. =:^)
5.9.2 is slated for next week and going to be in tree, that's what I would wait for.
5.9 minimum raised in upstream commit f7d76f006723e83ffae201b1b52617cd7eafdd8a
Fixed in upstream commit c1e432065ffcf24b2e3bcb6de7cb5cd5136482d7