Bug 91727 - [GTK][jhbuild] Switch to GStreamer 1.0 build
: [GTK][jhbuild] Switch to GStreamer 1.0 build
Status: RESOLVED FIXED
Product: WebKit
Classification: Unclassified
Component: Platform
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To: Xabier Rodríguez Calvar
:
Depends on: 91880 92006 98804 101349 104667
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-19 02:42 PDT by Philippe Normand
Modified: 2013-01-31 17:46 PST (History)
12 users (show)

See Also:


Attachments
Patch (5.54 KB, patch)
2012-07-19 04:19 PDT, Philippe Normand
gns: commit‑queue-
Details | Formatted Diff | Diff
Patch (5.59 KB, patch)
2012-07-19 06:54 PDT, Philippe Normand
gns: commit‑queue-
Details | Formatted Diff | Diff
Patch (5.58 KB, patch)
2012-07-20 07:16 PDT, Philippe Normand
no flags Details | Formatted Diff | Diff
Patch (10.83 KB, patch)
2012-07-23 06:01 PDT, Philippe Normand
no flags Details | Formatted Diff | Diff
Patch (10.40 KB, patch)
2012-07-23 06:03 PDT, Philippe Normand
no flags Details | Formatted Diff | Diff
Patch (5.57 KB, patch)
2012-08-08 07:15 PDT, Philippe Normand
no flags Details | Formatted Diff | Diff
Patch (6.80 KB, patch)
2012-11-22 06:43 PST, Xabier Rodríguez Calvar
no flags Details | Formatted Diff | Diff
Patch (6.70 KB, patch)
2012-11-22 07:58 PST, Xabier Rodríguez Calvar
no flags Details | Formatted Diff | Diff
Patch (6.69 KB, patch)
2012-11-22 08:24 PST, Xabier Rodríguez Calvar
no flags Details | Formatted Diff | Diff
Patch (2.79 KB, patch)
2012-11-26 08:20 PST, Xabier Rodríguez Calvar
no flags Details | Formatted Diff | Diff
Patch (5.41 KB, patch)
2012-11-27 04:01 PST, Xabier Rodríguez Calvar
no flags Details | Formatted Diff | Diff
Patch (6.25 KB, patch)
2012-11-27 10:29 PST, Xabier Rodríguez Calvar
no flags Details | Formatted Diff | Diff
Patch (9.09 KB, patch)
2012-11-29 07:47 PST, Xabier Rodríguez Calvar
no flags Details | Formatted Diff | Diff
Patch (9.48 KB, patch)
2012-12-04 11:27 PST, Xabier Rodríguez Calvar
no flags Details | Formatted Diff | Diff
Patch (9.34 KB, patch)
2012-12-10 09:46 PST, Xabier Rodríguez Calvar
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Normand 2012-07-19 02:42:00 PDT
We should at least switch build-webkit to GStreamer 0.11 so that later on we're more confident to to switch the ./configure option by default for GNOME 3.6 too.
Comment 1 Philippe Normand 2012-07-19 04:19:41 PDT
Created attachment 153222 [details]
Patch
Comment 2 Gustavo Noronha (kov) 2012-07-19 06:48:23 PDT
Comment on attachment 153222 [details]
Patch

Attachment 153222 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/13281897
Comment 3 Philippe Normand 2012-07-19 06:54:22 PDT
Created attachment 153252 [details]
Patch
Comment 4 Gustavo Noronha (kov) 2012-07-19 08:30:46 PDT
Comment on attachment 153252 [details]
Patch

Attachment 153252 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/13280873
Comment 5 Philippe Normand 2012-07-19 09:53:43 PDT
Comment on attachment 153252 [details]
Patch

The gstreamer build makes the git checkout dirty because of .po files. I'd like to see if this issue can be fixed upstream, tomorrow. Pulling out of review queue for now.
Comment 6 Philippe Normand 2012-07-20 01:49:35 PDT
Gustavo can you please rm -fr WebKitBuild/Dependencies/Source/gstreamer in your EWS?

