[gentoo-dev] Re: [PATCH 0/1] ecm.eclass: set KDE_DEBUG=1 for ecm_src_test

[Duncan]

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