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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)