Bug 181476 - [GTK][JHBuild] Tools/gtk/install-dependencies: Package libxfont does not exist anymore in Arch Linux
Summary: [GTK][JHBuild] Tools/gtk/install-dependencies: Package libxfont does not exis...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Adrian Perez
URL:
Keywords: InRadar
Depends on:
Blocks: 181475
  Show dependency treegraph
 
Reported: 2018-01-10 05:09 PST by Adrian Perez
Modified: 2018-01-15 09:38 PST (History)
8 users (show)

See Also:


Attachments
Patch (3.45 KB, patch)
2018-01-10 18:09 PST, Adrian Perez
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ews126 for ios-simulator-wk2 (2.15 MB, application/zip)
2018-01-10 19:52 PST, EWS Watchlist
no flags Details
Patch (2.64 KB, patch)
2018-01-15 04:40 PST, Adrian Perez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Perez 2018-01-10 05:09:03 PST
The script tries to install “libxfont”, which does not exist anymore:
nowadays “libxfont2” is used instead and no other package in the Arch
Linux repositories depends on “libxfont”, and therefore it has been
removed.

The old version of “xorg-server” that is built inside the JHBuild _does_
use “libxfont” still, but as this library itself is not build in the
JHBuild, it's not possible to compile the old version of “xorg-server”
in Arch Linux.

IMHO, we should either include a “libxfont” module in the JHBuild (easier,
probably less risky) or update “xorg-server” to a newer release. What is
the preferred way to go about this? In any case, I can prepare the needed
patch :-)
Comment 1 Adrian Perez 2018-01-10 05:22:53 PST
(In reply to Adrian Perez from comment #0)

> IMHO, we should either include a “libxfont” module in the JHBuild (easier,
> probably less risky) or update “xorg-server” to a newer release. What is
> the preferred way to go about this? In any case, I can prepare the needed
> patch :-)

After chatting a bit about this with Carlos García, it is not very clear
why we are building the X.org server (module “xserver” in the JHBuild).
One option is because we are patching it with changes not upstreamed
(“xserver-search-for-DRI-drivers-at-LIBGL_DRIVERS_PATH-environ.patch”
for example which I believe is needed to make sure X.org picks the Mesa
drivers from our location which will have only “llvmpipe”), the other
is to have “Xvfb” built. If the reason is the latter (Xvfb), I would
rather remove the “xserver” module from the moduleset and let people
use their distro-provided Xvfb packages.
Comment 2 Adrian Perez 2018-01-10 05:23:46 PST
(Added Carlos López in CC, as he may have a good insight on the
reasoning behind including “xserver” in the JHBuild moduleset.)
Comment 3 Carlos Alberto Lopez Perez 2018-01-10 06:07:46 PST
We build xserver only to have a version of Xvfb that is patched to look for the mesa DRI driver in a custom path (the one of custom software rasterizer). We use this Xvfb when running layout tests with  --display-server=xvfb (the default) or with --display-server=weston (a weston that runs over the previous xvfb)

Check https://trac.webkit.org/r202619 for more details.

Perhaps we should add a comment on the JHBuild telling that the xserver we build on the JHBuild is only used for the layout tests.


This are the files xorg installs on my WebKit JHBuild



$ cat WebKitBuild/DependenciesGTK/Root/_jhbuild/manifests/xserver 
share/man/man1/Xserver.1
share/man/man1/Xvfb.1
lib/xorg/protocol.txt
bin/Xvfb
bin/Xwayland
Comment 4 Adrian Perez 2018-01-10 06:12:15 PST
(In reply to Carlos Alberto Lopez Perez from comment #3)
> We build xserver only to have a version of Xvfb that is patched to look for
> the mesa DRI driver in a custom path (the one of custom software
> rasterizer). We use this Xvfb when running layout tests with 
> --display-server=xvfb (the default) or with --display-server=weston (a
> weston that runs over the previous xvfb)

Thanks for confirming what I suspected. I'll go with the easy fix
and just add “libxfont” to the JHBuild moduleset.
Comment 5 Adrian Perez 2018-01-10 18:09:23 PST
Created attachment 331004 [details]
Patch
Comment 6 Michael Catanzaro 2018-01-10 18:37:10 PST
I think we should update the X server, unless there is a good reason not to do so.
Comment 7 EWS Watchlist 2018-01-10 19:52:05 PST
Comment on attachment 331004 [details]
Patch

Attachment 331004 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/6028689

New failing tests:
http/tests/misc/resource-timing-resolution.html
Comment 8 EWS Watchlist 2018-01-10 19:52:06 PST
Created attachment 331014 [details]
Archive of layout-test-results from ews126 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews126  Port: ios-simulator-wk2  Platform: Mac OS X 10.12.6
Comment 9 Adrian Perez 2018-01-11 03:58:37 PST
(In reply to Michael Catanzaro from comment #6)
> I think we should update the X server, unless there is a good reason not to
> do so.

As far as I understand it should be relatively safe to update the X server
without it needing a rebaseline of the layout tests. What I am not so sure
is moving from libxfont to libxfont2... Let's give it a try and see how it
goes :-)
Comment 10 Adrian Perez 2018-01-15 03:33:51 PST
(In reply to Adrian Perez from comment #9)
> (In reply to Michael Catanzaro from comment #6)
> > I think we should update the X server, unless there is a good reason not to
> > do so.
> 
> As far as I understand it should be relatively safe to update the X server
> without it needing a rebaseline of the layout tests. What I am not so sure
> is moving from libxfont to libxfont2... Let's give it a try and see how it
> goes :-)

Also, the patch to change the GL drivers search patch applies cleanly to
the latest release of “xorg-server”. I'm trying locally a full rebuild of
the JHBuild moduleset before posting the patch.
Comment 11 Adrian Perez 2018-01-15 04:40:49 PST
Created attachment 331328 [details]
Patch
Comment 12 Adrian Perez 2018-01-15 09:36:22 PST
Comment on attachment 331328 [details]
Patch

Clearing flags on attachment: 331328

Committed r226950: <https://trac.webkit.org/changeset/226950>
Comment 13 Adrian Perez 2018-01-15 09:36:27 PST
All reviewed patches have been landed.  Closing bug.
Comment 14 Radar WebKit Bug Importer 2018-01-15 09:38:41 PST
<rdar://problem/36524242>