James Beddek posted on Wed, 20 Oct 2021 09:42:14 +0000 as excerpted: >> > KDE provides a variable, KDE_DEBUG [1], which when set disables the >> > DrKonqi crash handler. Using this results in the tests segfaulting >> > and the test phase simply failing, rather than hanging. >> Do crashes of other (non-ecm) tests trigger DrKonqi too? What's the >> reason to add this variable only to ecm.eclass? >> > As far as I can tell only packages that use ecm.eclass trigger DrKonqi > upon a test segfault. However, this may just be to me not experiencing > crashes in other test suites. To the best of my knowledge it's purely > the KDE/ecm packages.
DrKonqi is part of kde's plasma, in gentoo as kde-plasma/drkonqi . As such it depends on various kde-frameworks/* including kde-frameworks/ extra-cmake-modules, shortened in kde-dev lingo to ECM, thus ecm.eclass. And ECM is the way they handle kde-specific cmake detection so basically any app that cares about drkonqi is going to be using ecm.eclass as well. Tho the reverse doesn't necessarily hold -- ECM as a framework is far more basic than drkonqi as a plasma component, and while my kde/plasma installation is somewhat lite, nothing's actually pulling in drkonqi and it's not merged, while a quick equery d extra-cmake-modules | wc -l suggests 151 packages depend on extra-cmake-modules and a look at the list confirms they're all kde related, tho a few like media-libs/phonon are not kde-*. And without drkonqi I get segfaults. Which suggests another possible workaround, unmerging drkonki. If the only thing pulling it in is a set or metapackage the alternative would be either a local-overlay null- package, or commenting that entry in a local copy of the set/metapackage. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