I'm preparing a new patch and I'd like your EWS to process it instead of mine :)
Comment 7 Philippe Normand 2012-07-20 01:57:22 PDT
I updated the gstreamer .po files in http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=80f94703f985d8f125196dec1baa08d46657923f

Not sure though why our jhbuild stuff updated them in the first place...
Comment 8 Philippe Normand 2012-07-20 07:16:58 PDT
Created attachment 153499 [details]
Patch
Comment 9 Philippe Normand 2012-07-20 08:13:10 PDT
Comment on attachment 153499 [details]
Patch

Clearing flags on attachment: 153499

Committed r123220: <http://trac.webkit.org/changeset/123220>
Comment 10 Philippe Normand 2012-07-20 08:13:15 PDT
All reviewed patches have been landed.  Closing bug.
Comment 11 Philippe Normand 2012-07-20 10:27:22 PDT
../../Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp: In function ‘WTF::GRefPtr<T> WTF::adoptGRef(T*) [with T = _GstElement]’:
../../Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp:31:146: error: ‘GST_OBJECT_IS_FLOATING’ was not declared in this scope
../../Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp: In function ‘WTF::GRefPtr<T> WTF::adoptGRef(T*) [with T = _GstPad]’:
../../Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp:51:146: error: ‘GST_OBJECT_IS_FLOATING’ was not declared in this scope
../../Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp: In function ‘WTF::GRefPtr<T> WTF::adoptGRef(T*) [with T = _GstPadTemplate]’:
../../Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp:71:146: error: ‘GST_OBJECT_IS_FLOATING’ was not declared in this scope
../../Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp: In function ‘WTF::GRefPtr<T> WTF::adoptGRef(T*) [with T = _GstTask]’:
../../Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp:105:138: error: ‘GST_OBJECT_IS_FLOATING’ was not declared in this scope
../../Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp: In function ‘WTF::GRefPtr<T> WTF::adoptGRef(T*) [with T = _GstBus]’:
../../Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp:125:138: error: ‘GST_OBJECT_IS_FLOATING’ was not declared in this scope
../../Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp: In function ‘WTF::GRefPtr<T> WTF::adoptGRef(T*) [with T = _GstElementFactory]’:
../../Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp:145:138: error: ‘GST_OBJECT_IS_FLOATING’ was not declared in this scope
Comment 12 WebKit Review Bot 2012-07-20 10:27:55 PDT
Re-opened since this is blocked by 91880
Comment 13 Philippe Normand 2012-07-20 10:31:12 PDT
I'll rework this on Monday.
Comment 14 Philippe Normand 2012-07-23 06:01:23 PDT
Created attachment 153786 [details]
Patch
Comment 15 Philippe Normand 2012-07-23 06:03:30 PDT
Created attachment 153787 [details]
Patch
Comment 16 Philippe Normand 2012-07-23 08:39:53 PDT
Comment on attachment 153787 [details]
Patch

Clearing flags on attachment: 153787

Committed r123339: <http://trac.webkit.org/changeset/123339>
Comment 17 Philippe Normand 2012-07-23 08:40:00 PDT
All reviewed patches have been landed.  Closing bug.
Comment 18 WebKit Review Bot 2012-07-23 09:10:44 PDT
Re-opened since this is blocked by 92006
Comment 19 Philippe Normand 2012-08-03 07:36:26 PDT
I think the media test failures on the 64-bit Release bot were related with Pulseaudio. Now that I fixed this issue I'll attempt to land this patch again and keep an eye on the bots.
Comment 20 Philippe Normand 2012-08-03 07:44:27 PDT
Committed r124614: <http://trac.webkit.org/changeset/124614>
Comment 21 Philippe Normand 2012-08-03 08:52:16 PDT
Reverted r124614 for reason:

gstreamer core .po files mess up the build again

Committed r124617: <http://trac.webkit.org/changeset/124617>
Comment 22 Philippe Normand 2012-08-08 07:15:09 PDT
Created attachment 157212 [details]
Patch

