I installed gentoo. I emerged xfree I emerged kde Somewhere in that process, the following entry was added to /etc/rc.conf: XSESSION="kde-3.0.2" This isn't very useful, however, as when I ran startx, I got twm, not KDE. The reason is because the name is wrong: tank Sessions # pwd /etc/X11/Sessions tank Sessions # ls -al total 16 drwxr-xr-x 2 root root 4096 Aug 24 16:12 . drwxr-xr-x 15 root root 4096 Sep 10 19:05 .. -rwxr-xr-x 1 root root 2187 Sep 8 19:10 Xsession -rwxr-xr-x 1 root root 36 Aug 24 16:11 kde-3.1.2 XSESSION should have been set to "kde-3.1.2". Reproducible: Always Steps to Reproduce: 1. Install gentoo-1.4-rc4 [I think] 2. emerge xfree 3. emerge kde 4. startx Actual Results: The X server starts, with "twm" as the window manager. Expected Results: KDE should have started. I don't know which package actually broke the /etc/rc.conf file. I would guess it was the "emerge kde", but .... I'd be happy to fix the package, but I haven't had time to read up on how emerge / ebuild / etc. works. So far, I've just been winging it. emerge info follows: Portage 2.0.49-r3 (default-sparc64-1.4, gcc-3.2.3, glibc-2.3.1-r4, 2.4.21-sparc- r1) ================================================================= System uname: 2.4.21-sparc-r1 sparc64 sun4u ccache version 2.2 [enabled] ACCEPT_KEYWORDS="sparc" AUTOCLEAN="yes" CFLAGS="-mcpu=ultrasparc -O3 -pipe" CHOST="sparc-unknown-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share /config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-mcpu=ultrasparc -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/d istributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="sparc apm avi crypt cups encode fbcon foomaticdb gif jpeg libwww mad mikmod mpeg ncurses nls oss png pdflib spell truetype xv xml2 xmms zlib gdbm berkdb sl ang readline arts guile X sdl tcpd pam ssl perl python esd imlib oggvorbis motif opengl -java -gnome -gtk qt kde"
run "startkde" instead of "startx" on the command line. If you have any other problems, feel free to reopen the bug.
Todd: The "startkde" script is somehow called by "startx". I tried running "startkde" once I discovered it existed, and before I spent ~1-2 hours last night tracking this down. Here's a snippet of [hand-typed] output [can't cut and paste at the moment]: barnett@tank barnett $ startkde xsetroot: unable to open display '' xset: unable to open display "" startkde: Starting up... startkde: Running kpersonalizer... kwin: cannot connect to X server kpersonalizer: cannot connect to X server kpersonalizer: cannot connect to X server kpersonalizer: cannot connect to X server kpersonalizer: cannot connect to X server kpersonalizer: cannot connect to X server kpersonalizer: cannot connect to X server kpersonalizer: cannot connect to X server kpersonalizer: cannot connect to X server kpersonalizer: cannot connect to X server ^C Without using "startx" with kde-3.1.2, the X server is not started. Please either: 1. tell me: a. how the emerge system works, and b. how to update the kde emerge package so that c. /etc/rc.conf gets a proper XSESSION entry, or 2. Please fix the kde emerge package such that "XSESSION=kde-3.1.2" is added to /etc/rc.conf instead of "XSESSION=kde-3.0.2" during "emerge kde". The XSESSION=kde-3.0.2 is not a hold-over from a previous kde version, as this is a fresh 1.4-rc4 install, with new xfree and kde emerges. Whoever added the kde-3.1.2 emerge package [I'm assuming] must have forgotten to change the above. For your edification, my startup process looks like this: 1. startx calls 2. xinit /etc/X11/xinit/xinitrc ... 3. /etc/X11/xinit/xinitrc has: 4. elif [ -n "`/etc/X11/chooser.sh`" ]; then exec "`/etc/X11/chooser.sh`" -- This is the path I've been following 5. /etc/X11/chooser.sh returns the window manager to start. In my case, it follows the following logic: if [ -f /etc/X11/Sessions/${XSESSION} ]; then GENTOO_EXEC="/etc/X11/Sessions/${XSESSION}" Well, since XSESSION is "kde-3.0.2" in /etc/rc.conf, but /etc/X11/Sessions/kde-3.0.2 doesn't exist [because version 3.1.2 of kde has /etc/X11/Sessions/kde-3.1.2], the default action: # If all else fail, run twm GENTOO_EXEC="/usr/X11R6/bin/twm" occurs and "twm" is started. So, how does the kde emerge package get fixed such that /etc/rc.conf gets XSESSION="kde-3.1.2" instead of: XSESSION="kde.3.0.2" ??? Thanks. Dave
Ok, first, do you want kdm to start or kde itself? KDM is the KDE'ized version of the X Display Manager (xdm) which allows for graphical logins. You will need to edit /etc/rc.conf to set DISPLAYMANAGER to kdm and then start xdm via the "/etc/init.d/xdm start" command. If you do not want graphical logins, then you will want to set your XSESSION variable in /etc/rc.conf. The reason kde-3.0.2 is in your /etc/rc.conf is because it is an example. You have to change it by hand to reflect what you want. For reference, I think the following doc will answer a lot of your questions; http://www.gentoo.org/doc/en/desktop.xml
At the point I began this quest, I was just trying to get kde to start. DISPLAYMANAGER="kdm" was automagically set for me in /etc/rc.conf, I didn't have to change it, so I assumed that everything was ready to go. I read the "Desktop HOWTO" that you linked to the other night [and re-read it just now], but no where in there is there any mention of fixing the XSESSION variable to point to the "right" entry [kde-3.1.2, instead of kde-3.0.2], and since I didn't know any better at the time.... What this implied to me was that "emerge kde" was supposed to "do the right thing". But what your saying is that if I do "emerge gnome", I would run into the same problem, right? Why can't the kde emerge package be updated to update XSESSION for us poor newbies to Gentoo who don't know better? I've been using Redhat on Intel for quite a long time, and have never run into a similar issue.... The reason I'm harping on this is that it took me quite a long time to find the problem, and it's a nasty little problem that could be easily fixed for everyone's benefit. Proposed solution: At "emerge kde" time, "/etc/rc.conf" is opened, and reviewed for an XSESSION= entry that is not a comment. If found, a second commented entry would be added [to help the newbies, me included]: #XSESSION="kde-3.1.2" If no "XSESSION=" entry, then an uncommented one would be added: XSESSION="kde-3.1.2" Two questions remain: 1. Where can I find the emerge / ebuild back-end documentation [i.e. the bits for how to build an emerge package]? 2. How to determine that proper version number. Help with #1, and I'll do my best to provide a patched kde emerge package.
> At the point I began this quest, I was just trying to get kde to start. > DISPLAYMANAGER="kdm" was automagically set for me in /etc/rc.conf, I didn't > have to change it, so I assumed that everything was ready to go. Are you sure you haven't changed this in the past? This is not the default behavor and nothing should have modified it for you (that I'm aware of at least). > I read the "Desktop HOWTO" that you linked to the other night [and re-read it > just now], but no where in there is there any mention of fixing the XSESSION > variable to point to the "right" entry [kde-3.1.2, instead of kde-3.0.2], and > since I didn't know any better at the time.... Ok yes the XSESSION variable is not in there. I think setting it up is implied in the installation guide at step 27 where it indicates editing your /etc/rc.conf by following the commented directions in the file <http://www.gentoo.org/doc/en/gentoo-sparc-install.xml#doc_chap27>. The comments in there do talk about this. > What this implied to me was that "emerge kde" was supposed to "do the right > thing". But what your saying is that if I do "emerge gnome", I would run into > the same problem, right? Yes you would run into the same problem with GNOME, though the versioning doesn't so much apply there IIRC. XFree86 by default doesn't know what you want to run for a window manager/windowing environment. There are ways to set this mentioned in the XFree86 documentation, but they are limited to the scope of an individual user. Each distribution handles setting a system-wide window manager/windowing environment a little differently. One of the goals of Gentoo is not to have configuration files adjusted on you without your knowledge. So by what you are re-ferring to as "do the right thing" breaks this goal, which is why it isn't supported. > Why can't the kde emerge package be updated to update XSESSION for us poor > newbies to Gentoo who don't know better? I've been using Redhat on Intel for > quite a long time, and have never run into a similar issue.... This partially touches on the point above. Also, if you were to emerge another window manager or windowing environment for testing purposes, or a user who doesn't want to use the default you have set previously, it would clobber that setting, causing all users to use the new window manager/windoing environment. > The reason I'm harping on this is that it took me quite a long time to find > the problem, and it's a nasty little problem that could be easily fixed for > everyone's benefit. I think this is more of a preference as to how configurations are handled rather than a problem. Though perhaps an addition to the Desktop Guide to mention this should be added. > Proposed solution: > At "emerge kde" time, "/etc/rc.conf" is opened, and reviewed for an XSESSION= > entry that is not a comment. If found, a second commented entry would be > added [to help the newbies, me included]: #XSESSION="kde-3.1.2" > If no "XSESSION=" entry, then an uncommented one would be added: > XSESSION="kde-3.1.2" > Two questions remain: > 1. Where can I find the emerge / ebuild back-end documentation [i.e. the bits > for how to build an emerge package]? > 2. How to determine that proper version number. > Help with #1, and I'll do my best to provide a patched kde emerge package. This cannot be done as portage is configured to protect your configuration files and will cause the package to die while emerging. If you wanted to write a patch to change the behavior, you could have the ebuild make the changes after you have installed the packge. The current packages for mod_ssl and mod_php show a good example for something similar to this. I've CC'd the KDE team on this bug so you can get their input about this.
> > At the point I began this quest, I was just trying to get kde to start. > > DISPLAYMANAGER="kdm" was automagically set for me in /etc/rc.conf, I didn't > > have to change it, so I assumed that everything was ready to go. > > Are you sure you haven't changed this in the past? Nearly 100% positive. This is a new "nearly discarded" box I salvaged before its trip to the dumpster, as my employer is phasing out all Sun hardware. I did the gentoo install, followed a bit later by emerge xfree, and then emerge kde. I don't have a record so I can't be 100% sure, but I'm 90+% sure I never updated the XSESSION variable.... > This is not the default behavor and nothing should have modified it for you > (that I'm aware of at least). > > I read the "Desktop HOWTO" that you linked to the other night [and re-read it [snip] > Ok yes the XSESSION variable is not in there. I think setting it up is > implied in the installation guide at step 27 where it indicates editing your > /etc/rc.conf by following the commented directions in the file > <http://www.gentoo.org/doc/en/gentoo-sparc-install.xml#doc_chap27>. > The comments in there do talk about this. I'm pretty sure I hadn't touched XSESSION, since during the install, I hadn't even considered X and KDE, yet, let alone know what version to put.... > One of the goals of Gentoo is not to have configuration files adjusted on you > without your knowledge. So by what you are re-ferring to as "do the right > thing" breaks this goal, which is why it isn't supported. Okay, now that I can see as a valid reason why it doesn't updated /etc/rc.conf for you.... > This partially touches on the point above. Also, if you were to emerge > another window manager or windowing environment for testing purposes, or a > user who doesn't want to use the default you have set previously, it would > clobber that setting, causing all users to use the new window > manager/windoing environment. Got it, makes sense. > > The reason I'm harping on this is that it took me quite a long time to find > > the problem, and it's a nasty little problem that could be easily fixed for > > everyone's benefit. > > I think this is more of a preference as to how configurations are handled > rather than a problem. Though perhaps an addition to the Desktop Guide to > mention this should be added. Adding a note to the Desktop Guide would be helpful. :-) > > Proposed solution: [snip] > This cannot be done as portage is configured to protect your configuration > files and will cause the package to die while emerging. If you wanted to > write a patch to change the behavior, you could have the ebuild make the > changes after you have installed the packge. The current packages for > mod_ssl and mod_php show a good example for something similar to this. Okay, thanks for the input. I do see the wisdom of not touching config files without permission. > I've CC'd the KDE team on this bug so you can get their input about this. Fair enough. Thanks for your feedback.
So what would you like to do with this bug? We can either close it or change it to an enhancement request for having the desktop doc modified.
Well, since updating the config file is "the wrong thing", let's make this a request to update the Desktop doc about properly setting the XSESSION variable. Thanks.
Re-assigning to the Docs team. User would like to see an addition to the Desktop Configuration Guide in regards to setting up the XSESSION variable in rc.conf. Currently this is covered in the Install Guide, but when looking for X setup help, that would not probably be the first place users would look.
Created attachment 18367 [details, diff] Patch to add information about XSESSION
I can't verify myself if the XSESSION is really valid, but on #gentoo it seems to be generally accepted :) 14:46 < SwifT> anyone here use the XSESSION="" inside rc.conf to determine the windowmanager that gets started when you type "startx" ? 14:46 < pArt1cl3> SwifT: i do it works 14:46 < bold> swift, i do
patch looks good
Committed. Thanks for reporting!
