Message ID | 1349386039-817-1-git-send-email-gvaxon@gmail.com |
---|---|
State | Superseded |
Headers | show |
Valentine,
Thanks for all your great patches!
On Fri, 5 Oct 2012 01:27:19 +0400, Valentine Barshak wrote:
> This is a known issue, which has been fixed in glib 2.32.2.
Is there anything that prevents us from bumping libglib2 to this
version instead of backporting patches?
Best regards,
Thomas
On 10/05/2012 11:52 AM, Thomas Petazzoni wrote: > Valentine, Hi Thomas, > > Thanks for all your great patches! Thank you! I've been using buildroot for a while and I really like it. Just want to have as little deviations from the mainstream as possible :) > > On Fri, 5 Oct 2012 01:27:19 +0400, Valentine Barshak wrote: > >> This is a known issue, which has been fixed in glib 2.32.2. > > Is there anything that prevents us from bumping libglib2 to this > version instead of backporting patches? I tried to bump to 2.32.2 (and higher), but it didn't work for me. It doesn't build as is. It needs additional hacks to the libglib2-optional-ipv6.patch plus some minor configure script changes (at least). Even when I finally managed to build it, it didn't work. Starting any gtk application would result in no window being displayed. I've tried on a real x86 machine and vmware with no luck. It just hangs without displaying any errors or warnings. It's gonna take some time to debug. Probably some other packages have to be updated as well, I'm not sure. Since cherry-picking this single change worked fine for me, I've decided to stick with it at least for now. > > Best regards, > > Thomas > Thanks, Val.
On Fri, 05 Oct 2012 17:54:59 +0400, Valentine Barshak wrote: > > Thanks for all your great patches! > > Thank you! I've been using buildroot for a while and I really like it. > Just want to have as little deviations from the mainstream as > possible :) That's certainly a good motivation :) > > Is there anything that prevents us from bumping libglib2 to this > > version instead of backporting patches? > > I tried to bump to 2.32.2 (and higher), but it didn't work for me. > It doesn't build as is. It needs additional hacks to the > libglib2-optional-ipv6.patch plus some minor configure script changes > (at least). > > Even when I finally managed to build it, it didn't work. > Starting any gtk application would result in no window being > displayed. I've tried on a real x86 machine and vmware with no luck. > It just hangs without displaying any errors or warnings. > It's gonna take some time to debug. Probably some other packages > have to be updated as well, I'm not sure. > > Since cherry-picking this single change worked fine for me, I've > decided to stick with it at least for now. Argh, ok. I hope someone will find the time to fix this. It's not great to get stuck with older versions due to regressions. Best regards, Thomas
On 10/05/2012 06:03 PM, Thomas Petazzoni wrote: > > On Fri, 05 Oct 2012 17:54:59 +0400, Valentine Barshak wrote: > >>> Thanks for all your great patches! >> >> Thank you! I've been using buildroot for a while and I really like it. >> Just want to have as little deviations from the mainstream as >> possible :) > > That's certainly a good motivation :) > >>> Is there anything that prevents us from bumping libglib2 to this >>> version instead of backporting patches? >> >> I tried to bump to 2.32.2 (and higher), but it didn't work for me. >> It doesn't build as is. It needs additional hacks to the >> libglib2-optional-ipv6.patch plus some minor configure script changes >> (at least). >> >> Even when I finally managed to build it, it didn't work. >> Starting any gtk application would result in no window being >> displayed. I've tried on a real x86 machine and vmware with no luck. >> It just hangs without displaying any errors or warnings. >> It's gonna take some time to debug. Probably some other packages >> have to be updated as well, I'm not sure. >> >> Since cherry-picking this single change worked fine for me, I've >> decided to stick with it at least for now. > > Argh, ok. I hope someone will find the time to fix this. It's not great > to get stuck with older versions due to regressions. Yeah, it would be better to move to the newer version, but it might take some time, since it doesn't seem to work as is. Meanwhile, can we have this fix? Thanks, Val. > > Best regards, > > Thomas >
Dear Valentine Barshak, On Wed, 10 Oct 2012 02:50:53 +0400, Valentine Barshak wrote: > > Argh, ok. I hope someone will find the time to fix this. It's not great > > to get stuck with older versions due to regressions. > > Yeah, it would be better to move to the newer version, but it might take > some time, since it doesn't seem to work as is. > > Meanwhile, can we have this fix? Yes, I don't have any problem getting this fix in until someone bumps libglib2 to a newer version. Thomas
diff --git a/package/libglib2/libglib2-gmain-block-child-sources-when-blocking-the-parent.patch b/package/libglib2/libglib2-gmain-block-child-sources-when-blocking-the-parent.patch new file mode 100644 index 0000000..58671fd --- /dev/null +++ b/package/libglib2/libglib2-gmain-block-child-sources-when-blocking-the-parent.patch @@ -0,0 +1,100 @@ +This should fix midori save file dialog not being displayed. +Backported from the following changes: + +From ffb000e37be998df55d446c85edbc440fad06a17 Mon Sep 17 00:00:00 2001 +From: Dan Winship <danw@gnome.org> +Date: Wed, 11 Apr 2012 15:21:17 -0400 +Subject: [PATCH] gmain: block child sources when blocking the parent + +When blocking a source that has child sources, we need to consider the +children blocked as well. Otherwise they will still trigger repeatedly +in an inner loop started from the parent source's callback. + +https://bugzilla.gnome.org/show_bug.cgi?id=669260 +diff -pruN glib-2.30.2.orig/glib/gmain.c glib-2.30.2/glib/gmain.c +--- glib-2.30.2.orig/glib/gmain.c 2011-11-11 21:56:52.000000000 +0400 ++++ glib-2.30.2/glib/gmain.c 2012-09-22 03:41:07.686442208 +0400 +@@ -185,7 +185,8 @@ typedef struct _GSourceCallback GSourceC + typedef enum + { + G_SOURCE_READY = 1 << G_HOOK_FLAG_USER_SHIFT, +- G_SOURCE_CAN_RECURSE = 1 << (G_HOOK_FLAG_USER_SHIFT + 1) ++ G_SOURCE_CAN_RECURSE = 1 << (G_HOOK_FLAG_USER_SHIFT + 1), ++ G_SOURCE_BLOCKED = 1 << (G_HOOK_FLAG_USER_SHIFT + 2) + } GSourceFlags; + + #ifdef G_THREADS_ENABLED +@@ -323,8 +324,7 @@ struct _GSourcePrivate + #endif + + #define SOURCE_DESTROYED(source) (((source)->flags & G_HOOK_FLAG_ACTIVE) == 0) +-#define SOURCE_BLOCKED(source) (((source)->flags & G_HOOK_FLAG_IN_CALL) != 0 && \ +- ((source)->flags & G_SOURCE_CAN_RECURSE) == 0) ++#define SOURCE_BLOCKED(source) (((source)->flags & G_SOURCE_BLOCKED) != 0) + + #define SOURCE_UNREF(source, context) \ + G_STMT_START { \ +@@ -2352,12 +2352,24 @@ block_source (GSource *source) + + g_return_if_fail (!SOURCE_BLOCKED (source)); + ++ source->flags |= G_SOURCE_BLOCKED; ++ + tmp_list = source->poll_fds; + while (tmp_list) + { + g_main_context_remove_poll_unlocked (source->context, tmp_list->data); + tmp_list = tmp_list->next; + } ++ ++ if (source->priv && source->priv->child_sources) ++ { ++ tmp_list = source->priv->child_sources; ++ while (tmp_list) ++ { ++ block_source (tmp_list->data); ++ tmp_list = tmp_list->next; ++ } ++ } + } + + /* HOLDS: source->context's lock */ +@@ -2366,15 +2378,27 @@ unblock_source (GSource *source) + { + GSList *tmp_list; + +- g_return_if_fail (!SOURCE_BLOCKED (source)); /* Source already unblocked */ ++ g_return_if_fail (SOURCE_BLOCKED (source)); /* Source already unblocked */ + g_return_if_fail (!SOURCE_DESTROYED (source)); + ++ source->flags &= ~G_SOURCE_BLOCKED; ++ + tmp_list = source->poll_fds; + while (tmp_list) + { + g_main_context_add_poll_unlocked (source->context, source->priority, tmp_list->data); + tmp_list = tmp_list->next; + } ++ ++ if (source->priv && source->priv->child_sources) ++ { ++ tmp_list = source->priv->child_sources; ++ while (tmp_list) ++ { ++ unblock_source (tmp_list->data); ++ tmp_list = tmp_list->next; ++ } ++ } + } + + /* HOLDS: context's lock */ +@@ -2453,8 +2477,7 @@ g_main_dispatch (GMainContext *context) + if (!was_in_call) + source->flags &= ~G_HOOK_FLAG_IN_CALL; + +- if ((source->flags & G_SOURCE_CAN_RECURSE) == 0 && +- !SOURCE_DESTROYED (source)) ++ if (SOURCE_BLOCKED (source) && !SOURCE_DESTROYED (source)) + unblock_source (source); + + /* Note: this depends on the fact that we can't switch