kde-baloo crashes

[Duncan]

Rens Oliemans posted on Fri, 20 Sep 2024 11:12:12 +0200 as excerpted:

> Hi all,

[My second attempt at a reply; the first got too far "into the weeds" (you 
think /this/ one's long??) and I killed it.]

> kde-baloo crashes at each execution when run via systemd (stacktrace &
> versions below). I've tried running /usr/lib/kf6/baloo_file directly,
> but that is taking hours and hours. It's still running - let me know if
> you want its output.
> 
> I've done a clean Arch install two days ago, and have installed KDE
> Plasma on it. (Though I don't think it's too relevant, that went
> somewhat unorthodox: I first installed 'plasma-meta' and
> 'kde-applications-meta', but soon found that 'kde-applications-meta'
> included too much for my liking and uninstalled that with 'pacman -Rs
> kde-applications-meta'. Since then, I've installed some specific
> packages. If you want more information, please let me know.)

[Stack-traces elided as extraneous for the purposes of my reply.]
                 
> Versions:
>  - baloo          :: 6.6.0 [obtained by balooctl6]
>  - KDE Plasma     :: 6.1.5 - KDE Frameworks :: 6.6.0 - kernel         ::
>  6.10.10-arch1-1 (64-bit)
> 
> I'm new to this mailing list, please inform me if I've missed something
> important.

Seems you covered things pretty well! =:^)

Maybe you'll get a better direct answer from someone with the specific 
knowledge, but FWIW if you don't or until then...

TLDR summary:  May not be a solution you consider viable, but consider 
either run-time disabling (but keeping installed as a dep) or build-time-
disabling and removing baloo.  For me at least it's not worth the hassle.

So facts are there's not too many regulars here, and those that are tend 
to have rather strong somewhat peculiar ideas about how they want their 
system to behave and what they'll tolerate on it.  For example, one 
regular here is still running mostly (qt4-based) kde4 (yes, still kde4, 
even as plasma6 is current and kde/plasma5 is phasing down), because it 
meets his needs while current kde/plasma does not.

I actually tend toward the other extreme, running live-git-master for most 
of my kde frameworks/plasma/apps/gear packages, via the gentoo/kde project 
overlay ebuilds for that purpose, the better to track changes via git log 
and bug-report or occasionally patch-revert if I don't like what the 
commits did.

But more to the point for this thread, from long experience going back to 
my MS days last century, I know the trouble and draggy systems even when 
working as intended that "oh-so-(un-)helpful" file indexing systems like 
baloo can bring, and not only refuse to have it on my system, but felt 
strongly enough about keeping "semantic desktop" (with its file indexing, 
etc) off my system that during the period in the kde4 era when gentoo/kde 
discontinued its IUSE=semantic-desktop option, I continued carrying and 
updating the patches locally to ensure semantic-desktop STAYED off my 
system -- the alternative was finding another desktop to use 
(enlightenment always sounded interesting), but luckily, upstream kde 
continued supporting disabling semantic-desktop (except for kdepim-based 
apps like kmail, which I switched away from), and it wasn't /too/ 
difficult to grab the gentoo/kde stuff for it out of git when they dropped 
it, and continue carrying it myself.  And luckily, gentoo/kde eventually 
brought back its support for disabling the related options, and I could 
subsume to my upstream for them once again. =:^)

And arch's known for its technically-minded users just as gentoo was and 
still is, tho of course for some time arch's been more popular.  So I 
imagine, if you haven't yet developed such strong and peculiar opinions 
about what you think is appropriate for your system, if you stay with arch 
long enough, you will.  Either that or at some point you'll decide arch 
isn't worth the hassle and switch to a more normal binary distro (OpenSUSE 
is considered a strong kde distro).  Because most if not all users of such 
strongly technical-user oriented distros eventually either decide the 
extra hassle's not worth it, or find they now have a site-specific reason 
that said hassle *is* still worth it.

Anyway, I'm not sure if arch has a way to totally disable baloo at build 
time as does gentoo, or if you'd find it worth it if so, but the other 
alternative is to simply runtime disable it (but keep it installed as a 
dep), thus avoiding the performance issues even when it /is/ working, 
along with having to trace down brokenness when it isn't, like this thread 
is about.

There is some cost, however, which you might not find worth it, tho I 
obviously do.  AFAIK some of the kdepim-based packages (kmail being the 
post popular, kontact if you're into office-apps, some others) may break, 
altho I believe akonadi's sql-based not baloo-based, so you may need to 
find alternatives for them if you're using them.  And some of the file 
metadata stuff in dolphin, gwenview, etc, is baloo-based, so it goes stale 
or gets disabled.  But in general, kde apps and plasma still work, and the 
side effects are reduced to some extent if you just disable baloo instead 
of removing it (build-time disable option, via USE/IUSE on gentoo).

As I said a strong opinion and it may or may not be worth it for you, but 
I don't have baloo problems because I won't allow baloo on my system. 
YMMV.

(Meanwhile, not apropos to the thread but I found your mention of arch kde 
metapackages that install a whole collection of packages as deps 
interesting, because the gentoo/kde project took the exact same approach 
and has metapackages as well.  And like you, I found the metapackages 
installed too many packages I didn't really need or want so I do 
individual packages instead.  (Tho at least on gentoo/kde, there's "sets" 
that can be used too, either directly paralleling the metapackages, or as 
I've done, using them as a helpful list but copying the sets and 
commenting out the packages I won't want/need or as typical for some libs, 
that are deps of other packages anyway so something I don't actually need 
to pull in with the set.  Then from time to time I diff my set against the 
current gentoo/kde project set and sync up. =:^)

-- 
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