freeze break request
A change in GTK+ caused the scales in the zoom options dialog to shrink into nothingness, which makes them pretty unusable. I've put a fix in https://bugzilla.gnome.org/show_bug.cgi?id=708493 and would like to request a freeze break for it. ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: freeze break request: fix control-center deadlock w/magnifier running
On Fri, Sep 20, 2013 at 4:51 PM, Mike Gorse wrote: > Hi all, > > Some background: Late in the cycle, some improvements to the magnifier were > committed to gnome-shell; the GSoC project of Magdalen Berns (BGO#647074). > Giovanni discovered a few days ago that starting gnome-control-center and > switching to the display panel now resulted in the desktop freezing for up > to 30 seconds. He then made a commit to gnome-shell so that it would not > start the magnifier unless it was actually used. Jasper felt that the > underlying bug should be fixed and tried to convince Giovanni to revert his > commit, although now it would require a freeze break request to do so, and > he has not made one--I don't know if he plans on doing so. The bug still > affects users of the magnifier; it doesn't affect all GNOME users unless > Giovanni's commit is reverted. > > The problem is that gnome-control-center is making a synchronous D-Bus call > to gnome-shell to get information on the monitor, and the new gnome-shell > focus caret tracker responds to the focus changing by making a synchronous > D-Bus call to gnome-control-center. The processes deadlock waiting on each > other until the AT-SPI call times out. > > I filed https://bugzilla.gnome.org/show_bug.cgi?id=708387 for this. > > There are a few options for handling this, and what makes the most sense > might depend in part on whether the "don't start the magnifier unless it is > needed" commit gets reverted. > > I've made patches for at-spi2-core and at-spi2-atk (attached, and added to > the bug) that fix the issue for me. They start to move in the direction that > I think we should take for 3.12 (reduce the need for synchronous D-Bus > calls--for instance, when sending an event, also send the information that > the AT will need in order to process the event, rather than make the AT > request the information). Ideally this should be configurable, but this > patch sends the information that gnome-shell's state-changed:focused handler > needs, avoiding the need for it to make calls over D-Bus. Having these > patches in 3.10 would be nice since they eliminate the deadlock completely > and don't cause the magnifier's calls to time out and fail, but they aren't > trivial patches. > > Alternatively, gnome-shell could lower AT-SPI's timeout values (also > attached a patch to do this). This would make the AT-SPI calls time out > after a relatively short amount of time, mitigating the impact of the > deadlock, although it would not eliminate it (the number of users impacted > on this would depend on whether or not Giovanni's commit stays), and the > magnifier may behave incorrectly when switching to the display panel in > gnome-control-center. It would also increase the likelihood that a call > would time out if an app is busy, although I picked a timeout of 250 ms > fairly arbitrarily as a timeout that would have a relatively small impact in > the case of a deadlock. > > Committing both sets of patches would also be an option in case there are > other deadlocks that we don't know about (I haven't tried to account for the > listener that is activated when the text caret moves, although I'm guessing > that that is less likely to result in a D-Bus query to gnome-shell than > would a focus change). We need to fix this more properly, but that will have > to wait for 3.12. Hey Mike, thanks for all this background information, that is really useful. I can easily reproduce the 30 second hang with .92 - it is really uncomfortable, because the compositor stops drawing - it feels like the system is entirely frozen. We clearly need to do something for 3.10. I do think that your idea of sending relevant information along with the events is the right fix in principle - avoiding roundtrips, etc. But looking at the non-trivial nature of the patches in multiple modules, I would say that the one-line timeout reduction in the shell is the safer choice for 3.10. I've tested that fix, and with it, the behaviour is very much acceptable. So, my suggestion is: use the one-line timeout fix in gnome-shell for 3.10, and do the proper fix in 3.11. ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Orca code freeze break request (yeah, one more)
Matthias Clasen wrote: > On Fri, Sep 20, 2013 at 4:49 PM, Joanmarie Diggs wrote: > > Greetings release team! > > > > I have been testing our shiny new gnome-software with Orca and filing > > bugs based on my findings for Matthias. Turns out one of the bugs was > > mine. (Oops). > > > > It's another one-line safe fix which causes Orca to present the presence > > of a necessary GtkButton so users know they can remove/install the > > selected item. > > > > If y'all would be so kind as to grant me a(nother) freeze break, I'd > > appreciate it. > > > > https://bugzilla.gnome.org/show_bug.cgi?id=708497 > > > > Looks fine to me, +1 Sure. 2. Fred ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break request for the control-center
On Fri, 2013-09-20 at 12:19 -0400, Matthias Clasen wrote: > We have a new display panel in the control-center this cycle. > The early feedback we got on it indicates that many people miss the > 'off' button. To avoid unnecessary blowback and controversy of the > 'gnome always removes options, freedom!!!@" kind, > https://bugzilla.gnome.org/show_bug.cgi?id=707570 adds back an option > to turn a monitor off. I have tested the patch, it works fine. Docs team really should be notified for this kind of change. Added to CC. -- Shaun ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
freeze break request: fix control-center deadlock w/magnifier running
Hi all, Some background: Late in the cycle, some improvements to the magnifier were committed to gnome-shell; the GSoC project of Magdalen Berns (BGO#647074). Giovanni discovered a few days ago that starting gnome-control-center and switching to the display panel now resulted in the desktop freezing for up to 30 seconds. He then made a commit to gnome-shell so that it would not start the magnifier unless it was actually used. Jasper felt that the underlying bug should be fixed and tried to convince Giovanni to revert his commit, although now it would require a freeze break request to do so, and he has not made one--I don't know if he plans on doing so. The bug still affects users of the magnifier; it doesn't affect all GNOME users unless Giovanni's commit is reverted. The problem is that gnome-control-center is making a synchronous D-Bus call to gnome-shell to get information on the monitor, and the new gnome-shell focus caret tracker responds to the focus changing by making a synchronous D-Bus call to gnome-control-center. The processes deadlock waiting on each other until the AT-SPI call times out. I filed https://bugzilla.gnome.org/show_bug.cgi?id=708387 for this. There are a few options for handling this, and what makes the most sense might depend in part on whether the "don't start the magnifier unless it is needed" commit gets reverted. I've made patches for at-spi2-core and at-spi2-atk (attached, and added to the bug) that fix the issue for me. They start to move in the direction that I think we should take for 3.12 (reduce the need for synchronous D-Bus calls--for instance, when sending an event, also send the information that the AT will need in order to process the event, rather than make the AT request the information). Ideally this should be configurable, but this patch sends the information that gnome-shell's state-changed:focused handler needs, avoiding the need for it to make calls over D-Bus. Having these patches in 3.10 would be nice since they eliminate the deadlock completely and don't cause the magnifier's calls to time out and fail, but they aren't trivial patches. Alternatively, gnome-shell could lower AT-SPI's timeout values (also attached a patch to do this). This would make the AT-SPI calls time out after a relatively short amount of time, mitigating the impact of the deadlock, although it would not eliminate it (the number of users impacted on this would depend on whether or not Giovanni's commit stays), and the magnifier may behave incorrectly when switching to the display panel in gnome-control-center. It would also increase the likelihood that a call would time out if an app is busy, although I picked a timeout of 250 ms fairly arbitrarily as a timeout that would have a relatively small impact in the case of a deadlock. Committing both sets of patches would also be an option in case there are other deadlocks that we don't know about (I haven't tried to account for the listener that is activated when the text caret moves, although I'm guessing that that is less likely to result in a D-Bus query to gnome-shell than would a focus change). We need to fix this more properly, but that will have to wait for 3.12. Thanks, -MikeFrom f9a2201ea0fc9f703a3d20efaf99f18b4b2b2652 Mon Sep 17 00:00:00 2001 From: Mike Gorse Date: Fri, 20 Sep 2013 12:05:05 -0500 Subject: [PATCH] Cache interfaces and extents sent from events Events may now send a list of properties to avoid the need to call out to get information that could be delivered up-front with the event. This will improve performance slightly and is particularly useful in cases where the AT-SPI client may need to respond to non-AT-SPI queries from other processes, creating the possibility of a deadlock. This change is sufficient to allow gnome-shell's focus caret tracker to process state-changed:focused events without needing to make D-Bus method calls. https://bugzilla.gnome.org/show_bug.cgi?id=708387 --- atspi/Makefile.am| 1 + atspi/atspi-accessible-private.h | 40 ++ atspi/atspi-accessible.c | 7 +- atspi/atspi-accessible.h | 3 +++ atspi/atspi-component.c | 6 ++ atspi/atspi-event-listener.c | 46 +++- atspi/atspi-misc.c | 5 + 7 files changed, 106 insertions(+), 2 deletions(-) create mode 100644 atspi/atspi-accessible-private.h diff --git a/atspi/Makefile.am b/atspi/Makefile.am index 2cb21da..bd5b279 100644 --- a/atspi/Makefile.am +++ b/atspi/Makefile.am @@ -54,6 +54,7 @@ libatspi_la_SOURCES = \ atspi.h \ atspi-accessible.c \ atspi-accessible.h \ + atspi-accessible-private.h \ atspi-action.c \ atspi-action.h \ atspi-application.c \ diff --git a/atspi/atspi-accessible-private.h b/atspi/atspi-accessible-private.h new file mode 100644 index 000..3e8499b --- /dev/null +++ b/atspi/atspi-accessible-private.h @@ -0,0 +1,40
Re: Orca code freeze break request (yeah, one more)
On Fri, Sep 20, 2013 at 4:49 PM, Joanmarie Diggs wrote: > Greetings release team! > > I have been testing our shiny new gnome-software with Orca and filing > bugs based on my findings for Matthias. Turns out one of the bugs was > mine. (Oops). > > It's another one-line safe fix which causes Orca to present the presence > of a necessary GtkButton so users know they can remove/install the > selected item. > > If y'all would be so kind as to grant me a(nother) freeze break, I'd > appreciate it. > > https://bugzilla.gnome.org/show_bug.cgi?id=708497 > Looks fine to me, +1 ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Orca code freeze break request (yeah, one more)
Greetings release team! I have been testing our shiny new gnome-software with Orca and filing bugs based on my findings for Matthias. Turns out one of the bugs was mine. (Oops). It's another one-line safe fix which causes Orca to present the presence of a necessary GtkButton so users know they can remove/install the selected item. If y'all would be so kind as to grant me a(nother) freeze break, I'd appreciate it. https://bugzilla.gnome.org/show_bug.cgi?id=708497 --joanie ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break request for Bluetooth crashers
> gnome-bluetooth bug: > https://bugzilla.gnome.org/show_bug.cgi?id=708477 > > gnome-control-center bug: > https://bugzilla.gnome.org/show_bug.cgi?id=708478 The patches all look correct to me. +1 ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break request for gnome-desktop
On Fri, Sep 20, 2013 at 8:40 AM, Bastien Nocera wrote: > This is a fix for a crasher in nautilus: > https://bugzilla.gnome.org/show_bug.cgi?id=708435 +1 from me. colin said on irc that his review of the patch should count as another +1, so good to go. ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Freeze break request for Bluetooth crashers
This fixes a number of bugs that occurred when leaving the Bluetooth panel, after you'd have interacted with a device's connection status for example. gnome-bluetooth bug: https://bugzilla.gnome.org/show_bug.cgi?id=708477 gnome-control-center bug: https://bugzilla.gnome.org/show_bug.cgi?id=708478 Cheers ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Freeze break request for the control-center
We have a new display panel in the control-center this cycle. The early feedback we got on it indicates that many people miss the 'off' button. To avoid unnecessary blowback and controversy of the 'gnome always removes options, freedom!!!@" kind, https://bugzilla.gnome.org/show_bug.cgi?id=707570 adds back an option to turn a monitor off. I have tested the patch, it works fine. The patch adds two new strings, "Turn off" "Don't use this display" ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Nautilus search provider hard code freeze break request, bug 692041
On 2013-09-20 18:16, Andre Klapper wrote: r-t approval 1 of 2 (or 2 of 2, depending on what Matthias said). Thanks! Pushed: https://git.gnome.org/browse/nautilus/commit/?id=2e67887344aa9e347d30d0b2c69fb8c84c23b9da -- http://amigadave.com/ signature.asc Description: Digital signature ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break request for the control-center
2013/9/20 Matthias Clasen : > We have a new display panel in the control-center this cycle. > The early feedback we got on it indicates that many people miss the > 'off' button. To avoid unnecessary blowback and controversy of the > 'gnome always removes options, freedom!!!@" kind, > https://bugzilla.gnome.org/show_bug.cgi?id=707570 adds back an option > to turn a monitor off. I have tested the patch, it works fine. > > The patch adds two new strings, > > "Turn off" > "Don't use this display" 1/2 from i18n. -- Piotr Drąg http://raven.fedorapeople.org/ ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break request for the control-center
Le vendredi 20 septembre 2013 à 18:25 +0200, Piotr Drąg a écrit : > 2013/9/20 Matthias Clasen : > > We have a new display panel in the control-center this cycle. > > The early feedback we got on it indicates that many people miss the > > 'off' button. To avoid unnecessary blowback and controversy of the > > 'gnome always removes options, freedom!!!@" kind, > > https://bugzilla.gnome.org/show_bug.cgi?id=707570 adds back an option > > to turn a monitor off. I have tested the patch, it works fine. > > > > The patch adds two new strings, > > > > "Turn off" > > "Don't use this display" > > 1/2 from i18n. 2/2. Claude ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Nautilus search provider hard code freeze break request, bug 692041
On Fri, Sep 20, 2013 at 11:47 AM, David King wrote: > Hi > > Currently, Nautilus does not give any results when searching from the > activities overview in the shell. The bug is on the blocker list for 3.10: > > https://bugzilla.gnome.org/show_bug.cgi?id=692041 > > I have a quite small and simple patch attached to the above bug, which > corrects the return types and values of some gdbus skeleton method handlers, > as these were missing before. Matthias Clasen has already approved it, and I > have tested it locally as well as with a test build in Koji on a Fedora 20 > system. It seems to work fine, and I get search results again. > I already gave my +1 in the bug, indeed. ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Nautilus search provider hard code freeze break request, bug 692041
On Fri, 2013-09-20 at 16:47 +0100, David King wrote: > Currently, Nautilus does not give any results when searching from the > activities overview in the shell. The bug is on the blocker list for > 3.10: > > https://bugzilla.gnome.org/show_bug.cgi?id=692041 > > I have a quite small and simple patch attached to the above bug, which > corrects the return types and values of some gdbus skeleton method > handlers, as these were missing before. Matthias Clasen has already > approved it, and I have tested it locally as well as with a test build > in Koji on a Fedora 20 system. It seems to work fine, and I get search > results again. r-t approval 1 of 2 (or 2 of 2, depending on what Matthias said). andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Nautilus search provider hard code freeze break request, bug 692041
Hi
Currently, Nautilus does not give any results when searching from the
activities overview in the shell. The bug is on the blocker list for
3.10:
https://bugzilla.gnome.org/show_bug.cgi?id=692041
I have a quite small and simple patch attached to the above bug, which
corrects the return types and values of some gdbus skeleton method
handlers, as these were missing before. Matthias Clasen has already
approved it, and I have tested it locally as well as with a test build
in Koji on a Fedora 20 system. It seems to work fine, and I get search
results again.
--
http://amigadave.com/
From 2e67887344aa9e347d30d0b2c69fb8c84c23b9da Mon Sep 17 00:00:00 2001
From: David King
Date: Fri, 20 Sep 2013 15:28:47 +0100
Subject: [PATCH] search-provider: Return TRUE from GDBus method handlers
As Matthias Clasen noticed, the signal handlers for the gdbus-codegen
skeleton for the shell search provider have the wrong signature, and
should return TRUE to indicate that the signal has been handled.
Otherwise, it is down to chance if the method is handled or if a
method-not-implemented error is emitted. It seems that the GCC option
-fstack-protector-strong causes the default return value to be
interpreted as FALSE, so this might explain why the problem was only
noticed by a wide variety of users recently.
The bug manifests as Nautilus not returning any search results when
using the gnome-shell activities overview search.
https://bugzilla.gnome.org/show_bug.cgi?id=692041
---
src/nautilus-shell-search-provider.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/nautilus-shell-search-provider.c b/src/nautilus-shell-search-provider.c
index 449ab70..d127115 100644
--- a/src/nautilus-shell-search-provider.c
+++ b/src/nautilus-shell-search-provider.c
@@ -438,7 +438,7 @@ execute_search (NautilusShellSearchProvider *self,
g_free (terms_joined);
}
-static void
+static gboolean
handle_get_initial_result_set (NautilusShellSearchProvider2 *skeleton,
GDBusMethodInvocation *invocation,
gchar**terms,
@@ -448,9 +448,10 @@ handle_get_initial_result_set (NautilusShellSearchProvider2 *skeleton,
g_debug ("** GetInitialResultSet");
execute_search (self, invocation, terms);
+ return TRUE;
}
-static void
+static gboolean
handle_get_subsearch_result_set (NautilusShellSearchProvider2 *skeleton,
GDBusMethodInvocation *invocation,
gchar**previous_results,
@@ -461,6 +462,7 @@ handle_get_subsearch_result_set (NautilusShellSearchProvider2 *skeleton,
g_debug ("** GetSubSearchResultSet");
execute_search (self, invocation, terms);
+ return TRUE;
}
typedef struct {
@@ -570,7 +572,7 @@ result_list_attributes_ready_cb (GList*file_list,
result_metas_data_free (data);
}
-static void
+static gboolean
handle_get_result_metas (NautilusShellSearchProvider2 *skeleton,
GDBusMethodInvocation *invocation,
gchar**results,
@@ -601,7 +603,7 @@ handle_get_result_metas (NautilusShellSearchProvider2 *skeleton,
if (missing_files == NULL) {
result_metas_return_from_cache (data);
result_metas_data_free (data);
-return;
+return TRUE;
}
nautilus_file_list_call_when_ready (missing_files,
@@ -610,9 +612,10 @@ handle_get_result_metas (NautilusShellSearchProvider2 *skeleton,
result_list_attributes_ready_cb,
data);
nautilus_file_list_free (missing_files);
+ return TRUE;
}
-static void
+static gboolean
handle_activate_result (NautilusShellSearchProvider2 *skeleton,
GDBusMethodInvocation*invocation,
gchar*result,
@@ -632,9 +635,10 @@ handle_activate_result (NautilusShellSearchProvider2 *skeleton,
}
nautilus_shell_search_provider2_complete_activate_result (skeleton, invocation);
+ return TRUE;
}
-static void
+static gboolean
handle_launch_search (NautilusShellSearchProvider2 *skeleton,
GDBusMethodInvocation*invocation,
gchar **terms,
@@ -652,6 +656,7 @@ handle_launch_search (NautilusShellSearchProvider2 *skeleton,
g_free (uri);
nautilus_shell_search_provider2_complete_launch_search (skeleton, invocation);
+ return TRUE;
}
static void
--
1.8.3.1
signature.asc
Description: Digital signature
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.
Re: Empathy: hardcode freeze break request - bgo#708403
On Fri, 2013-09-20 at 10:58 -0400, Matthias Clasen wrote: > On Fri, Sep 20, 2013 at 10:39 AM, Guillaume Desmottes > wrote: > > Hi guys, > > > > Would it be ok to merge > > https://bugzilla.gnome.org/review?bug=708403&attachment=255342 to > > empathy master? > > > > It fixes https://bugzilla.gnome.org/show_bug.cgi?id=708403 causing > > crashes on some system (not mine for some reason so I didn't catch it > > earlier). > > Trivial fix, +1 Approval 2 of 2, as I already wrote on the ticket. andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Empathy: hardcode freeze break request - bgo#708403
On Fri, Sep 20, 2013 at 10:39 AM, Guillaume Desmottes wrote: > Hi guys, > > Would it be ok to merge > https://bugzilla.gnome.org/review?bug=708403&attachment=255342 to > empathy master? > > It fixes https://bugzilla.gnome.org/show_bug.cgi?id=708403 causing > crashes on some system (not mine for some reason so I didn't catch it > earlier). Trivial fix, +1 ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Empathy: hardcode freeze break request - bgo#708403
Hi guys, Would it be ok to merge https://bugzilla.gnome.org/review?bug=708403&attachment=255342 to empathy master? It fixes https://bugzilla.gnome.org/show_bug.cgi?id=708403 causing crashes on some system (not mine for some reason so I didn't catch it earlier). thanks! G. ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Orca code freeze break request
On Fri, 2013-09-20 at 08:23 -0400, Matthias Clasen wrote: > On Fri, Sep 20, 2013 at 8:05 AM, Joanmarie Diggs wrote: > > It turns out that when you get into Orca's preferences and then cancel > > out of them, Orca is not cleaning up after itself and leaving > > unused/unneeded speech-dispatcher threads running. This can be fixed > > safely with a one-line change. Therefore I am requesting code freeze break. > > > > https://bugzilla.gnome.org/show_bug.cgi?id=707708 > > > > Hey, I marked this as 3.10 blocker because I thought it was always > happening - if it only occurs in very specific circumstances > (cancelling preferences), it may not be that bad. But since you have a > safe fix now, +1 from me. ...and a second +1. andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Freeze break request for gnome-desktop
This is a fix for a crasher in nautilus: https://bugzilla.gnome.org/show_bug.cgi?id=708435 Cheers ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Orca code freeze break request
On Fri, Sep 20, 2013 at 8:05 AM, Joanmarie Diggs wrote: > Hey all. > > It turns out that when you get into Orca's preferences and then cancel > out of them, Orca is not cleaning up after itself and leaving > unused/unneeded speech-dispatcher threads running. This can be fixed > safely with a one-line change. Therefore I am requesting code freeze break. > > https://bugzilla.gnome.org/show_bug.cgi?id=707708 > Hey, I marked this as 3.10 blocker because I thought it was always happening - if it only occurs in very specific circumstances (cancelling preferences), it may not be that bad. But since you have a safe fix now, +1 from me. ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Orca code freeze break request
Hey all. It turns out that when you get into Orca's preferences and then cancel out of them, Orca is not cleaning up after itself and leaving unused/unneeded speech-dispatcher threads running. This can be fixed safely with a one-line change. Therefore I am requesting code freeze break. https://bugzilla.gnome.org/show_bug.cgi?id=707708 Sorry and thanks. --joanie ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
gst-plugins-base 1.1.90
ChangeLog = 2013-09-19 Sebastian Dröge * configure.ac: releasing 1.1.90 2013-09-18 20:42:55 -0400 Olivier Crête * gst-libs/gst/video/gstvideodecoder.c: videodecoder: If there is no PTS at all, assume it starts from the segment start This is to make the multifilesrc ! pngdec case work https://bugzilla.gnome.org/show_bug.cgi?id=688043 2013-09-19 09:44:47 +0200 Sebastian Dröge * po/af.po: * po/az.po: * po/bg.po: * po/ca.po: * po/cs.po: * po/da.po: * po/de.po: * po/el.po: * po/en_GB.po: * po/eo.po: * po/es.po: * po/eu.po: * po/fi.po: * po/fr.po: * po/gl.po: * po/hr.po: * po/hu.po: * po/id.po: * po/it.po: * po/ja.po: * po/lt.po: * po/lv.po: * po/nb.po: * po/nl.po: * po/or.po: * po/pl.po: * po/pt_BR.po: * po/ro.po: * po/ru.po: * po/sk.po: * po/sl.po: * po/sq.po: * po/sr.po: * po/sv.po: * po/tr.po: * po/uk.po: * po/vi.po: * po/zh_CN.po: po: Update translations 2013-09-18 22:05:36 +0200 Sebastian Dröge * gst/playback/gstplaybin2.c: playbin: Implement context caching for sinks that are not in playsink yet 2013-09-18 18:21:54 +0200 Sebastian Dröge * gst/playback/gstplaybin2.c: playbin: No need to set the GstContext on the sink before activating it This is all handled by the GstBin code now. 2013-09-04 20:21:54 -0400 Olivier Crête * gst-libs/gst/allocators/gstdmabuf.c: * gst-libs/gst/allocators/gstdmabuf.h: dmabuf: Make it not a singleton Makes it easier to track how many users there are Also make it possible to create a dmabuf struct on systems without mmap, it just won't be possible to map it. https://bugzilla.gnome.org/show_bug.cgi?id=707793 2013-09-13 16:01:42 +0200 Wim Taymans * gst-libs/gst/rtp/gstrtpbuffer.c: rtpbuffer: check for valid payload type The payload type can't be between 72 and 76 because with the marker bit set, this could be mistaken for an RTCP packet then. We do a relaxed check and only refuse 72-76 when the marker bit is set. The effect is that when we try to map an RTCP packet as an RTP packet, we will certainly fail. 2013-09-13 09:17:38 +0100 Tim-Philipp Müller * configure.ac: configure: rely solely on pkg-config to find libogg and libvorbis And get rid of AS_SCRUB_INCLUDES https://bugzilla.gnome.org/show_bug.cgi?id=707658 2013-09-12 12:23:35 +0200 Wim Taymans * gst/videoscale/vs_4tap.c: videoscale: fix 4tap for RGB15 and RGB16 Fix component ordering, it's wrong in both the scanline and merge function so it cancels eachother out and isn't really a except for loss of precision of the green component. Fix calculation of the filter weight 2013-09-10 17:02:44 +0200 Wim Taymans * gst/videoscale/vs_scanline.c: videoscale: optimize merge for RGB15 and RGB16 2013-09-10 16:55:25 +0200 Wim Taymans * gst/videoscale/vs_4tap.c: videoscale: remove redundant MAX The checks above make it inpossible for the value to be smaller than what we check against with the MAX call. 2013-09-12 09:42:36 +0200 Sebastian Dröge * gst-libs/gst/audio/gstaudiodecoder.c: * gst-libs/gst/audio/gstaudioencoder.c: audioencoder/decoder: Mark pads as requiring reconfiguration again if negotiation fails Otherwise we might end up in non-optimal configuration, especially when a flush happened during reconfiguration. 2013-09-12 09:35:00 +0200 Sebastian Dröge * gst-libs/gst/video/gstvideodecoder.c: * gst-libs/gst/video/gstvideoencoder.c: videodecoder/videoencoder: Mark pads as requiring reconfiguration again if negotiation fails Otherwise we might end up in non-optimal configuration, especially when a flush happened during reconfiguration. 2013-09-10 21:44:33 +0200 Matej Knopp * gst-libs/gst/pbutils/descriptions.c: pbutils: Add description for TechSmith Screen Capture 2 https://bugzilla.gnome.org/show_bug.cgi?id=707878 2013-09-10 21:44:21 +0200 Matej Knopp * gst-libs/gst/riff/riff-media.c: riff: Add support for TechSmith Screen Capture 2 https://bugzilla.gnome.org/show_bug.cgi?id=707878 2013-09-06 15:36:12 -0300 Thiago Santos * ext/ogg/gstoggdemux.c: oggdemux: check for full eos after a pad goes eos in push mode After a pad is on EOS, verify if all pads are EOS and return upstream, avoiding keeping
gstreamer 1.1.90
ChangeLog = 2013-09-19 Sebastian Dröge * configure.ac: releasing 1.1.90 2013-09-19 09:49:40 +0200 Sebastian Dröge * docs/gst/gstreamer-sections.txt: * gst/gstcontext.c: * gst/gstcontext.h: * win32/common/libgstreamer.def: context: Add convenience function gst_context_has_context_type() 2013-09-19 09:42:15 +0200 Sebastian Dröge * po/af.po: * po/az.po: * po/be.po: * po/bg.po: * po/ca.po: * po/cs.po: * po/da.po: * po/de.po: * po/el.po: * po/en_GB.po: * po/eo.po: * po/es.po: * po/eu.po: * po/fi.po: * po/fr.po: * po/gl.po: * po/hr.po: * po/hu.po: * po/id.po: * po/it.po: * po/ja.po: * po/lt.po: * po/nb.po: * po/nl.po: * po/pl.po: * po/pt_BR.po: * po/ro.po: * po/ru.po: * po/rw.po: * po/sk.po: * po/sl.po: * po/sq.po: * po/sr.po: * po/sv.po: * po/tr.po: * po/uk.po: * po/vi.po: * po/zh_CN.po: * po/zh_TW.po: po: Update translations 2013-09-18 23:07:31 +0200 Sebastian Dröge * gst/gstmessage.c: message: Implement getting the name of the context message types 2013-09-17 21:36:22 +0200 Sebastian Dröge * gst/gstcontext.c: * gst/gstmessage.c: * gst/gstquery.c: * tests/check/gst/gstcontext.c: context: Fix unit test for GstContext changes 2013-09-17 14:34:47 +0200 Sebastian Dröge * tools/gst-launch.c: gst-launch: Update for GstContext changes 2013-09-17 14:29:06 +0200 Sebastian Dröge * docs/gst/gstreamer-sections.txt: * win32/common/libgstreamer.def: context: Update docs 2013-09-17 14:25:10 +0200 Sebastian Dröge * gst/gstbin.c: bin: Implement context caching and propagation again 2013-09-17 13:50:08 +0200 Sebastian Dröge * gst/gstmessage.c: * gst/gstmessage.h: * gst/gstquark.c: * gst/gstquark.h: * gst/gstquery.c: * gst/gstquery.h: message/query: Simplify CONTEXT messages/queries to only contain a single type 2013-09-17 13:33:33 +0200 Sebastian Dröge * docs/design/part-context.txt: * gst/gstcontext.c: context: Update documentation 2013-09-17 13:28:42 +0200 Sebastian Dröge * gst/gstcontext.c: * gst/gstcontext.h: * gst/gstinfo.c: context: Change GstContext to contain only a single context It was unintuitive that GstContext was actually a list of different contexts. GstContext now is only a type string and a structure to contain the actual context. 2013-09-17 13:12:28 +0200 Sebastian Dröge * gst/gstbin.c: * gst/gstelement.c: * gst/gstelement.h: element: Remove GstContext caching 2013-09-17 13:10:53 +0200 Sebastian Dröge * gst/gstcontext.c: * gst/gstcontext.h: context: Add persistent qualifier for a context Non-persistent contexts are removed when elements go back to NULL state, persistent contexts are not. Applications most likely want to set persistent contexts. 2013-09-17 13:10:16 +0200 Sebastian Dröge * gst/gstquery.h: query: Make CONTEXT query upstream and downstream 2013-09-17 13:09:34 +0200 Sebastian Dröge * gst/gstevent.c: * gst/gstevent.h: * gst/gstquark.c: * gst/gstquark.h: event: Remove CONTEXT downstream event This is going to be implemented with an upstream query instead for consistency and simplicity. 2013-09-13 14:41:45 +0200 Jonas Holmberg * gst/gst.c: gst: Stop all unused threads in GThreadPool in gst_deinit() Since the default number of max unused threads in GThreadPool has been changed from 0 to 2 it needs to be set to 0 to stop all threads or valgrind will report them as memory leaks. 2013-09-10 16:39:30 +0100 Rico Tzschichholz * libs/gst/controller/gstargbcontrolbinding.c: * libs/gst/controller/gstdirectcontrolbinding.c: controlbindings: fix pspec relaxation for control source properties The change should have been from PARAM_CONSTRUCT_ONLY to PARAM_CONSTRUCT, otherwise bindings are affected, since they look for the CONSTRUCT flag. See ec55363d 2013-09-10 10:15:03 +0200 Sebastian Dröge * plugins/elements/gstqueue2.c: queue2: Only update current level if we already downloaded a range Otherwise queue->level is NULL and dereferencing that is not a good idea in general. https://bugzilla.gnome.org/show_bug.cgi?id=707648 2013-09-09 15:40:25 +0200 Sebastian Dröge
gst-plugins-good 1.1.90
ChangeLog = 2013-09-19 Sebastian Dröge * configure.ac: releasing 1.1.90 2013-09-19 09:45:18 +0200 Sebastian Dröge * po/cs.po: * po/nl.po: * po/pl.po: * po/uk.po: * po/vi.po: po: Update translations 2013-09-11 14:27:02 -0400 Olivier Crête * sys/v4l2/gstv4l2bufferpool.c: v4l2bufferpool: dmabuf is not a singleton anymore https://bugzilla.gnome.org/show_bug.cgi?id=707793 2013-09-16 13:53:45 -0300 Thiago Santos * ext/soup/gstsouphttpsrc.c: souphttpsrc: do not do http requests in READY HEAD requests to discover if the server is seekable shouldn't be done in READY as it might lock the main thread that is doing the state change. https://bugzilla.gnome.org/show_bug.cgi?id=705371 2013-09-18 16:32:28 +0200 Wim Taymans * gst/rtpmanager/gstrtpjitterbuffer.c: rtpjitterbuffer: reevaluate the current timer after timeout When we trigger the timeout logic of a timer, reevaluate it because it is possible that it still has the lowest timeout. 2013-09-18 16:31:26 +0200 Wim Taymans * gst/rtpmanager/gstrtpjitterbuffer.c: rtpjitterbuffer: don't update time when unscheduled Don't try to estimate the current time when we got unscheduled. 2013-09-18 16:29:37 +0200 Wim Taymans * gst/rtpmanager/gstrtpjitterbuffer.c: rtpjitterbuffer: init packet spacing on first buffer Already init the packet spacing variables on the first buffer so that we can calculate the spacing on the second buffer already. 2013-09-18 15:08:45 +0200 Wim Taymans * tests/check/elements/rtpjitterbuffer.c: tests: fix comments 2013-09-18 14:57:09 +0200 Wim Taymans * gst/rtpmanager/gstrtpjitterbuffer.c: rtpjitterbuffer: push the lost event from the timer thread Instead of pushing the lost event from the chain function, schedule a timeout that will push the lost event from the timer thread. This avoid blocking the upstream thread while we push and sync the event. 2013-09-18 14:23:55 +0200 Wim Taymans * tests/check/elements/rtpjitterbuffer.c: rtpjitterbuffer: add another test The test is modified slightly because the late lost packets are only generated now when a large gap is received. 2013-09-18 14:12:47 +0200 Wim Taymans * gst/rtpmanager/gstrtpjitterbuffer.c: * tests/check/elements/rtpjitterbuffer.c: rtpjitterbuffer: round gap duration to multiple of duration Make sure the gap duration in the lost event is a multiple of the packet duration. Enable another test. 2013-09-18 12:29:38 +0200 Wim Taymans * gst/rtpmanager/gstrtpjitterbuffer.c: * tests/check/Makefile.am: * tests/check/elements/rtpjitterbuffer.c: rtpjitterbuffer: keep track of duration Keep track of the estimated duration of missing packets and use it in the lost event. Enable another unit test 2013-09-18 11:59:28 +0200 Wim Taymans * gst/rtpmanager/gstrtpjitterbuffer.c: * tests/check/elements/rtpjitterbuffer.c: rtpjitterbuffer: handle large gaps with one lost event When we have a large number of missing packets, generate one lost event for all the packets that have no chance of being pushed out in time. Fix and activate unit test for large gaps. 2013-09-18 11:56:38 +0200 Wim Taymans * gst/rtpmanager/gstrtpjitterbuffer.c: rtpjitterbuffer: refactor lost event sending Also make sure we only increment the expected seqnum and last output timestamp. 2013-09-17 23:21:09 +0200 Wim Taymans * gst/rtpmanager/gstrtpjitterbuffer.c: jitterbuffer: refactor timeout triggers 2013-09-17 23:03:45 +0200 Wim Taymans * gst/rtpmanager/gstrtpjitterbuffer.c: jitterbuffer: simplify the timeout code Keep track of the current time in the timeout loop. Loop over all timers and trigger all the expired ones, we can do this in the same loop that selects the new best timer. 2013-09-17 23:01:17 +0200 Wim Taymans * gst/rtpmanager/gstrtpjitterbuffer.c: jitterbuffer: rearrange timer update code Also update the timers when retransmission is disabled. We need to do this because when we added LOST timers when we detected missing packets and we need to remove those timers when the packet finally arrives. 2013-09-17 22:02:04 +0100 Tim-Philipp Müller * gst/videomixer/Makefile.am: videomixer: link to libm for maths stuff Fixes undefined references to rint and pow on ubuntu build bot. 2013-09-17 15:19:42 +0200 Wim Taymans * gst/rtpmanager/gstrtpjitter
