I'll have to yield to Dyyryath on this one--- I've never seen that msg about a galeon schema before, so I have no clue what it's looking for :confused:
Maybe your BreakMy Gentoo build broke Galeon??
the rest looks like its coming along nicely tho.....
<Long edit:>
I pulled this off the FAQ:
# When I run Galeon I get a message about GConf not being configured properly. How can I configure GConf?
First and foremost, be sure you have a new GConf (1.0.7 is the latest at this writing) rather than an old one. In particular, 1.0.4 is too old and causes problems.
If you do ps jaxwww | grep gconf and see two gconfd-1 processes, that's what's wrong; just kill them both and restart Galeon. This problem has not been reported with GConf 1.0.7, only older versions.
If you have trouble with 1.0.7, most likely it's because your home directory is NFS-mounted and either your operating system doesn't support locks in NFS directories or you have stuck locks due to a hard system crash. Try rm -r ~/.gconf*/*lock if you are sure you have no gconfd processes (for your login name) running on any machine using your NFS home directory. If you nuke the lock when gconfd is running and bad stuff happens, it's your own fault. ;-)
If you want to use GConf while logged in from two different machines, sharing the same home directory, you must enable TCP/IP for ORBit by adding the line ORBIIOPIPv4=1 to /etc/orbitrc and restart gconfd. You will need to do this on both machines; one machine will contact the gconfd running on the other. This setup is poorly tested but should work.
It's possible schema installation failed when you installed Galeon, so you can try reinstalling them as follows:
GCONF_CONFIG_SOURCE=`gconftool-1 --get-default-source` \
gconftool-1 --makefile-install-rule /etc/gconf/schemas/galeon.schemas
Be sure your GConf config file is set up correctly by editing the path file in the directory $sysconfdir/gconf/1. A basic configuration for the default backend would look like:
xml:readonly:/etc/gconf/gconf.xml.mandatory
include "$(HOME)/.gconf.path"
xml:readwrite:$(HOME)/.gconf
xml:readonly:/etc/gconf/gconf.xml.defaults
You can also take a look at $sysconfdir/gconf/1/path.example and in most cases you can simply move it to $sysconfdir/gconf/1/path. Be sure that the path file can be read by all users.
Ensure you have a $sysconfdir/gconf/gconf.xml.defaults dir set up with the right permissions. In most cases you can run chmod -R 755 $sysconfdir/gconf/gconf.xml.defaults.
WARNING: The GConf deamon makes heavy use of a cache so when changing your setup you will probably need to restart it.
Be sure you have no applications depending on gconf running and then run:
gconftool --shutdown
GConf will then restart when it is required.
If none of the above works, enable user syslogging and see if gconf is logging any error messages. On Linux, to do this try adding this line to /etc/syslog.conf:
user.* /var/log/user
then run service syslog restart, reproduce your gconf problem, and look in /var/log/user for messages. If gconf is failing to get a lock then the issue is probably the NFS thing mentioned earlier. Otherwise maybe there are other informative error messages.
If you still can't figure it out, try mailing
[email protected], describing what happened when you tried all of the above and what version of gconf you have, what exact error messages you get, etc.