----- Forwarded message from Ken Moffat <[email protected]> -----

 Sent this after a very long night, but it doesn't seem to have
arrived.  Trying again.

 Well, I've now fixed my mouse (cable problems) and tested gdm.
I've now got it "working" (i.e. able to use my xsession files for
'startfluxbox' and 'icewm-session', and now, at last, gnome itself
has found the applications (item 1.1 below) :

 This is a summary of play:

1.  I built in /usr, and went with /etc/gnome for GNOME_SYSCONFDIR.
People have already pointed out that /etc is more normal.  For gdm,
if gnome-settings-daemon.desktop is not in /etc/gnome/xdg/autostart
(there are other places on its search path, but /etc/gnome and
/etc/gnome-3.2 are not among them), then gdm will fail to start (the
details are logged in /var/log/daemon.log.  I have no idea what
happens if you build somewhere else such as /opt/gnome.

1.1 Originally, I was going to say that I had gdm working, but only
for non-gnome windowmanagers.  The problem is another side-effect of
not putting everything in /etc/xdg : the menus (in my case) are in
/etc/gnome/xdg/menus - metacity (and presumably gnome-shell) can't
find them, so although it will let you access 'places'  (e.g. ~/)
and logout, you can't do anything!  Symlinking the menus from
/etc/xdg solved that.

1.2 I suppose we could stress that anyone not building in /usr &&
/etc needs to provide symlinks in /etc/xdg if they want to use gdm ?

---
UPDATE: if this mail gets through, I'll reply with the logs showing
where it searches.  I've got other files in /etc/gnome/xdg/autostart,
e.g. from bluetooth-applet, caribou, gnome-sound-applet : I suspect
all of them ought to be symlinked.  Most of them are not things I
use.
---

2.  The bootscript is old-style.  Works, but not in the current
Provides/Required-Start/... style.  If I was motivated, I could
probably come up with something, but whether it would have the
correct names for the variables is anybody's guess.  I still think
the old scripts were better because they were easy to understand -
no doubt there is a key somewhere explaining things such as
"$network", but I suspect it is in a locked drawer in a room marked
"beware of the leopard" ;-)

3. The default gnome session installed by gdm (i.e. without d-bus)
reports an error, something along the lines of failing to find the
clock applet.  Since D-Bus is *required* for gnome (e.g. GConf needs
d-bus glib bindings), we could either overwrite the inadequate
version it supplies, or perhaps better (to retain the translations -
see attachment) sed Exec= and TryExec= to use the book's
preferences.  Either way, the sentence "If you have D-BUS installed
and you want to start the session D-BUS daemon..." needs to be
reqorded.  I suspect the suggestion to use gdm without D-Bus is just
historical baggage, but I don't understand why gdm ships a version
that can't find everything.  Maybe soemthing else is in the wrong
place ?

4. For many of the PAM files in /etc/pam.d we chmod them to 644
after root has created them, but for a couple of newer ones the
chmod is not mentioned.  Looking at my results, they are 644 -
should be keep the chmod in case people have weird settings, and
therefore do it for all these files, or can we just assume
everything will be ok ?

 I'll also note that something about the gdm window (probably the
buttons - they seem a bit OS9, i.e 1990s mac) offends my sense of
taste: usually I don't particularly care, and the striped blue
background looks ok if you like that sort of thing, but I do wonder
where they are going with this.  Perhaps it looks better on more
powerful hardware which doesn't use the fallback - even the Sandy
Bridge i3/i965 I bought last week doesn't fit the bill for
gnome-shell, so who knows.

 I still plan to look at the gnome dependencies (to reduce what we
list by removing implicit deps), and I guess I can tag gdm as tested
in 7.0 - subject to agreement on dealing with the consequences of
not building in /usr and /etc.  But for the remaining points above,
I'm not sure.

--- attachment for default gnome.desktop inlined but mostly edited
out, I suspect this was what caused the mail not to get through.  It
has 'translations' of 'Name' and 'comment' in many languages - some
of which even I don't have fonts for.  They were the poit of
attaching it, but whatever
[Desktop Entry]
Name=GNOME
...
Name[en_GB]=GNOME
...
Comment=This session logs you into GNOME
...
Comment[en_GB]=This session logs you into GNOME
...
Exec=gnome-session
TryExec=gnome-session
Icon=
Type=Application

----- End forwarded message -----

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to