Ken Moffat wrote:
> ----- 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.
I suppose I should build gnome in /opt/gnome to check it out. I've been
trying out Ubuntu on a new box lately and find the user interface
terrible (I switched it to KDE).
On ubuntu there is:
/etc/gnome
defaults.list menus.blacklist
/etc/gnome-app-install
packages-whitelist
/etc/gnome-settings-daemon
xrandr/ (empty)
/etc/gnome-vfs-2.0
modules/
default-modules.conf extra-modules.conf
There is also ~/.gnome2
For kde, there is nothing in /etc, but there is in ~/.kde.
> 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 ?
That seems a logical thing to do.
> 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" ;-)
Not really: http://wiki.debian.org/LSBInitScripts
I can update the script easily enough if the commands are still current,
Are they basically still:
start) loadproc gdm ;;
stop) if [ -f $pidfile ]; then loadproc gdm-stop; fi ;;
reload) loadproc gdm-safe-restart ;;
restart) loadproc gdm-restart ;;
> 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
> reworded. I suspect the suggestion to use gdm without D-Bus is just
> historical baggage,
It is required for build. daemon/main.c has an unconditional
#include <dbus/dbus-glib.h>.
> but I don't understand why gdm ships a version
> that can't find everything. Maybe something else is in the wrong
> place ?
Perhaps we could find the search locations from the source?
It looks like you can toggle debug messages with the signal USR1.
> 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 ?
It really depends on umask. I'd say we need to be consistent.
> 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 think it's the video hw, not the cpu.
> 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.
If it basically works, then it works. If we need to go back and add
some configuration issues later, than it sill works.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
