Bug 181476 – [GTK][JHBuild] Tools/gtk/install-dependencies: Package libxfont does not exist anymore in Arch Linux

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Adrian Perez]

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 :-)

[Adrian Perez]

(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.

[Adrian Perez]

(Added Carlos López in CC, as he may have a good insight on the
reasoning behind including “xserver” in the JHBuild moduleset.)

[Carlos Alberto Lopez Perez]

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

[Adrian Perez]

(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.

[Adrian Perez]

Created attachment 331004 [details]
Patch

[Michael Catanzaro]

I think we should update the X server, unless there is a good reason not to do so.

[EWS Watchlist]

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

[EWS Watchlist]

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

[Adrian Perez]

(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 :-)

[Adrian Perez]

(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.

[Adrian Perez]

Created attachment 331328 [details]
Patch

[Adrian Perez]

Comment on attachment 331328 [details]
Patch

Clearing flags on attachment: 331328

Committed r226950: <https://trac.webkit.org/changeset/226950>

[Adrian Perez]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/36524242>