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
>
On Sun, May 09, 2010 at 11:56:27AM -0400, Colin Walters wrote:
> On Sat, May 8, 2010 at 2:22 PM, Toshio Kuratomi 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 inst
On Sat, May 8, 2010 at 2:22 PM, Toshio Kuratomi 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 suboptima
Okay, the patch is being applied with a significant offset but it still
looks like it's going to the right place.
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
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
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
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#GCo
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
On Fri, May 07, 2010 at 01:37:20PM -0400, Colin Walters wrote:
> On Fri, May 7, 2010 at 1:17 PM, Toshio Kuratomi 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
On Fri, May 7, 2010 at 1:17 PM, Toshio Kuratomi 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
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 wrote:
> > >
> > > Would it be allowed to try to restart gconfd ?
> >
> > It would make sense to SIGHUP gconfd after new schemas a
On Fri, May 07, 2010 at 12:15:20PM -0400, Colin Walters wrote:
> On Fri, May 7, 2010 at 12:05 PM, Toshio Kuratomi 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 wrote:
> >> >
> >> > Would it be allowed to try to restart g
On Fri, 2010-05-07 at 09:38 -0400, Colin Walters wrote:
> On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves 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 onc
On Fri, May 7, 2010 at 12:05 PM, Toshio Kuratomi 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 wrote:
>> >
>> > Would it be allowed to try to restart gconfd ?
>>
>> It would make sense to SIGHUP gconfd after new schemas are
On Fri, May 07, 2010 at 09:38:45AM -0400, Colin Walters wrote:
> On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves 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 t
On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves 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.
--
dev
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 c
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 unsur
18 matches
Mail list logo
