Installing new schemas with --makefile-install-rule (eg, as part of a package %post) don't seem to be picked up by running instances of gconfd-2. First noticed with gnome-power-manager but reproduced with a pretty trivial schema file afterwards, so I don't think it has anything to do with the specific schema.
Hey Jeremy, So at one point, g-p-m had this: %preun export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-uninstall-rule \ %{_sysconfdir}/gconf/schemas/gnome-power-manager.schemas >/dev/null which might manifest itself as the problem you're seeing here. Do you think that's what happened? If you do: $ gconftool-2 --recursive-unset /apps/gnome-power-manager $ killall gconfd-2 $ gconftool-2 \ --direct --config-source=$(gconftool-2 --get-default-source) \ --makefile-uninstall-rule \ /etc/gconf/schemas/gnome-power-manager.schemas then install the latest version of gnome-power-manager are you still seeing the problem?
I was getting the same thing to happen, though, just with a foo.schema that set /apps/foo/mykey
Note, that I added a hack around to the rhythmbox spec file. When this bug is fixed, that hack should be removed.
If run as root, gconftool-2 --makefile-install-rule could do killall -HUP gconfd-2 perhaps ... (The problem was always there, but it's worse now with the merged subtree)
Upstream: http://bugzilla.gnome.org/show_bug.cgi?id=328697
Fedoraproject Scriptlet Snippets page recommends running "killall -HUP gconfd-2 || :" after doing a --makefile-install-rule/--makefile-uninstall-rule:: http://www.fedoraproject.org/wiki/ScriptletSnippets#head-ff64cd482595764f672082d5a3b83e1fc22962e8 If gconftool-2 adds this internally, I'll note that the need for it has been removed for FC5+. The alternative would be Core packages installing gconf schemas follow the advice to send a HUP in the rpm scriptlets.
Testing a patch now. Taking.
Fixed in tomorrow's rawhide using patch from http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/GConf2/GConf-2.8.1-reload.patch?rev=1.1&content-type=text/plain
Unless patch has changed on FC5, the patch needs to be updated. The area that it's updating has several sections that are very similar and the fuzz factor is causing problems:: gconf_engine_unref (conf); g_spawn_command_line_sync ("/usr/bin/killall -q -HUP " GCONF_SERVERDIR "/" GCONFD, NULL, NULL, NULL, NULL); g_spawn_command_line_sync ("/usr/bin/killall -q -HUP " GCONF_SERVERDIR "/" GCONFD, NULL, NULL, NULL, NULL); return retval; } This is screwy enough it might be considered a patch bug.... I'll submit an updated patch in a moment.
Created attachment 124058 [details] Have gconftool send a HUP to gconfd Previous patch applies to the wrong section of code. This patch applies one section to the makefile-install code path and one to the makefile-uninstall code.
Hah. I did know that and created a new patch; I just uploaded the wrong one. Fixing.
Still seems broken in post-test3 rawhide. I changed gnome-applets to include mini commander again, but when I updated the package, the schema did not get picked up. manually installing the schema again did not help either. restarting gconfd did.
Hi, Chris says that he built updated packages into rawhide that may fix this problem. Closing... (but let's reopen if it the problem happens again).
The handling in gconftool-2 was not working for me; on investigation it turned out to be a bug/misfeature in killall, see bug 214214. If bug 214214 isn't fixed, replacing 'killall /usr/libexec/gconfd-2' with 'killall gconfd-2' would be advised.
So does rstrode's fix of 6-Nov-2006 (e.g., http://www.redhat.com/archives/fedora-package-announce/2006-November/msg00151.html) fix this problem? Or is it still a bug?
It's fixed, yea, thanks.