[Please resummarize/re-categorize as appropriate.] Doing my weekly updates yesterday, after doing the normal system update and starting the smart-live-rebuild (which checks for updates to all live-git packages and rebuilds those that have updates) after updating some of the frameworks, a number of kde packages (both frameworks and plasma/gear) failed to build, while others continued to build just fine. Repeating the run did find a few new updates, and I've repeated it several times since hoping a new frameworks update would fix the problem, but the failing builds continue to fail so no luck since. Using live-git-master packages from the gentoo/kde overlay for frameworks/plasma/gear. Reported versions (from plasma-discover) are frameworks 5.93.0, qt 5.15.2 (normal gentoo packages not live for qt, built against same), discover-5.24.80. I checked the reported-last-7-days bug list and didn't see anything like this so (unless I just missed it) either nobody else is seeing this or it's common knowledge among the devs and on the CI and nobody bothered bug-reporting it. But it's affecting a bunch of packages which are now over a week outdated, with systemsettings being one of them and now it's refusing to run with a symbol lookup error because I can't get it rebuilt to account for the recent kauth changes. The errors all seem to be on an #include, many like the bovo error below on #include <KAboutData>, tho there are some other include failures as well, apparently all frameworks includes, tho. The bovo upgrade failure is notable as it has only a single new commit since my previous successful update, that being c8336f50d: GIT_SILENT Upgrade release service version to 22.07.70, which shouldn't change anything about the build process. Of course that strongly implies the culprit is actually a commit in the just upgraded frameworks not the now erroring build. Unfortunately, attempting to regress a few obvious frameworks candidates to earlier commits wasn't successful and not being a dev my frameworks fu appears not to be up to tracing it down to the bad framework, which would allow a bisect. FAILED: CMakeFiles/bovo.dir/gui/main.cc.o /usr/lib/ccache/bin/x86_64-pc-linux-gnu-g++ -DKCONFIGWIDGETS_NO_KAUTH -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x055900 -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_FROM_BYTEARRAY -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH -DQT_NO_KEYWORDS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_URL_CAST_FROM_STRING -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_STRICT_ITERATORS -DQT_SVG_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/tmp/portage/kde-apps/bovo-9999/work/bovo-9999_build -I/tmp/portage/kde-apps/bovo-9999/work/bovo-9999 -I/tmp/portage/kde-apps/bovo-9999/work/bovo-9999_build/bovo_autogen/include -I/tmp/portage/kde-apps/bovo-9999/work/bovo-9999/game -I/tmp/portage/kde-apps/bovo-9999/work/bovo-9999/gui -I/tmp/portage/kde-apps/bovo-9999/work/bovo-9999/ai -isystem /usr/include/KF5/KXmlGui -isystem /usr/include/KF5 -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtXml -isystem /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/mkspecs/linux-g++ -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -isystem /usr/include/KF5/KConfig -isystem /usr/include/KF5/KConfigCore -isystem /usr/include/KF5/KConfigWidgets -isystem /usr/include/KF5/KCodecs -isystem /usr/include/KF5/KWidgetsAddons -isystem /usr/include/KF5/KConfigGui -isystem /usr/include/qt5/QtDBus -isystem /usr/include/KF5/KI18n -isystem /usr/include/KF5/KF5KDEGames -isystem //include/qt5 -isystem //include/qt5/QtQuickWidgets -isystem //include/qt5/QtQuick -isystem //include/qt5/QtQmlModels -isystem //include/qt5/QtQml -isystem /usr/include/qt5/QtNetwork -isystem /usr/include/KF5/KDBusAddons -isystem /usr/include/KF5/KCrash -isystem //include/qt5/QtSvg -isystem /usr/include/qt5/QtConcurrent -DQT_NO_DEBUG -march=native -O2 -fgcse-sm -fgcse-las -fgcse-after-reload -ftree-vectorize -fdiagnostics-color -fno-operator-names -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Werror=init-self -Wvla -Wdate-time -Wsuggest-override -Wlogical-op -pedantic -Wzero-as-null-pointer-constant -Wmissing-include-dirs -fdiagnostics-color=always -fexceptions -fvisibility=hidden-fvisibility-inlines-hidden -fPIC -std=c++11 -MD -MT CMakeFiles/bovo.dir/gui/main.cc.o -MF CMakeFiles/bovo.dir/gui/main.cc.o.d -o CMakeFiles/bovo.dir/gui/main.cc.o -c /tmp/portage/kde-apps/bovo-9999/work/bovo-9999/gui/main.cc /tmp/portage/kde-apps/bovo-9999/work/bovo-9999/gui/main.cc:24:10: fatal error: KAboutData: No such file or directory 24 | #include <KAboutData> | ^~~~~~~~~~~~ One unique aspect of my system is that /usr is a symlink pointing back at / itself: /usr -> . , so the canonical path for /usr/include/ is /include/, the canonical path for /usr/lib64/ is /lib64/, etc. If others and the CI are *NOT* seeing the problem, it's quite likely that whatever the old framework code did to find things accounted for symlinks while the code in the culprit commit does not, thus triggering the bug only here with my symlink. Here's the list of installed packages that are affected here. Note that it won't be a complete list of affected kde packages since I don't have them all installed (and I actually took the opportunity to try and decide I didn't need a few additional broken kdegames packages, the currently installed executables still ran unlike systemsettings now, which therefore aren't showing up in my list of failures any longer) * (kde-apps/bovo-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-apps:bovo-9999:20220316-010043.log' * (kde-apps/kcharselect-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-apps:kcharselect-9999:20220316-010048.log' * (kde-apps/kcolorchooser-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-apps:kcolorchooser-9999:20220316-010105.log' * (kde-apps/kruler-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-apps:kruler-9999:20220316-010110.log' * (kde-apps/killbots-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-apps:killbots-9999:20220316-010151.log' * (kde-apps/knetwalk-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-apps:knetwalk-9999:20220316-010156.log' * (kde-apps/kollision-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-apps:kollision-9999:20220316-010212.log' * (kde-apps/kshisen-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-apps:kshisen-9999:20220316-010217.log' * (kde-apps/kwalletmanager-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-apps:kwalletmanager-9999:20220316-010229.log' * (kde-plasma/breeze-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-plasma:breeze-9999:20220316-010247.log' * (kde-plasma/oxygen-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-plasma:oxygen-9999:20220316-010319.log' * (kde-plasma/systemsettings-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-plasma:systemsettings-9999:20220316-010345.log' * (kde-apps/kmix-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-apps:kmix-9999:20220316-010359.log' * (kde-plasma/kwin-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-plasma:kwin-9999:20220316-010428.log' * (kde-plasma/plasma-workspace-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-plasma:plasma-workspace-9999:20220316-010448.log' * (kde-plasma/plasma-desktop-9999:5/5::kde, ebuild scheduled for merge), Log file: * '/lg/portage/kde-plasma:plasma-desktop-9999:20220316-010503.log' As mentioned, most of the failures I checked (especially the games) are on #include <KAboutData>, but systemsettings as a counterexample is failing on #include <kauth_version.h>, especially frustrating due to the recent kauth changes meaning the existing executable won't run due to a missing kauth symbol. But it almost certainly traces to the same frameworks bug. Kmix can't find either <kaboutdata.h> or <KProcess>. The plasma-workspace error is occurring earlier, in config, and may be a different bug (perhaps new kauth code related based on the second bit below), but I need this one fixed and maybe it'll be gone, before I can really do much with it if it's still there. Here's that error in any case: CMake Error at kcms/kfontinst/dbus/CMakeLists.txt:30 (install): install PROGRAMS given no DESTINATION! CMake Error at kcms/kfontinst/dbus/CMakeLists.txt:35 (kauth_install_helper_files): Unknown CMake command "kauth_install_helper_files". As for date range, my existing plasma-workspace (picked due to frequent updates so the last commit should have been real close to when I updated) is at f4d444bbf with a commit date of Mar 7 21:58:05 2022 +0000, so that's a reasonable range begin (say a couple hours before that to be sure since the framework pull and build would have been earlier). And based on the portage log the first failure was at (convert from UNIX time...) Mon Mar 14 01:19:42 AM UTC 2022. So the culprit commit(s) time range: Mar 7 20:00 to Mar 14 01:19, UTC. Any pointers on which framework to try bisecting?
(In reply to Duncan from comment #0) > FAILED: CMakeFiles/bovo.dir/gui/main.cc.o ... > -isystem /usr/include/KF5/KXmlGui > -isystem /usr/include/KF5 ... Hmm... I see a bunch of -isystem /usr/include/KF5/*, but what I do *NOT* see is ... -isystem /usr/include/KF5/KCoreAddons ... which has KAboutData and kaboutdata.h , which is what it can't find. What mechanism is supposed to generate that inclusion, that now isn't, and in what framework (because it's now missing in multiple apps, including bovo which only had the version bump commit, so it's gotta be below the individual package level) is it? That would appear to be the culprit framework. And why are some, including KXMLGui, still included, but others, here KCoreAddons, missing?
Created attachment 147574 [details] bovo targetlibs patch (workaround) Why it's happening is beyond me, it's clearly below the leaf package level, but this patch at the leaf package level does at least allow bovo (as my first test package) to build again. If a dev doesn't get to it first I'll have to try to figure out why it's now necessary and fix the real problem or make workarounds for the other packages later.
Likely related: kwayland commit de442e4a9: Install Client headers in a dirs hierarchy matching the C++ namespaces which references https://mail.kde.org/pipermail/kde-frameworks-devel/2022-January/120608.html . Quoting the commit: This auto-magically worked with KF5 because <prefix>/include/KF*/ was always added to the targets interface include dirs by ECM (for compatibility with KDE4?). From the symptoms it seems ECM isn't doing that any more even on KF5. (Looking at new updates and came across that. Hopefully it means the others are caught now too and are fixed (or being fixed), and I'll catch them as I look at more updates. Maybe I'll be able to RESOLVED/FIXED, or at least narrow down the list of affected builds a bit, with my next comment.)
(In reply to Duncan from comment #3) > (Hopefully it means the others > are caught now too and are fixed (or being fixed), and I'll catch them as I > look at more updates. Maybe I'll be able to RESOLVED/FIXED, or at least > narrow down the list of affected builds a bit, with my next comment.) Bovo seems to have (independently) committed the exact patch I suggested as a workaround in comment #2, as 6c8142100 . And plasma-workspace seems to have done something similar, and I think there are others tho not all of them yet. So it seems the fixes are going into the individual repos/packages. I'll probably eventually close this and open bugs against the individual packages that aren't yet fixed, but will leave it open for now so I can more easily find and reference it as I file the others.
So closing this generic bug RESOLVED/INTENTIONAL as it appears it's just that at the frameworks level and people are supposed to do their own includes now. And since I'm filing bugs on the remaining-to-be-fixed individual packages now this one should be closed..