# Calibre ebook-viewer requires QtWebEngine

DoneSubmitted by Andreas Enge.
Details
3 participants
• Andreas Enge
• Brendan Tildesley
• Prafulla Giri
Owner
unassigned
Severity
normal
A
A
Andreas Enge wrote on 1 Sep 11:48 +0200
20200901094817.GB4371@jurong
Hello,
when trying to view an epub using ebook-viewer from the calibre package(or by directly clicking on an epub in calibre), the program fails withthe message: Could not find QtWebEngineProcess
I see that commit d79ec4fd343bc2a72652aa3a4b4ae14bd8df88ac has addedpython2-pyqtwebengine and qtwebengine to the calibre inputs, but thisis apparently not enough.
I did not git bisect to see where the problem first appeared, but coulddo so if this would help debugging.
Andreas
A
A
Andreas Enge wrote on 1 Sep 12:03 +0200
20200901100347.GA5189@jurong
I did an strace and found the following:4989 access("/gnu/store/kwx5xihpxmjjf8f8446vn883ank1qcg1-qtbase-5.14.2/lib", F_OK) = 04989 access("/gnu/store/kwx5xihpxmjjf8f8446vn883ank1qcg1-qtbase-5.14.2/lib/qt5/libexec/QtWebEngineProcess", F_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)4989 access("/gnu/store/sd278fsdfx5hjrcgncflnp9qq4l42p1c-python2-2.7.17/bin/QtWebEngineProcess", F_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)4989 write(2, "Could not find QtWebEngineProces"..., 34) = 34
This is a problem with a non-monolithic qt package: The file it islooking for resides in qtwebengine, not qtbase.
The following works:QTWEBENGINEPROCESS_PATH=guix build qtwebengine/lib/qt5/libexec/QtWebEngineProcess ebook-viewer
Do we need to set a search path in qtwebengine?
Andreas
A
A
Andreas Enge wrote on 1 Sep 12:37 +0200
Re: bug#43151: Calibre ebook-viewer requires QtWebEngine
20200901103712.GA6381@jurong
On Tue, Sep 01, 2020 at 12:03:47PM +0200, Andreas Enge wrote:
Toggle quote (5 lines)> The following works:> QTWEBENGINEPROCESS_PATH=guix build qtwebengine/lib/qt5/libexec/QtWebEngineProcess ebook-viewer> > Do we need to set a search path in qtwebengine?
Well, no, since qtwebengine is not actually installed. Probably add it in awrapper around ebook-viewer and wherever else it pops up in applications?
Andreas
B
B
Brendan Tildesley wrote on 3 Sep 05:33 +0200
Re: Calibre ebook-viewer requires QtWebEngine
I created this patch which I think fixes it, copying the phase from
Perhaps I should have only wrapped the ebook-viewer with qtwebengine instead of every program.
A
A
Andreas Enge wrote on 6 Sep 10:25 +0200
Re: bug#43151: Calibre ebook-viewer requires QtWebEngine
20200906082519.GA1716@jurong
(cc-ing this and only this bug, the other one seems to have diverged towardscss and typescript)
On Fri, Sep 04, 2020 at 07:53:02PM +1000, Brendan Tildesley wrote:
Toggle quote (20 lines)> > I did not realise there was already an open ticket for updating calibre,> > thanks for pointing it out. Indeed I do not think we need to wrap all> > programs. I tried out the programs in ...calibre-4.18.0/bin, and only these> > two fail with an error message:> > ebook-edit> > ebook-viewer> > I did not try the different calibre-*; calibre itself starts. Then it can call> > ebook-viewer, and I do not know the mechanism, so it might just call the> > wrapped binary ebook-viewer, or it might need wrapping itself because of using> > internal python mechanics. I would give it a try and not wrap it in the first> > place.> > > > All "binaries" are already wrappend with PYTHONPATH, so there is probably some> > mechanic to avoid double wrapping (which your patch may already address).> Since it uses (replace 'wrap..., it won't run the old wrap phase any more.> Also I don't think it matters much that the other variables also have the Qt> variable wrapped, perhaps it is more correct anyway. Especially since the> wrap script uses '=, which wrap-program interprets as overwriting the> variable completely, so applying it twice won't make a difference anyway.
Well, I think we should not wrap more than absolutely necessary. And it wouldeven be easier to write (no need to look for all the binaries, just use thesetwo names). Would you like to create a patch maybe for the current calibre,and handle the update following the other bug?
Andreas
B
B
Brendan Tildesley wrote on 7 Sep 08:01 +0200
27419617-9220-0f24-6ce1-6a2faae939d9@brendan.scot
On 6/9/20 6:25 pm, Andreas Enge wrote:
Toggle quote (30 lines)> (cc-ing this and only this bug, the other one seems to have diverged towards> css and typescript)>> On Fri, Sep 04, 2020 at 07:53:02PM +1000, Brendan Tildesley wrote:>>> I did not realise there was already an open ticket for updating calibre,>>> thanks for pointing it out. Indeed I do not think we need to wrap all>>> programs. I tried out the programs in ...calibre-4.18.0/bin, and only these>>> two fail with an error message:>>> ebook-edit>>> ebook-viewer>>> I did not try the different calibre-*; calibre itself starts. Then it can call>>> ebook-viewer, and I do not know the mechanism, so it might just call the>>> wrapped binary ebook-viewer, or it might need wrapping itself because of using>>> internal python mechanics. I would give it a try and not wrap it in the first>>> place.>>>>>> All "binaries" are already wrappend with PYTHONPATH, so there is probably some>>> mechanic to avoid double wrapping (which your patch may already address).>> Since it uses (replace 'wrap..., it won't run the old wrap phase any more.>> Also I don't think it matters much that the other variables also have the Qt>> variable wrapped, perhaps it is more correct anyway. Especially since the>> wrap script uses '=, which wrap-program interprets as overwriting the>> variable completely, so applying it twice won't make a difference anyway.> Well, I think we should not wrap more than absolutely necessary. And it would> even be easier to write (no need to look for all the binaries, just use these> two names). Would you like to create a patch maybe for the current calibre,> and handle the update following the other bug?>> Andreas>
It's actually a bit more complicated because every other executable still requires PYTHONPATH wrapping anyway as python-build-system does it. I just tested creating such a wrap phase that only sets QTWEBENGINEPROCESS_PATH for ebook-viewer and ebook-edit. It works when they are opened directly, but when they are opened via the calibre interface, they fail to find qtwebengine. so it does seem that calibre it's self needs that variable set anyway.
I've attached a patching fixing this one issue. For those I've emailed coming from the Issue I created for updating Calibre, since it looks like the update will be delayed until Mathjax 3 is packaged properly, would you mind just reviewing this fix to get it through for the current Calibre.
I think Ricardo was having a go at packaging swc to transpile typescript which is needed for mathjax, but it looks like quite a challenge.
From 33b497cd3b8d21a76307b36729efb67baa08ac26 Mon Sep 17 00:00:00 2001From: Brendan Tildesley <mail@brendan.scot>Date: Mon, 7 Sep 2020 01:05:37 +1000Subject: [PATCH] gnu: calibre: Wrap QTWEBENGINEPROCESS_PATH.
* gnu/packages/ebook.scm (calibre): Wrap QTWEBENGINEPROCESS_PATH inaddition to wrapping PYTHONPATH as python-build-system does.--- gnu/packages/ebook.scm | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)
Toggle diff (36 lines)diff --git a/gnu/packages/ebook.scm b/gnu/packages/ebook.scmindex aab4155d3d..38040c6f65 100644--- a/gnu/packages/ebook.scm+++ b/gnu/packages/ebook.scm@@ -246,6 +246,29 @@ (assoc-ref inputs "js-mathjax") "/share/javascript/mathjax")) (invoke "python2" "setup.py" "rapydscript")))+ (replace 'wrap+ ;; Here we wrap PYTHONPATH exactly as it would be in+ ;; python-build-system, plus the addition of+ ;; QTWEBENGINEPROCESS_PATH, fixing a bug where Calibre would not+ ;; find Qtwebengine.+ (lambda* (#:key inputs outputs #:allow-other-keys)+ (let* ((out (assoc-ref outputs "out"))+ (bin (string-append out "/bin"))+ (python (assoc-ref inputs "python"))+ (site-packages+ (cons (string-append out "/lib/python"+ (python-version python)+ "/site-packages")+ (search-path-as-string->list (getenv "PYTHONPATH"))))+ (qtwebengineprocess+ (string-append (assoc-ref inputs "qtwebengine")+ "/lib/qt5/libexec/QtWebEngineProcess")))+ (for-each (lambda (program)+ (wrap-program program+ ("QTWEBENGINEPROCESS_PATH" = (,qtwebengineprocess))+ ("PYTHONPATH" prefix ,site-packages)))+ (find-files bin ".")))+ #t)) (add-after 'install 'install-man-pages (lambda* (#:key outputs #:allow-other-keys) (copy-recursively-- 2.28.0
B
B
Brendan Tildesley wrote on 7 Sep 10:12 +0200
Re: Resolve Calibre run-time dependency
a99e52ae-decc-0396-6d4e-d3dff56dd5d2@brendan.scot
There is actually a Bug report by Andreas for this very issue. I created a bug report just for updating, and fixed this issue after it while I could, without realising. Sorry for all the confusion with things happening in 3 different threads.
I created an updated patch just for this one here. https://issues.guix.gnu.org/43151#5
Your patch also works I think but it will wrap the programs twice, so you will get calibre, .calibre-real, and ..calibre-real-real, etc for every program, which seems ugly. My patch reproduces the same PYTHONPATH that is set in python-build-system in addition to wrapping PYTHONPATH (unless I made a mistake), although at the cost of code duplication. I leave it to you and who ever is reviewing this to decide which way is more correct and push one, haha.

Please continue any discussion of the QtWebEngine bug on issue 43121: 43151@debbugs.gnu.org / https://issues.guix.gnu.org/43151
B
B
Brendan Tildesley wrote on 7 Sep 10:15 +0200
6492c3cc-07e0-b56b-ea72-99d403770755@brendan.scot
Sorry I tried sending this with a typo in your gmail address so I'm resending just for you:
On 7/9/20 6:12 pm, Brendan Tildesley wrote:
Toggle quote (19 lines)> There is actually a Bug report by Andreas for this very issue. I > created a bug report just for updating, and fixed this issue after it > while I could, without realising. Sorry for all the confusion with > things happening in 3 different threads.>> I created an updated patch just for this one here. > https://issues.guix.gnu.org/43151#5>> Your patch also works I think but it will wrap the programs twice, so > you will get calibre, .calibre-real, and ..calibre-real-real, etc for > every program, which seems ugly. My patch reproduces the same > PYTHONPATH that is set in python-build-system in addition to wrapping > PYTHONPATH (unless I made a mistake), although at the cost of code > duplication. I leave it to you and who ever is reviewing this to > decide which way is more correct and push one, haha.>>> Please continue any discussion of the QtWebEngine bug on issue 43121: > 43151@debbugs.gnu.org / https://issues.guix.gnu.org/43151
A
A
Andreas Enge wrote on 8 Sep 22:11 +0200
Re: bug#43151: Resolve Calibre run-time dependency
(name . Brendan Tildesley)(address . mail@brendan.scot)
20200908201144.GA25269@jurong
Hello,
On Mon, Sep 07, 2020 at 06:15:15PM +1000, Brendan Tildesley wrote:
Toggle quote (8 lines)> Your patch also works I think but it will wrap the programs twice, so> you will get calibre, .calibre-real, and ..calibre-real-real, etc for> every program, which seems ugly. My patch reproduces the same PYTHONPATH> that is set in python-build-system in addition to wrapping PYTHONPATH> (unless I made a mistake), although at the cost of code duplication. I> leave it to you and who ever is reviewing this to decide which way is> more correct and push one, haha.
thanks to both of your for your patches! I just pushed Brendan's, whichwraps only once at the price of copy-pasting from another package. I confirmthat it works, also to click on an epub file from within calibre. Closingthe two bugs asking about qtwebengine.
Concerning the update, is mathjax a required input now, or could we justleave it out and update nevertheless?
Andreas
Closed
P
P
Prafulla Giri wrote on 9 Sep 10:38 +0200
(name . Andreas Enge)(address . andreas@enge.fr)
CAFw+=j0McVLzs-vxeB19Je91Npq7G+AS3X2WZmiGY7fzB8UWTA@mail.gmail.com
I see. Thank you for the update.
Hopefully (wrap-program) will be fixed soon. That should save us a lot ofcode-duplication.
Congratulations, Mr. Tildesley! (:
Attachment: file
Closed
?