On 04/03/2012 05:23 PM, 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. > > 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
Great. And then everyone told me how /etc/gnome and prefix other than /usr can work. Well, yes they can. But there is a lot of additional configuration that needs to be done, and also I still haven't found a way to make policykit rules installed somewhere else than in /usr available to the daemon. So, I am asking again. If everyone else agrees, I'd like to drop GNOME_SYSCONFDIR - lot easier than making symlinks and if possible GNOME_PREFIX or keep it with fat warning that it might break things (that is if anyone wants to test if that works, I'm not going to do that). -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