I think it would be good to manually clean the previous checkouts of
gst* on the bots before landing this patch.
Comment 23 Philippe Normand 2012-08-08 09:43:14 PDT
GTK EWS failure is due to a previous gst* checkout, I checked it build locally with clean checkouts
Comment 24 Philippe Normand 2012-08-08 10:24:36 PDT
Gustavo, I'd like to land this patch (again) tomorrow. Can you please clean the gst* checkouts on your bots beforehand?
Comment 25 Gustavo Noronha (kov) 2012-08-23 08:09:24 PDT
Done! Sorry for the delay, I was on vacations and am still catching up with mail.
Comment 26 Xabier Rodríguez Calvar 2012-10-29 04:53:08 PDT
When we finish bug 98804, we can switch.
Comment 27 Xabier Rodríguez Calvar 2012-11-22 06:43:39 PST
Created attachment 175665 [details]
Patch

This is the rebased patch including compiling against tag 1.0.3, removing the flag for unstable API and enabling only 1.0 if not specified otherwise.
Comment 28 Early Warning System Bot 2012-11-22 06:47:28 PST
Comment on attachment 175665 [details]
Patch

Attachment 175665 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/14967390
Comment 29 Early Warning System Bot 2012-11-22 06:50:05 PST
Comment on attachment 175665 [details]
Patch

Attachment 175665 [details] did not pass qt-wk2-ews (qt):
Output: http://queues.webkit.org/results/14963339
Comment 30 Build Bot 2012-11-22 07:30:12 PST
Comment on attachment 175665 [details]
Patch

Attachment 175665 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/14961399
Comment 31 kov's GTK+ EWS bot 2012-11-22 07:47:16 PST
Comment on attachment 175665 [details]
Patch

Attachment 175665 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/14961411
Comment 32 Xabier Rodríguez Calvar 2012-11-22 07:58:01 PST
Created attachment 175677 [details]
Patch

Fixed the perl issues.
Comment 33 Philippe Normand 2012-11-22 08:09:01 PST
Comment on attachment 175677 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=175677&action=review

> Tools/Scripts/webkitdirs.pm:2048
> +    # Enable upcoming GStreamer 1.0 build support through build-webkit.

"upcoming" can be removed now. I wrote this patch before 1.0 was officially released.
Comment 34 Xabier Rodríguez Calvar 2012-11-22 08:24:25 PST
Created attachment 175682 [details]
Patch

