After a lot of testing, I think I've found the actual culprit — it's
QtWebEngine's GPU probing on GPU-less servers, not html5-parser
itself.
The workaround that fixed it:
Quote:
|
QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox --disable-gpu --disable-software-rasterizer" ebook-convert b.epub b.pdf
|
The full investigation with AI support is as follows:
Quote:
Finally nailed it down completely. It's not an html5-parser bug at
all — it's QtWebEngine's GPU/EGL probing on GPU-less servers.
Root cause, confirmed via full LD_DEBUG traces comparing calibre 8.13
(works) vs 9.11 (fails) on identical GPU-less Debian 12 hosts:
8.13 — after EGL/GBM init, goes straight into QtWebEngineCore, only
ever loads one libxml2 (calibre's bundled libxml2.so.16). Clean run.
9.11 — after libEGL_mesa.so.0, goes on to actually load Mesa's
software rasterizer fallback:
calling init: libEGL_mesa.so.0
find library=libxml2.so.2 [0]; searching
trying file=/lib/x86_64-linux-gnu/libxml2.so.2
calling init: libicudata.so.72 / libpciaccess.so.0 / libxml2.so.2
calling init: libLLVM-15.so.1
calling init: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
...
calling init: html5_parser.html_parser.so
RuntimeError: html5-parser and lxml are using different versions
of libxml2 ... html5-parser: (2, 9, 14) != lxml: (2, 15, 3)
swrast_dri.so is Mesa's software rasterizer (a Debian system package,
not part of calibre), and it pulls in the system's own libxml2.so.2
as a transitive dependency — loading it into the same process as
calibre's bundled libxml2.so.16. Two different libxml2 copies end up
coexisting in one process, and html5-parser's version check reads the
wrong one.
Both servers are equally GPU-less, so 9.11's bundled Qt/QtWebEngine
apparently probes one step further into EGL/GPU detection than 8.13's
did — actually reaching the Mesa software-rasterizer fallback instead
of stopping earlier. Looks like a Qt/QtWebEngine behavior change
between the two calibre builds.
|
Given that this will affect anyone running 9.11 on a GPU-less
VPS/server (a pretty common calibre-server setup), it might be worth
flagging in the docs, or even defaulting to --disable-gpu when no
display/GPU is detected.