Bug 218143 - /etc/kde/env/env.sh is not being exec'd when user=root
Summary: /etc/kde/env/env.sh is not being exec'd when user=root
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kdebase
Version: 6
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-12-02 00:16 UTC by Gene Heskett
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-01-26 13:34:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Gene Heskett 2006-12-02 00:16:28 UTC
Description of problem:
The env var that lists the paths to be used by kbuildsycoca, as set in
~/kde/env/env.sh is not being set/exported properly.  The net result is that a
run of kbuildsycoca misses and removes large section of the k-menu.


Version-Release number of selected component (if applicable):
Current FC6 kdebase package.

How reproducible:

Startx as root, add a program with yumex, in this case xmms and xmms*, then run
kbuildsycoca (also as root) in an attempt to add the new program to the menu's.
The menu's will lose all the admin stuffs, the games will not be subsorted,
kde's control center will be missing, among other things.  And the program is
not added to the menu.

Steps to Reproduce:
1. See above
2.
3.
  
Actual results:
crippled menu's.


Expected results:
program added to menu.


Additional info:

I've added a line to set a junk var and export it in /etc/kde/env/env.sh in an
effort to see if it showed up in an env report, it does not, so I have to assume
this file is not being sourced at boot time, or at startx time when running as
root, which I generally do as usual operating procedure here.

I've added the missing env var to my ~/.bashrc, and that works correctly, and my
menu's are now correct, but this sure seems like a kludge to me.

Selinux is disabled as it, even when set permissive, still prevents amanda,
installed from a tarball as I'm a tester, from running.  I have lots of firewall
upstream so I am not too concerned.

Comment 1 Rex Dieter 2006-12-02 04:13:36 UTC
> The env var that lists the paths to be used by kbuildsycoca, as set in
> ~/kde/env/env.sh is not being set/exported properly. 

From discussion on the lists, I think we concluded that XDG_CONFIG_DIRS gets set
properly for non-root users (good), root, however, ends up with an empty
XDG_CONFIG_DIRS (bad).  Therein lies the problem.

I'll see if I can (hopefully) reproduce this on my fc6 boxen on Monday.

Comment 2 Rex Dieter 2006-12-02 04:16:08 UTC
> Startx as root, add a program with yumex, in this case xmms and xmms*, then run
> kbuildsycoca (also as root) in an attempt to add the new program to the menu's.

Did you run that kbuildsycoca *inside* the kde session?  If not, that's the
source of the problem.

In general, you should never have to manually run kbuildsycoca (new apps should
appear automatically without manual intervention), and if you ever do run it by
hand, you need to be careful to do it right. (:

Comment 3 Gene Heskett 2006-12-02 05:48:25 UTC
Did you run that kbuildsycoca *inside* the kde session?  If not, that's the

yes, kde was running everytime I tried that.

Comment 4 Rex Dieter 2006-12-04 15:00:26 UTC
Cannot confirm, WORKSFORME.  

Whether logging in via kdm or just startx, whether a normal user or root, 
$ echo $XDG_CONFIG_DIRS
always returned
/etc/kde/xdg:/etc/xdg

Not sure why that's not working for you with root login.

Comment 5 Rex Dieter 2007-01-26 13:34:11 UTC
At this point, since we're unable to reproduce and since it WORKSFORME (and
most/all? other folks), I'll go ahead and mark this as such.

If you can provide details on how to reliably reproduce, feel free to reopen.


Note You need to log in before you can comment on or make changes to this bug.