update-webkitgtk-libs currently passes --no-interact to jhbuild. It's really hard to understate how frustrating this it -- it makes jhbuild continue to build even after something has failed, and it's very difficult to discover why things fail to build, since the error is always long past normal terminal scrollback limits. Instead, I expect to immediately get a build error with the nice menu that allows me to decide how to fix the problem.
If the bots need the --no-interact behavior, we'll need to add a flag to update-webkitgtk-libs for that.
(In reply to comment #0)
> update-webkitgtk-libs currently passes --no-interact to jhbuild. It's really
> hard to understate how frustrating this it -- it makes jhbuild continue to
> build even after something has failed, and it's very difficult to discover
> why things fail to build, since the error is always long past normal
> terminal scrollback limits. Instead, I expect to immediately get a build
> error with the nice menu that allows me to decide how to fix the problem.
> If the bots need the --no-interact behavior, we'll need to add a flag to
> update-webkitgtk-libs for that.
JHBuild should not ask any question, so no-interact make a lot of sense.
What don't makes sense is that it continues building even when no-interact is enabled.
I have tested this patch and it fixes the problem:
@@ -304,7 +304,7 @@ class TerminalBuildScript(buildscript.BuildScript):
self.triedcheckout = None
if not self.config.interact:
- return 'fail'
uprint('  %s' % _('Rerun phase %s') % phase)
I see two options:
a) We fork jhbuild (on github for example) and we apply this patch and then we use it as source on the script Tools/jhbuild/jhbuild-wrapper instead of using upstream git://git.gnome.org/jhbuild'
b) We add an extra step on Tools/gtk/jhbuild.modules after cloning the repo to apply a serie of patches.
Which option is preferred? If is the b. I already have it more or less ready, I can upload a patch for review.
Option B sounds fine to me.
Michael: thanks for reporting this upstream.
I have one doubt... if upstream merges the patch, instead of applying a patch as I suggested previously. I think we can directly raise the version of jhbuild to the one merging that patch, can't we?
Anybody seems any problem raising the version of jhbuild?
The version we are using now seems to be 3.10+, was updated for last time on bug 124966.
(In reply to comment #3)
> Anybody seems any problem raising the version of jhbuild?
I don't see any issues with updating it.
I don't either
OK, upstream jhbuild now has an --exit-on-error option. It can be used like this:
jhbuild --exit-on-error build whatever
Or you can add to jhbuildrc:
exit_on_error = True
Created attachment 256776 [details]
The EFL EWS failed with:
Traceback (most recent call last):
File "/home/gyuyoung/eflews/WebKit/WebKitBuild/DependenciesEFL/Source/jhbuild/jhbuild/config.py", line 197, in load
File "/home/gyuyoung/eflews/WebKit/Tools/jhbuild/../../Tools/efl/jhbuildrc", line 35, in <module>
_libeail_path = os.path.join(os.environ['CMAKE_LIBRARY_PATH'], 'libeail.so')
File "/usr/lib/python2.7/UserDict.py", line 23, in __getitem__
Seems this key is used also by Tools/efl/jhbuildrc
Created attachment 256782 [details]
I added a speculative fix for EFL; let's see if it works.
Note that after this patch, you will almost surely need to rm -rf WebKitBuild before the next time you run update-webkitgtk-libs. As long as you don't try to use jhbuild, I expect your current build directory should continue to work fine.
Created attachment 256783 [details]
Created attachment 256786 [details]
GTK+ EWS just needs a clean build.
Not sure about Mac; it's massively broken, but surely they don't use jhbuild?
OK, Mac is broken without this patch, so I think this patch is good.
Well it should not be a problem for the bots, but my local build failed:
[5445/5718] Generating ../docs-build-no-html.stamp
FAILED: cd /home/mcatanzaro/WebKit/WebKitBuild/Release && CC=/usr/lib64/ccache/cc CFLAGS= /home/mcatanzaro/WebKit/Tools/gtk/generate-gtkdoc --skip-html && touch docs-build-no-html.stamp
Copying template files to output directory...
/usr/lib64/libpangoft2-1.0.so.0: undefined reference to `FcWeightToOpenType'
/usr/lib64/libpangoft2-1.0.so.0: undefined reference to `FcWeightFromOpenType'
collect2: error: ld returned 1 exit status
Linking of scanner failed:
Question is, why is it using the system pango? libpangoft2-1.0.so.0 exists in my jhbuild prefix....
Also, it looks like libffi is broken, improperly installing itself to DependenciesGTK/Root/lib64. It must ignore the libdir set by jhbuild. That's pretty weird, since it uses autotools. Strange that doesn't seem to hurt anything.
A python2.7 folder also gets improperly created for me under DependenciesGTK/Root/lib64, but I'm pretty sure that is a Fedora bug.
Comment on attachment 256786 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=256786&action=review
> +os.environ['LLVMPIPE_LIBGL_PATH'] = os.path.abspath(os.path.join(checkoutroot, 'Mesa', 'lib', 'gallium'))
Note that this has changed, we use buildroot now instead of checkoutroot
Created attachment 266775 [details]
Comment on attachment 266775 [details]
Clearing flags on attachment: 266775
Committed r193639: <http://trac.webkit.org/changeset/193639>
All reviewed patches have been landed. Closing bug.