With the 4.11 betas I can't get plasma to load my existing activities properly when it starts. It *DOES* load plasma-desktop-appletsrc, as my customized panels are there, but it *REFUSES* to load any existing activities at all, neither to display, nor to the activities list if I select activities from the toolbox menu. All it has is the newly created activity. However, if I then kquitapp plasma-desktop and restart it, it loads both the newly created activity *AND* the old ones it couldn't see at initial kde startup. The newly created activity is selected, with the previously existing customized activities running and selectable. If I don't delete the newly created activity, the next time I restart, I get yet another newly created activity -- adding a new one each time I restart kde, whether from fresh reboot, or from a CLI login using startx with the kde session set in my environment. I verified that the same behavior exists with a clean user config, so it's nothing in the existing user config. Note that as I mentioned, I login at the CLI and run startx with the kde session set. I do NOT have kdm or other *dm installed on this machine at all. I should however mention that my system (not user) kde start script is customized to set a few KDE vars in the environment before it starts kde. #!/bin/bash # For details, see the KDE User Guide (part of the khelpcenter package), # Part VI. KDE for Administrators, Chapter 25, KDE Internals, # Environment variables subheading. # Obvious... export KDE_NO_IPV6=1 export KDE_UTF8_FILENAMES=1 # ensure TMPDIR is set [[ ! $TMPDIR && -d $HOME/tmp ]] && export TMPDIR="$HOME/tmp" [[ $TMPDIR ]] || export TMPDIR=/tmp # KDE user settings, defaults to $HOME/.kde export KDEHOME="$HOME/kde" # KDE temp dir, defaults to /tmp/kde-$USER export KDETMP="$TMPDIR/kde" # KDE var/cache dir, defaults to /var/tmp/ (kdecache-$USER) export KDEVARTMP="$HOME/config/cache" mkdir -p $KDEVARTMP ########################################### # XDG_*, freedesktop.org standard locations # *HOME indicates user dir # system dirs are colon separated # default: $HOME/.local/share export XDG_DATA_HOME="$HOME/config/local/share" # default: $HOME/.config export XDG_CONFIG_HOME="$HOME/config" # default: $HOME/.cache export XDG_CACHE_HOME="$KDEVARTMP" Again, despite trying with a clean user where the $HOME locations mentioned above (except for $HOME/tmp being a symlink to a user dir in /tmp, which is tmpfs, with the user subdirs being created at each boot) didn't even exist until created by the first kde startup, with very minimal customization of the first-start newly created activity so I could tell if it was reused or not, a kde restart failed to deliver that minimally customized activity back to me, insisting on creating a new one. What appears to be happening, possibly because I'm running startx/startkde and not using the *dm graphical login most testers probably use, is some sort of race such that services (kded? dbus? maybe kactivity-managerd itself and it's plasma-desktop racing with it? something else? I don't know) kactivity-managerd depends on aren't there yet when it first starts, so it creates a new activity because it can't get information about the old one. By the time I can manually do the kquitapp plasma-desktop; plasma-desktop, thing later in kde startup, whatever services are up and running, so kactivity-managerd can supply the usual information, and the new plasma-desktop session can see its activities as it should. Three other somewhat unusual things about my desktop: * I'm running both /home and / (separate partitions) on btrfs configured in raid1 mode with fairly fast dual ssds. That certainly boots to kde faster than the old "spinning rust" did, and it's possible that's triggering a data-i/o race that normal configs won't see. * I run a lot of pre-release software, including mainline git-kernels, the kde pre-release (obviously) and kde-git-branch when it branches (I'm not running live-trunk now due to dependency issues, gentoo/kde's live-kde ebuilds depend on a similar version of oxygen-icons, which is still svn not git, and while I have git on my system for all the various live packages I run, I'm not particularly interested in installing svn, so no live-package oxygen-icons and thus no live-edge kde, only branch-live once it branches, as for it the latest release version of oxygen-icons suffices), and currently mesa, xf86-video-ati, and various other x/mesa related bits, tho I'm not running xorg-server itself live (xorg-server-1.14.2 FWIW). However, they are unlikely to be the problem both because previous kde/plasma worked, and because once kde is up and running, a plasma reset gets a working plasma back. * gentoo/kde had this idea that 4.11, just as kde4's going into maintenance mode, was a great time to drop the semantic-desktop and related USE flags and force it on. Well, given the time and effort I spent ridding myself of the millstone that is semantic-desktop, that's *NOT* going to happen here, so I 4.10/4.11 diffed the kde ebuilds I used that /had/ a semantic-desktop USE flag in 4.10 and painstakingly went thru the results, creating semantic-desktop-removal patches that now get auto-applied to ebuilds as gentoo/kde updates them. Of course the upstream kde build options are still there (unlike gentoo/kde, hopefully if semantic-desktop is forced by upstream kde it'll be with the 4 -> 5/frameworks major bump, and with the whole modularity thing for 5/frameworks, I'm HOPING kde won't be forcing semantic-desktop with 5/frameworks, either), so it's only the gentoo ebuilds I'm patching, not upstream kde sources, but that DOES mean I'm not running standard gentoo/kde any longer, so semantic desktop can't be assumed on my system as it could be for most gentooers for 4.11, from the betas onward. Finally, it's worth noting that the new activities are blank, a black background, no wallpaper or other image at all, which seems abnormal to me and likely attributes to the same resources inavailability at kde startup. Additionally, there's one more possible clue, two of these entries in .xsession-errors (possibly related to the two different customized activities I have): trying to alter state of unknown activity!! And one more (/h/x is my $HOME, so /h/x/kde is my $KDEHOME): QFileSystemWatcher: failed to add paths: /h/x/kde/share/config/activitymanager-pluginsrc With luck, those messages should be related to whatever's going sour on me, making tracking down the problem far easier for someone who knows where the come from. =:^) Reproducible: Always Steps to Reproduce: 1. Start kde from the text console using startx with kde as the session 2. Find only a brand new activity, blank wallpaper. 3. kquitapp plasma-desktop; plasma-desktop (in krunner or whatever) 4. The activities list now has the two custom activities that should have shown up with one active at boot, instead of ignoring them and starting a new "blank" activity. Expected Results: The configured activities should reappear normally after a kde restart. (I'm setting severity Major as that describes the problem, activities are a major feature, and they're broken.)
Yep, happens to me too since upgrading from 4.10 to 4.11. I don't have any real customisations at all. The only "unusual" thing that I can think of is that I run twin screens, a 2560x1440 and a laptop screen ( 1920x1080 ) with the larger screen above and in the centre of the smaller one. Pretty much as Duncan says. After running "kquitapp plasma-desktop ; sleep 5 ; plasma-desktop" I can see my old activities, but switching to them doesn't work ( normally the first try does nothing, the second results in a white screen and/or crash dialog for plasma, after which the name of the activity that I'm trying to switch to disappears and you can't delete it - "deleting activity undefined." ) I agree with the major status... in this state I can't customise my desktop - it's a complete waste of time changing backgrounds or adding widgets because I have no way to get them back once I log out. I've tried deleting everything that I could see related to plasma in ~/.kde but that didn't help.
Forgot to mention - I AM using kdm to start sessions. I've carried out some more tests, and there is a certain randomness to what happens - now activities are in fact present on login, but I can't switch to them ( I always end up in a "New Activity", and attempting to switch to my previously defined activity results in the New Activity name being erased, but no switch. ) Nothing, as far as I'm aware, has changed since I had to do the kquitapp plasma-desktop thing above. I can't actually run "startx" from my user account... X quits with no apparent reason that I can see. However, I have now also set up a test user, and that account seemed to work correctly, both using kdm and startx/startkde.... so in my case there may still be something in the .kde directory, but I'm not sure what. I guess I'm going to have to start from scratch :(. ( I can't just delete .kde completely because I have a huge amount of mail stored in there. )
Apologies for bombarding the cc list with e-mails.... but I've found a BIG clue as to what is happening in my case at least. This problem only happens if I have desktop effects enabled at startup, and composting is using OpenGL 2.0 or 3.1 ( XRender and OpenGL1.2 seem not to cause the issue. ) I have the Qt graphics system as Native in all cases. If I don't enable at startup, then the problem also doesn't seem to happen ( I can happily enable them once logged in using Alt-Shift-F12. ) I guess other relevant info is that I'm using the Nouveau driver on a laptop with an NVidia Quadro 2000M. I'm also currently using the Xorg-edgers repository ( Ubuntu ) though I did try purging that and it didn't make a difference, other than the fact that I couldn't enable desktop effects after log in. Come to think of it, this may have been present prior to the 4.11 upgrade, because I also switched from the NVidia proprietary driver to Nouveau to try to resolve another issue, but didn't connect the two at the time.
Ok... a cold boot this morning caused the issue again with OpenGL 1.2 enabled at startup. Thought I'd tried a cold boot, but maybe it was loads of warm boots.... or maybe it's affected by the time that the rendering system takes to initialise ( and hence random but better with OpenGL 1.2 than the others. ) Anyway.... just tried a cold boot without effects enabled at startup and it was fine, so I'll see how it goes ( it's definitely something to do with that because it failed every single time with OpenGL 2/3.1. ) Haven't tried a cold boot with XRender because frankly I was losing the will to live :(.
I had reported this during the betas so it could get fixed before release. <sigh> Not even a plasma-dev comment... What's the point of betas if there's no followup on bugs filed on 'em? Anyway, just bumped version to 4.11.0 as I still see the problem with post-4.11.0 live-git-branch (kde-workspace commit b10e22b8). FWIW, I noticed that if I manually killed and restarted plasma-desktop (kactivitymanagerd may also need killed, see below), it would work. So I automated the process, working around the problem by sticking a script in $KDEHOME/autostart (my autostart path as set in kde settings, paths) that does (approximately) this: -- cut here -- # set the first sleep to allow the initial plasma-desktop # to start, I'm on SSD, so this can be fairly short, here sleep 2 # kquitapp is the kde way, or just killall kquitapp plasma-desktop # you may want/need to killall/quitapp kactivitymanagerd # too, I don't need to, here, see the read-only files # discussion below # kquitapp kactivitymanagerd # second sleep to make sure it's had time to die sleep 1 # restart plasma-desktop -- cut here -- Note that I have both activitymanagerrc and plasma-desktop-appletsrc (both found in $KDEHOME/share/config/) set read-only, so they don't get overwritten by the bad configuration of the initial (bad) startup, before the scripted plasma-desktop restart. Without that, each startup adds a new blank activity and they add up pretty fast. =:^( Also note that unless kactivitymanagerd is killed as well, it'll still be tracking the new/blank activity, but with both files named above set read-only, neither it nor plasma-desktop can write that to disk, so it isn't saved. However, with kactivitymanagerd still running, plasma-desktop will still restart using the new/blank activity, BUT the saved activities will also be available and can be switched to using whatever method you normally use to switch activities. (Here, I have vertscroll over the desktop set to change virtual desktops, and ctrl-vertscroll set to switch activities, so after the scripted plasma-desktop restart leaves me at the blank activity, I can ctrl-vertscroll to switch to my ordinary activities.) With the scripted plasma-desktop restart workaround in place, I couldn't be sure whether the bug had been fixed or not, without disabling the workaround to test it. Which I just did and the bug is still there. =:^( Duncan (bug reporter)
*** This bug has been confirmed by popular vote. ***
Bumped version to 4.12.1 as the bug is still here. =:^( Well, I guess 4.12.1+ since I'm on live-branch and updated after 4.12.1 release, but anyway... At least with the workaround restart script above, plasma's still usable. I guess I'll see if it's in plasma2/kde-frameworks-5 at some point, as development focus is no longer on kde4 and I doubt it'll be fixed there, but I'll be trying frameworks-5 sometime soon. (Thanks CB for the cc, reminding me to followup on this again.)
I'm still geting this with KDE 4.13.1. The weird thing is, that it only happens when I'm using the open-source radeonsi driver - with fglrx no new activity is created when starting KDE.
Sorry for the late response. Are you all using Gentoo, or is this a cross-distro issue. The only reason why this can happen (that comes to mind) is that plasma starts before kactivitymanagerd, creates a default activity to handle the unknown state, and then, when kactivitymanagerd starts, it asks it to save the "new"activity.
If bug 320561 and this are really the same thing, then this isn't just Gentoo. It happens on openSUSE sometimes, other times not, with no discernable pattern why it happens to any particular user or on any particular login instance.
For what it's worth, I *am* using Gentoo and start KDE with the default init scripts. What controls the order in which kactivitymanagerd and plasma are started? And what could make this different between the open and closed-source radeon drivers - if the difference was only in the startup times I'd expect it to succeed sometimes with radeonsi and fail sometimes with fglrx. Felix: I have noticed the symptoms mentioned in that bug report (minimized windows, can't restore), but only once - normally windows are restored without issue.
I am also using Gentoo and the open radeon driver. But from my observations I only get this problem if I logout from the KDE session. As long as I choose "reboot" or "shutdown" instead of "logout" I don't have this problem.
I can't imagine why a graphics driver would have this effect. The only application that creates activities is plasma, and the only scenario where I see it can create an invalid activity is the above. The only thing I can say is that I can not reproduce the issue. And I don't know any plasma people using Gentoo to ask to investigate the issue.
I can confirm this issue on Kubuntu 13.10 with PXE boot and nfs mounted home folder. Each user on each login got new activity, so after long work activities number goes up to 999 and more. How can I disable this or debug the problem?
KDE version is 4.13.0 How is defaul activity id is generated? Maybe because on PXE boot system hostname is undefined - always new id is generated on login?
Current (kde4) git as of a day or so ago still has the problem: $ plasma-desktop --version Qt: 4.8.5 KDE Development Platform: 4.13.60 Plasma Desktop Shell: 4.11.10 $ kactivitymanagerd --version [...] KDE Activity Manager: 3.0 I do have a couple new clues to report, however. =:^) 1) I disabled most of my autostart apps (all that would access the net) and noticed that upon starting x/kde, I still get a bunch of net traffic. Checking netstat to see where it's going, it seems to be the PotD background and Comicstrip plasmoid updates, for the very same activities that then refuse to show up unless I quit and restart plasma-desktop (which I normally do automatically via autostart scriptlet, but that was disabled, so all I was getting was the new activity shown). So even tho the activities refuse to actually show up, they're evidently still being updated, so plasma *MUST* indeed be seeing them at SOME level or it couldn't update them, it's simply refusing to show them! 2) While investigating that, I discovered at first quite by accident, then by doing it repeatedly, that if I run startx (which runs the kde xsession) and as soon as X starts up, before anything but the black screen and the mouse pointer appears (the kde splash is disabled), switch back to a different VT (with a radeon KMS text login) and wait until all that network update activity ceases... Then when I switch back to the X/KDE VT, *MY NORMAL ACTIVITES HAVE APPEARED*, without the usual additional new/blank activity. So it's definitely some sort of race condition. If I'm at the X display when the activities try to start, something goes wrong and the existing activities are not detected in time, so it starts with a new, blank activity, even tho it detects and updates the PotD backgrounds and comic-strip plasmoids on the missing activities. But if I'm switched to a different VT, existing activites are detected and launched normally, so that when I switch back to the X/KDE VT, the existing activities are there as they should be! Also possibly of interest. When I originally reported this bug I was running SysV init and openrc. I've since switched to systemd, but still have the bug. So whatever the race condition is seems to be independent of init system and systemd's logind stuff.
(In reply to Duncan from comment #0) > However, if I then kquitapp plasma-desktop and restart it, it loads both the > newly created activity *AND* the old ones it couldn't see at initial kde > startup. The newly created activity is selected, with the previously > existing customized activities running and selectable. > > 4. The activities list now has the two custom activities that should have > shown up with one active at boot, instead of ignoring them and starting a > new "blank" activity. > > Expected Results: > The configured activities should reappear normally after a kde restart. > Same issue reproduced here in openSUSE 13.1 with KDE 4.14 (and also after upgrading to 4.14.1). After starting plasma-desktop again kquitapp/kstart sequence the created/renamed activities show up with the added New Activity that was seen after re-login.
(In reply to Lassi Väätämöinen from comment #17) > Same issue reproduced here in openSUSE 13.1 with KDE 4.14 (and also after > upgrading to 4.14.1). > After starting plasma-desktop again kquitapp/kstart sequence the > created/renamed activities show up with the added New Activity that was seen > after re-login. Tried with KDE 4.14.1. With clean ~/.kde4/ this is mostly working in my quick test. Except for the fact that there was an "undefined" activity listed in the first login.. Reverting back to my existing settings causes this issue again. So activity-config files could use some clean-up? I tried removing some of those, and my existing acitivity settings were erased, but after creating new acitvities and doing logout-login exercise the issue still persists.
(In reply to Duncan from comment #16) > So it's definitely some sort of race condition. If I'm at the X display > when the activities try to start, something goes wrong and the existing > activities are not detected in time, so it starts with a new, blank > activity, even tho it detects and updates the PotD backgrounds and Coming to think of it, the root cause in my case looks very likely to be a race condition as well, as I only recently noticed this issue, since switching to use an SSD as /home -disk.
Created attachment 88801 [details] Please ignore this. GMail attached an HTML version of the email. I still have this issue after mentioning it waaay back, and I'm now on 4.14. I get around it by having desktop effects disabled at startup. The reason that I'm chiming in now is that I also have an SSD, and have had since I first saw the bug. I can't be 100% sure that I DIDN'T have the issue when I was running a mechanical drive, but it seems like a bit of a coincidence. On 22 September 2014 21:39, Lassi Väätämöinen <lassi.vaatamoinen@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=321781 > > --- Comment #19 from Lassi Väätämöinen <lassi.vaatamoinen@gmail.com> --- > (In reply to Duncan from comment #16) > > So it's definitely some sort of race condition. If I'm at the X display > > when the activities try to start, something goes wrong and the existing > > activities are not detected in time, so it starts with a new, blank > > activity, even tho it detects and updates the PotD backgrounds and > > Coming to think of it, the root cause in my case looks very likely to be a > race > condition as well, as I only recently noticed this issue, since switching > to > use an SSD as /home -disk. > > -- > You are receiving this mail because: > You voted for the bug. > You are on the CC list for the bug. >
*** Bug 339403 has been marked as a duplicate of this bug. ***
Just to add to the comments about SSDs, I'm running /home and / on an SSD as well as others mentioning this here. I have some spare spinning disc partitions on my system, when time permits I'll clone onto one of those and see if the behaviour is different (may be a few days, due to other commitments).
(In reply to Tony Green from comment #22) > Just to add to the comments about SSDs, I'm running /home and / on an SSD as > well as others mentioning this here. Adding to the SSD comments, I'm on (btrfs on) SSD now, but was on (reiserfs on) spinning rust when I originally reported. However, it should be noted that I'm on gentoo and am running a pretty lean kde, including among other things USE=-semantic-desktop so no akonadi/nepomuk/baloo/whatever, also no policykit, etc, and that I login at the text login and startx with a startkde session from there, no *dm graphical login. BTW no ksplash either. So it could very well be that whatever race condition it is, is most often triggered on ssds due to their relative lack of bottlenecking, but that I originally triggered it here on spinning rust as well, because I simply don't start whatever it is that slows most folks' kde startup down so they don't see it. And as said earlier when I originally reported I was on sysvinit/openrc, but am now on systemd, so whatever it is wouldn't appear to be init-system related, either. FWIW, tried plasma2/kdeframeworks-5 a month or so ago but kwin was repeatedly crashing so didn't get to see much but a few error dialogs. Either that or it was other bugs in the very early gentoo overlay versions I was running. So while I wanted to try it and see if I suffered a similar bug there, I didn't get that far. Maybe next time... Meanwhile, bumping the affected version in the title/summary again (can't bump it further in the dropdown), altho I doubt it'll do any good at this point since the focus is obviously on kf5/plasma2 now. Which is why I had wanted to try it there too. Unfortunately... $>>plasma-desktop --version Qt: 4.8.6 KDE Development Platform: 4.14.1 Plasma Desktop Shell: 4.11.12 $>>kactivitymanagerd --version Qt: 4.8.6 KDE Development Platform: 4.14.1 KDE Activity Manager: 3.0
(In reply to Adam from comment #3) > Apologies for bombarding the cc list with e-mails.... but I've found a BIG > clue as to what is happening in my case at least. > > This problem only happens if I have desktop effects enabled at startup, and > composting is using OpenGL 2.0 or 3.1 ( XRender and OpenGL1.2 seem not to > cause the issue. ) I have the Qt graphics system as Native in all cases. If > I don't enable at startup, then the problem also doesn't seem to happen ( I > can happily enable them once logged in using Alt-Shift-F12. ) > > I guess other relevant info is that I'm using the Nouveau driver on a laptop > with an NVidia Quadro 2000M. I'm also currently using the Xorg-edgers > repository ( Ubuntu ) though I did try purging that and it didn't make a > difference, other than the fact that I couldn't enable desktop effects after > log in. Come to think of it, this may have been present prior to the 4.11 > upgrade, because I also switched from the NVidia proprietary driver to > Nouveau to try to resolve another issue, but didn't connect the two at the > time. Disabling desktop effects stops the problem happening for me as well. Though leaving them enabled and changing compositing doesn't fix it for me. Interesting bug... :-)
(In reply to Tony Green from comment #24) > Disabling desktop effects stops the problem happening for me as well. Same here..
I just ran into this bug. I moved from HDD to SSD and I started getting it. Gentoo 32b, KDE 4.12.5
I remember I had this once when fiddling with hostname. I guess the activity identifiers include the hostname?
activityId is a GUID and the bug occurs even on a newly created user account. Plasma simply creates a new activity. But if I disable desktop effects, everything works correctly, so I enable the effects later in .kde4/Autostart (In reply to Christoph Feck from comment #27) > I remember I had this once when fiddling with hostname. I guess the activity > identifiers include the hostname?
*** Bug 341610 has been marked as a duplicate of this bug. ***
This bug is a show stopper for KDE use. Is there a workaround that doesn't depend on timmings? The relation of this problem with desktop effects must be very dependent on timmings of the specific machine where it is running. Therefore, even if it "fixes" the problem for some machines it will prevent anything other than micro scale deploys of KDE. From my experience: - chattr +i on plasma-desktop-appletsrc doesn't fix the problem (plasma-desktoprc is changed too) - chattr +i on plasma-desktoprc makes login take forever and kdialog popup with a warning
(In reply to gustavo from comment #30) > This bug is a show stopper for KDE use. Is there a workaround that doesn't > depend on timmings? The workaround which is successful for me is to disable compositing in the configuration, then putting the following line in an autostart script: qdbus org.kde.kwin /KWin toggleCompositing
(In reply to Tony Green from comment #31) > (In reply to gustavo from comment #30) > > This bug is a show stopper for KDE use. Is there a workaround that doesn't > > depend on timmings? > > > The workaround which is successful for me is to disable compositing in the > configuration, then putting the following line in an autostart script: > > qdbus org.kde.kwin /KWin toggleCompositing Thanks Tony. I will try that and report later on. (Still, since compositing is not related to activities its use must be only exposing a race condition bug that might be exposed in other ways depending on the hardware.)
Any news? Hundreds of my users are very close to kill me because of this annoying bug.
(In reply to Eugeny Shkrigunov from comment #33) > Any news? > Hundreds of my users are very close to kill me because of this annoying bug. No news... and in this case, that isn't good news! =:^( Best I can suggest is use one of the scripted workarounds for your users; probably the one turning desktop-effects off by default, then on with an autostart script, thus avoiding having to set the two mentioned files to read-only. Tho I did notice that when a new systemd version broke networking, the problem didn't happen. It may be that if no activities have an Internet enabled plasmoid, or if networking isn't enabled until after plasma starts, it won't happen. Last I checked kde5, kwin5 was still crashing on my hardware (seems it doesn't like either my radeon 6670/turks with current freedomware kernel/mesa/radeon drivers, or the triple monitor setup <shrug>), tho I really need to test again as it has been a few months and releases, and nobody else here has updated the bug with kde5 status, so I still don't even know if the problem is gone with kde5, or not. Tho if kde5 forces semantic-desktop (last I checked it seems to, at least on gentoo =:^( ), I'll probably stick with kde4 for awhile longer, and then switch to something else. Over the course of kde4, as they broke various kde apps or they jumped the shark (like kmail requiring akonadi) I switched away from kde for about everything but plasma/kwin/konsole, so switching away from kde entirely is pretty much simply a matter of trying out a few other desktops and window managers (terminal window apps shouldn't be an issue) and see what others I like. What I've read about enlightenment has me interested, so it's tops on my try list.
FWIW, on kf5/plasma5 now and for I think a year or so now, and no sign of this bug. So anyone still on kde4/plasma4 and struggling with it, know that it does appear to be fixed in kf5/plasma5 -- you may wish to upgrade. =:^) (Meanwhile, my previous comment was worrying about semantic-desktop/baloo, whether it was required for plasma5. FWIW, until a few days ago it was indeed officially required for both plasma-desktop-5 and plasma-workspace-5, tho patching out the requirement and skipping build of the plasma components that required it was reasonably trivial and I was doing exactly that. But I can happily report that as of a few days ago, it's officially optional now, at least in live-git-kf5/plasma5, which I run via the gentoo/kde overlay live-git packages. =:^) And gentoo has already enabled the option again as the semantic-desktop USE flag, as well, at least for the live-git builds, tho it'll likely take some time to be released upstream and then to filter down to ~arch and stal^Hble for gentooers. But it's coming in gentoo, and for those who care enough to build it themselves, it's actually possible to use the official option to turn the baloo deps off at build-time, now, instead of having to carry their own patches to do it. So I'm reasonably happy with kde/plasma, now, and shouldn't have to worry about having to switch desktop environments for awhile. =:^)
Hello! This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug has already been resolved in Plasma 5. Accordingly, we hope you understand why we must close this bug report. If the issue described here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham