Re: GConf error
On Sat, May 8, 2010 at 2:22 PM, Toshio Kuratomi a.bad...@gmail.com wrote: I see that we're calling killall -TERM instead of killall -HUP in the patch. That seems non-optimal (since it means we'll keep shutting down the gconfd server instead of letting it use it's 30second timeout) That's definitely suboptimal because we'll lose the caches etc. from the running process. Anyone know why we haven't seen progress on the upstream bug? No one's raised any philosophical blockers with doing this: http://bugzilla.gnome.org/show_bug.cgi?id=328697 I commented there. Colin, if no one's looking into fixing this bug there's two ways to workaround this bug: Change macros.gconf2 to run killall after the schemas are installed or uninstalled. This requires an update of the GConf2 package. We don't know which Fedora versions this affects yet (the guake update was for F13) killall -TERM? Restore the packaging guideline suggestion to run killall -HUP gconfd-2 Since we don't know which versions this affects, we'd need to recommend it on all Fedora releases. I don't think that helps - the original problem report was failure on initial install + run, which I believe must be a result of the 30 second delay in gconfd from SIGHUP. What do you think about my comment here? https://bugzilla.gnome.org/show_bug.cgi?id=328697#c9 If we can't get the changes to RPM made to do it once post-transaction, then I suggest we simply bite the bullet and remove the 30 second timeout from gconfd until such time as the RPM change can be made. I'll take slower without race conditions over faster but racy. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Sun, May 09, 2010 at 11:56:27AM -0400, Colin Walters wrote: On Sat, May 8, 2010 at 2:22 PM, Toshio Kuratomi a.bad...@gmail.com wrote: I see that we're calling killall -TERM instead of killall -HUP in the patch. That seems non-optimal (since it means we'll keep shutting down the gconfd server instead of letting it use it's 30second timeout) That's definitely suboptimal because we'll lose the caches etc. from the running process. Anyone know why we haven't seen progress on the upstream bug? No one's raised any philosophical blockers with doing this: http://bugzilla.gnome.org/show_bug.cgi?id=328697 I commented there. Colin, if no one's looking into fixing this bug there's two ways to workaround this bug: Change macros.gconf2 to run killall after the schemas are installed or uninstalled. This requires an update of the GConf2 package. We don't know which Fedora versions this affects yet (the guake update was for F13) killall -TERM? killall -HUP Restore the packaging guideline suggestion to run killall -HUP gconfd-2 Since we don't know which versions this affects, we'd need to recommend it on all Fedora releases. I don't think that helps - the original problem report was failure on initial install + run, which I believe must be a result of the 30 second delay in gconfd from SIGHUP. I'm a bit unclear on the original problem report, actually. In addition to what you've said, the report also says that the user had to logout and log back in before it worked. That seems like a different symptom. 30 seconds is not that long so I would expect that just starting application from the menu, reading failure message, trying to start the application from menu a second time would be enough time... Also, I'm unclear if simply adding killall -HUP to the guake scriptlets fixed the problem (or if something else about the install transactions were different). If that's all it took, then that also points at something other than the 30 second timeout being the issue. Are we able to reproduce the original reporter's issue? What do you think about my comment here? https://bugzilla.gnome.org/show_bug.cgi?id=328697#c9 If we can't get the changes to RPM made to do it once post-transaction, then I suggest we simply bite the bullet and remove the 30 second timeout from gconfd until such time as the RPM change can be made. I'll take slower without race conditions over faster but racy. Note: %posttransaction would allow us to group all of the SIGHUPs in a closer timespan (we'd run all of the sighups [and other posttransactions] at the end of the rpm transaction). So perhaps having:: gconftool-2 --makefile-(un)install-rule --delay-sighup=$SECONDS in the general case would work. We could specify delay-sighup as 5 seconds or so in the gconf macros. I also realized that in the unlikely case that something is run in a %post transaction needs to use something that was installed, we'd need to sighup gconf in %post with no delay... that'll be tricky since the sighup should really go in the package providing the tool but we will get the problem reports in the package depending on the tool. On the speed front: 1) Using %posttransaction even without the delay could be faster due to fs caching -- we won't have clobbered that by doing a few package installs between gconf sighups. 2) The new gconf macros are more intelligent than the old scripts -- they don't run if the schemas are unchanged. That might take some of the sting out of gconf reloading schemas more frequently again. 3) mclasen performed some optimization of gconf itself recently... I don't know precisely how that affects the original rationale for the delay. You'll need to flag down panu or ffesti to see if 'do-this-action-once' is something they're planning for an upcoming rpm release (and we'll still have to document in guidelines what to do until then). -Toshio pgpCScajJJ99C.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Sun, 2010-05-09 at 14:04 -0400, Toshio Kuratomi wrote: I'm a bit unclear on the original problem report, actually. In addition to what you've said, the report also says that the user had to logout and log back in before it worked. That seems like a different symptom. 30 seconds is not that long so I would expect that just starting application from the menu, reading failure message, trying to start the application from menu a second time would be enough time... Also, I'm unclear if simply adding killall -HUP to the guake scriptlets fixed the problem (or if something else about the install transactions were different). If that's all it took, then that also points at something other than the 30 second timeout being the issue. Are we able to reproduce the original reporter's issue? I have been able to reproduce it only once, yesterday when I reinstall my F-13. From all my machine it's the only time I could reproduce it. And then, I waiting sometime doing a ls .gconf/apps and I saw the guake folder appearing. I think the restart of X solves the problem indeed since I take usually more than 30sec to log out, log in and retry to start the application. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, 2010-05-07 at 13:24 -0400, Toshio Kuratomi wrote: (Since this might be a regression in gconf2, you might need to still add the %posttrans scriptlet wth the new scriptlets. If Colin knows that this is %a bug that won't be fixed in some versions of Fedora I'll add the killall %to the appropriate point in the Guidelines.) hm it seem that the changes have made are not enough: https://admin.fedoraproject.org/updates/guake-0.4.1-3.fc13 The spec is present there: http://cvs.fedoraproject.org/viewvc/F-13/guake/guake.spec?view=markup Any suggestions ? Thanks, Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Sat, May 08, 2010 at 12:26:17PM +0200, Pierre-Yves wrote: On Fri, 2010-05-07 at 13:24 -0400, Toshio Kuratomi wrote: (Since this might be a regression in gconf2, you might need to still add the %posttrans scriptlet wth the new scriptlets. If Colin knows that this is %a bug that won't be fixed in some versions of Fedora I'll add the killall %to the appropriate point in the Guidelines.) hm it seem that the changes have made are not enough: https://admin.fedoraproject.org/updates/guake-0.4.1-3.fc13 Looks like the last comment there gave you the details you needed and you got something that works: https://admin.fedoraproject.org/updates/guake-0.4.1-4.fc13 I've looked at the patch to our GConf2 that Colin pointed out a bit more and I think that at some point it was rebased and broken. It appears to me that the killall is being both more often than it shoulod be and not in all cases. I'll need to look at the patch's history a bit more to see if I'm right. -Toshio pgp1g1y6V3n9c.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Thu, 2010-05-06 at 20:44 +0200, Pierre-Yves wrote:
Hi,
Being the maintainer of Guake I have received a number of bug gconf
related [1]. Their common pattern is that they only appear the first
time guake is installed and run (and then again not always).
If the user restart X/the computer, the bug does not appear at all.
I am therefore quite unsure of what to do with these bugs. I asked
upstream who also is not sure. It is like if the gconf schema was not
correctly install while I install it via:
%post
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
gconftool-2 --makefile-install-rule \
%{_sysconfdir}/gconf/schemas/%{name}.schemas /dev/null || :
(cf [2] and [3] for build log)
Why am I doing wrong ?
Is this gconf issue ?
Would it be allowed to try to restart gconfd ?
It seems that the debian package is doing so.
Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves pin...@pingoured.fr wrote: Would it be allowed to try to restart gconfd ? It would make sense to SIGHUP gconfd after new schemas are installed, yes. Note though we should really only be doing this once at the end of a transaction when installation is complete. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 07, 2010 at 09:38:45AM -0400, Colin Walters wrote: On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves pin...@pingoured.fr wrote: Would it be allowed to try to restart gconfd ? It would make sense to SIGHUP gconfd after new schemas are installed, yes. Note though we should really only be doing this once at the end of a transaction when installation is complete. My understanding was that with current Fedoras, gconf doesn't need this but I could be misremembering, missing a corner case, or just wrong :-) What are the cases that we need to still send a sighup to gconf? (or is this a workaround for an undiagnosed bug in the guake gconf schema?) We can't do this only once at the end of a transaction but if I'm remembering a different discussion, doing it multiple times at the end of the rpm transaction should be almost as good (since gconf will wait for a few moments from getting the first SIGHUP to see if it will get any other ones.) Is that correct? -Toshio pgpMfzXzRSJcL.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 7, 2010 at 12:05 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Fri, May 07, 2010 at 09:38:45AM -0400, Colin Walters wrote: On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves pin...@pingoured.fr wrote: Would it be allowed to try to restart gconfd ? It would make sense to SIGHUP gconfd after new schemas are installed, yes. Note though we should really only be doing this once at the end of a transaction when installation is complete. My understanding was that with current Fedoras, gconf doesn't need this but I could be misremembering, missing a corner case, or just wrong :-) [walt...@pocket gconf (master)]$ git grep inotify [walt...@pocket gconf (master)]$ git grep g_file_monitor [walt...@pocket gconf (master)]$ So... We can't do this only once at the end of a transaction but if I'm remembering a different discussion, doing it multiple times at the end of the rpm transaction should be almost as good (since gconf will wait for a few moments from getting the first SIGHUP to see if it will get any other ones.) Is that correct? It has a 30 second timer currently for periodic cleanup, and SIGHUP just sets a flag that that function reads. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, 2010-05-07 at 09:38 -0400, Colin Walters wrote: On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves pin...@pingoured.fr wrote: Would it be allowed to try to restart gconfd ? It would make sense to SIGHUP gconfd after new schemas are installed, yes. Note though we should really only be doing this once at the end of a transaction when installation is complete. Thanks for your help, I will update the spec to do this. Would you have any advice/example on what would be the best way to do it ? Do you think it should be done on %postun as well ? Pirre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 07, 2010 at 12:15:20PM -0400, Colin Walters wrote: On Fri, May 7, 2010 at 12:05 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Fri, May 07, 2010 at 09:38:45AM -0400, Colin Walters wrote: On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves pin...@pingoured.fr wrote: Would it be allowed to try to restart gconfd ? It would make sense to SIGHUP gconfd after new schemas are installed, yes. Note though we should really only be doing this once at the end of a transaction when installation is complete. My understanding was that with current Fedoras, gconf doesn't need this but I could be misremembering, missing a corner case, or just wrong :-) [walt...@pocket gconf (master)]$ git grep inotify [walt...@pocket gconf (master)]$ git grep g_file_monitor [walt...@pocket gconf (master)]$ So... It's in gconftool.c: Running makefile-install-schema and makefile-uninstall-schema eventually calls do_sync() which was supposed to reread the schemas. That's currently calling gconf_engine_suggest_sync() in gconf.c and I'm not sure whether there's some logic in there that could cause it not to suggest syncing in our current setup. Here's our bug where it was implemented but the code has changed since then: https://bugzilla.redhat.com/show_bug.cgi?id=173869 Possibly a regression? We can't do this only once at the end of a transaction but if I'm remembering a different discussion, doing it multiple times at the end of the rpm transaction should be almost as good (since gconf will wait for a few moments from getting the first SIGHUP to see if it will get any other ones.) Is that correct? It has a 30 second timer currently for periodic cleanup, and SIGHUP just sets a flag that that function reads. nod So changing policy back to doing a killall -HUP in %posttrans should work. It would be nice to know what Fedora versions are affected by this and whether it will someday be fixed before updating the Guidelines, though. -Toshio pgpttwMxOIzVA.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 07, 2010 at 06:59:29PM +0200, Pierre-Yves wrote: On Fri, 2010-05-07 at 09:38 -0400, Colin Walters wrote: On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves pin...@pingoured.fr wrote: Would it be allowed to try to restart gconfd ? It would make sense to SIGHUP gconfd after new schemas are installed, yes. Note though we should really only be doing this once at the end of a transaction when installation is complete. Thanks for your help, I will update the spec to do this. Would you have any advice/example on what would be the best way to do it ? Do you think it should be done on %postun as well ? Something like this: %posttrans killall -HUP gconfd-2 /dev/null || : You might want to switch to using the macros documented here at the same time:: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GConf I don't know which version of Fedora those went into GConf though. (Since this might be a regression in gconf2, you might need to still add the %posttrans scriptlet wth the new scriptlets. If Colin knows that this is %a bug that won't be fixed in some versions of Fedora I'll add the killall %to the appropriate point in the Guidelines.) -Toshio pgpLh9pVqz22z.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 7, 2010 at 1:17 PM, Toshio Kuratomi a.bad...@gmail.com wrote: Running makefile-install-schema and makefile-uninstall-schema eventually calls do_sync() which was supposed to reread the schemas. That's currently calling gconf_engine_suggest_sync() in gconf.c and I'm not sure whether there's some logic in there that could cause it not to suggest syncing in our current setup. I don't understand how this could ever work - GConf IPC happens in terms of ORBit which is per-uid, so a bare --makefile-install-rule might contact the GConf engine for uid 0 and ask it to reload, but that's it. It would have to jump through hoops to contact the GConf running as uid 500 or whatever, and I don't see those hoops being jumped. Oh but...I see, it's a Fedora patch not in the upstream GConf code to run killall. My bad looking at upstream gconf git. Sigh... So changing policy back to doing a killall -HUP in %posttrans should work. It would be nice to know what Fedora versions are affected by this and whether it will someday be fixed before updating the Guidelines, though. So though this still leaves a window of up to 30 seconds where after installing an application the schema will be invalid. Which seems very likely what people are hitting. I think ideally we'd have the RPM system detect a schema was installed and do an immediate reload once post transaction, and nuke the 30 second timeout from gconf. That still leaves though the problem of the massive copypaste scriptlets; we could remove the killall from --makefile-install-rule which would help. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 07, 2010 at 01:37:20PM -0400, Colin Walters wrote: On Fri, May 7, 2010 at 1:17 PM, Toshio Kuratomi a.bad...@gmail.com wrote: Running makefile-install-schema and makefile-uninstall-schema eventually calls do_sync() which was supposed to reread the schemas. That's currently calling gconf_engine_suggest_sync() in gconf.c and I'm not sure whether there's some logic in there that could cause it not to suggest syncing in our current setup. I don't understand how this could ever work - GConf IPC happens in terms of ORBit which is per-uid, so a bare --makefile-install-rule might contact the GConf engine for uid 0 and ask it to reload, but that's it. It would have to jump through hoops to contact the GConf running as uid 500 or whatever, and I don't see those hoops being jumped. Oh but...I see, it's a Fedora patch not in the upstream GConf code to run killall. My bad looking at upstream gconf git. Sigh... Ah I guess that's also why I thought the code had changed. Thought that was something we'd pushed upstream and subsequent changes had removed parts of it. So changing policy back to doing a killall -HUP in %posttrans should work. It would be nice to know what Fedora versions are affected by this and whether it will someday be fixed before updating the Guidelines, though. So though this still leaves a window of up to 30 seconds where after installing an application the schema will be invalid. Which seems very likely what people are hitting. Interesting -- so to test this we'd need: 1) Update package with new schema 2) Hopefully the package is the only thing being updated, otherwise, we could pass the timeout if no other schema-installing packages are also installed in the transaction. 3) Immediately try to invoke the program. The program then reads the old gconf schema and bails out or something. However, this would seem to mean that if the user just stops the program and restarts it after 30 seconds it should pick up the new schema. I think ideally we'd have the RPM system detect a schema was installed and do an immediate reload once post transaction, and nuke the 30 second timeout from gconf. That still leaves though the problem of the massive copypaste scriptlets; we could remove the killall from --makefile-install-rule which would help. The current scriptlets are pretty short... perhaps even too short :-( I had to look at the draft page for the gconf update to remember what they're doing behind the scenes. I remember panu and ffesti were exploring ideas in the area of autodetecting types of files that were installed and running scripts based on that but I don't know what they've found. -Toshio pgpS4qprgMAwK.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, 2010-05-07 at 17:25 -0400, Toshio Kuratomi wrote: I remember panu and ffesti were exploring ideas in the area of autodetecting types of files that were installed and running scripts based on that but I don't know what they've found. Link? This is an idea I have been meaning to push as a feature for a while, but I hadn't gotten around to it. I would be glad to join an existing effort. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, 2010-05-07 at 13:24 -0400, Toshio Kuratomi wrote: Something like this: %posttrans killall -HUP gconfd-2 /dev/null || : You might want to switch to using the macros documented here at the same time:: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GConf I have updated devel and F-13 to use the macro and only added the % posttrans for F-12 and F-11. Thanks for the help, Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GConf error
Hi,
Being the maintainer of Guake I have received a number of bug gconf
related [1]. Their common pattern is that they only appear the first
time guake is installed and run (and then again not always).
If the user restart X/the computer, the bug does not appear at all.
I am therefore quite unsure of what to do with these bugs. I asked
upstream who also is not sure. It is like if the gconf schema was not
correctly install while I install it via:
%post
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
gconftool-2 --makefile-install-rule \
%{_sysconfdir}/gconf/schemas/%{name}.schemas /dev/null || :
(cf [2] and [3] for build log)
Why am I doing wrong ?
Is this gconf issue ?
Thanks in advance,
Pierre
[1]
https://bugzilla.redhat.com/show_bug.cgi?id=575963
https://bugzilla.redhat.com/show_bug.cgi?id=589417
https://bugzilla.redhat.com/show_bug.cgi?id=571277
https://bugzilla.redhat.com/show_bug.cgi?id=571631
https://bugzilla.redhat.com/show_bug.cgi?id=573310
[2]
http://cvs.fedoraproject.org/viewvc/devel/guake/guake.spec?view=markup
[3]
http://koji.fedoraproject.org/koji/buildinfo?buildID=154417
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
