| Summary: | empty left pane in kdesu kcontrol | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Denis Prost <denis.prost> |
| Component: | tdebase | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | CONFIRMED --- | ||
| Severity: | minor | CC: | bugwatch, darrella, denis.prost, ktbz.aoneshot.eliddell, slavek.banko |
| Priority: | P5 | ||
| Version: | 3.5.13.x [Trinity] | ||
| Hardware: | i386 | ||
| OS: | All | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 1397 | ||
|
Description
Denis Prost
2010-10-01 03:05:38 CDT
Is the sudo-trinity package installed? dpkg -l|grep sudo ii libgksu2-0 2.0.13~pre1-1 library providing su and sudo functionality rc sudo 1.7.2p7-1 Provide limited super user privileges to specific users ii sudo-trinity 1.7.2p7-1 Provide limited super user privileges to specific users OK, I can replicate the problem. Workaround for now is to start kcontrol itself as a normal user, then click the "Administrator Mode" button if a control module needs root access. Initial thought is that sudo strips kdedirs or a similar variable from the environment, causing kcontrol to be unable to locate the .desktop files that describe the installed control modules. I just wanted to change the look of kde apps running as root, so the workaround you propose can't be used for that. But this is definitely not an emergency matter ! I had a problem very similar to this except that it didn't involve kdesu. It turned out that I needed to set the XDG_ environment directories (XDG_CONFIG_DIRS, XDG_CONFIG_HOME, XDG_DATA_DIRS, and XDG_DATA_HOME) for the affected user to get kcontrol to work right. Maybe the problem is that these aren't set for the superuser? Is this report still valid? For this I have a simple observation: ssh -CX user@test-machine /opt/trinity/bin/kcontrol KControl is ok. ssh-CX root@test-machine /opt/trinity/bin/kcontrol Left panel in KControl is empty. The same machine, different user => normal user × root. Interesting. I tried the following: ssh -CX warbler kfmclient openProfile filemanagement The KDE4 version of konqueror opened rather than the Trinity version. That indicates a $PATH problem. I have KDE4 installed in /usr and Trinity in /opt/trinity. When I ssh into the other system without launching apps in the same command, then the session correctly sources variables from /etc/profile.d scripts. Then when I run kcontrol or kfmclient openProfile filemanagement everything functions correctly and I see icons as expected and the kcontrol left panel. Trying to ssh and run apps in the same command suffers from the problem of not correctly setting environment variables and $PATH. Is this a Trinity corner case issue or Not Our Problem? Although I confirm the problem exists when using ssh and Trinity is installed in a location other than /usr, the original problem description focused on local machines. I can't replicate the problem within a local machine. (Odpověď na komentář #9)
> Although I confirm the problem exists when using ssh and Trinity is installed
> in a location other than /usr, the original problem description focused on
> local machines. I can't replicate the problem within a local machine.
Yes, I know, the problem was originally reported for local launching. However, it is clear that with the remote launching although both users have the same initial conditions, behavior is different.
I assume that the cause of the problem may be the same in both cases - as remote launching, and originally reported local launching.
|