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
