Re: [arch-general] (now 4.5.5-1) Re: kde-4.5.4 loads kde3 kicker and background (even with ~/.kde & ~/.kde4 removed)
On 01/08/2011 04:21 PM, David Rosenstrauch wrote:
Seriously David, I think it's time for you to give up on kde3 already.
You can't expect the people on the Arch list to help support old, unsupported, and out of date software. The more you bring your Arch box up to date the less and less likely it'll be that old, unsupported software will run on it.
Why not switch to XFCE or something? You can still use some KDE(4) apps if you want, without having to be tied down to the whole environment.
DR
Thanks DR. I'm not looking for help with kde3. (I know it is dead and not supported and I wouldn't bother the list with it) I'm looking for why kde4 is loading the old kde3 kicker & background by default. The issue here has nothing to do with kde3. There is no reason I shouldn't be able to leave it installed and still use kde4. Ever since the June 2008 launch of kde 4.0.4, it has been widely represented that you can have both kde3 and kde4 installed side-by-side and they should not interfere with each other. That's why K3 is /opt based with its user config in ~/.kde while K4 is /usr based with its user config in ~/.kde4. What I need to find is where and why in the kde4.5.5-1 load process the Arch i686 packages are looking for the prior kde config and creating an erroneous ~/.kde4/share/config/kickerrc. I'm not bitching, I'm just trying to find answers to not only solve my problem, but help everyone else out that might be bitten by this. There seems to be some difference in the Arch kde4 packaging between i686 and x86_64. (I know it doesn't make sense...) I have a dozen Arch boxes and I have no problems with the x86_64 kde4 where kdemod3 is still installed. But for some reason on the i686 Dell boxes, I either get kde4 pulling in its plasma panel & the kde3 kicker or I get lockups of kde4 at the end of ksplash (box hardlocks) On my suse boxes with both kde3 and kde4 installed, both i686 and x86_64, kde4 loads without any of this strangeness. That's the only reason it points me to the possibility of an Arch i686 k4 packaging issue. The biggest difference is the Arch install creates the ~/.kde4/share/config/kickerrc which loads the kde3 kicker panel in kde4. That should not happen. The SuSE install of kde4 creates no ~/.kde4/share/config/kickerrc at all (which is correct because kde4 has a 'plasma panel' and no 'kicker' at all) So why the Arch k4 i686 packaging causes a k4 kickerrc to be created at all is a mystery to me and probably worth looking into as it should not be occurring at all. The Arch x86_64 kde4 packaging does not do this either. On my Arch x86_64 boxes, no kickerrc is created: 13:41 nirvana:~> l ~/.kde4/share/config/kicker* ls: cannot access /home/david/.kde4/share/config/kicker*: No such file or directory So something is not correct with the i686 k4 packaging that causes a kde4 kickerrc to be created. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On 01/09/2011 02:45 PM, David C. Rankin wrote:
On 01/08/2011 04:21 PM, David Rosenstrauch wrote:
Seriously David, I think it's time for you to give up on kde3 already.
You can't expect the people on the Arch list to help support old, unsupported, and out of date software. The more you bring your Arch box up to date the less and less likely it'll be that old, unsupported software will run on it.
Why not switch to XFCE or something? You can still use some KDE(4) apps if you want, without having to be tied down to the whole environment.
DR
Thanks DR.
I'm not looking for help with kde3. (I know it is dead and not supported and I wouldn't bother the list with it) I'm looking for why kde4 is loading the old kde3 kicker& background by default.
The issue here has nothing to do with kde3. There is no reason I shouldn't be able to leave it installed and still use kde4. Ever since the June 2008 launch of kde 4.0.4, it has been widely represented that you can have both kde3 and kde4 installed side-by-side and they should not interfere with each other. That's why K3 is /opt based with its user config in ~/.kde while K4 is /usr based with its user config in ~/.kde4.
Not sure I agree with your reasoning here. Given that kde3 is completely dead/unsupported/not-necessarily-even-working at this point, I don't think that anybody can reliably represent anything about what should happen if you still have it installed. I stand by my original (private) email to you: you're best off to give up on kde3 already. Uninstall it and your problems will no doubt go away. You can try installing it again when (if) the time comes that someone makes a reliable set of Trinity packages for Arch. Until that time, you're just making trouble for yourself. And again, I don't see how anybody here on the Arch list can (or should) help you with bugs that are arising from this configuration. DR
KDE3 had done well, in fact I like it most in a mass of DEs. I guess it is the issue of xdg-autostart. Try to remove ~/.config/autostart(I'm not sure where it is :)
On 01/10/2011 10:24 PM, 宋文武 wrote:
KDE3 had done well, in fact I like it most in a mass of DEs.
I guess it is the issue of xdg-autostart. Try to remove ~/.config/autostart(I'm not sure where it is :)
Thank you 宋文武. I'll see if that will work. It might, because basket notepads (fantastic info collection app) is loaded in both k3 and k4 from ~/.config/autostart. It might be that loading basket notepads forces the load of the kde3 runtime which in turn pulls in the kicker panel, background and decorations. Will follow up with that. Let me also correct earlier statements limiting this problem to i686 packages. I have this problem on both i686 and x86_64 boxes. I think it may also be compiz related. Specifically, if you have ever use 'kwin --replace' to drop from compiz back to kwin, I think a default setting gets set for the default wm. When you then launch k4, k4 loads, but then pulls in the k3 settings based on the default set by using 'kwin --replace'. However, I think your thoughts on the issue being in ~/.config may be right on point. I have completely removed ~/.kde and ~/.kde4 and still get the kde3 elements pulled into kde4. I have pulled my hair out trying to find the common-thread, but until now I have completely overlooked ~/.config. Thanks. Ultimately though, there is still the question of "why on Arch?" to be answered. When I find the culprit, I'll pass it on so we can revisit whether there is something in how k4 is packaged for Arch needs tweaking. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Tue, 2011-01-11 at 17:01 -0600, David C. Rankin wrote:
Ultimately though, there is still the question of "why on Arch?" to be answered. When I find the culprit, I'll pass it on so we can revisit whether there is something in how k4 is packaged for Arch needs tweaking.
Yes, why don't we tweak upstream so that an unsupported older version can run alongside. Nothing against kde3, but if you want to use older versions, you're responsible to solve the incompatibilities (which you're trying to do) and perhaps maintain your own patches for whatever is needed. I do not see a need to change Arch's 'official' packaging for this.
On 01/11/2011 05:27 PM, Ng Oon-Ee wrote:
Yes, why don't we tweak upstream so that an unsupported older version can run alongside.
Nothing against kde3, but if you want to use older versions, you're responsible to solve the incompatibilities (which you're trying to do) and perhaps maintain your own patches for whatever is needed. I do not see a need to change Arch's 'official' packaging for this.
I now know what the problem is. The current kde4 build will create a: /var/tmp/kdecache-<user>/ksyscoca and /var/tmp/kdecache-<user>/ksyscoca4 if kde3 is left installed on the system. This is a bug. kde4 shouldn't generate a 'k'de 'sys'tem 'co'nfiguration 'ca'che for kde3 -- period. Removing kde3 does indeed solve the problem, but I notice no requirement to do so on the wiki. Do we want to drop a note there? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Tue, 2011-01-11 at 20:37 -0600, David C. Rankin wrote:
On 01/11/2011 05:27 PM, Ng Oon-Ee wrote:
Yes, why don't we tweak upstream so that an unsupported older version can run alongside.
Nothing against kde3, but if you want to use older versions, you're responsible to solve the incompatibilities (which you're trying to do) and perhaps maintain your own patches for whatever is needed. I do not see a need to change Arch's 'official' packaging for this.
I now know what the problem is. The current kde4 build will create a:
/var/tmp/kdecache-<user>/ksyscoca and /var/tmp/kdecache-<user>/ksyscoca4
if kde3 is left installed on the system. This is a bug. kde4 shouldn't generate a 'k'de 'sys'tem 'co'nfiguration 'ca'che for kde3 -- period. Removing kde3 does indeed solve the problem, but I notice no requirement to do so on the wiki. Do we want to drop a note there?
IMO there's no need, anymore than we should 'require' on the wiki for people to stop using gcc 3.6.
2011/1/12 Ng Oon-Ee <ngoonee@gmail.com>:
On Tue, 2011-01-11 at 20:37 -0600, David C. Rankin wrote:
On 01/11/2011 05:27 PM, Ng Oon-Ee wrote:
Yes, why don't we tweak upstream so that an unsupported older version can run alongside.
Nothing against kde3, but if you want to use older versions, you're responsible to solve the incompatibilities (which you're trying to do) and perhaps maintain your own patches for whatever is needed. I do not see a need to change Arch's 'official' packaging for this.
I now know what the problem is. The current kde4 build will create a:
/var/tmp/kdecache-<user>/ksyscoca and /var/tmp/kdecache-<user>/ksyscoca4
if kde3 is left installed on the system. This is a bug. kde4 shouldn't generate a 'k'de 'sys'tem 'co'nfiguration 'ca'che for kde3 -- period. Removing kde3 does indeed solve the problem, but I notice no requirement to do so on the wiki. Do we want to drop a note there?
IMO there's no need, anymore than we should 'require' on the wiki for people to stop using gcc 3.6.
No, it's worth a note for that kind of thing. We no longer support KDE3, but the wiki can house any kind of information, especially useful ones like this.
On 01/12/2011 12:17 AM, Ray Rashif wrote:
2011/1/12 Ng Oon-Ee <ngoonee@gmail.com>:
On Tue, 2011-01-11 at 20:37 -0600, David C. Rankin wrote:
On 01/11/2011 05:27 PM, Ng Oon-Ee wrote: <snip>
if kde3 is left installed on the system. This is a bug. kde4 shouldn't generate a 'k'de 'sys'tem 'co'nfiguration 'ca'che for kde3 -- period. Removing kde3 does indeed solve the problem, but I notice no requirement to do so on the wiki. Do we want to drop a note there?
IMO there's no need, anymore than we should 'require' on the wiki for people to stop using gcc 3.6.
No, it's worth a note for that kind of thing. We no longer support KDE3, but the wiki can house any kind of information, especially useful ones like this.
I went ahead and dropped a note in the kde wiki: https://wiki.archlinux.org/index.php/KDE#Potential_conflict:_KDE_.3E_4.5.3_w... That reads: Potential conflict: KDE > 4.5.3 will load KDEmod3 kicker, background & decorations As of either kde 4.5.3 or 4.5.4, kde4 will build both: /var/tmp/kdecache-<user>/ksyscoca /var/tmp/kdecache-<user>/ksyscoca4 and then load settings for both kde4 and kdemod3 when kde4 is launched if kdemod3 is left installed. This results in kde4 loading both it's plasma panel and the kde3 kicker panel along with the kde3 background and dialogs in kde4. If you experience this behavior, the only solution found so far is to remove kdemod3. See: https://bugs.kde.org/show_bug.cgi?id=262444 for additional details. If it needs changing or deleting, feel free. It would sure have been useful for me when I started seeing this strangeness to have the reference there because nowhere else have I seen any indication that a removal of kde3 is now required if you use kde4. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
participants (5)
-
David C. Rankin
-
David Rosenstrauch
-
Ng Oon-Ee
-
Ray Rashif
-
宋文武