#13590 closed defect (fixed)
was 'Jinja2 python2 ends in error', now 'QtWebEngine does not need Jinja2'.
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | 10.0 |
Component: | BOOK | Version: | SVN |
Severity: | normal | Keywords: | |
Cc: |
Description
Not sure if this happens all the time, or mostly, or only randomly.
I initially reported this in http://lists.linuxfromscratch.org/pipermail/blfs-support/2020-May/082000.html but at that time a subsequent DESTDIR install appeared to work without problems.
A day or so ago, I hit the same problem on a fresh system.
Note that Jinja-2.11.2 is the last version that will support Python2, so trying to debug it seems like a waste of time when there is a workaround.
What seems to happen is that after Jinja has been installed for 2.7, easy_install looks at the runtime dependencies and decides that MarkupSafe is needed. With 2.11.1 I think it didn't install that for 2.7, but now - at least when the problem occurs - it tries to install the current version and that does not supprot python2.
true' to the install (and to manually check that files in /usr/lib/python2.7/site-packages/Jinja2-2.11.2-py2.7.egg/jinja2/ have been installed). |
I'm proposing to include the workaround in the hope that jhalfs will not fail in this case.
For explanatory text:
Sometimes the python2 install tries to install the current version of MarkupSafe, and fails. As long as the files in /usr/lib/python2.7/site-packages/Jinja2-2.11.2-py2.7.egg/jinja2 have been installed, the install will be adequate for QtWebengine.
true" : do not return an error status when the install apparently fails (to allow scripted installs). |
I'll note that the source has the following references to MarkupSafe:
./setup.py: install_requires=MarkupSafe>=0.23,
./docs/templates.rst:MarkupSafe.Markup
strings with an html
attribute.
./docs/intro.rst:MarkupSafe Dependency
./docs/intro.rst:As of version 2.7 Jinja depends on the
MarkupSafe
_ module. If you install
./docs/intro.rst:.. _MarkupSafe: https://markupsafe.palletsprojects.com/
./CHANGES.rst:- Depend on MarkupSafe 0.23 or higher.
Also, I had the exact same problem when I first hit this and tried reverting to 2.11.1. Hmm, I had thought that MarkupSafe was unnecessary, but I see that in BLFS-9.1 it managed to install 1.1.1 for 2.7. Whatever, qtwebengine doesn't need it. Perhaps Python-2.7.18 broke something.
Change History (7)
comment:1 by , 4 years ago
comment:2 by , 4 years ago
My current 4-core build has just got to Qt. Will try using only python3 for Jinja2.
comment:3 by , 4 years ago
To my immense surprise (given that only a Python3 module gets installed by Jinja2), everything completed.
Looking at the logs from qtwebengine-5.15.0, no mention of Jinja, the references to jinja seem to be all for python2 :
ken@origin ~ $grep jinja /home/logs/LFS-svn-20200526-glibcdef/desktop5/qtwebengine-everywhere-src-5.15.0.log [932/18172] /usr/bin/python2 ../../../../src/3rdparty/chromium/third_party/inspector_protocol/code_generator.py --jinja_dir ../../../../src/3rdparty/chromium/third_party/ --output_base gen/components/ui_devtools --config ../../../../src/3rdparty/chromium/components/ui_devtools/inspector_protocol_config.json --inspector_protocol_dir //third_party/inspector_protocol [3601/18172] /usr/bin/python2 ../../../../src/3rdparty/chromium/third_party/inspector_protocol/code_generator.py --jinja_dir ../../../../src/3rdparty/chromium/third_party/ --output_base gen/content/browser/devtools --config ../../../../src/3rdparty/chromium/content/browser/devtools/protocol_config.json --inspector_protocol_dir //third_party/inspector_protocol --config_value protocol.path=gen/third_party/blink/public/devtools_protocol/protocol.json [3629/18172] /usr/bin/python2 ../../../../src/3rdparty/chromium/third_party/inspector_protocol/code_generator.py --jinja_dir ../../../../src/3rdparty/chromium/third_party/ --output_base gen/third_party/blink/renderer/core --config ../../../../src/3rdparty/chromium/third_party/blink/renderer/core/inspector/inspector_protocol_config.json --inspector_protocol_dir //third_party/inspector_protocol --config_value imported.path=../../../../src/3rdparty/chromium/v8/include/js_protocol.pdl [3692/18172] /usr/bin/python2 ../../../../src/3rdparty/chromium/third_party/blink/renderer/bindings/scripts/code_generator.py gen/third_party/blink/renderer/bindings/scripts gen/third_party/blink/renderer/bindings/scripts/cached_jinja_templates.stamp [3697/18172] touch obj/third_party/blink/renderer/bindings/scripts/cached_jinja_templates.stamp [4375/18172] /usr/bin/python2 ../../../../src/3rdparty/chromium/third_party/dawn/generator/dawn_json_generator.py --dawn-json ../../../../src/3rdparty/chromium/third_party/dawn/dawn.json --wire-json ../../../../src/3rdparty/chromium/third_party/dawn/dawn_wire.json --targets dawn_headers --template-dir /scratch/working/qtwebengine-everywhere-src-5.15.0/src/3rdparty/chromium/third_party/dawn/generator/templates --jinja2-path /scratch/working/qtwebengine-everywhere-src-5.15.0/src/3rdparty/chromium/third_party/jinja2 --output-json-tarball gen/third_party/dawn/dawn_headers_gen.json_tarball --depfile gen/third_party/dawn/dawn_headers_gen.json_tarball.d --expected-outputs-file gen/third_party/dawn/dawn_headers_gen.expected_outputs --allowed-output-dirs-file gen/third_party/dawn/dawn_headers_gen.allowed_output_dirs [10011/18172] /usr/bin/python2 ../../../../src/3rdparty/chromium/v8/third_party/inspector_protocol/code_generator.py --jinja_dir ../../../../src/3rdparty/chromium/third_party/ --output_base gen/v8/src/inspector --config ../../../../src/3rdparty/chromium/v8/src/inspector/inspector_protocol_config.json --inspector_protocol_dir //v8//third_party/inspector_protocol
I'm expecting to do a fresh build of cross-chap5 on this system in the next week or two, trying -O2 -march=native in glibc re my sigfpe quest. I'll remove Jinja2 from my buildscript, and find out whether it really is needed for qtwebengine.
comment:4 by , 4 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Summary: | Jinja2 python2 ends in error → was 'Jinja2 python2 ends in error', now 'QtWebEngine does not need Jinja2'. |
I've now built QtWebengine-5.15 without installing Jinja2. Will remove that dependency.
Looking at the other user (kapidox) that definitely has Jinja2 as a runtime dep, and claims to support 2 or 3. I don't build kde, and it is not clear to me how kapidox would invoke python. I suspect it might expect Python to be a symlink to 3, not 2 if it is to use 3.
Whatever, I've just run a Jinja2-2.11.2 python2 'DESTDIR' install (--root=/some/where) which again succeeded, so I'll just remove the dependency from qtwebengine and leave the py2 build alone.
comment:5 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
OK, I removed the jinja dependency from qtwebengine and made jinja oython3 only.
Reopen if we run into a problem.
I am not convinced we need this change. The book does not use && between the p2 and p3 install commands. I think the only issue here is when scripting. My script does not use && and did not have any problem.
I did look at my log from May 13 and I did see entries similar to:
in two places but repeated 4 times for 8 total messages. However the appropriate files are in place.
At most, I think a note in the book would be appropriate. For jhalfs we might want to add an attribute like remap='nofail' so it does not complain.
I will note that async is a p3 keyword but not recognized by p2.
I'll also note that we only reference Jinja in kf5 and qtwebengine. Perhaps we should just drop the p2 version of Jinja.