Created attachment 600002 [details] full build log (Effectively) Reverting that commit (upstream 7ae94bb27) allows milou to build and merge without issue. I should mention that this is with qt-5.14.0 (tho first tripped over with its previous betas), from the qt overlay. (I made a git show -R (aka revert) patch and put it in /etc/portage/patches, but it failed to apply at the first chunk due to a later commit adding a "include(KDEClangFormat)" line right before the first change. So I manually added that line to the output and then the chunk and patch applied. Thus the "effectively" parenthetical above. I guess a rebase would be the "git way" to do it but that's outside my git comfort zone.) * I've not tested patch-reverting individual chunks, but I did try both 5.17.4 release and 5.17.49.9999 branch ebuilds (using --nodeps to override portage's deps objection) while tracing the bug down and they built fine, so it's only 9999/master that's affected. Between being confined to master (the only place that commit is applied ATM) and the 'if (EXISTS "${CMAKE_SOURCE_DIR}/.git")' test of that first chunk, I suspect that may be the actual culprit, and that the rest of that commit may be entirely fine. * That's why I'm reporting here, not upstream, as gentoo's git-r3.eclass git-handling method appears to violate the assumptions upstream made (perhaps a qt 5.15 branch assumption?) about people building from git. OK, so here's the error (note the correctly named candidate expects 4 args, 0 provided). I'll attach the full log as well. ../milou-9999/lib/draghelper.cpp: In constructor 'Milou::DragHelper::DragHelper(QObject*)': ../milou-9999/lib/draghelper.cpp:32:32: error: no matching function for call to 'qmlRegisterType<QMimeData>()' 32 | qmlRegisterType<QMimeData>(); | ^ In file included from /include/qt5/QtQuick/qquickitem.h:44, from /include/qt5/QtQuick/QQuickItem:1, from ../milou-9999/lib/draghelper.cpp:25: /include/qt5/QtQml/qqml.h:291:5: note: candidate: 'int qmlRegisterType(const char*, int, int, const char*) [with T = QMimeData]' 291 | int qmlRegisterType(const char *uri, int versionMajor, int versionMinor, const char *qmlName) | ^~~~~~~~~~~~~~~ /include/qt5/QtQml/qqml.h:291:5: note: candidate expects 4 arguments, 0 provided /include/qt5/QtQml/qqml.h:322:5: note: candidate: 'template<class T, int metaObjectRevision> int qmlRegisterType(const char*, int, int, const char*)' 322 | int qmlRegisterType(const char *uri, int versionMajor, int versionMinor, const char *qmlName) | ^~~~~~~~~~~~~~~ /include/qt5/QtQml/qqml.h:322:5: note: template argument deduction/substitution failed: ../milou-9999/lib/draghelper.cpp:32:32: note: candidate expects 4 arguments, 0 provided 32 | qmlRegisterType<QMimeData>(); | ^
Created attachment 600008 [details, diff] patch I'm using (manually modified from a straight commit revert)
Created attachment 600010 [details] emerge --info milou
(In reply to Duncan from comment #0) > * I've not tested patch-reverting individual chunks, but I did try both > 5.17.4 release and 5.17.49.9999 branch ebuilds (using --nodeps to override > portage's deps objection) while tracing the bug down and they built fine, so > it's only 9999/master that's affected. Between being confined to master > (the only place that commit is applied ATM) and the 'if (EXISTS > "${CMAKE_SOURCE_DIR}/.git")' test of that first chunk, I suspect that may be > the actual culprit, and that the rest of that commit may be entirely fine. > > * That's why I'm reporting here, not upstream, as gentoo's git-r3.eclass > git-handling method appears to violate the assumptions upstream made > (perhaps a qt 5.15 branch assumption?) about people building from git. git-r3.eclass is not inferfering here, the upstream cmake hack with `EXISTS .git` ensures the deprecation error only happens on git sources. Plasma/5.17 branch does not contain the aggressive disable deprecated bits, so that's why it builds.
Seems like upstream commit dfecda35d4c797a274ca66930a735be39c21086c should fix your issue.
(In reply to Andreas Sturmlechner from comment #4) > Seems like upstream commit dfecda35d4c797a274ca66930a735be39c21086c should > fix your issue. Confirming upstream fix. Thanks. =:^)
