[WPE] Update jhbuild dependencies
Created attachment 332648 [details] Patch
Created attachment 332649 [details] Patch
Comment on attachment 332649 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=332649&action=review > Tools/wpe/jhbuild.modules:61 > + <branch module="/pub/GNOME/sources/glib/2.54/glib-2.54.3.tar.xz" version="2.54.3" This will break RunLoop, see https://bugzilla.gnome.org/show_bug.cgi?id=761102. It looks OK if you add the patch for this.
Created attachment 332668 [details] Patch
Comment on attachment 332668 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=332668&action=review > Tools/ChangeLog:25 > + > + The initial reason for performing these upgrades was that when > + visiting https://youtube.com, WPE was getting TLS certificate > + errors. After upgrading glib-networking, these were fixed, but the > + upgrade introduced dependencies on newer versions of the other > + packages upgraded in this commit. > + > + The upgrade to glib caused a linking error in gstreamer, the > + following errors were being logged during linking, > + > + //usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined reference to `hb_glib_script_from_script' > + //usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined reference to `hb_glib_get_unicode_funcs' > + //usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined reference to `hb_glib_script_to_script' > + > + This was fixed by removing the --with-glib=no from the harfbuzz > + package. .... > Tools/wpe/jhbuild.modules:122 > <autotools id="harfbuzz" autogen-sh="configure" > - autogenargs="--with-cairo=no --with-glib=no --with-freetype=yes --with-fontconfig=yes"> > + autogenargs="--with-cairo=no --with-freetype=yes --with-fontconfig=yes"> > <dependencies> > <dep package="freetype6"/> > <dep package="fontconfig"/> Why is better passing "--with-glib=no" to the configure instead of adding a '<dep package="glib">' entry in the module build dependencies ?
Created attachment 332678 [details] Patch
(In reply to Carlos Alberto Lopez Perez from comment #5) > Comment on attachment 332668 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=332668&action=review > > > Tools/ChangeLog:25 > > + > > + The initial reason for performing these upgrades was that when > > + visiting https://youtube.com, WPE was getting TLS certificate > > + errors. After upgrading glib-networking, these were fixed, but the > > + upgrade introduced dependencies on newer versions of the other > > + packages upgraded in this commit. > > + > > + The upgrade to glib caused a linking error in gstreamer, the > > + following errors were being logged during linking, > > + > > + //usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined reference to `hb_glib_script_from_script' > > + //usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined reference to `hb_glib_get_unicode_funcs' > > + //usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined reference to `hb_glib_script_to_script' > > + > > + This was fixed by removing the --with-glib=no from the harfbuzz > > + package. > > .... I don't know what your dots mean, but I rephrased this sentence. > > > Tools/wpe/jhbuild.modules:122 > > <autotools id="harfbuzz" autogen-sh="configure" > > - autogenargs="--with-cairo=no --with-glib=no --with-freetype=yes --with-fontconfig=yes"> > > + autogenargs="--with-cairo=no --with-freetype=yes --with-fontconfig=yes"> > > <dependencies> > > <dep package="freetype6"/> > > <dep package="fontconfig"/> > > Why is better passing "--with-glib=no" to the configure instead of adding a > '<dep package="glib">' entry in the module build dependencies ? I don't have an answer to that question, I dropped to it rely on the auto package behavior and pick up the glib in the jhbuild. I switched to your suggestion.
Comment on attachment 332678 [details] Patch OK, but watch the bots when this lands because this is likely to both break and fix many tests. You'll need to update the expectations accordingly....
A(In reply to Michael Catanzaro from comment #8) > Comment on attachment 332678 [details] > Patch > > OK, but watch the bots when this lands because this is likely to both break > and fix many tests. You'll need to update the expectations accordingly.... Agreed, I didn't notice much running the test deltas locally, but I will be checking the results after it lands, which I'll do tomorrow when I can baby sit it.
Comment on attachment 332678 [details] Patch Attachment 332678 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/6264721 New failing tests: imported/w3c/web-platform-tests/service-workers/service-worker/navigation-redirect.https.html
Created attachment 332697 [details] Archive of layout-test-results from ews104 for mac-sierra-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews104 Port: mac-sierra-wk2 Platform: Mac OS X 10.12.6
Created attachment 332757 [details] Patch Rebase patch
Created attachment 332758 [details] Patch for landing
Is this patch stuck in the commit queue because of comment 11 (which surely can't be caused by this patch, surely!) https://trac.webkit.org/wiki/CommitQueue Q: How long until a patch lands after I set commit-queue+? 10-15 minutes. Depends on if the tree is red or not. The commit-queue will not commit when buildbots for the core platforms are red.
Comment on attachment 332758 [details] Patch for landing Clearing flags on attachment: 332758 Committed r227900: <https://trac.webkit.org/changeset/227900>
All reviewed patches have been landed. Closing bug.
The wiki page is wrong/obsolete. commit-queue normally takes an hour or thereabouts.