If kde-3.5 and kde-4.x are installed in parallel, startkde does not appropriately filter XDG_DATA_DIRS for other kde versions. The result is that kde-3.5 happily searches through /usr/kde/4.1/share and thus kde4 apps show up in a kde3 session. More seriously though is the fact that, depending on the path order, kde3 tries to use the now registered kde4 apps instead of the working kde3 ones and will fail. I have included updated patches from both the 3.5.10 and the 4.1.1 ebuilds which will properly fix this problem. I have also fixed a corner case with the filtering sed rule which did not catch every kde occurrence (last element was always missed). Reproducible: Always Steps to Reproduce: 1. Install e.g. kde-3.5.10 and kde-4.1.1 in parallel (works with 4.0.x as well) 2. start kde-3 2. click a picture or a folder Alternatively have a look through the start menu. Actual Results: KDEInit will complain that it was unable to launch some kde-4 app like Dolphin instead of Konqueror. start menu: it will look pretty messed up, containing a mix of kde3 and kde4 with missing icons as well. Expected Results: The proper kde-version app is being launched and the start menu contains only the appropriate apps for that particular version.
Created attachment 165484 [details, diff] updated gentoo-startkde4.patch
Created attachment 165485 [details, diff] updated startkde-3.5 patch
One more note: in order to fix ones kde home directory, the only solution I have come up with so far is to save all revelant data, wipe it clean and reconfigure everything from scratch. Otherwise you will still have the cached kde4 remnants.
Created attachment 165521 [details, diff] kde4 startkde sed rule(s) should now be bullet proof and cover all corner cases.
Created attachment 165523 [details, diff] kde3 startkde sed rule(s) should now be bullet proof and cover all corner cases.
*** Bug 237650 has been marked as a duplicate of this bug. ***
I update to the latest version of kde-base/kdebase-startkde from the kde-testing overlay and I still can not start KDE 3.5.10 without KDE 4.1.1 showing up.
Both startkde scripts from kde-3 and kde-4 need updating. So far only the kde4 one has been updated in kde-testing which will only affect starting kde-4. So you'll either have to wait until the kde-3 startkde fix hits portage or you apply one of the changes by hand for the meantime. Edit /usr/kde/3.5/bin/startkde and insert the following line without the quotes before the "# Gentoo part ends": "export XDG_DATA_DIRS=${_KDEDIR}/share:$(echo ${XDG_DATA_DIRS} | sed 's/$/:/g;s#/usr/kde/[^/]*/share/\?:##g;s/:$//g')" That should work just fine. When the fix hits portage and you recompile the appropriate package, startkde will be overwritten with the official version.
should we open an official bug for 3.5?
No need to open a new bug report. Please be a bit more patient, the patches will be included soon.
I applied the rest of this to the KDE 4 stuff in the overlay which is destined for the tree. I will look at the KDE 3.5 stuff soon and get that in there.
OK - I have committed kdebase-startkde-3.5.10-r1 which should address these issues along with the KDEDIRS issue. I am marking this bug as fixed but would appreciate feedback on any problems anyone hits with the new startup scripts.
This patch lead to stop work of many applications in kde3. In my system I observed knemo not working, amarok crashes at startup, and some modules in control center. So maybe there should be changed something.
I can confirm that neither media-sound/amarok x11-themes/crystal doesn't work. dev-util/kdevelop complains about missing plugins, and media-video/kaffeine can't find xine_part.desktop. All these apps are installed in the FHS compliant directories.
This is actually unrelated to this bug. What happened is: the changes proposed here got merged together with other changes and those unfortunately broke a few things. The problem is that "/usr" got removed from the KDEDIRS env variable. That's causing all the trouble. Until it hits portage, edit /usr/kde/3.5/bin/startkde and add "/usr" to KDEDIRS. Should look like this: "export KDEDIRS=${_KDEDIR}:/usr:/usr/local" I'll try to contact one of the devs and let them know.
OK - I added a -r2 with the old KDEDIRS in place. I try to combine multiple pending patches where possible to reduce recompilation of packages...
Please reopen this bug, as for me its now broken again. With kdebase-startkde-3.5.10-r1 I got my KMenu back. But now after upgrading to kdebase-startkde-3.5.10-r2 ist completely empty again. Other things that are back to strange with -r2: something seems to start nepomukserver and that starts a few other kde4 things into the kde3-session. One one them is plasma that results in the kde3-kicker being move to the middle of the screen because of kde4 xinerama bug. After killall-ing plasma the desktop seems to work normal except for the empty KMenu and kcontrol without any modules. (With startkde-3.5.10-r1 kcontrol worked normal, I didn't even need to reemerge it) I'm using ~amd64 kde-3.5.10 from the main tree and have kde-4.1.1 from kde-testing installed.
Could you please run this "env | grep -Ei "^(KDEDIRS|XDG_DATA_DIRS|ROOTPATH|PATH|LDPATH)"" while being logged in kde and post the output here? Unfortunately due to the fact that startkde did not set XDG_DATA_DIRS for quite some time, your ~/.kde dir got mixed up. Could you please try to rename your .kde directory, revert all changes you made to startkde or anything related and start a new (clean) kde session and see if everything is fine then? I suspect your .kde directory is causing the trouble here. Thanks.
PATH=/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.2.4:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/bin:/usr/qt/3/bin:/usr/games/bin KDEDIRS=/usr/kde/3.5:/usr:/usr/local XDG_DATA_DIRS=/usr/share:/usr/share ROOTPATH=/usr/kde/3.5/sbin:/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.2.4:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/bin:/usr/qt/3/bin:/usr/games/bin LDPATH=/usr/kde/3.5/lib:/usr/kde/3.5/lib64:/usr/kde/3.5/lib32: ~ $ ls -ld .kde* lrwxrwxrwx 1 xxxx xxxx 7 Sep 29 21:31 .kde -> .kde3.5 drwxr-xr-x 4 xxxx xxxx 93 May 18 2007 .kde3.5 drwx------ 4 xxxx xxxx 77 Sep 26 06:39 .kde4 -rw------- 1 xxxx xxxx 450 Jun 15 05:49 .kderc Trying to fix this I removed the .kde4 directory several times, but if the broken session (with nepomuk / plasma / etc) starts it is recreated. I did not try to delete anything from the .kde3.5 because nothing there looked obvious wrong, but I did not look very far. I have not changed anything in startkde / startx / etc. Only removed the -br from the X command line from kdmrc ;) I will try a new kde session tomorrow.
Ok, the problem is that XDG_DATA_DIRS is missing /usr/kde/3.5/share which I cannot quite explain myself because everything looks right. By the way, the problem with the kde-3 session is not the ~/.kde4 directory. The problem lies within ~/.kde3 because several kde4 apps got already registered/cached and have a higher priority than their kde3 counterparts. Thus those apps get started. Could you please rename your ~/.kde3.5 directory and start a fresh kde3 session. Does it work as expected? Is XDG_DATA_DIRS set appropriately, meaning does it contain /usr/kde/3.5/share as its first element? If this does not work, please check/report the following: 1) grep XDG_DATA_DIRS /etc/env.d/* 2) You may have stale kde env files lying around: ls /etc/env.d/*kde* (only 45kdepaths-3.5, 45kdepaths-4 should come up) 3) check start /usr/kde/3.5/bin/startkde is indeed the right version 4) in the text console (not in X): "env | grep -Ei "^(KDEDIRS|XDG_DATA_DIRS|ROOTPATH|PATH|LDPATH)" Sorry for the trouble. But I doubt the startkde script is causing any problems 'cause it's working fine on my machine and there is no reason why all the others env variables get set right and XDG_DATA_DIRS is not.
Sorry, meant: 3) check /usr/kde/3.5/bin/startkde is indeed the right version
>The problem lies within ~/.kde3 because several kde4 apps got already >registered/cached and have a higher priority than their kde3 counterparts. I first thought it was because a kde4-amarok had destroyed something important. Because that would have been my own fault, I did not report this to bugzilla. But then with startkde-3.5.10-r1 it worked again and startkde-3.5.10-r2 returned to the broken state. So now I thought this might be a bug in the gentoo patches. >Could you please rename your ~/.kde3.5 directory and start a fresh kde3 >session. Does it work as expected? Is XDG_DATA_DIRS set appropriately, meaning >does it contain /usr/kde/3.5/share as its first element? I just created a new user and logged into this account. The kde-3.5 firstrun wizard started correct, then the normal 3.5 slash screen. But after the desktop came up, the that thing as with my normal account happend: the KMenu was empty and plasma started up. But as I did have my second monitor turned on this time, I noticed that additional to the 3.5-kicker a plasma panel with a second KMenu was started. This 4er Menu had entries. > 1) grep XDG_DATA_DIRS /etc/env.d/* /etc/env.d/43kdepaths-4.1:XDG_DATA_DIRS="/usr/share:/usr/share:/usr/local/share" /etc/env.d/43kdepaths-4.1:COLON_SEPARATED="XDG_DATA_DIRS" /etc/env.d/45kdepaths-3.5:XDG_DATA_DIRS="/usr/share:/usr/kde/3.5/share:/usr/local/share" /etc/env.d/45kdepaths-3.5:COLON_SEPARATED="XDG_DATA_DIRS" > 2) You may have stale kde env files lying around: ls /etc/env.d/*kde* > (only 45kdepaths-3.5, 45kdepaths-4 should come up) I have 43kdepaths-4.1 instead. This file belongs to kde-base/kdelibs-4.1.1-r4 from the kde-testing overlay. equery check says everthings is OK with this package. (I have seen that kde-4.1 was mentioned in the description and so assumed that it was OK to use this bug, even if the kde comes from an overlay, because 4.1 is not in the main tree yet.) > 3) check start /usr/kde/3.5/bin/startkde is indeed the right version This file belongs to kde-base/kdebase-startkde-3.5.10-r2 from main tree. [ Checking kde-base/kdebase-startkde-3.5.10-r2 ] * 15 out of 15 files good So I assume its OK. ;) > 4) in the text console (not in X): "env | grep -Ei >"^(KDEDIRS|XDG_DATA_DIRS|ROOTPATH|PATH|LDPATH)" PATH=/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/bin:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin KDEDIRS=/usr:/usr/local:/usr/kde/3.5 XDG_DATA_DIRS=/usr/share:/usr/local/share:/usr/kde/3.5/share > But I doubt the startkde script is causing any problems [...] Its just that the -r1 version worked and -r2 regressed for me again that I commented on this bug. If you need me to test anything else, just ask.
Ah, okay. I see what's the problem is. You've got kde 4.1.1 installed non-prefixed whereas kde 3.5.10 is installed prefixed. The way things currently are, this could definitely cause trouble, even though kde-3 is first in all important env variables. I don't know if it's even meant to be possible to do that at all. (Marcus? Actually I would suggest making the non-prefixed install unavailable if a prefixed kde is around.) Hm... this still does not explain why XDG_DATA_DIRS is missing the kde-3 entry when you start a kde3 session. Ok the more I think about it, this really shouldn't be mixed. Your kde-4.1 is installed under /usr which is naturally included in the KDEDIRS env variable because not all kde apps install under the prefixed kde dir. So what's happening now is that kde-3 finds your kde-4 apps, registers them and due the fact some of them get a higher priority, those get started as well or instead. I am sorry but I currently have no idea how to easily fix this. Removing /usr from KDEDIRS will cause more trouble for you as some kde-3 apps that are not installed under /usr/kde/3.5 will stop functioning. Actually I'd suggest installing kde-4.1 prefixed. This way everything should work just fine. Sorry. :-( @Marcus: I'd suggest adding a blocker to the kde-4 ebuilds or eclass preventing users from installing a non-prefixed kde-4 next to a prefixed kde-3. Or do you have any patches or ideas for this...?
No need to apologize to much. Using an unstable system with additional overlays just means that sometimes it will break. ;) Yes, I have kde-4 installed without a prefix, not really intentional but just because I thought that the new useflag 'kdeprefix' is some kind of new optional way to get kde installed into somewhere like /opt. I will just set this useflag and remerge kde-4. Tomorrow is the scheduled release of 4.1.2 so I would have build a new one anyway. :) Thanks for explaining.
Seems this is still not solved. As it seems the problem affects USE="kdprefix", I'll be able to check it as I'll be updating my box tonight.
I have just seen that kde 4.1.2 hit portage- even though still masked. I think before even more people run into this, there should be some way to block the prefixed and non-prefixed side-by-side install. Otherwise I can imagine that people start testing with USE="-kdeprefix" while kde 3.5.x is still around and things will get hairy from there on: messed up ~/.kde, recompile and so on. By the way. I am not 100% sure but I bet the problem with prefixed 3.5 and non-prefixed 4.1 is related to xdg.sh. The 4.1.x version sets XDG_DATA_DIRS by itself whereas the 3.5.x one leaves it alone. So when 4.1 is installed non-prefixed, this gets copied to /etc/env/xdg.sh. I think somewhere down the read, this gets executed by some part of kde 3.5.x and thus we end up having the wrong XDG_DATA_DIRS.
@Torsten: do you still have your original setup installed or have you already re-emerged everything prefixed? In case you haven't, could you please give me the output of the following either here or directly by mail...? 1) equery files kdebase-startkde (should output both for 3.5.10 and 4.1.1) 2) Is there a /usr/env directory? If yes, what does it contain? 3) cat /usr/kde/3.5/env/xdg.sh 4) find / -iname xdg.sh (ignore any permission denied or other error msgs) I have a few ideas what the problem might be even though I doubt it can be solved sanely other then by blocking mixed non-prefixed/prefixed installs.
forgot the following: 5) just for testing: rename /etc/kde to something different and start a fresh kde 3.5 session. Is everything correct...? What does "env | grep -Ei "^(KDEDIRS|XDG_DATA_DIRS|ROOTPATH|PATH|LDPATH)" say?
> @Torsten: do you still have your original setup installed or have you already > re-emerged everything prefixed? I did not have the time yesterday, as I was still trying to figured out how to get layman to use the 4.1.2 branch from kde-testing. ;) > 1) equery files kdebase-startkde > (should output both for 3.5.10 and 4.1.1) [ Searching for packages matching kdebase-startkde... ] * Contents of kde-base/kdebase-startkde-3.5.10-r2: /etc /etc/X11 /etc/X11/Sessions /etc/X11/Sessions/kde-3.5 /usr /usr/kde /usr/kde/3.5 /usr/kde/3.5/bin /usr/kde/3.5/bin/startkde /usr/kde/3.5/env /usr/kde/3.5/env/xdg.sh /usr/kde/3.5/shutdown /usr/share /usr/share/xsessions /usr/share/xsessions/kde-3.5.desktop * Contents of kde-base/kdebase-startkde-4.1.1: /etc /etc/X11 /etc/X11/Sessions /etc/X11/Sessions/kde-4.1 /etc/kde /etc/kde/shutdown /etc/kde/shutdown/agent-shutdown.sh /etc/kde/startup /etc/kde/startup/agent-startup.sh /etc/kde/startup/xdg.sh /usr /usr/bin /usr/bin/safestartkde /usr/bin/startkde /usr/share /usr/share/doc /usr/share/doc/kde /usr/share/doc/kde/kdebase-startkde-4.1.1 /usr/share/doc/kde/kdebase-startkde-4.1.1/README.bz2 /usr/share/xsessions /usr/share/xsessions/KDE-4.desktop > 2) Is there a /usr/env directory? If yes, what does it contain? bash: cd: /usr/env: No such file or directory > 3) cat /usr/kde/3.5/env/xdg.sh export XDG_CONFIG_DIRS="/usr/kde/3.5/etc/xdg" > 4) find / -iname xdg.sh > (ignore any permission denied or other error msgs) treogen ~ # locate -i xdg.sh /etc/kde/startup/xdg.sh /usr/kde/3.5/env/xdg.sh /boot/usr/kde/3.5/env/xdg.sh My /boot partition is rather big, as it contains a complete gentoo installation as a "rescue" system. But that kde installation (still 3.5.6) should not be messing with anything, as both systems are completely separated. They don't share a /home or anything else. > I have a few ideas what the problem might be even though I doubt it can be > solved sanely other then by blocking mixed non-prefixed/prefixed installs. I dont have any problems with such a solution, as my non-prefixed install was more or less just caused by missunderstanding what use=+kdeprefix meant. Installing a prefixed 4.1.2 is still on my TODO list for one of the next few days. :) > 5) just for testing: rename /etc/kde to something different and start a fresh > kde 3.5 session. Is everything correct...? What does "env | grep -Ei > "^(KDEDIRS|XDG_DATA_DIRS|ROOTPATH|PATH|LDPATH)" say? * move /etc/kde away * env-update * created a new user, restarted kdm * login -> kpersonalizer did its firstrun -> mixed desktop again but: the 3.5-KMenu was filled this time the 4.1-KMenu was also filled, but the icons from the folders where missing, the programs themself did have icons grep says: PATH=/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/bin:/usr/qt/3/bin:/usr/games/bin KDEDIRS=/usr/kde/3.5:/usr:/usr/local XDG_DATA_DIRS=/usr/kde/3.5/share:/usr/share:/usr/local/share ROOTPATH=/usr/kde/3.5/sbin:/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/bin:/usr/qt/3/bin:/usr/games/bin LDPATH=/usr/kde/3.5/lib:/usr/kde/3.5/lib64:/usr/kde/3.5/lib32:
Ok this is absolutely strange. When you start a kde-3.5 session, nothing should start anything from /etc/kde/startup/ except kde-4.1's startkde script which contains a few extra lines for this. I double checked everything- nothing. No matter what- thanks a lot (!) for your patience and help. Even if we figure out, why the 4.1 xdg.sh gets executed, it'll only partially fix those issues. You'll still end up with a mixed desktop as long as /usr is in KDEDIRS which it needs to be or other apps will stop working. So I can only hope users get stopped from doing those mixed installs otherwise once kde 4.1.2 is released, this bug might fill up. ;-) By the way, I suggest waiting just a bit longer with remerging kde because as you may have seen, those kde-4.1.2 ebuilds hit portage today and as soon as this version is released (any time now), there is no need for using the overlay anymore.
I was just in contact with some akregator dev... and what I figured is the following: - Setting KDEDIR/KDEDIRS is deprecated/should not be used. When these variables are not set, kde3 apps use kde-config --prefix and kde4 apps use kde4-config --prefix to get their respective directories. So I tried the following: I removed the export KDEDIR in the startkde script of kde3 -> no more kde4 stuff started in kde3. I stumbled across this issue by a very related problem: - start kde4 - run yakuake (kde3 version) - verify that KDEDIR variables are set for kde3 - start akregator4 -> segfault. This doesn't work because the kdedirs is set for kde3, which prevents kde4 apps from function correctly. So the proper fix is to remove export KDEDIR
> -> segfault. This doesn't work because the kdedirs is set for kde3, which > prevents kde4 apps from function correctly. So the proper fix is to remove > export KDEDIR ^^^^^^ you mean KDEDIRS? to remove export KDEDIRS from: kdebase-startkde:3.5 /usr/kde/3.5/bin/startkde) and delibs:3.5 /etc/env.d/ kdepaths ? export KDEDIR (witout 's') looks required in both (3.5, 4.1) startkde scripts to me and they should be set as appropriate (in KDE4.1 to /usr or /usr/kde/4.1 based on kdeprefix USE flag and to /usr/kde/3.5 in KDE3). Definitely KDEDIRS shouldn't be pointed at any of /usr or /usr/kde-XXX as it should be treated as 'external' KDE resource location (like in home directory, for developers to test plugins/apps/themes without the need to interfere in kde base install) That's my view on that.
Simply setting USE="kdeprefix" solved all problems I had running KDE 3.5.9 and KDE 4.1.2. Not having it set messed up my KDE 3 config. As most users will have KDE 3.5.* installed simultaneously with KDE 4.1.*, I think, at least for the “transitional phase”, USE="kdeprefix" should be set by default to avoid problems.
(In reply to comment #32) > > -> segfault. This doesn't work because the kdedirs is set for kde3, which > > prevents kde4 apps from function correctly. So the proper fix is to remove > > export KDEDIR > ^^^^^^ > > you mean KDEDIRS? > I talked about both KDEDIR and KDEDIRS. Clashes are inevitable if you set them. The problem is, that these vars don't differentiate between kde3 and kde4 and apps from both kde3 and kde4 read them. So If you set KDEDIR/KDEDIRS for kde3, then kde4 apps have problems (like the segfault I reported above). Likewise if you do it the other way round. You are completely right - these vars are intended for development use so you can have your private environment in your home dir. gentoo really should not use these at all Cheers P.s. I'm confused about the difference between KDEDIR and KDEDIRS. That's why I unset both of them and it presumably worked
OK I have been looking into this for most of the afternoon and think I have found a solution that seems to keep everything working nicely with -kdeprefix (the desktop I am running). I have tested with kword, digikam and a few other KDE 3 apps I have laying around. Please try adding a file called /usr/kde/3.5/share/config/kdeglobals with the following contents, [Directories][$i] dir_lib=/usr/lib64 dir_apps=/usr/share/applnk dir_data=/usr/share/apps dir_icon=/usr/share/icons dir_module=/usr/lib64/kde3 dir_config=/usr/share/config dir_kcfg=/usr/share/config.kcfg dir_exe=/usr/bin dir_mime=/usr/share/mimelnk dir_services=/usr/share/services dir_servicetypes=/usr/share/servicetypes dir_templates=/usr/share/templates I have not isolated which ones are absolutely necessary, but with no KDEDIR/KDEDIRS exported and a kdeglobals file containing these parameters then third party KDE 3 applications work for me. If this seems like a good solution I will release a rev bumped kdebase-startkde that installs this kdeglobals file. Thanks for all the feedback. Hopefully this is a good solution to this issue for everyone. I have learnt lots of new things about KDE startup and environment variables these last few weeks!
Forgot to say, s:lib64:lib if you are on a 32 bit system. Obviously the final patch will be able to take care of this for people.
I have committed kdebase-startkde-3.5.10-r3 - hopefully third time lucky. Thanks to everyone who has commented here. I have spent much of the day testing and reading and so I am hoping we have got to the bottom of this issue now. Please let me know how this works for you.
Result from kdebase-startkde-3.5.10-r3: (both with a new blank user and my normal account, I still have the non-kdeprefix'ed 4.1.1 installed) * 3.5-KMenu is filled, seems to contain most kde programs twice * on the desktop the system and the home icon are ok, the trash icon is broken * plasma still starts in a kde-3.5 session I have right now started the upgrade to a kdeprefixed 4.1.2 and will report the result when this finishes...
I'm sorry to say but unfortunately even the latest versions do not work, I have kde 4.1.2 emerged prefixed and the only version of this package that appears to work for me on my box are the original 3.5.10 and 4.1.2, although honestly , I don't know how well it works on kde 4.1.2 login.
I have to say that =kdebase-startkde-3.5.10 works for me as far as KDE 3.5 is concerned (haven't tested KDE 4 though). All versions above (i.e -r2/-r3) result in these strange menu entries and konqueror menus.
OK, kde has finished compiling and I found some time to test this. Both kde-3.5 and kde-4.1 sessions work normally for me with kdebase-startkde 3.5.10-r3 and 4.1.2-r1. I did not see any duplicate entries, but some of entries in the kde-4.1 menu (using the 'classic' style) where missing their icons. Also the trash icon in 3.5 is still only a blank page instead of the normal thrashcan. But I think these icon bugs are probably my own fault, as I did not clean .kde* for these tests and I also had several betas of kde4 installed on this system. (I even just upgraded from nonprefixed to prefixed without unmerging the nonprefixed version. Did work without any errors.) For my troubles it looks like switching the kdeprefix useflag on really was the correct solution. So I'm with suggestion from Matthias in Comment #30: Prevent mixing prefixed and nonprefixed installs or at least warn very loud that this is very likely not what the user really wants.
startkde-3.5.10-r3 did'nt solve my problem. When I start a kde-3.5.10 session from kdm-4.1 kde is unuseble. Kcontrol is empty and the menu is filed with kde-4 stuff. Mounting a usb-device will start dolphin and so on. "env | grep -Ei "^(KDEDIRS|XDG_DATA_DIRS|ROOTPATH|PATH|LDPATH)"" in 4.1 shows: PATH=/usr/kde/4.1/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.1:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/qt/3/bin:/opt/vmware/workstation/bin:/home/zigulle/bin KDEDIRS=/usr:/usr/local:/usr/kde/4.1:/usr/kde/3.5 ROOTPATH=/usr/kde/4.1/sbin:/usr/kde/4.1/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.1:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/qt/3/bin:/opt/vmware/workstation/bin XDG_DATA_DIRS=/usr/kde/4.1/share:/usr/share which seems to be ok. But in 3.5.10: PATH=/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/bin:/usr/qt/3/bin:/usr/games/bin KDEDIRS=/usr/kde/3.5:/usr:/usr/local XDG_DATA_DIRS=/usr/kde/4.1/share:/usr/share:/usr/local/share ^^^^^ ROOTPATH=/usr/kde/3.5/sbin:/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/bin:/usr/qt/3/bin:/usr/games/bin LDPATH=/usr/kde/3.5/lib:/usr/kde/3.5/lib64:/usr/kde/3.5/lib32: I emerged all stuff with the kdeprefix use-flag. I didn't have a clue, why die XDG_DATA_DIR isn't set right. export XDG_DATA_DIRS=/usr/kde/3.5/share:/usr/share:/usr/local/share & kcontrol will give me a useble kcontrol with entries. If you need more details, please let me known.
When did you emerge --sync? kdebase-startkde-3.5.10-r3 should give a commented out KDEDIRS and so not set it. XDG_DATA_DIRS=${_KDEDIR}/share which resolves to _KDEDIR=/usr/kde/3.5 from the patch. kdelibs-3.5.10-r1 removes the KDEDIRS from the environment file too. Did you try env-update, logging out and back in after this? It seems like may be one of these updates is missing from your installation. I have checked and rechecked. Pasting /usr/kde/3.5/bin/startkde (the Gentoo lines at the start) may help but I suspect you just need an emerge sync.
> When did you emerge --sync? kdebase-startkde-3.5.10-r3 should give a commented > out KDEDIRS and so not set it. XDG_DATA_DIRS=${_KDEDIR}/share which resolves to > _KDEDIR=/usr/kde/3.5 from the patch. kdelibs-3.5.10-r1 removes the KDEDIRS from > the environment file too. Did you try env-update, logging out and back in after > this? Last sync is 10 min ago. Did an emerge -1 =kdebase-startkde-3.5.20-r3; env-update, logging out and logging in serveral times but no result. Here my output of env | grep -Ei "^(KDEDIRS|XDG_DATA_DIRS|ROOTPATH|PATH|LDPATH)" PATH=/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.1:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/qt/3/bin:/opt/vmware/workstation/bin:/home/zigulle/bin KDEDIRS=/usr:/usr/local:/usr/kde/4.1:/usr/kde/3.5 XDG_DATA_DIRS=/usr/kde/4.1/share:/usr/share ROOTPATH=/usr/kde/3.5/sbin:/usr/kde/3.5/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.1:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin:/usr/qt/3/bin:/opt/vmware/workstation/bin LDPATH=/usr/kde/3.5/lib:/usr/kde/3.5/lib64:/usr/kde/3.5/lib32: again and the first lines of /usr/kde/3.5/bin/startkde: # Gentoo: setup environment, filter other slotted KDE installs from PATH _KDEDIR=/usr/kde/3.5 #export KDEDIRS=${_KDEDIR}:/usr:/usr/local export PATH=${_KDEDIR}/bin:$(echo ${PATH} | sed 's/$/:/g;s#/usr/kde/[^/]*/s\?bin/\?:##g;s/:$//g') export ROOTPATH=${_KDEDIR}/sbin:${_KDEDIR}/bin:$(echo ${PATH} | sed 's/$/:/g;s#/usr/kde/[^/]*/s\?bin/\?:##g;s/:$//g') export LDPATH=/usr/kde/3.5/lib:/usr/kde/3.5/lib64:/usr/kde/3.5/lib32:${LDPATH} export XDG_DATA_DIRS=${_KDEDIR}/share:$(echo ${XDG_DATA_DIRS} | sed 's/$/:/g;s#/usr/kde/[^/]*/share/\?:##g;s/:$//g') # Gentoo part ends I manualy edit /usr/kde/3.5/bin/startkde and set XDG_DATA_DIRS static to the right values but it doesn't solve the problem (same output von env... as above. Maybe /usr/kde/4.1/bin/startkde ist started by kdm when I start a kde3.5 session? I don't know how to test it. find / -name startkde /usr/kde/3.5/bin/startkde /usr/kde/4.1/bin/startkde This are the only startkde-files on the system.
Solved my Prolbem, after updatig kdelibs to kdelibs-3.5.10-r1 and kdelibs-4.1.2-r1 kdedirs isn't set anymore. kde3.5 works fine kde4.1 not tested jet.
Marking this bug as fixed - hopefully it is for good this time. If not it may be worth opening a new bug that is more targeted at the new issues.
Is this problem expected to exist for 3.5.9? Is it worth creating 3.5.9-r1 with the patchset for 3.5.10-r3? I have filed a bug #242856 for this. I would like to install 4.1 alongside my current 3.5.9 installation.
(In reply to comment #46) > Marking this bug as fixed - hopefully it is for good this time. If not it may > be worth opening a new bug that is more targeted at the new issues. > Well it's not fixed; I opened a new bug: http://bugs.gentoo.org/show_bug.cgi?id=243062
Similar behavior if you try to have KDE3 and 4 together and you use startx. http://bugs.gentoo.org/show_bug.cgi?id=290676
