its cerainly a gconf configuration and schemas installation issue

what are your gconf 1 and gconf 2 versions?
are you getting any messages on the console?

If you upgraded galeon & gconf what was the previous installed version
(working combination)

marco,ric,jorn - have you had much problems getting the two gconf
coexisting and should we increase the required gconf 1 version number
to combat these errors?

[kbreit@kbreit kbreit]$ rpm -q GConf
GConf-1.0.7-ximian.4
[kbreit@kbreit kbreit]$ rpm -q GConf2
GConf2-1.1.7.0.200202101248-snap.ximian.1

The only printing I am getting on the console is this:
LoadPlugin: failed to initialize shared library
/home/kbreit/adobesvg-3.0/libNPSVG3.so
[/home/kbreit/adobesvg-3.0/libNPSVG3.so: cannot open shared object
file: No such file or directory]
and that would be REALLY interesting to see that be the issue we're
dealing with.
I had Galeon 1.0.3 (what I have now) installed since its release.  I
haven't upgraded GConf recently (I don't think).  I just installed
GConf2 last night though.

I had similar probs. The last gconf ximian package + last gconf2 
released package (cant remember version atm) seem to have solved them)

it's definately a gconf problem. Let's keep the bug here to remember 
about it but removing 1.2 target

we will still be getting the same damend bugreports over and over again :(

Yeah that suck but I dont think we can do something about it in 
galeon, so I dont think keeping it as 1.2 bug make sense unless we 
want to delay our release until gconf is fixed.

With more and more people trying gnome2 galeon will almost certainly
break for them, given the uncertainty on what gconf1/2
packages/combination of the both work or dont work.

We are in this situation now,  and I dont see any well documented
steps  to at least partialy fix that. 

I dont think I'll be able to document how to fix this because the 
only way I know is killall gconfd-2 and anyway this doesnt seem to 
work reliably. Also there are too many possible gconf combination and 
too many possible packages that I bet will give different problems.
If someone feel like doing it, that is going to be higly 
appreciated ;)

So, I was bored sensless and started working on this.
Here's a workaround....
run:
    LANG=C galeon

Gconf doesn't seem to be falling back to C when the LANG/LC_* can't be
found in the schema

I'm filing this comment in a galeon 1.1.3 running against a gconfd-2

Hey, the LANG=C galeon workaround fixed my problem.
So at this point, do I leave this up to the developers to fix?  Do you
need anymore input?

Thanks Frank!

*** Bug 72705 has been marked as a duplicate of this bug. ***

Debian users have reported this gconf issue, too.
It also seems to be locale-dependant, several reported that it was
gone with LANG=C.
In current galeon package we have found another workaround:
Do install the gconf templates in your .gconf directory by doing
/usr/bin/gconftool --install-schema-file=/etc/gconf/schemas/galeon.schemas
(the debian galeon wrapper will do this automatically right now; the
wrapper in the galeon-beta package, containing a cvs checkout from
20020301, does store the version number, too, and will reinstall the
schemas upon upgrade)

Yeah, try not to encourage too many broken workarounds; I'm going to
fix this very soon, I promise. ;-)

Adding

What's the status on this? Can people still reproduce? 

The gconf test suite now runs in a bunch of different locales, so 
I'm not sure what's going on. Perhaps the client has to be gconf1 
in order to trigger it?

Hrm. not sure why my comment got cut off. I can still reproduce; I do
'rm -rf .gconf/apps/galeon; gconftool --shutdown' and instead of
defaults I get blank stuff unless I use LANG=C. This is with this
morning's CVS snaps for all g2 stuff.

Re-titling to make this easier for yaneti and I to find if we see
duplicates.

It occurs with locales NOT in the schema file.
At least when i sed -e 's/name="C"/name="de_DE"/' and install that
schema file, i then can use the "de_DE" locale (but not the de_DE@euro
locale, which ide de_DE.ISO8859-15) - unless i make the same trick
again, it then works, too.

ok, I had this 'galeon all grey' bug using GConf 1.0.7 and 1.1.8.
So I tried updating to GConf 1.0.8 to see if that solved it. It didn't
the error still persists. 

So I tried running the galeon-config-tool to a) uninstall schema,
install schema, fix perms and clean. But now Galeon just says 'Cannot
find schema for Galeon setup..etc.'. But in Gconf-editor I clearly see
that I do have a galeon schema setup.

Right because gconf-editor is a GConf 2 app, and Galeon is a GConf 1
app, I think. There's some interaction issue.

Note that this same problem happens if you put gconf 1/2 in two
separate prefixes, though the people who can fix it by changing LANG
are not seeing this issue.

This is not happening on my system. Not good...

I tried getting some info from gconfd-2's debug output, but it did not
seem to contain useful information... if you give me some diff's
against gconf2 1.1.8 i'll test them.

Here's some debug output infos i got:
dir file /etc/gconf/gconf.xml.mandatory/schemas/apps/galeon/%gconf.xml
not found
dir file /home/erich/.gconf/schemas/apps/galeon/%gconf.xml not found
loaded dir /etc/gconf/gconf.xml.defaults/schemas/apps/galeon
Caching dir /schemas/apps/galeon
[...]
Using dir / from cache
found locale `C'
[repeated 2 times]
Setting XML node to schema with locale `C'
found <local_schema> with no locale setting
In lookup_with_schema_name returning schema name
'/schemas/apps/galeon/gconf_test' error 'none'

when i install the schema into my .gconf/schemas directory it works -
that's what is most irritating...

