FS#44706 - [qt5-webengine] Fails to build due to TypeError in ply/yacc.py

Attached to Project: Arch Linux
Opened by Florian Bruhin (The-Compiler) - Thursday, 23 April 2015, 19:36 GMT
Last edited by Felix Yan (felixonmars) - Wednesday, 06 May 2015, 05:31 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I'm trying to build qt5-webengine via makepkg, however the build fails after a while with the following python exception:

[2531/10084] RULE Generating C++ code from ax_enums.idl IDL files
FAILED: cd ../../../src/3rdparty/chromium/ui/accessibility; python ../../tools/json_schema_compiler/compiler.py "ax_enums.idl" "--root=../.." "--destdir=../../../../../src/core/Release/gen" "--namespace=" "--generator=cpp" "--
impl-dir=chrome/browser/extensions/api"
Traceback (most recent call last):
File "../../tools/json_schema_compiler/compiler.py", line 170, in <module>
opts.impl_dir)
File "../../tools/json_schema_compiler/compiler.py", line 50, in GenerateSchema
api_def = schema_loader.LoadSchema(os.path.split(schema)[1])
File "/home/florian/proj/qt-debug-pkgbuild/qt5/src/qt-everywhere-opensource-src-5.4.1/qtwebengine/src/3rdparty/chromium/tools/json_schema_compiler/schema_loader.py", line 64, in LoadSchema
api_defs = idl_schema.Load(schema_path)
File "/home/florian/proj/qt-debug-pkgbuild/qt5/src/qt-everywhere-opensource-src-5.4.1/qtwebengine/src/3rdparty/chromium/tools/json_schema_compiler/idl_schema.py", line 462, in Load
idl = idl_parser.IDLParser().ParseData(contents, filename)
File "/home/florian/proj/qt-debug-pkgbuild/qt5/src/qt-everywhere-opensource-src-5.4.1/qtwebengine/src/3rdparty/chromium/tools/json_schema_compiler/../../ppapi/generators/idl_parser.py", line 908, in __init__
optimize=0, write_tables=0)
File "/usr/lib/python2.7/site-packages/ply/yacc.py", line 3234, in yacc
read_signature = lr.read_table(outputdir, tabmodule)
File "/usr/lib/python2.7/site-packages/ply/yacc.py", line 1967, in read_table
parsetab = __import__(module)
TypeError: __import__() argument 1 must be string, not None
[2531/10084] CXX obj/src/3rdparty/chromium/skia/ext/skia_chrome.bitmap_platform_device_skia.o
ninja: build stopped: subcommand failed.

I've talked to upstream about this in their IRC channel, and they've not seen this happen so far:

17:44 <@bbandix> The-Compiler: never seen that, what is your python version?
17:46 <The-Compiler> bbandix: I'm on Archlinux, so /usr/bin/python is 3.4.3 by default, but while packaging a folder with python as 2.7.9 gets inserted at the beginning of $PATH.
17:47 <@bbandix> The-Compiler: yeah, python 3 is not supported by chromium
17:47 <@bbandix> The-Compiler: not sure why you see this, I also use arch, and it compiles fine for me
17:50 <The-Compiler> bbandix: it seems like it actually *is* using python2.7, see /usr/lib/python2.7/site-packages/ply/yacc.py
17:50 <The-Compiler> and it used to work for me as well last time I built it
17:52 <@bbandix> yeah saw that, was just interested in the x in 2.7.x, but already qmake should fail if python is not right, so this is probably not a version issue
17:57 <The-Compiler> It's a custom PKGBUILD with minimal changes (see https://github.com/The-Compiler/qt-debug-pkgbuild/compare/symbols ) - though to be sure I can try building the default Arch one
18:01 <@mibrunin> The-Compiler: and that is with 5.4.1?
18:01 <The-Compiler> mibrunin: yep
18:01 <The-Compiler> qt-everywhere-opensource-src-5.4.1.tar.xz
18:01 <@mibrunin> The-Compiler: ah, okay - strange
18:02 <@mibrunin> The-Compiler: we changed something in the python idl generator scripts, but that was after 5.4.1
18:14 <The-Compiler> mibrunin: is this something which would be likely to be affected by builds with vs. without debug symbols?
18:14 <@mibrunin> The-Compiler: I don't think so
18:15 <@mibrunin> The-Compiler: at least, haven't seen a python error that was specific to debug or release so far
18:15 <The-Compiler> Yeah, that's what I thought too... I'll still try with the default one, and if it's there too I guess the best thing would be to open an Archlinux bug

I remember having built -3 successfully in the past, but now I can't anymore (also deleted everything and rebuilt), so no idea how it broke...
This task depends upon

Closed by  Felix Yan (felixonmars)
Wednesday, 06 May 2015, 05:31 GMT
Reason for closing:  Upstream
Comment by Florian Bruhin (The-Compiler) - Thursday, 23 April 2015, 21:14 GMT
Downgrading python2-ply to 3.4-4 (from 3.5-1) fixes the issue. Is this something I should report upstream?

(also, sorry for the messed up formatting above)
Comment by Florian Bruhin (The-Compiler) - Monday, 04 May 2015, 10:05 GMT
I also see this happening with the chromium package. Removing python2-ply entirely also makes the problem go away as the one in third_party is used then.

I opened a chromium bug report here: https://code.google.com/p/chromium/issues/detail?id=484119
Comment by Florian Bruhin (The-Compiler) - Monday, 04 May 2015, 11:20 GMT
I just found the related bugreport for ply:

https://github.com/dabeaz/ply/issues/63

> Hmmm. I'll be honest, I'm not super keen on supporting this passing of the bare module objects like that (although apparently past versions of PLY allowed it for some reason).

> I'm going to fix this, but I'm going to wait another 4-5 days for a release just to see if other issues come in.

So I think this can be closed - sorry for the noise!

Loading...