Bugzilla Bug 15315

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 an attachment (id=8172) [details]
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.