BTW: This is NOT a gconf1 vs. gconf2 interaction issue.
gconf-editor does show the entries, but it does not show the default
values. It's just the default values that are missing for locales that
are not in the schema file.
LANG=C LC_ALL=C LD_PRELOAD= gconf-editor
works, whereas
LANG=C LC_ALL=de_DE LD_PRELOAD= gconf-editor
does not have the default values.

adding to cc list - it's happening for me as well. This is with the
latest RC updates for gnome and using the gnome2 snapshots channel.

I can confirm what Erich suggests with latest cvs gconf; I'm not sure
exactly what it /means/, though- does this mean that it is a problem
with the galeon schemas and not gconf? or is it still a gconf problem?
Sort of letting this serve as a poke, since it is still a problem for
lots of people and is definitely slowing adoption/testing of g2 snaps
for galeon users.

I don't think it's a problem with galeon's schema files, as all
applications i've tried that use gconf show this behaviour.
For example gnome-gv is missing the menu bar and doesn't store that i
enabled it. The schema says "true" as value, but gnome-gv get's false
by gconf. don't know why it doesn't save my settings...
gtranslator also has problems remembering my name...

I believe this is fixed for GConf2 in CVS. It looks like GConf 1 has
the same bug, so I don't really get why GConf2 installation was
triggering the problem, though - so maybe I didn't fix the right bug.
I fixed the 
only bug I could reproduce though...

Someone please verify with current CVS.

i tried cvs, didn't work for me. Same problem.
LC_MESSAGES=de_DE ggv
is still missing it's default values, same for galeon.
doesn't work for LC_MESSAGES=en_US ggv either btw.

So we're back to "I can't reproduce this in any way whatsoever" - and
this time I really did set the locale correctly when testing, I did 
a printf(setlocale(LC_ALL, NULL)) to prove it.

Are all you guys using Debian maybe and I'm using Red Hat? Just deluge
me in info about your computers and GNOME builds and how they might be
different from mine. Don't be shy...

Can someone also tar up their ~/.gconf and
prefix/etc/gconf/gconf.xml.defaults directory and send me that to
hp@redhat.com.

Trying to think what else...

You're sure you restarted gconfd and were running gconfd-2 not
gconfd-1 after getting latest CVS, right?

Yes, i'm sure gconfd-2 is running (at least ps ax shows it...) and it
was spawned (i killed it before installaing the new version)
The problem probably is somewhere in the libgconf, as it's dependant
on the application's locale, not gconfd's.
gconf2-apps like gconf-editor don't work either unfortunately...

Maybe the problem is due to some dependencies:
ii  libatk13                      0.13-3     Unstable ATK
accessibility library
ii  libc6                         2.2.5-3    GNU C Library: Shared
libraries an
ii  libfreetype6                  2.0.9-1    FreeType 2 font engine,
shared lib
ii  libgconf2-4                   1.1.8-4    GNOME configuration
database syste
ii  libglib1.3-15                 1.3.15-2   Unstable GLib
general-purpose C li
ii  libgtk1.3-15                  1.3.15-3   Unstable GTK+ graphical
user inter
ii  liblinc1                      0.1.19-1   library to simplify
creating netwo
ii  liborbit2                     2.3.106-1  Libraries for ORBit2 - a
CORBA ORB
ii  libpango0.26                  0.26-2     Layout and rendering of
internatio
ii  libpopt0                      1.6.2-7    lib for parsing cmdline
parameters
ii  libxml2                       2.4.16-2   GNOME XML library
ii  xlibs                         4.1.0-14   X Window System client
libraries
ii  zlib1g                        1:1.1.4-1  compression library - runtime

Havoc, I am using Red Hat 7.2 with Ximian Gnome 2 Snapshots.
If you'd like my configuration, please let me know.  I'll be more than
happy to email it to you!

Kevin: and this morning's gconf snaps don't do it for you? They Just
Work  here (on two separate machines). Looks like we may have a
multiplicity of problems. :/

I just tried the following commands:
unset LOCALE
gconftool --shutdown
echo $LOCALE
galeon
and galeon works now.  I am using Galeon 1.2.0 with today's snapshots.

So Luis, Kevin - it _does_ work for you?

Erich - does your user.* syslog have errors about running out of file
descriptors? You need CVS versions of linc and GLib or gconfd will run
out of file descriptors and be unable to open the XML files. 
If you have that problem you should have user.* syslog spew, and 
the locale shouldn't make a difference.

No, it is locale dependant and i don't get an out-of-fd error.
And if i add explicite locale values to the schema files for my locale
the default values do work; just not if they are only specified with
no locale or the "C" locale, so it's some
default-value-fallback-to-C-locale issue, dependant on the locale of
the calling process.

Syslog has just the usual
Resolved address "..." and start as well as stop messages.
Kevin's posting is irritating, he should really try running
export LC_MESSAGES=en_EN
galeon
just using "echo $LOCALE" doesn't set a value...

Havoc: just to be clear, it definitely works for me, and according to
Kevin (in IRC) it definitely works for him. Note that we are both on
RH systems with Ximian snaps, so we are (1) in a pretty similar boat
to you locale wise, by default, and (2) very up-to-date.

Erich, if you notice, I unset the variable, so I was just verifying it
was unset.

When i unset the locale variables i don't have any problems either...
but that's no solution. that's not even an acceptable workaround.

Good news. I ran "cvs up" again today, and this time it worked.
Maybe the anoncvs.gnome.org mirror i used last time wasn't updated yet.
So as far as i can tell, the bug really is gone now.
Seems like it takes more than half an hour till the changes propagate ;)

OK, great. I have another report of this getting fixed, too, 
from Mandrake. So let's call it fixed. (I still wish I understood why
the bug didn't happen in GConf 1.0.x, but...)