From the above URL, "/usr is shareable, read-only data." This is how my system is configured. However, from my kdm logs: /etc/X11/xdm/Xsetup_0: line 7: /usr/kde/3.1/bin/kdmdesktop: No such file or dire ctoryons: SessionTypes=Gnome,Sessions,Xsession,blackbox,enlightenment,fluxbox,kd e-3.1,ng kdmrc in /usr/kde/3.1 cp: cannot create regular file `kdmrc.orig': Read-only file system /etc/X11/xdm/Xsetup_0: line 28: kdmrc: Read-only file system rm: cannot remove `kdmrc.orig': No such file or directory Changing kdmrc in /usr /etc/X11/xdm/Xsetup_0: line 25: cd: /usr/share/config/kdm: No such file or direc toryging kdmrc in /usr/kde/3.1 cp: cannot create regular file `kdmrc.orig': Read-only file system /etc/X11/xdm/Xsetup_0: line 28: kdmrc: Read-only file system rm: cannot remove `kdmrc.orig': No such file or directory And then trying to see who owns this package: bash-2.05b# qpkg -f Xsetup_0 bash-2.05b# From the very KDE-specific nature of Xsetup_0, it looks like it was installed by one of the KDE ebuilds. I don't know for sure though. My recommendation would be to rework this script so that it does not assume that /usr is writable. (Why is it moving configuration files around everytime anyway?) Anyhoo. This also led to long delays at start-up, both KDM and the login to a KDE session.
It's installed by xfree but geared for kdm. The reason for this stuff is to autoupdate kdmrc based on the contenst of /etc/X11/Sessions (Gentoo-style session files installed by various WMs, e.g. kde, gnome, xsession etc). This obviously needs to be fixed. Of course we could just make it do nothing if there's no write access to kdmrc, but then you'd get a wrong session list in kdm, and since you can't enter a session in freetext, it's not a good situation (as in, you won't be able to start your new kde from kdm). Still that would better at least than failing trying to write on readonly FSs and making delays. Better ideas?...
The general FHS approach seems to be links. If you can't compile the code to look elsewhere for information you wish to be dynamic, then make the directory it's attempting to access a soft link into some region you can control, such as /var. /var has to be writable (or someone can expect their machine to have serious problems getting off the ground). (/tmp is out of the question because it would provide a limited (thought potentially dangerous) opportunity to modify how kdm handles things like remote users or password-less logins). My suggestion: mkdir /var/cache/kdm (with only root writable) mv /usr/kde/3.1/share/config/kdm/kdmrc /var/cache/kdm/kdmrc ln -s /var/cache/kdm/kdmrc /usr/kde/*/share/config/kdm/kdmrc Then modify the script as provided. Possible problems: If the syntax of the kdmrc file has changed significantly (i.e., a v3.1 kdmrc does not work with a v2 kdm), then you would have to make multiple files in var, and update each one separately. I don't think this a big deal, but it depends how many versions of KDE Gentoo is planning on supporting, and how differently those versions like to work.
Created attachment 8172 [details, diff] Patch for Xsetup_0 Patch also includes a bit of fall-back support (if nothing is there). How much of an rc file does kdm need before it will allow you to start?
this also bears on the following thread in the forums: http://forums.gentoo.org/viewtopic.php?p=260550#260550 Where it is shown that kdmrc is spontaneously blown away if kde or kdm is exited abnormally sometimes both copies in the 3.05a and the 3.1.1 or 3.1 directories. a reasonable fix would be for read only master files to exist and copies to be used for normal use with and customizations or changes saved in the normal use copies. Then if the working copies get blown away the kdm application can at least start with a default configuration. Perhaps these should exist in either /var as suggested or in /etc as proper config files should. derk
still occurs with kde 3.1.1a and kde 3.0.5b installed ... just happened again derk
This bug has been inactive for a long time. Any progress?
I've stopped using KDM in favour of GDM, but I've just checked the "/etc/X11/xdm/Xsetup_0" script. It still contains the code that attempts write access in the "/usr" partition.
The code in Xsetup_0 doesn't apply to kdm 3.3.x. We don't have a static session list in kdmrc anymore, but rather use .desktop files in /usr/share/xsessions. So the code doesn't do anything to current kdmrc files evn when it runs. It can be removed as soon as we can retire all KDEs older than 3.3.0. Considering the fact that we still have 3.1.5 around, this won't be soon. Almost certainly not before 3.4.0 is released. Meanwhile users can remove the code from their Xsetup_0. We should make new ebuild revisions for old kdebases, that would provide an Xsetup_0 under $KDEDIR for kdm to use. That way people who don't have an old kde installed won't get the problematic code with x11.
Err... unfortunately kde-3.3 assumes /usr is writable, too: /usr/kde/3.3/share/config/kdm/Xsetup generates .desktop files in /usr/kde/3.3/share/config/kdm/sessions/. But this will not be a problem if we really move session files to /usr/share/xsessions, is it going to happen soon? (maybe this discussion could continue in bug 66055)
Yes. I hope it'll be soon. I've already modified the kdm ebuild in the split ebuilds to be this way: install a kde session file in /usr/share/xsessions, read files from there rather than from usr/kde/3.3/share/config/kdm/sessions/, and not to use the /usr-modifying code. I sent a mail about this to kde@g.o today and if noone objects there I'll change the monolithic ebuilds the same way. Some of the more obscure WMs may not install session files there yet, and should be fixed (rather than changing kdm's behaviour).
Both the monolithic kdebase and the split kdebase-startkde packages now install a /usr/share/xsessions/kde-$ver.desktop. We should now ask the x11 people to remove our ugly code from Xsetup_0. We should also have an Xsetup_0 in kdm's config dir call kdmdesktop, so as to remove all kde-specific code from the xorg-x11 package. There's no point in always trying to run kdmdesktop without even checking for its existence, anyway. This would be a good time to remove from portage kde 3.1.x, whose kdm AFAIR does need the cusom Xsetup_0. KDE 3.2.x and 3.3.x have, between them, all the keywords 3.1.5 has. Objections to removal?
I'm all for removing 3.1. I'd like to see 3.2 removed prior to 3.2.3 as well, but some arches have non stable keywords on 3.2.3.
> We should also have an Xsetup_0 in kdm's config dir call kdmdesktop, so as > to remove all kde-specific code from the xorg-x11 package. There's no point > in always trying to run kdmdesktop without even checking for its existence, > anyway. kdmdesktop was removed from kde more than 2 years ago, so Xsetup_0 can be removed completely. kdm-3.3.x still does not use /usr/share/xsessions, right? For 3.4.x, it is a good idea to have the desktop file be kde-${VERSION:0:3} instead of kde-${VERSION} in both /usr/share/xsessions and /etx/X11/xsessions. (see also bug 63748) And of course I agree on removing kde-3.1.
> kdmdesktop was removed from kde more than 2 years ago, so Xsetup_0 can be > removed completely. We have to wait until kdm 3.2.x is removed from portage. IIRC it can't use .desktop session files and so needs our kdmrc mangling. Then again, our mangling doesn't use /usr/share/xsessions anyway... > kdm-3.3.x still does not use /usr/share/xsessions, right? As of kdebase-3.3.2-r1 it installs a .desktop file there, and it can use it if configured to do so. However, I don't remember whether the default kdmrc in 3.3.2 is configured that way (I only have the split 3.3 ebuilds emerged). > For 3.4.x, it is a good idea to have the desktop file be kde-${VERSION:0:3} > instead of kde-${VERSION} in both /usr/share/xsessions and > /etx/X11/xsessions. (see also bug 63748) I don't agree. /usr/share/xsessions isn't in CONFIG_PROTECT, so bug 63748 doesn't apply. When KDE is upgraded, the older file is removed. As for /etc/X11/sessions nothing uses it anymore and we don't install anyhing there. > And of course I agree on removing kde-3.1. OK, let's do that. I'll warn gentoo-dev m/l just in case.
*** Bug 50732 has been marked as a duplicate of this bug. ***
> As of kdebase-3.3.2-r1 it installs a .desktop file there, and it can use it > if configured to do so. However, I don't remember whether the default kdmrc > in 3.3.2 is configured that way (I only have the split 3.3 ebuilds emerged). I checked and it doesn't use it yet. We should make a new revision that does: just change files/$PVR/kdmrc to read SessionsDirs=/usr/share/xsessions. However, I don't have a monolithic 3.3 install, so someone else should do it. Doing so will close bug 50732, too.
>> kdmdesktop was removed from kde more than 2 years ago, so Xsetup_0 can be >> removed completely. > We have to wait until kdm 3.2.x is removed from portage. IIRC it can't use > .desktop session files and so needs our kdmrc mangling. > Then again, our mangling doesn't use /usr/share/xsessions anyway... Nope, kde-3.2 uses .desktop files (bug 32994). >> For 3.4.x, it is a good idea to have the desktop file be kde-${VERSION:0:3} >> instead of kde-${VERSION} in both /usr/share/xsessions and >> /etx/X11/xsessions. (see also bug 63748) > I don't agree. /usr/share/xsessions isn't in CONFIG_PROTECT, so bug 63748 > doesn't apply. When KDE is upgraded, the older file is removed. > As for /etc/X11/sessions nothing uses it anymore and we don't install > > anyhing there. True, but it's a good idea anyway, it's much cleaner, so why not? By the way, /etc/X11/Sessions will still apply to 'startx' users, and they will still need to change the value of the XSESSION variable every time the patchlevel changes.
>> We have to wait until kdm 3.2.x is removed from portage. IIRC it can't use >> .desktop session files and so needs our kdmrc mangling. >> Then again, our mangling doesn't use /usr/share/xsessions anyway... > Nope, kde-3.2 uses .desktop files (bug 32994). OK. Then we can remove our XSetup_0 stuff from xorg, right? >>> For 3.4.x, it is a good idea to have the desktop file be kde-${VERSION:0:3} >>> instead of kde-${VERSION} in both /usr/share/xsessions and >>> /etx/X11/xsessions. (see also bug 63748) >> I don't agree. /usr/share/xsessions isn't in CONFIG_PROTECT, so bug 63748 >> doesn't apply. When KDE is upgraded, the older file is removed. >> As for /etc/X11/sessions nothing uses it anymore and we don't install > >> anyhing there. > True, but it's a good idea anyway, it's much cleaner, so why not? OK. I don't really mind either way. Will do so in the split ebuilds. > By the way, /etc/X11/Sessions will still apply to 'startx' users, and they > will still need to change the value of the XSESSION variable every time the > patchlevel changes. grep -i session `which startx`: no results. I don't know how startx and related scripts work. What exactly accesses /etc/X11/Sessions?
>> By the way, /etc/X11/Sessions will still apply to 'startx' users, and they >> will still need to change the value of the XSESSION variable every time the >> patchlevel changes. > grep -i session `which startx`: no results. I don't know how startx and > related scripts work. What exactly accesses /etc/X11/Sessions? the code is in /etc/X11/chooser.sh, and is very ugly :)
> the code is in /etc/X11/chooser.sh, and is very ugly :) OK. Then we're done with this bug, as far as the split ebuild kdebase-startkde is concerned. We just need to tell the X11 people to remove the custom Xsetup_0.
That's bug #80225. This bug will be closed as soon as 80225 is resolved.
Can be closed now.
