Bug 145697

(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: --- a/jhbuild/frontends/terminal.py +++ b/jhbuild/frontends/terminal.py @@ -304,7 +304,7 @@ class TerminalBuildScript(buildscript.BuildScript): self.triedcheckout = None if not self.config.interact: - return 'fail' + sys.exit(1) while True: print uprint(' [1] %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] Patch

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 execfile(filename, config) 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__ raise KeyError(key) KeyError: 'CMAKE_LIBRARY_PATH' Seems this key is used also by Tools/efl/jhbuildrc

Created attachment 256782 [details] Patch

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] Patch

Created attachment 256786 [details] Patch

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... Running gtkdoc-scan Running gtkdoc-scangobj /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] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=256786&action=review > Tools/gtk/jhbuildrc:36 > +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] Patch

Comment on attachment 266775 [details] Patch Clearing flags on attachment: 266775 Committed r193639: <http://trac.webkit.org/changeset/193639>

All reviewed patches have been landed. Closing bug.