Bug 79904 – [EFL] Add and use run-with-jhbuild and update-webkitefl-libs scripts for EFL

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

[Dominik Röttsches (drott)]

Next step for solving bug 79480, providing dependencies for EFL by using jhbuild.

Adding a run-with-jhbuild and update-webkitefl-libs variant for EFL,
then using run-with-jhbuild as a prefix to cmake.

One advantage is that we can also clamp the EFL versions.

I had to patch ecore's configure.ac to avoid a version conflict with gettext. If someone has a better idea how to fix this, suggestions are welcome.

[Dominik Röttsches (drott)]

Created attachment 129439 [details]
Adding jhbuild build configuration for EFL, v1

[Gyuyoung Kim]

Comment on attachment 129439 [details]
Adding jhbuild build configuration for EFL, v1

Attachment 129439 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11769194

[Dominik Röttsches (drott)]

(In reply to comment #2)
> (From update of attachment 129439 [details])
> Attachment 129439 [details] did not pass efl-ews (efl):
> Output: http://queues.webkit.org/results/11769194

[Dominik Röttsches (drott)]

(In reply to comment #2)
> (From update of attachment 129439 [details])
> Attachment 129439 [details] did not pass efl-ews (efl):
> Output: http://queues.webkit.org/results/11769194

The patch depends on the patch in bug 79673 - that's why efl EWS fails.

[Raphael Kubo da Costa (:rakuco)]

Comment on attachment 129439 [details]
Adding jhbuild build configuration for EFL, v1

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

> Tools/Scripts/webkitdirs.pm:1970
> +        return File::Spec->catfile(sourceDir(), "Tools", "efl", "run-with-jhbuild");

Bug 79673 only creates gtk/run-with-jhbuild, are you sure this is right or you're not missing a file here?

> Tools/efl/ecore-gettext-version.patch:8
> +-AM_GNU_GETTEXT_VERSION([0.17])
> ++AM_GNU_GETTEXT_VERSION([0.18])

Can you explain the reasoning behind this patch?

> Tools/efl/jhbuild.modules:20
> +      <dep package="cairo"/>
> +      <dep package="fonts"/>
> +      <dep package="fontconfig"/>
> +      <dep package="freetype6"/>
> +      <dep package="gdk-pixbuf"/>
> +      <dep package="gtk+"/>
> +      <dep package="glib"/>
> +      <dep package="glib-networking"/>
> +      <dep package="gnome-icon-theme"/>
> +      <dep package="libsoup"/>
> +      <dep package="at-spi2-core"/>
> +      <dep package="at-spi2-atk"/>
> +      <dep package="edje"/>

From this list, I'd say the non-EFL dependencies we need are cairo, fonts, fontconfig, freetype6, glib, glib-networking and libsoup. I'm unsure about adding EFL dependencies here, as we sometimes depend on features which are only in trunk and just poke Gyuyoung to update the bot accordingly.

[Dominik Röttsches (drott)]

(In reply to comment #5)
> (From update of attachment 129439 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=129439&action=review
> 
> > Tools/Scripts/webkitdirs.pm:1970
> > +        return File::Spec->catfile(sourceDir(), "Tools", "efl", "run-with-jhbuild");
> 
> Bug 79673 only creates gtk/run-with-jhbuild, are you sure this is right or you're not missing a file here?

The failure for the EFL EWS is because it doesn't find Tools/jhbuild/jhbuild-wrapper. Creating/Moving that script is part of the patch in 79673. 
In the patch attached to this bug here (79904) I am just adding the wrapper for efl, i.e. Tools/efl/run-with-jhbuild, which is supposed to call the generic one Tools/jhbuild/jhbuild-wrapper.

> > Tools/efl/ecore-gettext-version.patch:8
> > +-AM_GNU_GETTEXT_VERSION([0.17])
> > ++AM_GNU_GETTEXT_VERSION([0.18])
> 
> Can you explain the reasoning behind this patch?

Partially ;-). Ecore doesn't build on my system without this, since Ubuntu 11.10 version of gettext is 0.18. The build sees a mismatch between autoconf and gettext macros, IIRC. 
Gyuyoung said Ubuntu 11.10 is what he'll be using for the EFL EWS, so adding a patch to bump the required gettext version in Ecore here is currently the best I could come up with. As mentioned in the initial description of this bug, better suggestions are welcome. Maybe this should be also filed as an issue against Ecore.

> > Tools/efl/jhbuild.modules:20
> > +      <dep package="cairo"/>
> > +      <dep package="fonts"/>
> > +      <dep package="fontconfig"/>
> > +      <dep package="freetype6"/>
> > +      <dep package="gdk-pixbuf"/>
> > +      <dep package="gtk+"/>
> > +      <dep package="glib"/>
> > +      <dep package="glib-networking"/>
> > +      <dep package="gnome-icon-theme"/>
> > +      <dep package="libsoup"/>
> > +      <dep package="at-spi2-core"/>
> > +      <dep package="at-spi2-atk"/>
> > +      <dep package="edje"/>
> 
> From this list, I'd say the non-EFL dependencies we need are cairo, fonts, fontconfig, freetype6, glib, glib-networking and libsoup. I'm unsure about adding EFL dependencies here, as we sometimes depend on features which are only in trunk and just poke Gyuyoung to update the bot accordingly.

So you mean, remove: gdk-pixbuf, gtk+, gnome-icon-theme, at-spi2-*? I can try that.

I am very flexible regarding whether for EFL we take SVN versions or release versions. The clear advantage of having this as part of jhbuild is though, that we don't need to poke Gyuyoung but instead a patch can be filed that updates the requested SVN revision / tag and jhbuild updates the bot's environment automaticall.y

So, in your opinion, pulling from SVN is better here? It'd be good to have Gyuyoung comment on this as well.

[Raphael Kubo da Costa (:rakuco)]

Comment on attachment 129439 [details]
Adding jhbuild build configuration for EFL, v1

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

>>> Tools/Scripts/webkitdirs.pm:1970
>>> +        return File::Spec->catfile(sourceDir(), "Tools", "efl", "run-with-jhbuild");
>> 
>> Bug 79673 only creates gtk/run-with-jhbuild, are you sure this is right or you're not missing a file here?
> 
> The failure for the EFL EWS is because it doesn't find Tools/jhbuild/jhbuild-wrapper. Creating/Moving that script is part of the patch in 79673. 
> In the patch attached to this bug here (79904) I am just adding the wrapper for efl, i.e. Tools/efl/run-with-jhbuild, which is supposed to call the generic one Tools/jhbuild/jhbuild-wrapper.

D'oh, I didn't see this patch added efl/run-with-jhbuild :-)

>>> Tools/efl/ecore-gettext-version.patch:8
>>> ++AM_GNU_GETTEXT_VERSION([0.18])
>> 
>> Can you explain the reasoning behind this patch?
> 
> Partially ;-). Ecore doesn't build on my system without this, since Ubuntu 11.10 version of gettext is 0.18. The build sees a mismatch between autoconf and gettext macros, IIRC. 
> Gyuyoung said Ubuntu 11.10 is what he'll be using for the EFL EWS, so adding a patch to bump the required gettext version in Ecore here is currently the best I could come up with. As mentioned in the initial description of this bug, better suggestions are welcome. Maybe this should be also filed as an issue against Ecore.

This is weird. I have gettext 0.18.1.1 here on ArchLinux and have never had any issue building Ecore (I build it from SVN). We could try to work it out on enlightenment-devel or somewhere else, but putting the patch here looks like the wrong fix right now.

>>> Tools/efl/jhbuild.modules:20
>>> +      <dep package="edje"/>
>> 
>> From this list, I'd say the non-EFL dependencies we need are cairo, fonts, fontconfig, freetype6, glib, glib-networking and libsoup. I'm unsure about adding EFL dependencies here, as we sometimes depend on features which are only in trunk and just poke Gyuyoung to update the bot accordingly.
> 
> So you mean, remove: gdk-pixbuf, gtk+, gnome-icon-theme, at-spi2-*? I can try that.
> 
> I am very flexible regarding whether for EFL we take SVN versions or release versions. The clear advantage of having this as part of jhbuild is though, that we don't need to poke Gyuyoung but instead a patch can be filed that updates the requested SVN revision / tag and jhbuild updates the bot's environment automaticall.y
> 
> So, in your opinion, pulling from SVN is better here? It'd be good to have Gyuyoung comment on this as well.

Yes, I believe pulling the EFL from SVN is a better option here. As for the dependencies to remove, I think you're right: we only depend on the basic glib stuff, libsoup and cairo (plus the fontconfig/freetype stuff to reduce the font rendering inconsistencies). It is also possible to use pango instead of freetype as the font backend. It's not the default, but IIRC it rendered LTR languages better. Not sure how to add this here, though (the bot would need to be changed too, at least).

[Thiago Marcos P. Santos]

Adding EFL libraries as jhbuild dependencies is a good idea because:

1. Availability of EFL packages is not the best even in the mainstream distros. Anyway for people working with the trunk, a newer version of EFL is always a requirment.

2. It should make the life of people trying the port for the first time much easier by making it self-contained.

3. We can make sure that everybody is running the same version. This is specially important for libraries that has a direct impact on rendering results.

4. When a new version of a dependency is required, we just update jhbuild files and the change spreads magically to all developers, keeping test results consistence.

Qt port is doing something similar by keeping a script that builds and install Qt5 based on a git hash. Every time this hash changes on the build bot, the new hash is announced on the mailing list. Should be less error prone if we make this implicitly and automated as Dominik is suggesting.

[Dominik Röttsches (drott)]

(In reply to comment #7)

> >>> Tools/efl/ecore-gettext-version.patch:8
> >>> ++AM_GNU_GETTEXT_VERSION([0.18])
> >> 
> >> Can you explain the reasoning behind this patch?
> > 
> > Partially ;-). Ecore doesn't build on my system without this, since Ubuntu 11.10 version of gettext is 0.18. The build sees a mismatch between autoconf and gettext macros, IIRC. 
> > Gyuyoung said Ubuntu 11.10 is what he'll be using for the EFL EWS, so adding a patch to bump the required gettext version in Ecore here is currently the best I could come up with. As mentioned in the initial description of this bug, better suggestions are welcome. Maybe this should be also filed as an issue against Ecore.
> 
> This is weird. I have gettext 0.18.1.1 here on ArchLinux and have never had any issue building Ecore (I build it from SVN). We could try to work it out on enlightenment-devel or somewhere else, but putting the patch here looks like the wrong fix right now.

Agree. If you have time, it'd be good if you could apply 79673 and this patch here and try building Ecore through jhbuild on your machine (and remove that patch attribute in jhbuild.modules). It'd be interesting to see if it goes through. Might be an issue with jhbuild?

[Raphael Kubo da Costa (:rakuco)]

(In reply to comment #9)
> Agree. If you have time, it'd be good if you could apply 79673 and this patch here and try building Ecore through jhbuild on your machine (and remove that patch attribute in jhbuild.modules). It'd be interesting to see if it goes through. Might be an issue with jhbuild?

I wasn't able to make it that far, as eina failed to build with jhbuild:

*** Configuring eina *** [13/19]
./autogen.sh --prefix /home/rakuco/dev/webkit/WebKit/WebKitBuild/Dependencies/Root --libdir '/home/rakuco/dev/webkit/WebKit/WebKitBuild/Dependencies/Root/lib'  --disable-static --disable-gtk-doc
Running aclocal...
Running autoheader...
Running autoconf...
Running libtoolize...
Running automake...
doc/Makefile.am:33: wildcard $(srcdir: non-POSIX variable name
doc/Makefile.am:33: (probably a GNU make extension)
src/examples/Makefile.am:42: `pkglibdir' is not a legitimate directory for `PROGRAMS'
src/examples/Makefile.am:81: variable `eina_tiler_01_LDADD' is defined but no program or
src/examples/Makefile.am:81: library has `eina_tiler_01' as canonical name (possible typo)

[Dominik Röttsches (drott)]

Created attachment 129897 [details]
Adding jhbuild build configuration for EFL, v2, pulling EFL from SVN

Compilation of ecore is likely to fail due to the gettext version issue.
Workaround:
$ cd WebKitBuild/Dependencies/Source/ecore
$ rm -rf *
$ svn up
- then edit configure.ac and bump gettext version to 0.18
- go back to WebKit top level and run
- Tools/Scripts/update-webkitefl-libs
restart build, eg.
$ Tools/Scripts/build-webkit --efl --release

[Dominik Röttsches (drott)]

(In reply to comment #10)
> *** Configuring eina *** [13/19]
> ./autogen.sh --prefix /home/rakuco/dev/webkit/WebKit/WebKitBuild/Dependencies/Root --libdir '/home/rakuco/dev/webkit/WebKit/WebKitBuild/Dependencies/Root/lib'  --disable-static --disable-gtk-doc
> [...]
> doc/Makefile.am:33: wildcard $(srcdir: non-POSIX variable name
> doc/Makefile.am:33: (probably a GNU make extension)
> src/examples/Makefile.am:42: `pkglibdir' is not a legitimate directory for `PROGRAMS'

It seems that the release tarballs have some issues when running autogen.sh, it works a little better with the SVN heads.

[Dominik Röttsches (drott)]

Created attachment 129917 [details]
Adding jhbuild build configuration for EFL, v3, pulling fixed revision of EFL from SVN, partial_build=False

Setting partial_build=False in jhbuildrc fixes issues with gettext macro versions getting mixed up, using this patch + the patch in bug 79673 webkit-efl can be built completely using e.g. Tools/Scripts/build-webkit --efl --release. 
Thanks to Thiago for helping find this gettext/aclocal issue.

[Gyuyoung Kim]

Comment on attachment 129917 [details]
Adding jhbuild build configuration for EFL, v3, pulling fixed revision of EFL from SVN, partial_build=False

Attachment 129917 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11802039

[Raphael Kubo da Costa (:rakuco)]

Comment on attachment 129917 [details]
Adding jhbuild build configuration for EFL, v3, pulling fixed revision of EFL from SVN, partial_build=False

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

I was finally able to checkout and build the EFL with this version, thanks. Pardon if my comments in the patch sound stupid, but I've never used jhbuild before ;)

From the changes to webkitdirs.pm, it looks like jhbuild will be run every time build-webkit --efl is run, right? Is that what the autotools folks also do? My concern here is that distros and people who are building from a snapshot (or a stable release when one comes out) end up having to check out the jhbuild modules and build against them instead of their system libraries.

> Tools/efl/jhbuildrc:23
> +__efl_tools_directory = os.path.abspath(os.path.dirname(__file__))
> +sys.path.append(__efl_tools_directory)
> +import common

common.py is in the same directory, are you sure you need to manually add __efl_tools_directory to sys.path?

> Tools/efl/jhbuildrc:45
> +os.environ['MAKEFLAGS'] = '-j' + str(common.number_of_cpus())

Shouldn't we respect MAKEFLAGS if it's already set? One can be using icecc and have exported MAKEFLAGS to -j40, for example.

> Tools/efl/jhbuildrc:56
> +addpath('PKG_CONFIG_PATH', os.path.join(os.sep, 'usr', _libdir, 'pkgconfig'))
> +addpath('PKG_CONFIG_PATH', os.path.join(os.sep, 'usr', 'share', 'pkgconfig'))
> +
> +addpath('XDG_DATA_DIRS', '/usr/share')
> +addpath('XDG_CONFIG_DIRS', '/etc/xdg')

Are these really necessary? Hardcoding paths here doesn't feel very good (even if 99% of the Linux distros use this directory scheme, it won't really work with my FreeBSD installation at home :-)

> Tools/efl/jhbuildrc:59
> +# GTK+ 3.0.12 misses the -lm flag when linking the tests.
> +module_makeargs['gtk+'] = 'LDFLAGS="-lm" ' + makeargs

Do we need this even if we don't depend on GTK?

[Dominik Röttsches (drott)]

Created attachment 132026 [details]
Adding jhbuild build configuration for EFL, v4

(In reply to comment #15)
> From the changes to webkitdirs.pm, it looks like jhbuild will be run every time build-webkit --efl is run, right? Is that what the autotools folks also do? My concern here is that distros and people who are building from a snapshot (or a stable release when one comes out) end up having to check out the jhbuild modules and build against them instead of their system libraries.

As discussed on IRC, plain cmake based build should not be affected by this.

> > Tools/efl/jhbuildrc:23
> > +__efl_tools_directory = os.path.abspath(os.path.dirname(__file__))
> > +sys.path.append(__efl_tools_directory)
> > +import common
> 
> common.py is in the same directory, are you sure you need to manually add __efl_tools_directory to sys.path?

Yes, run-with-jhbuild is used from webkitdirs.pm which chdir's to WebKitBuild dir. Errors occur if I am not adding the filepath to the search path.

> > Tools/efl/jhbuildrc:45
> > +os.environ['MAKEFLAGS'] = '-j' + str(common.number_of_cpus())
> 
> Shouldn't we respect MAKEFLAGS if it's already set? One can be using icecc and have exported MAKEFLAGS to -j40, for example.

Done, not overwriting.

> > Tools/efl/jhbuildrc:56
> > +addpath('PKG_CONFIG_PATH', os.path.join(os.sep, 'usr', _libdir, 'pkgconfig'))
> > +addpath('PKG_CONFIG_PATH', os.path.join(os.sep, 'usr', 'share', 'pkgconfig'))
> > +
> > +addpath('XDG_DATA_DIRS', '/usr/share')
> > +addpath('XDG_CONFIG_DIRS', '/etc/xdg')
> 
> Are these really necessary? Hardcoding paths here doesn't feel very good (even if 99% of the Linux distros use this directory scheme, it won't really work with my FreeBSD installation at home :-)

The XDG ones seem to be necessary only for GTK+, removed.
The remaining PKG_CONFIG_PATH ones are needed to find remaining dependencies which we don't clamp using jhbuild but instead use from the system.

> > Tools/efl/jhbuildrc:59
> > +# GTK+ 3.0.12 misses the -lm flag when linking the tests.
> > +module_makeargs['gtk+'] = 'LDFLAGS="-lm" ' + makeargs
> 
> Do we need this even if we don't depend on GTK?

Removed.

[Gyuyoung Kim]

Comment on attachment 132026 [details]
Adding jhbuild build configuration for EFL, v4

Attachment 132026 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11953756

[Thiago Marcos P. Santos]

Better wait for bug 79673 to land before triggering EWS, isn't? :)

[Raphael Kubo da Costa (:rakuco)]

Comment on attachment 132026 [details]
Adding jhbuild build configuration for EFL, v4

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

Looks fine to be, just one nitpick below.

> Tools/efl/jhbuildrc:45
> +if (not 'MAKEFLAGS' in os.environ):

The Pythonic way of writing this is

    if 'MAKEFLAGS' not in os.environ:

[Dominik Röttsches (drott)]

Created attachment 132050 [details]
Adding jhbuild build configuration for EFL, v5

More pythonic now.

I think this one should be landed together with 80025 in order to have a full jhbuild configuration for the EFL buildbot.

[Gyuyoung Kim]

Comment on attachment 132050 [details]
Adding jhbuild build configuration for EFL, v5

Attachment 132050 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11958590

[Raphael Kubo da Costa (:rakuco)]

(In reply to comment #21)
> (From update of attachment 132050 [details])
> Attachment 132050 [details] did not pass efl-ews (efl):
> Output: http://queues.webkit.org/results/11958590

Weird, the build is first failing on p11-kit.

[Thiago Marcos P. Santos]

(In reply to comment #22)
> (In reply to comment #21)
> > (From update of attachment 132050 [details] [details])
> > Attachment 132050 [details] [details] did not pass efl-ews (efl):
> > Output: http://queues.webkit.org/results/11958590
> 
> Weird, the build is first failing on p11-kit.

libgcrypt is failing first (we might need to install some packages on the bot):

    configure: error: libgpg-error is needed.


But I think both errors are unrelated since the libs don't depend on each other.

[Dominik Röttsches (drott)]

Gyuyoung, it seems the EWS is missing at least:
libgpg-error-dev
libpthread-stubs0-dev

Could you try running
$ apt-get build-dep p11-kit
$ apt-get build-dep libgcrypt11

Then, I'll resubmit and see whether we can get it to pass? Thanks.

[Dominik Röttsches (drott)]

Created attachment 132225 [details]
Adding jhbuild build configuration for EFL, v5, resubmit

Resubmitting after Gyuyoung installed additional packages on EWS. (Thanks!)
Let's see if this build goes through in EWS.

[Gyuyoung Kim]

Comment on attachment 132225 [details]
Adding jhbuild build configuration for EFL, v5, resubmit

Attachment 132225 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11966054

[Dominik Röttsches (drott)]

Created attachment 132236 [details]
Adding jhbuild build configuration for EFL, v6

Now the build bot does not automatically fetch dependencies any more since the WebKitBuild/Depencies folder was created, I assume.
Adding an explicit jhbuild installation step to the buildbot.

[Gyuyoung Kim]

Comment on attachment 132236 [details]
Adding jhbuild build configuration for EFL, v6

Attachment 132236 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11963129

[Dominik Röttsches (drott)]

Created attachment 132256 [details]
Adding jhbuild build configuration for EFL, v5

Back to v5, master.cfg update needs to be manually pushed to build.webkit.org - according to README.
I created a separate bug 81337 for that.

It would be ideal if we are able to land bug 81337 and this one here, bug 79904 in direct succession.

[Gustavo Noronha (kov)]

Comment on attachment 132256 [details]
Adding jhbuild build configuration for EFL, v5

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

Partial review.

> Tools/Scripts/webkitdirs.pm:1974
> +    } else {
> +        return "";
> +    }
> +}

We don't need this else, just make the default case return "".

> Tools/efl/common.py:1
> +#!/usr/bin/env python

We should probably move this file to webkitpy so it can be shared.

[Dominik Röttsches (drott)]

Created attachment 132267 [details]
Adding jhbuild build configuration for EFL, v7,  (=v5 fixing else case)

else case replaced by default return.

[Raphael Kubo da Costa (:rakuco)]

Comment on attachment 132267 [details]
Adding jhbuild build configuration for EFL, v7,  (=v5 fixing else case)

Clearing the r? flag, we can just call this one the version for landing of the previous attempt.

[Dominik Röttsches (drott)]

(In reply to comment #30)
> (From update of attachment 132256 [details])

> We don't need this else, just make the default case return "".

Done in v7.

> > Tools/efl/common.py:1
> > +#!/usr/bin/env python
> 
> We should probably move this file to webkitpy so it can be shared.

Tracked in bug 81344.

[Gyuyoung Kim]

Comment on attachment 132267 [details]
Adding jhbuild build configuration for EFL, v7,  (=v5 fixing else case)

Attachment 132267 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11962377

[Raphael Kubo da Costa (:rakuco)]

The p11-kit problem seems to be solved in their next release, I'll update the patch and check again.

[Raphael Kubo da Costa (:rakuco)]

Created attachment 132312 [details]
Bump p11-kit to 0.12 and tickle EWS again

[Gyuyoung Kim]

Comment on attachment 132312 [details]
Bump p11-kit to 0.12 and tickle EWS again

Attachment 132312 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11960843

[Raphael Kubo da Costa (:rakuco)]

Created attachment 132429 [details]
Poke EWS again after cleaning Dependencies/ once more

[Gyuyoung Kim]

Comment on attachment 132429 [details]
Poke EWS again after cleaning Dependencies/ once more

Attachment 132429 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11966606

[Raphael Kubo da Costa (:rakuco)]

(In reply to comment #39)
> (From update of attachment 132429 [details])
> Attachment 132429 [details] did not pass efl-ews (efl):
> Output: http://queues.webkit.org/results/11966606

Sigh, the EFL EWS runs Ubuntu 10.04 LTS, whose libgpg-error-dev is too old (libgcrypt requires libgpg-error >= 1.8, we have 1.6). Will update jhbuild.modules again, adding gpg-error.

[Raphael Kubo da Costa (:rakuco)]

Created attachment 132440 [details]
Add libgpg-error to jhbuild.modules

[Gyuyoung Kim]

Comment on attachment 132440 [details]
Add libgpg-error to jhbuild.modules

Attachment 132440 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11974275

[Raphael Kubo da Costa (:rakuco)]

Created attachment 132442 [details]
Configure libgpg-error correctly

[Gyuyoung Kim]

Comment on attachment 132442 [details]
Configure libgpg-error correctly

Attachment 132442 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11960970

[Raphael Kubo da Costa (:rakuco)]

Created attachment 132443 [details]
Same patch after tinkering with the EFL EWS

[Raphael Kubo da Costa (:rakuco)]

Created attachment 132446 [details]
Poke EWS one more time

[Raphael Kubo da Costa (:rakuco)]

Created attachment 132448 [details]
Poke EWS one more time

[Raphael Kubo da Costa (:rakuco)]

Created attachment 132450 [details]
Make even more sure the jhbuild dependencies are being used

[Raphael Kubo da Costa (:rakuco)]

(In reply to comment #48)
> Created an attachment (id=132450) [details]
> Make even more sure the jhbuild dependencies are being used

Excellent, 17th time is a charm :-)

After tinkering with the EWS more than I would have liked, the last run finally picked up the libraries and binaries from WebKitBuild/Dependencies, so we're good to go.

[Raphael Kubo da Costa (:rakuco)]

Committed r111115: <http://trac.webkit.org/changeset/111115>

[Dominik Röttsches (drott)]

In Bug 81510 we needed to put the XDG_* vars back in.