Fixed the perl issues.
Comment 35 Xabier Rodríguez Calvar 2012-11-22 08:26:54 PST
(In reply to comment #34)
> Fixed the perl issues.

Too much command reuse. Fixed the comment of the perl code.
Comment 36 kov's GTK+ EWS bot 2012-11-22 13:46:00 PST
Comment on attachment 175682 [details]
Patch

Attachment 175682 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/14959452
Comment 37 Philippe Normand 2012-11-23 00:44:21 PST
I tried this patch locally, clean build, no issue. I wonder what's up with Gustavo's EWS here.
Comment 38 Philippe Normand 2012-11-26 05:43:16 PST
Gustavo, since 1.0.3 is packaged in Debian Sid maybe we can avoid to build GStreamer in jhbuild? I originally wrote this patch before 1.0 and back then it made sense to build gst in jhbuild but not now anymore, IMHO.

So would you agree to install gstreamer-1.0 in your bots?
Comment 39 Xabier Rodríguez Calvar 2012-11-26 08:20:24 PST
Created attachment 176006 [details]
Patch

Removed GStreamer from jhbuild. We still keep backwards compatibility with --with-gstreamer=0.10.
Comment 40 Martin Robinson 2012-11-26 08:28:41 PST
(In reply to comment #38)
> Gustavo, since 1.0.3 is packaged in Debian Sid maybe we can avoid to build GStreamer in jhbuild? I originally wrote this patch before 1.0 and back then it made sense to build gst in jhbuild but not now anymore, IMHO.
> 
> So would you agree to install gstreamer-1.0 in your bots?

Does having the wrong version of Gstreamer 1.0 cause the tests to fail? If so, gstreamer should remain installed by jhbuild. Jhbuild isn't used to fulfill dependencies, but make it simpler to get all tests passing reliably.
Comment 41 Philippe Normand 2012-11-26 08:32:11 PST
(In reply to comment #40)
> (In reply to comment #38)
> > Gustavo, since 1.0.3 is packaged in Debian Sid maybe we can avoid to build GStreamer in jhbuild? I originally wrote this patch before 1.0 and back then it made sense to build gst in jhbuild but not now anymore, IMHO.
> > 
> > So would you agree to install gstreamer-1.0 in your bots?
> 
> Does having the wrong version of Gstreamer 1.0 cause the tests to fail? 

Few tests will fail with gst < 1.0.3.

> If so, gstreamer should remain installed by jhbuild. Jhbuild isn't used to fulfill dependencies, but make it simpler to get all tests passing reliably.

1.0.3 is in Debian sid already, we can have configure check for that version.
And for now people can keep building for 0.10.x anyway.
Comment 42 Martin Robinson 2012-11-26 08:38:29 PST
(In reply to comment #41)
> Few tests will fail with gst < 1.0.3.

Since it's possible that in some circumstances having the wrong version of GStreamer can cause test failures, I'm wondering if we should leave it in the modules file. Then we are protected from anything that breaks in future versions. I often had issues in the past with media tests failing because of GStreamer version/codec issues.
Comment 43 Martin Robinson 2012-11-26 09:10:49 PST
Comment on attachment 175682 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=175682&action=review

> Tools/Scripts/webkitdirs.pm:2054
> +    # Enable GStreamer 1.0 build support through build-webkit.
> +    if ($project eq 'WebKit') {
> +        my @gstBuildArgs = grep { /--with-gstreamer=.+/ } @buildArgs;
> +        if (!@gstBuildArgs) {
> +            push @buildArgs, "--with-gstreamer=1.0";
> +        }
> +    }

Not everyone who runs tests uses build-webkit to build. Is it possible to simply detect if 1.0 is present in configure.ac and use it by default if so?

> Tools/gtk/jhbuild.modules:277
> +  <autotools id="libogg" autogen-sh="configure" >
> +     <branch repo="xiph" module="ogg/libogg-1.3.0.tar.gz"
> +             hash="sha256:a8de807631014615549d2356fd36641833b8288221cea214f8a72750efe93780"
> +             md5sum="0a7eb40b86ac050db3a789ab65fe21c2"
> +             version="1.3.0"/>
> +  </autotools>
> +  <autotools id="libvorbis" autogen-sh="configure" autogenargs="--disable-examples" >
> +     <branch repo="xiph" module="vorbis/libvorbis-1.3.3.tar.gz"
> +             hash="sha256:6d747efe7ac4ad249bf711527882cef79fb61d9194c45b5ca5498aa60f290762"
> +             md5sum="6b1a36f0d72332fae5130688e65efe1f"
> +             version="1.3.3"/>
> +  </autotools>
> +  <autotools id="libtheora" autogen-sh="configure" autogenargs="--disable-examples">
> +     <branch repo="xiph" module="theora/libtheora-1.1.1.tar.gz"
> +             hash="sha256:40952956c47811928d1e7922cda3bc1f427eb75680c3c37249c91e949054916b"
> +             md5sum="bb4dc37f0dc97db98333e7160bfbb52b"
> +             version="1.1.1"/>
> +    <dependencies>
> +      <dep package="libogg"/>
> +      <dep package="libvorbis"/>
> +    </dependencies>
> +  </autotools>

It seems that we could rely on system dependencies for these. I'm guessing that these are very stable packages and tests will pass with any version of them.
Comment 44 Xabier Rodríguez Calvar 2012-11-26 10:47:06 PST
(In reply to comment #43)
> (From update of attachment 175682 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=175682&action=review
> 
> > Tools/Scripts/webkitdirs.pm:2054
> > +    # Enable GStreamer 1.0 build support through build-webkit.
> > +    if ($project eq 'WebKit') {
> > +        my @gstBuildArgs = grep { /--with-gstreamer=.+/ } @buildArgs;
> > +        if (!@gstBuildArgs) {
> > +            push @buildArgs, "--with-gstreamer=1.0";
> > +        }
> > +    }
> 
> Not everyone who runs tests uses build-webkit to build. Is it possible to simply detect if 1.0 is present in configure.ac and use it by default if so?

Roger that. Actually I can also add the check for GStreamer >= 1.0.3, that I forgot.

> > Tools/gtk/jhbuild.modules:277
> > +  <autotools id="libogg" autogen-sh="configure" >
> > +     <branch repo="xiph" module="ogg/libogg-1.3.0.tar.gz"
> > +             hash="sha256:a8de807631014615549d2356fd36641833b8288221cea214f8a72750efe93780"
> > +             md5sum="0a7eb40b86ac050db3a789ab65fe21c2"
> > +             version="1.3.0"/>
> > +  </autotools>
> > +  <autotools id="libvorbis" autogen-sh="configure" autogenargs="--disable-examples" >
> > +     <branch repo="xiph" module="vorbis/libvorbis-1.3.3.tar.gz"
> > +             hash="sha256:6d747efe7ac4ad249bf711527882cef79fb61d9194c45b5ca5498aa60f290762"
> > +             md5sum="6b1a36f0d72332fae5130688e65efe1f"
> > +             version="1.3.3"/>
> > +  </autotools>
> > +  <autotools id="libtheora" autogen-sh="configure" autogenargs="--disable-examples">
> > +     <branch repo="xiph" module="theora/libtheora-1.1.1.tar.gz"
> > +             hash="sha256:40952956c47811928d1e7922cda3bc1f427eb75680c3c37249c91e949054916b"
> > +             md5sum="bb4dc37f0dc97db98333e7160bfbb52b"
> > +             version="1.1.1"/>
> > +    <dependencies>
> > +      <dep package="libogg"/>
> > +      <dep package="libvorbis"/>
> > +    </dependencies>
> > +  </autotools>
> 
> It seems that we could rely on system dependencies for these. I'm guessing that these are very stable packages and tests will pass with any version of them.

Phil can correct me if I am wrong, but I think we can. Actually I have 1.3.2 in my system when compiling my own GStreamer master and this caused no trouble.
Comment 45 Philippe Normand 2012-11-26 11:27:13 PST
Yes we can exclude ogg/theora/vorbis from the moduleset. Those container/codecs are not used for the tests anyway (AFAIK).
Comment 46 Xabier Rodríguez Calvar 2012-11-27 04:01:43 PST
Created attachment 176228 [details]
Patch

Readded GStreamer to jhbuild but removed the dependencies of those. Made GStreamer 1.0 default in the configure.ac
Comment 47 Philippe Normand 2012-11-27 04:10:35 PST
Comment on attachment 176228 [details]
Patch

We want to fallback on 0.10 if 1.0 is not found.
Comment 48 Xabier Rodríguez Calvar 2012-11-27 10:29:44 PST
Created attachment 176294 [details]
Patch

configure.ac checking for GStreamer 1.0 in case no version is specified. If 1.0 is not found, it falls back to 0.10. If a version is specified, it tries that and fails if it can't find it
Comment 49 Martin Robinson 2012-11-27 10:38:05 PST
Comment on attachment 176294 [details]
Patch

Okay. This seems reasonable.
Comment 50 Philippe Normand 2012-11-28 06:24:46 PST
Comment on attachment 176294 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=176294&action=review

> configure.ac:344
> +if test -z "$with_gstreamer"; then

Isn't this test always true given that AC_ARG_WITH() is called later on?
Also I think we want to perform this only if video or web-audio is enabled.
Comment 51 Xabier Rodríguez Calvar 2012-11-28 23:54:56 PST
(In reply to comment #50)
> (From update of attachment 176294 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=176294&action=review
> 
> > configure.ac:344
> > +if test -z "$with_gstreamer"; then
> 
> Isn't this test always true given that AC_ARG_WITH() is called later on?
> Also I think we want to perform this only if video or web-audio is enabled.

Martin asked my the very same question :)

At least when I tested it in my environment, it worked because the variable is set before that macro code is invoked. What the macro probably does is checking the "with_variable" variable value.
Comment 52 Philippe Normand 2012-11-29 00:14:16 PST
My second point is still valid though :) Care to update the patch?
Comment 53 Xabier Rodríguez Calvar 2012-11-29 07:47:00 PST
Created attachment 176737 [details]
Patch

gst-ffmpeg becomes gst-libav and not checking for GStreamer in case we don't want web audio or video.
Comment 54 Xabier Rodríguez Calvar 2012-12-04 11:27:45 PST
Created attachment 177518 [details]
Patch

Added a default --with-gstreamer=auto option to make the configure.ac clearer. I moved those checks to another place to be sure that enable video and web audio arguments are already processed.
Comment 55 Xabier Rodríguez Calvar 2012-12-04 11:28:58 PST
(In reply to comment #54)
> Created an attachment (id=177518) [details]
> Patch
> 
> Added a default --with-gstreamer=auto option to make the configure.ac clearer. I moved those checks to another place to be sure that enable video and web audio arguments are already processed.

If it is ok, we can land it tomorrow to properly sync with the bots.
Comment 56 Philippe Normand 2012-12-04 12:12:30 PST
Comment on attachment 177518 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=177518&action=review

> configure.ac:1062
> +if test "$have_gstreamer" != "yes" || test "$GST_API_VERSION" = "1.0"; then

In which case have_gstreamer is set to "yes" ? Isn't it enough to test GST_API_VERSION?
Comment 57 Xabier Rodríguez Calvar 2012-12-05 01:31:28 PST
(In reply to comment #56)
> (From update of attachment 177518 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=177518&action=review
> 
> > configure.ac:1062
> > +if test "$have_gstreamer" != "yes" || test "$GST_API_VERSION" = "1.0"; then
> 
> In which case have_gstreamer is set to "yes" ? Isn't it enough to test GST_API_VERSION?

No, because GST_API_VERSION is set before we actually check that GStreamer is present. It is set when the version is selected, but no when it is checked, which happens later, and that's why I also check for $have_gstreamer.

I realized it could when testing --with-gstreamer=1.0  and --disable-video --disable-web-audio or GStreamer 1.0 not present. In that case, the version is already set to 1.0, but there is no GStreamer in the end because either it is not installed or it is not going to be used because no video or web audio are requested.
Comment 58 Philippe Normand 2012-12-10 03:20:20 PST
Comment on attachment 177518 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=177518&action=review

Looks good, just two small nits to fix before landing.

> configure.ac:819
> +GSTREAMER_1_0_REQUIRED_VERSION=0.11.90
> +GSTREAMER_1_0_PLUGINS_BASE_REQUIRED_VERSION=0.11.90

Should be 1.0.3

> configure.ac:853
> +   AC_DEFINE([GST_USE_UNSTABLE_API], [1], [Using unstable GStreamer API])

That should be removed.
Comment 59 Xabier Rodríguez Calvar 2012-12-10 09:46:04 PST
Created attachment 178572 [details]
Patch

Fixing version and unstable API
Comment 60 kov's GTK+ EWS bot 2012-12-10 11:00:48 PST
Comment on attachment 178572 [details]
Patch

Attachment 178572 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/15230712
Comment 61 Philippe Normand 2012-12-11 01:43:38 PST
Comment on attachment 178572 [details]
Patch

Clearing flags on attachment: 178572

Committed r137271: <http://trac.webkit.org/changeset/137271>
Comment 62 Philippe Normand 2012-12-11 01:43:46 PST
All reviewed patches have been landed.  Closing bug.
Comment 63 WebKit Review Bot 2012-12-11 06:11:56 PST
Re-opened since this is blocked by bug 104667
Comment 64 Philippe Normand 2012-12-11 07:40:49 PST
The timeouts were due to missing libs (theora, vorbis, faad) on the bots.