You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
(12) |
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(15) |
Nov
(8) |
Dec
(4) |
2006 |
Jan
|
Feb
|
Mar
(11) |
Apr
(10) |
May
(105) |
Jun
(12) |
Jul
(42) |
Aug
(54) |
Sep
(15) |
Oct
(14) |
Nov
(27) |
Dec
(3) |
2007 |
Jan
(1) |
Feb
(6) |
Mar
(26) |
Apr
(11) |
May
(28) |
Jun
(5) |
Jul
(9) |
Aug
|
Sep
|
Oct
(4) |
Nov
(8) |
Dec
(7) |
2008 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
|
May
(6) |
Jun
(7) |
Jul
|
Aug
(16) |
Sep
(1) |
Oct
(4) |
Nov
(3) |
Dec
(1) |
2009 |
Jan
(37) |
Feb
(19) |
Mar
(32) |
Apr
(7) |
May
(2) |
Jun
(15) |
Jul
(8) |
Aug
(12) |
Sep
(2) |
Oct
(1) |
Nov
(6) |
Dec
(11) |
2010 |
Jan
(11) |
Feb
(5) |
Mar
(56) |
Apr
(75) |
May
(28) |
Jun
(10) |
Jul
(6) |
Aug
(1) |
Sep
(26) |
Oct
(23) |
Nov
(92) |
Dec
(41) |
2011 |
Jan
(6) |
Feb
(2) |
Mar
(2) |
Apr
(8) |
May
(20) |
Jun
(3) |
Jul
(1) |
Aug
(32) |
Sep
(6) |
Oct
(9) |
Nov
(3) |
Dec
(15) |
2012 |
Jan
(6) |
Feb
(13) |
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
(4) |
Aug
(7) |
Sep
|
Oct
(2) |
Nov
|
Dec
(4) |
2013 |
Jan
(9) |
Feb
(15) |
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
(9) |
Aug
|
Sep
(5) |
Oct
(4) |
Nov
(4) |
Dec
(11) |
2014 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
|
May
(4) |
Jun
(2) |
Jul
(2) |
Aug
(9) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
(3) |
May
(7) |
Jun
(3) |
Jul
(5) |
Aug
(15) |
Sep
|
Oct
(1) |
Nov
|
Dec
(6) |
2016 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(6) |
Nov
(7) |
Dec
(8) |
2017 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
2018 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(10) |
Jun
|
Jul
|
Aug
(5) |
Sep
(4) |
Oct
(3) |
Nov
(3) |
Dec
(4) |
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(40) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-08-08 16:09:11
|
https://bugzilla.gnome.org/show_bug.cgi?id=639557 gnome-perl | Gtk2 | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #1 from Torsten Schoenfeld <kaf...@gm...> 2011-08-08 16:08:55 UTC --- Committed, thanks. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-08-08 16:09:09
|
https://bugzilla.gnome.org/show_bug.cgi?id=639557 gnome-perl | Gtk2 | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #178348|none |committed status| | -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-08-08 16:02:51
|
https://bugzilla.gnome.org/show_bug.cgi?id=639558 gnome-perl | Gtk2 | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kaf...@gm... --- Comment #1 from Torsten Schoenfeld <kaf...@gm...> 2011-08-08 16:02:40 UTC --- (In reply to comment #0) > Is there a reason Gtk2::Gdk::Pixbuf->new_from_data() demands SvPOK of its data > input? I thought it might SvPV to stringize in the usual way. Doing so would > allow overloads and magic to work there the same way as they do elsewhere. Sounds good to me. > Possible simplification below, copying out the SvPV data into a malloced block > for the pixbuf data area rather than an newSVsv. Also good. But any particular reason you use perl's memory-handling macros? Nearly all the other code in Glib and Gtk2 uses glib's things (g_new, g_memdup). -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-08-08 15:42:33
|
https://bugzilla.gnome.org/show_bug.cgi?id=639559 gnome-perl | Gtk2 | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #178350|none |needs-work status| | --- Comment #1 from Torsten Schoenfeld <kaf...@gm...> 2011-08-08 15:42:19 UTC --- Review of attachment 178350: --> (https://bugzilla.gnome.org/review?bug=639559&attachment=178350) ::: xs/GdkWindow.xs @@ +201,3 @@ +these is created when a widget is "realized". + +As of Gtk 2.22 a window can only be created by It should be 'gtk+ 2.22' to avoid confusion. @@ +208,3 @@ +window creation, and that function always makes a C<GdkWindow> (the +class name argument to the Perl-Gtk C<< Gtk2::Gdk::Window->new >> +wrapper is unused). While it's true that you cannot subclass Gtk2::Gdk::Window from the GType perspective, you can still simply call Gtk2::Gdk::Window->new in your constructor and then re-bless the result. So maybe something like this: "And it's not possible to subclass C<Gtk2::Gdk::Window> using L<Glib::Object::Subclass>, [...]"? -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-08-08 15:31:14
|
https://bugzilla.gnome.org/show_bug.cgi?id=643337 gnome-perl | Gtk2 | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |kaf...@gm... Ever Confirmed|0 |1 --- Comment #1 from Torsten Schoenfeld <kaf...@gm...> 2011-08-08 15:31:02 UTC --- I think croak()-ing would indeed be better than silently accepting garbage. Can you write a patch for that? -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-08-08 15:23:49
|
https://bugzilla.gnome.org/show_bug.cgi?id=653681 gnome-perl | Glib | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #1 from Torsten Schoenfeld <kaf...@gm...> 2011-08-08 15:23:38 UTC --- Thanks, fixed. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gtk+ (bugzilla.gnome.o. <bug...@gn...> - 2011-08-02 21:54:13
|
https://bugzilla.gnome.org/show_bug.cgi?id=654688 gtk+ | general | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kaf...@gm... Component|general |general AssignedTo|gtk...@li...urce |gtk...@gt... |forge.net | Product|gnome-perl |gtk+ QAContact|gtk...@li...urce |gtk...@gt... |forge.net | --- Comment #1 from Torsten Schoenfeld <kaf...@gm...> 2011-08-02 21:54:01 UTC --- If this is a bug, then it's not with the Perl bindings, but with the underlying gtk+ library. Reassigning accordingly. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-07-15 16:25:47
|
https://bugzilla.gnome.org/show_bug.cgi?id=654688 gnome-perl | general | unspecified Summary: Gtk does not seem to handle XReparentWindow correctly Classification: Bindings Product: gnome-perl Version: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: general AssignedTo: gtk...@li... ReportedBy: dun...@ya... QAContact: gtk...@li... GNOME version: --- Raised a bug against xterm not reparenting its window correctly at https://bugs.launchpad.net/bugs/806969 which resulted in the maintainer saying the bug is with Gtk2 Full text of bug report is: === When re-parenting xterm into another window using '-into <id>' the term ignores all input. When using a different terminal such as "urxvt -embed <id>" it works as expected Attached scripts shows the problem when typing into the new window when using xterm and urxvt $ dpkg -l |grep xterm ii xterm 268-1ubuntu1 $ more /etc/debian_version squeeze/sid system is up to date === #!/usr/bin/perl use warnings; use strict; use Gtk2; init Gtk2; my $window = new Gtk2::Window 'toplevel'; $window->signal_connect( 'destroy' => sub { Gtk2->main_quit; return 0; } ); my $frame = new Gtk2::Frame "embedded terminal"; $window->add($frame); my $rxvt = new Gtk2::Socket; $frame->add($rxvt); $frame->set_size_request( 700, 400 ); $window->show_all; my $xid = $rxvt->window->get_xid; # works with rxvt but xterm loses keyboard focus system "xterm -into $xid &"; #system "urxvt -embed $xid &"; $window->show_all; $rxvt->add_events( [qw( all_events_mask key_press_mask )] ); main Gtk2; === Response from xterm admin === Investigated, found that the essential difference between xterm and urxvt in this aspect is that xterm initializes using one of the functions such as XtOpenApplication, which does resource initialization, etc., on a shell widget that it creates. Later, it uses XReparentWindow to handle the "-into" option. urxvt on the other hand, processes its "-embed" option before creating its first window, using the parameter directly as its parent window. While Tcl/Tk handles the XReparentWindow, Gtk does not, it seems. Given the nature of the problem (a bug in Gtk), revising xterm's initialization to work around Gtk's problems would seem to be a wish- list item for xterm rather than a bug in xterm. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-06-29 22:24:24
|
https://bugzilla.gnome.org/show_bug.cgi?id=653681 gnome-perl | Glib | unspecified Summary: signal_query() ref leak on unknown signal name Classification: Bindings Product: gnome-perl Version: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: Normal Component: Glib AssignedTo: gtk...@li... ReportedBy: us...@zi... QAContact: gtk...@li... GNOME version: --- In the GSignal.xs wrapper of g_signal_query() it looks like "oclass" is not unreffed in the "0 == signal_id" case of an unknown signal name. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-06-07 16:34:28
|
https://bugzilla.gnome.org/show_bug.cgi?id=620099 gnome-perl | Glib | unspecified --- Comment #10 from Quentin Sculo <squ...@fr...> 2011-06-07 16:34:17 UTC --- Created an attachment (id=189418) --> (https://bugzilla.gnome.org/attachment.cgi?id=189418) test case exhibing the hanging I talked about in comment #8 I managed to reproduce it in this small hang.pl script that simply play a file given on the command line. I tested this on a xubuntu 11.04, the hanging happens every time with the more elaborated notify callback and with the line setting the volume to 1. If any of these are removed, everything works correctly. example output : GStreamer::Pipeline=HASH(0xa248c00) volume : 1 Use of uninitialized value in concatenation (.) or string at hang.pl line 14. GStreamer::Pipeline=HASH(0xa248c00) uri : Playing: /home/squentin/Music/Miles Davis/Kind of Blue/01 - So What.ogg GStreamer::Pipeline=HASH(0xa248c00) source : Glib::Object::_Unregistered::GstFileSrc=HASH(0xa248f60) *** GPerl asked to invoke callback from another thread, handing callback over to the main loop Without the patch it doesn't hang or crash, but with an earlier and more complex version of this script (that printed the time in a gtk window) I once got a segmentation fault. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-06-05 11:49:27
|
https://bugzilla.gnome.org/show_bug.cgi?id=620099 gnome-perl | Glib | unspecified --- Comment #9 from Torsten Schoenfeld <kaf...@gm...> 2011-06-05 11:49:13 UTC --- (In reply to comment #8) > I also tested connecting to the notify signal of the playbin2 gstreamer element > to get a signal when its volume property change (the volume of the playbin2 > element is linked to the master volume when using pulseaudio), and though a > simple callback as {warn "@_"} seems to work (it crashes when changing the > volume without the patch), a more elaborate callback such as : > my ($object,$property)=@_; > my $name=$property->get_name; > warn "$object property $name changed : ".$object->get($name)."\n"; > causes the app to hang when it starts playing (it crashes without the patch) > after printing a few "property changed" messages, it ends with the "*** GPerl > asked to invoke callback from another thread, handing callback over to the main > loop" message from the patch. > > I also got at least 2 similar hanging while testing the visual gstreamer plugin > (plugin that does some drawing with the music) Can you provide test programs that exhibit these hangs? -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-18 20:07:59
|
https://bugzilla.gnome.org/show_bug.cgi?id=620099 gnome-perl | Glib | unspecified Quentin Sculo <squentin> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |squ...@fr... --- Comment #8 from Quentin Sculo <squ...@fr...> 2011-05-18 20:07:43 UTC --- Thanks a lot. I did only a few tests so far, but it seems good enough for using playbin2 and the about_to_finish signal in my app. I did a few quick tests with other sources of crashes related to gstreamer, and it is much better, for example, computing replaygain info in my app using the gstreamer plugin was extremely unstable before, with this patch it looks very stable. I also tested connecting to the notify signal of the playbin2 gstreamer element to get a signal when its volume property change (the volume of the playbin2 element is linked to the master volume when using pulseaudio), and though a simple callback as {warn "@_"} seems to work (it crashes when changing the volume without the patch), a more elaborate callback such as : my ($object,$property)=@_; my $name=$property->get_name; warn "$object property $name changed : ".$object->get($name)."\n"; causes the app to hang when it starts playing (it crashes without the patch) after printing a few "property changed" messages, it ends with the "*** GPerl asked to invoke callback from another thread, handing callback over to the main loop" message from the patch. I also got at least 2 similar hanging while testing the visual gstreamer plugin (plugin that does some drawing with the music) So it is a great improvement, though it seems there is still some cases where it will hang. I don't know if it is possible to fix that, but even as is I hope it will be committed soon. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-15 16:05:26
|
https://bugzilla.gnome.org/show_bug.cgi?id=639930 gnome-perl | Glib | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |kaf...@gm... Resolution| |INVALID -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-15 16:02:40
|
https://bugzilla.gnome.org/show_bug.cgi?id=614650 gnome-perl | GStreamer | unspecified --- Comment #8 from Torsten Schoenfeld <kaf...@gm...> 2011-05-15 16:02:28 UTC --- I've now implemented muppet's suggestion in attachment 187851 to bug 620099. It sort of fixes the problem. "Sort of" because it does not fix the test case as-is. The timeout source \&count needs to be disabled (or, at least, its duration needs to be shortened) for the new approach to work: with it still in place, the main loop is blocked from processing the about-to-finish invocation in time. Is that still good enough for your purposes, Quentin? -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-15 15:53:10
|
https://bugzilla.gnome.org/show_bug.cgi?id=620099 gnome-perl | Glib | unspecified --- Comment #7 from Torsten Schoenfeld <kaf...@gm...> 2011-05-15 15:52:57 UTC --- Alright, I've finally convinced myself that my previous approach cannot work. So I caved in and implemented what muppet has been suggesting all along: when invoked from a non-main thread, hand the request over to the main loop so that it gets executed on the main thread. This works fine in the following common case: * main thread connects handler to a signal, then goes into main loop * non-main thread gets created somewhere to do some work, then emits said signal * our marshallers hands the request over to the main loop * main loop executes the request on the main thread It does not work, however, if the main thread is busy doing something else. In this case, the main loop does not run, and so the signal invocation is blocked until the main thread returns control to the main loop. The attached patch, still containing some debug spew and FIXME question, implements this approach in our normal signal marshaller, gperl_closure_invoke. It does not fix custom signal marshallers, or stuff that uses direct callbacks. Comments, criticism, suggestions welcome. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-15 15:46:48
|
https://bugzilla.gnome.org/show_bug.cgi?id=620099 gnome-perl | Glib | unspecified --- Comment #6 from Torsten Schoenfeld <kaf...@gm...> 2011-05-15 15:46:35 UTC --- Created an attachment (id=187851) View: https://bugzilla.gnome.org/attachment.cgi?id=187851 Review: https://bugzilla.gnome.org/review?bug=620099&attachment=187851 Make signal marshalling thread-safe When a signal that has Perl handlers is emitted from a non-main non-Perl thread, we used to simply use PERL_SET_CONTEXT to associated this thread with the main Perl interpreter. But since it is not safe to call into one Perl interpreter concurrently, this does not work. Instead we now, upon noticing that we are being called from a thread without asoociated Perl interpreter, hand the marshalling request over to the main loop which in turn later wakes up the main thread and lets it handle the request. dGPERL_CLOSURE_MARSHAL_ARGS also needed to be adjusted not to use dSP since that dereferences the current thread's Perl interpreter without NULL check. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-14 10:57:18
|
https://bugzilla.gnome.org/show_bug.cgi?id=649615 gnome-perl | GStreamer | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |kaf...@gm... Resolution| |FIXED --- Comment #13 from Torsten Schoenfeld <kaf...@gm...> 2011-05-14 10:56:51 UTC --- All fixed in git now. I'll try do roll a new release soon. Thanks for your efforts. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-14 10:56:15
|
https://bugzilla.gnome.org/show_bug.cgi?id=649615 gnome-perl | GStreamer | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #187729|none |rejected status| | --- Comment #12 from Torsten Schoenfeld <kaf...@gm...> 2011-05-14 10:56:06 UTC --- Review of attachment 187729: --> (https://bugzilla.gnome.org/review?bug=649615&attachment=187729) I committed a different, backwards-compatible fix instead. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-14 10:56:05
|
https://bugzilla.gnome.org/show_bug.cgi?id=649615 gnome-perl | GStreamer | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #187688|none |rejected status| | --- Comment #11 from Torsten Schoenfeld <kaf...@gm...> 2011-05-14 10:55:52 UTC --- Review of attachment 187688: --> (https://bugzilla.gnome.org/review?bug=649615&attachment=187688) I committed a different, backwards-compatible fix instead. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-14 10:54:50
|
https://bugzilla.gnome.org/show_bug.cgi?id=649615 gnome-perl | GStreamer | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #187682|none |committed status| | --- Comment #10 from Torsten Schoenfeld <kaf...@gm...> 2011-05-14 10:54:38 UTC --- Review of attachment 187682: --> (https://bugzilla.gnome.org/review?bug=649615&attachment=187682) Committed. Thanks. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-14 10:54:34
|
https://bugzilla.gnome.org/show_bug.cgi?id=649615 gnome-perl | GStreamer | unspecified Torsten Schoenfeld <kaffeetisch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #187683|none |committed status| | --- Comment #9 from Torsten Schoenfeld <kaf...@gm...> 2011-05-14 10:54:20 UTC --- Review of attachment 187683: --> (https://bugzilla.gnome.org/review?bug=649615&attachment=187683) Committed. Thanks. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-12 18:25:42
|
https://bugzilla.gnome.org/show_bug.cgi?id=649615 gnome-perl | GStreamer | unspecified --- Comment #8 from Dominic Hargreaves <do...@ea...> 2011-05-12 18:25:29 UTC --- Created an attachment (id=187729) View: https://bugzilla.gnome.org/attachment.cgi?id=187729 Review: https://bugzilla.gnome.org/review?bug=649615&attachment=187729 a fix for the broken GstElement test A naive fix to match the new library behaviour. Not backwards compatible. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-12 09:39:02
|
https://bugzilla.gnome.org/show_bug.cgi?id=649615 gnome-perl | GStreamer | unspecified Dominic Hargreaves <dom> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Tests fail when built with |Tests fail when built with |gstreamer 0.10.32 |gstreamer 0.10.33 -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-12 09:37:51
|
https://bugzilla.gnome.org/show_bug.cgi?id=649615 gnome-perl | GStreamer | unspecified --- Comment #7 from Dominic Hargreaves <do...@ea...> 2011-05-12 09:37:34 UTC --- This leaves the following test to fix (and possibly a better fix for the GstValue problem which is backwards-compatible: > # Failed test at t/GstElement.t line 117. > # got: 'none' > # expected: undef > # Looks like you failed 1 test of 39. > t/GstElement.t .......... > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/39 subtests > (less 2 skipped subtests: 36 okay) -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |
From: gnome-perl (bugzilla.gnome.o. <bug...@gn...> - 2011-05-12 09:34:00
|
https://bugzilla.gnome.org/show_bug.cgi?id=649615 gnome-perl | GStreamer | unspecified --- Comment #6 from Dominic Hargreaves <do...@ea...> 2011-05-12 09:33:44 UTC --- Created an attachment (id=187688) View: https://bugzilla.gnome.org/attachment.cgi?id=187688 Review: https://bugzilla.gnome.org/review?bug=649615&attachment=187688 a fix for the broken GstValue test A naive fix to match the new library behaviour. Not backwards compatible. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |