I upgraded to KDE 3.1 (from 3.0.5a) soon after it was released, and it was working well until last night, when I did an "emerge update world" and the kdelibs and kdebase packages were upgraded. The next time I started KDE 3.1, the KDE 3.0 splash screen appeared (instead of the usual 3.1 splash screen), and although my desktop appeared, nothing worked. I can start KDE 3.0.5a without any problems. Any suggestions? Reproducible: Always Steps to Reproduce: 1.Upgrade kdebase and kdelibs packages using "emerge update" 2.Restart KDE 3. Actual Results: As above Expected Results: KDE 3.1 should have started normally--please note that the KDE 3.0 splash screen appears instead of the KDE 3.1 screen (the 3.1 screen appeared prior to the upgrade). I posted this problem on forums.gentoo.org this morning, and several other users have experienced the same problem. Please see above URL for the thread.
I can just fill in and confirm this. KDE 3.1 hung while I burned a CD and forced a reset of computer. Next startup kdm gave me the 3.0 splash while starting 3.1, the bad (and dissapointing) news are I did a complete "emerge -e kde" compiled everything belonging to and dependent of kde (took almost 2 days) just notice same behaviour when tried to start 3.1 twenty minutes ago... I wonder if there is some kind of "mixup" between 3.0 and 3.1 in the way they are "sloted" to give place for both. An observation I did when upgrading was 3.0.3 and 3.0.4 suddenly showed up in my kdm menu, although the first version of kde I installed was 3.0.5? Something seam to be out of sync here, just don't know why...
this is also reported in bug #7179 afaics. you've run etc-update and env-update after merging new kde versions? if this (running etc-update or env-update) helps anyone, we should add a einfo to the ebuilds.
I wish it was so simple. It helped me that time to emerge kdelibs-3.1-r2 and run etc-update after (didn't run env-update) to update conf files. But same problem seam to have come back and after emerged all kde apps again I got no conf files to update (ran etc-update to be sure) and env-update don't help either. NO there is something else with this, BUT it all started with the kdelibs-3.1-r1 fix - something must have been overlooked with this, somewere. I'm pretty sure if I go back to kdelibs-3.1 I will have kdm give me the 3.1 spalsh again. Well you will know shortly... I don't know if this have anything to do with it (but in case I got a hard way back...), when my 3.1 crashed, something started to spawn processes finaly using up all available resourses forcing a reboot by reset. I notice now when starting up 3.0.5a I have to wait 5-10 minutes before I can do something because there is intensive activity on my HD (probably swaping) and this comes back... runing top shows kdeinit using lots of cpu as well as kswapd and I have 1G RAM and only run 1 xterm (top) and 1 Konqueror. Will try going back to kdelibs-3.1 now...
The new kdebase and kdelibs cause all kde panel icons to crash, but only after reboot. There are no icons on the desktop. Defualts to KDE 3.0 splash. Only non-kde panel icons work. I have both 3.1 and 3.0 installed. These upgrades must be REMOVED IMMEDIATELY. John
the relevant difference is: @@ -66,8 +69,11 @@ echo "PATH=${PREFIX}/bin ROOTPATH=${PREFIX}/sbin:${PREFIX}/bin LDPATH=${PREFIX}/lib -KDEDIRS=${PREFIX} CONFIG_PROTECT=${PREFIX}/share/config" > ${D}/etc/env.d/49kdelibs-${PV} # number goes down with version upgrade so setting KDEDIRS=/usr/kde/3.1 in /etc/env.d/49kdelibs-3.1 should fix this problem.
The abovementioned change fixed the problem. Thank you! Fix: set KDEDIRS=/usr/kde/3.1 in /etc/env.d/49kdelibs-3.1
I figure all this started with the kdelibs-3.1-r1 fix (http://bugs.gentoo.org/show_bug.cgi?id=7179) which was said about in the changlog [quote]This is a bug/fix almost noone cares about, so no need to upgrade unless you know what this is[/quote] I had this error then upgrading and went back to plain initial kdelibs-3.1 and it worked, did same thing now, had a overnight nap while it compiled and returned to a functioning 3.1 this morning. I would say this fix, r1 was not properly done and I expect there will be a r3 soon, either taking it back to initial state or completely fix this environment thing onces for all.
ok, I added KDEDIRS=/usr/kde/3.1 again to kdelibs-3.1-r2.ebuild. should fix this bug.
That's not a proper fix, just a temporary ace-in-the-hole since this is a serious bug in the stable kde ebuilds. My initial working theory is that this is happening because portage isn't smart enough. You see, I made new revisions for kdelibs and kdebase 3.0.5a together with the ones for 3.1, and all four new revisions (kdelibs-3.0.5a-r1, kdelibs-3.1-r1, kdebase-3.0.5a-r2, kedbase-3.1-r1) are needed to make a dual-kde system work correctly. I'd counted on emerge selecting all four upgrades in the world update, but now it seems it wouldn't have, sorry about that... To test this fix without waiting for compile times, please put the following files in your env.d (overwriting any others), env-update and restart kdm. They are the correct ones from the new revisions and if they work for you you can merge the new reivisions to have them registered in /var/db/pkg. ------- /etc/env.d/49kdelibs-3.1: ------------- PATH=/usr/kde/3.1/bin ROOTPATH=/usr/kde/3.1/sbin:/usr/kde/3.1/bin LDPATH=/usr/kde/3.1/lib CONFIG_PROTECT=/usr/kde/3.1/share/config ------------- /etc/env.d/50kdedir-3.0.5a: ------------- KDEDIR=/usr/kde/3 ------------- /etc/env.d/56kdedir-3.1: ------------- KDEDIR=/usr/kde/3.1 ------------- /etc/env.d/65kdelibs-3.0.5a: ------------- PATH=/usr/kde/3/bin ROOTPATH=/usr/kde/3/bin LDPATH=/usr/kde/3/lib CONFIG_PROTECT=/usr/kde/3/share/config ------------- /etc/env.d/99kde-env: ------------- KDEDIRS=/usr CONFIG_PROTECT=/usr/share/config --------------- Please respond as soon as you test this in the env.d stage (whether it works or not), because I want to know whether to post it as a fix on forusm mailing lists etc. ASAP.
My system has 3.0.4 and 3.1, so I had to use 3.0.4 filenames as per Dan's fix instead of 3.0.5. I really expected to be coming back here to say that it didn't work, as the only file that differed was /etc/env.d/65kdelibs-3.0.4 (/etc/env.d/65kdelibs-3.0.5a). My file had a KDEDIRS= line above CONFIG_PROTECT. It looked like it was pointing to the correct directory for 3.0.4. In any case, I removed it, ran env-update, restarted KDM and everything was back to normal! Go figure.
Yes, that's because the KDEDIRS setting of kde 3.0.x affect kde 3.1 since we remove kde 3.1's KDEDIRS setting. Anyway this is the concise solution: edit /etc/env.d/65kdelibs-3.0.* and remove the KDEDIRS= line (careful, not the KDEDIR= one) for a quick fix, or emerge the latest 3.0.5a revisions. I'll be publicising this as much as I can...
What about removing 3.0.5a and just keep 3.1 on system, will it work aka solve this dilemma as well? If I understand the above right this all happen because both kde 3.0 and 3.1 are onboard, right? So if I don't see any point in this and just want to run 3.1 can 3.0 be safely removed? Or does 3.1 depend on 3.0 in some way? Sounds really weird to me...
Removing kde 3.0 will also solve the problem (provided you remove its env.d files too, which might be left behind). kde 3.1 certainly doesn't depend on it, they are both left on yuor system because they ahve separate SLOTs. However with the new fixes in, they should work just fine together. This is fixed; closing the bug.
*** Bug 16386 has been marked as a duplicate of this bug. ***
I emerged 2 days ago. I have tried all that was suggested here - except removing KDE 3.1 and 3.0.5, yet the problem is not solved. I have cleaned up /tmp, removed my .kde* files. I also get the error "could not start process unable to create io-slave klauncher said: Unknown protocol "file"
