[PATCH 0/4] gnu: calibre: Update to 4.22.0.

---

gnu/packages/ebook.scm | 3 +--

1 file changed, 1 insertion(+), 2 deletions(-)

input with newly required MathJax 3.

---

gnu/packages/ebook.scm | 10 +++++-----

1 file changed, 5 insertions(+), 5 deletions(-)

---

gnu/packages/javascript.scm | 40 +++++++++++++++++++++++++++++++++++++

1 file changed, 40 insertions(+)

from Anki to wrap QTWEBENGINEPROCESS_PATH. This fixes the 'Could not

find QtWebEngineProcess error' when opening a book with the

ebook-viewer.

---

gnu/packages/ebook.scm | 34 +++++++++++++++++++++++++++++++++-

1 file changed, 33 insertions(+), 1 deletion(-)

---

gnu/packages/ebook.scm | 4 ++--

1 file changed, 2 insertions(+), 2 deletions(-)

On Fri, Aug 21, 2020 at 07:20:14PM +1000, Brendan Tildesley wrote:

Thanks! Can you send an updated patch series? I don't think we should

update to 4.22.0 and then immediately to 4.23.0.

Calibre 4.23.0 was released. This just replaces the second patch. the

others should still apply without conflict.

On Sun, Aug 16, 2020 at 05:03:15PM +1000, Brendan Tildesley wrote:

I pushed this patch as 29f61501f309a719be91a47fd43872437435cd1a

On Sun, Aug 16, 2020 at 05:03:16PM +1000, Brendan Tildesley wrote:

I'm not really familiar with the state of JavaScript in Guix. However,

Guix generally only includes packages built from source.

Is this a case where the package has bene "minified"? Or, in what way is

not built from source?

If I understand correctly, we already have a mathjax package built from

source. See js-mathjax.

On August 24, 2020 2:25:16 PM GMT+10:00, Arun Isaac <arunisaac@systemreboot.net> wrote:

Mathjax 3 is a complete rewrite of mathjax 2. I had thought js-mathjax was just the component files too and not truely built from source. Maybe I was wrong. Currently, building this from the true source requires a huge number of js packages and we haven't got a npm importer and full JavaScript bootstrap yet so I wasn't sure what to do. If you like we can ignore this and I can modify calibre to disable mathjax for now since I don't think it works with the old mathjax 2. I would like to work on getting more JavaScript in to guix properly

True. js-mathjax is not truly built from source. A true source build

will properly depend on a huge number of other js packaces. js-mathjax

only redoes the minification step. In light of this, perhaps we should

remove js-mathjax from Guix. But, I'm not sure.

Yes, disabling mathjax for calibre is a good way to go if the

functionality is not too critical. But, I don't know much about

calibre. So, someone else should take a call.

On August 24, 2020 4:44:37 PM GMT+10:00, Arun Isaac <arunisaac@systemreboot.net> wrote:

On August 24, 2020 4:44:37 PM GMT+10:00, Arun Isaac <arunisaac@systemreboot.net> wrote:

Its just for rendering math in the eBook-viewer for books that include it. It shouldn't be essential. The reason I felt OK adding it is because its not like its actually proprietary, its just we haven't gotten around to integrating JavaScript into guix yet fully, and it doesn't look like that will happen any time soon.

This replaces the second patch, renaming mathjax-bin to mathjax-3 since

its not actually binary.

Hello there!

Arun, Leo, what’s the status of this patch series?

https://issues.guix.gnu.org/42885

Can it be applied?

Brendan, to make it clear what the latest version of the patch series is

(next time), consider adding a “v2” etc. suffix to the subject, like so:

git format-patch --subject-prefix="PATCH v2" …

Thanks,

Ludo’.

Hello,

On Fri, Sep 04, 2020 at 11:02:46AM +0200, Ludovic Courtès wrote:

why is the variable called mathjax-bin? Should it not be mathjax?

By the way, there is a version 3.1.0 now.

Andreas

Arun Isaac <arunisaac@systemreboot.net> writes:

js-mathjax does not contain minified JavaScript. The code is in

editable and readable form although it is not in the form that upstream

uses for development. In this case I still consider it to be actual

source code, because for the purposes of Guix this is the preferred

format (given that we have no way of building the sources in the format

that is used by upstream).

--

Ricardo

Ricardo has clarified that we may consider the existing js-mathjax 2.7.2

package to have been built from source even though it isn't the form

upstream uses for development. No problems there.

But, like Brendan said, mathjax 3 is quite a different beast. With

mathjax 2, the source was in javascript, and our build system had merely

to minify it. But mathjax 3 is written in typescript that gets compiled

into javascript and then combined into "web component files" (this is

the first I'm hearing of web components and I'm not entirely clear what

they are). Since we don't have a typescript build system, packaging

mathjax 3 may be non-trivial. So, we should proceed with updating

calibre without mathjax support.

You could also do the slightly shorter

git format-patch -v2 ...

Cheers!

Arun Isaac <arunisaac@systemreboot.net> writes:

There may be a way to transpile the TypeScript sources with swc, a

babel-like transpiler with TypeScript support; it’s written in Rust, so

there may be a way to work around the JavaScript packaging problem.

--

Ricardo

Hey there Mr. Tildesley,

Without knowing that this was going on, I worked on, and sent a patch to

fix the QtWebEngineProcess issue yesterday:

My patch also fixes this issue, but without appending things to PYTHONPATH.

And it works just the same.

Since you say, sir, that you copied the wrap-phase from Anki to fix the

issue, and I manually poked around with things, grepping the output of

`env` and stuff to deal with it - I wonder if I have stumbled upon the bare

minimum changes necessary to resolve this issue.

I would like to request that you, and other esteemed contributors, test my

patch. And, if it seems good to you, I would like to request that you

incorporate my patch in this change set.

Attached are the wrappers for `ebook-viewer`: with your patch applied, and

with my patch applied, for anyone to compare.

Please do let me know if there are any insufficiencies in my solution, or

if it does not work for anybody else (I did use --pure option with `guix

environment`).

Thank you

I just realized that the PYTHONPATH set by the default %standard-phase

'wrap of python-build-environment is (most likely) a superset of the manual

PYTHONPATH set by the custom phase 'wrap phase added after 'install in

patch no. 4. As such, perhaps it is redundant, too?

On Mon, Sep 7, 2020 at 8:56 AM Prafulla Giri <pratheblackdiamond@gmail.com>

wrote:

Hello,

On Mon, Sep 07, 2020 at 06:15:15PM +1000, Brendan Tildesley wrote:

thanks to both of your for your patches! I just pushed Brendan's, which

wraps only once at the price of copy-pasting from another package. I confirm

that it works, also to click on an epub file from within calibre. Closing

the two bugs asking about qtwebengine.

Concerning the update, is mathjax a required input now, or could we just

leave it out and update nevertheless?

Andreas

I am packaging swc for Guix. I'm running into some unstable feature

issues with Rust, but otherwise things are going well. I will report on

further progress by tonight.

Arun Isaac <arunisaac@systemreboot.net> writes:

Oh, me too.

I’m currently at rust-napi@0.4.

--

Ricardo

I see. Thank you for the update.

Hopefully (wrap-program) will be fixed soon. That should save us a lot of

code-duplication.

Congratulations, Mr. Tildesley! (:

Oops, hopefully we haven't duplicated too much work.

Packaging rust programs is a much deeper rabbit hole than I imagined!

But, I'm making progress, and will hopefully be done given some more

time. Will keep you posted.

Hi,

I have finished packaging swc. I am now mid-way through cleaning up and

committing my changes. Considering the number of commits, that alone

might take a couple more days. I will push my changes to a wip-swc

branch and let you know.

But, I also have some bad news. swc is not entirely written in rust. Its

CLI, swc-cli, is a separate package and uses node. So, packaging that

may be yet another deep rabbit hole.

Regards,

Arun

Hi Arun,

Wow, thank you very much!

I expected as much, but I was hoping that we could invoke it some other

way, much like we invoke uglify-js (the Common Lisp package) with a

little custom wrapper.

--

Ricardo

I have pushed my commits to a new wip-swc branch. A few questions and

discussion points below.

Considering that only the source of rust dependencies is used, should

those packages successfully build on their own? In the wip-swc branch, I

have only verified that the rust-swc package builds. There may be some

dependencies which fail to build on their own.

Related to the previous question, what is the purpose of the

#:skip-build? argument? Should it be set to #t for all dependency

packages?

While working on this patchset, I hacked the crate importer a bit to

make my life easier. In particular, I modified it to correctly append

the version to the package variable name. This requires a slightly more

general recursive importer than we have currently. The current recursive

importer assumes that we will package only one version for each

package. That assumption does not stand for rust crates.

We also don't always need to put the minor version into the package

variable name. For example, rust-syn-1 is sufficient. rust-syn-1.0 is

not required. The exact rules follow from

I improved the crate importer to better understand these version

requirement rules and put packages of the correct version into the

#:cargo-inputs and #:cargo-development-inputs fields.

I will send patches for these crate importer improvements separately

after this patchset is approved.

We also need some automated way to "garbage collect" old versions of

packages in crates-io.scm. crates-io.scm is getting quite large, and I

suspect many packages in there are old versions that are not really

necessary.

That is a good idea. But, I have never written any rust. Perhaps someone

who is more familiar with rust should write it.

On 21/9/20 8:36 pm, Arun Isaac wrote:

Are you aware of this importer: https://issues.guix.gnu.org/issue/38408/?

Oh, I wasn't aware of this importer. It seems to address my

concerns. So, I'll just wait for it to get merged into master.

BTW, is it possible for your wip-swc branch to be merged into master? I

found my self building a package of my own starting from this branch

because it includes the rust packages I needed. Is there any reason it

can't be done? It would be convenient for me at least.

I think it can be done. I was just waiting for someone to review and

approve it.

@Ricardo: Shall I go ahead and merge?

I have merged wip-swc into master. Should this bug report be closed now?

Is there any pending work here related to calibre? We need a typescript

build system that uses swc. But, we should handle that in a separate bug

report.

Thanks!

On 12/10/20 5:23 pm, Arun Isaac wrote:

Thank you very much.

I'm kind of worried how long it will take to get that build system. Even

if we have it, will it really succeed at building MathJax so easily? If

it's going to take a while, I'm tempted to just update Calibre without

mathjax support. In theory I'm willing to do work to help but it all

seems rather advanced for me, so i'm glad to see you make progress.

What's the next step?

Calibre 5+ is out now which is on python3. I could even create a

calibre-next so that both calibre@4.18.0 exists and calibre will be

calibre@5.0.1, utilizing Guix's design.

:-)

True, I have similar concerns too. The next step, like Ricardo said, is

to write a simple rust script that uses rust-swc to compile typescript

to javascript. I am unfamiliar with both rust and typescript. So, if I

am to do it, I would need some time. If someone else volunteers to do

it, that would be great.

I think we shouldn't let the typescript build system and mathjax block

calibre. If I understand correctly, calibre depends on mathjax only

optionally. So, you should go ahead with your work on calibre regardless

of what happens with mathjax.

Arun Isaac <arunisaac@systemreboot.net> writes:

I looked at this today, but my rust-foo is very, very weak.

I tried to compile this:

https://github.com/swc-project/swc/blob/master/examples/usage.rs

jlicht told me on IRC that we also have a package for esbuild now, which

could also be used for transpiling TypeScript to JS.

--

Ricardo

I managed to get this working. Please see the attached tarball. The

steps to test are:

Unpack the tarball and change directory.

Clone the swc git repo.

Build and run using cargo.

src/main.rs in the tarball is a slightly modified version of

examples/usage.rs in the swc git repo. On running, it transpiles the

file foo.ts and outputs to stdout.

The next step is to see if this is any good for building MathJax from

source.

Cheers!

Hey ho!

What’s the status of this Calibre update?

https://issues.guix.gnu.org/42885

It it waiting on the SWC thing?

Thanks in advance, :-)

Ludo’.

Hi Ludo,

I got a minimal swc (attached in my previous mail) working. This minimal

swc works for compiling typescript to javascript. But, I haven't figured

out how to use it to build web components. This is blocking packaging

mathjax v3, and thus calibre. I feel that if calibre can go ahead

without mathjax v3, it should. Then, we can close this issue and open a

separate one for web components and mathjax.

Regards,

Arun

Arun Isaac <arunisaac@systemreboot.net> writes:

We can also try esbuild.

I’ve been trying to package mathjax v3 for a while, but didn’t get far

enough to present anything yet. Here’s what I have:

--

Ricardo

On 14/1/21 1:00 am, Ludovic Courtès wrote:

I was away from the project for a bit, but I'm back. I intend to update

Calibre to the latest (5.11.0) without mathjax since it's not a big

deal. New obstacles have come in to existence. I think python-pyqt5 may

need to be updated to use sip5 or sip6, which uses some new sip-build

thingy. I found it results in make files that tries to install files to

the python-wrapper store directory, which is immutable. Haven't yet

figured out how to fix that.

---

gnu/packages/qt.scm | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

(python-sip-4): New variable. Rename the old python-sip to python-sip-4.

---

gnu/packages/qt.scm | 52 +++++++++++++++++++++++++++++++++------------

1 file changed, 39 insertions(+), 13 deletions(-)

---

gnu/packages/maths.scm | 3 ++-

1 file changed, 2 insertions(+), 1 deletion(-)

---

gnu/packages/qt.scm | 21 +++++++++++++++++++++

1 file changed, 21 insertions(+)

---

gnu/packages/qt.scm | 19 +++++++++++++++++++

1 file changed, 19 insertions(+)

[source]: Remove pyqt-public-sip.patch. PyQt uses python-pyqt5-sip

now. This patch is still used by python2-pyqt so we don't delete it completely.

[inputs]: Add python-pyqt-builder, python-pyqt5-sip

[arguments]: Add phase to link PyQt5-sip module.

---

gnu/packages/qt.scm | 18 ++++++++++++++----

1 file changed, 14 insertions(+), 4 deletions(-)

---

gnu/packages/python-xyz.scm | 33 +++++++++++++++++++++++++++++++++

1 file changed, 33 insertions(+)

---

gnu/packages/python-xyz.scm | 28 +++++++++++++++++++++++++++-

1 file changed, 27 insertions(+), 1 deletion(-)

---

gnu/packages/python-check.scm | 23 +++++++++++++++++++++++

1 file changed, 23 insertions(+)

---

gnu/packages/python-compression.scm | 30 +++++++++++++++++++++++++++++

1 file changed, 30 insertions(+)

---

gnu/packages/python-compression.scm | 4 ++--

1 file changed, 2 insertions(+), 2 deletions(-)

---

gnu/packages/python-compression.scm | 18 ++++++++++++++++++

1 file changed, 18 insertions(+)

---

gnu/packages/python-compression.scm | 27 +++++++++++++++++++++++++++

1 file changed, 27 insertions(+)

variable.

---

gnu/packages/python-compression.scm | 29 +++++++++++++++++++++++++++++

1 file changed, 29 insertions(+)

---

gnu/packages/python-compression.scm | 40 +++++++++++++++++++++++++++++

1 file changed, 40 insertions(+)

---

gnu/packages/python-xyz.scm | 4 ++--

1 file changed, 2 insertions(+), 2 deletions(-)

---

gnu/packages/web.scm | 6 +++---

1 file changed, 3 insertions(+), 3 deletions(-)

since it doesn't work with 5.

---

gnu/packages/pdf.scm | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

Calibre, just updating this since I updated python-sip.)

---

gnu/packages/pdf.scm | 4 ++--

1 file changed, 2 insertions(+), 2 deletions(-)

---

gnu/packages/ebook.scm | 20 ++++++++++++++++++++

1 file changed, 20 insertions(+)

propragated-inputs. html5lib uses this as a fallback for encoding

detection, and Calibre tests for its being there, so ad it.

---

gnu/packages/python-web.scm | 3 ++-

1 file changed, 2 insertions(+), 1 deletion(-)

---

gnu/packages/freedesktop.scm | 21 +++++++++++++++++++++

1 file changed, 21 insertions(+)

[inputs]: Add libjpeg and libjxz.

[arguments]: substitute Calibre's weird get_exe_path procedure that looks

in poppler's output directory for binaries with direct paths to

jpegtran, cjpeg, optipng, and JxrDecApp.

---

gnu/packages/ebook.scm | 9 ++++++++-

1 file changed, 8 insertions(+), 1 deletion(-)

Switch all Python 2 inputs to their Python 3 equivalents.

[native-inputs]: Add new dependency python-pyqt-builder.

[inputs]: Remove js-mathmax. Calibre now uses a newer mathjax that we

don't have in guix since it's needs a javascript bootstrap.

Remove python-chardet. This is still used by python-html5lib but since

I added the input directly to python-htmpl5lib, it is no longer needed

here.

Remove chmlib. python-chmlib bindings are used now.

Remove python-sip

Add new dependencies:

- python-cchardet

- python-speechd

- python-zeroconf

- python-py7zr

- python-pychm

- python-pycryptodome (Used by some Calibre extensions)

[arguments]: get_sip_dir isn't used anymore, so now we specify the sip

directory by editing the project.toml file. Also, for whatever reason,

it doesn't build unless the WS_X11 tag is set.

Don't try building mathjax support.

Don't set SIP_BIN anymore since it isn't needed.

Remake these patches to work with the slightly different new source

code.

startars

---

gnu/packages/ebook.scm | 101 +++++++++---------

.../patches/calibre-no-updates-dialog.patch | 22 ++--

.../patches/calibre-remove-test-sqlite.patch | 21 ++--

.../patches/calibre-remove-test-unrar.patch | 24 ++---

4 files changed, 88 insertions(+), 80 deletions(-)

This fixes part of the broken qt test, but not all. It still fails

printing to pdf.

---

gnu/packages/ebook.scm | 6 +++---

1 file changed, 3 insertions(+), 3 deletions(-)

---

gnu/packages/qt.scm | 19 -------------------

1 file changed, 19 deletions(-)

---

gnu/packages/qt.scm | 14 --------------

1 file changed, 14 deletions(-)

These two patches go after the last 27 patches, fixing up some mistakes I made earlier.

On Wed, Mar 10, 2021 at 08:00:49PM +1100, Brendan Tildesley wrote:

Thanks a lot for working on this! I'm going to start reviewing / pushing

patches today.

On Wed, Mar 10, 2021 at 08:00:49PM +1100, Brendan Tildesley wrote:

Alright, the patches are aleady stale, even at patch 2 of 27.

To make this easier, can you either put this work online in a Git repo

somewhere? It's easier to clone a repo with a custom branch to rebase

the patches.

Alternatively, can you say which older Guix Git commit these patches

apply to?

Thansk!

I fixed the conflict updated to latest master here.

Also, a minor change, I oved the

"gnu: veusz: Fix build"

until after

"gnu: python-pyqt: Fix build for new python-sip."

since it doesn't actually work until that ones applied.

On Wed, Mar 24, 2021 at 03:13:26AM +0100, Brendan Tildesley wrote:

Thanks for the updated branch! I'm going through the patches now.

On Wed, Mar 24, 2021 at 03:13:26AM +0100, Brendan Tildesley wrote:

Can you clarify some things about the commit "gnu: python-pyqt: Fix

build for new python-sip"? First, python-pyqt before applying this

commit; if it's broken, can you say how?

Also, there is a comment "Linking here means the sip module can be found

without python-pyqt5-sip needing to be added as an input". But,

python-pyqt5-sip is an input to this package. Can you explain what you

mean?

I think we should drop the commit "gnu: calibre: Add qtsvg as input.",

since it adds a dependency but for what seems to be no reason. What do

you think?

Based on your branch, I've made the following changes and pushed the

branch at

https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-update-calibre.

Can you take a look and tell me what you think?

I squashed the first two commits, so that there is no commit where

python2-sip fails to build. It's not always easy to avoid intermediate

breakage in complicated package upgrades like this, but it's worth

trying. At least, it can improve the utility of `git bisect`.

I also squashed the "fix veusz" commit into that one, for the same

reason. And all the rest of the commits that are adjusting to that

change.

For the "Fix build for new python-sip" commit, I removed the hardcoding

of "python3.8" in the 'pyqt5-sip' phase, and instead used the

python-version procedure.

I squashed the remaining cleanup-type commits into the Calibre update.

I pushed the commit 'gnu: python-poppler-qt5: Update to 21.1.0.' as

02f664a0a3dd3a936213e687802bdc62f2a10983

I corrected the license of python-pychm from gpl3 to gpl2+.

I made many other changes to satisfy `guix lint`, and improved synopses

and descriptions.

Me adding python-pyqt-builder here looks like a mistake. I left it

there while experimenting. When I was Upgrading SIP, I experimented

with switching to the new 'sip-build' tool introduced in SIP 5. SIP

6's main change is to delete obsoleted code, so the old 'python

configure.py' won't work. I never got it working so I just went back

to the old way with SIP 5. python-pyqt-builder is still needed by

Calibre however.

The only other functional change in this patch is to remove the patch

pyqt-public-sip.patch. The introduction of python-pyqt5-sip as a

separate module means means that with this patch, the module is not

found at all. Removing it fixes it. I don't understand it in any great

depth but it seems the patch may only really relevant to SIP 4.

Upstream for whatever reason chose to move the sip module part out in

to a separate source package python-pyqt5-sip. It's broken without

removing the pyqt-public-sip.

The linking can be removed, but it would mean for every input that

requires python-pyqt5 as an input, you also need to add

python-pyqt5-sip so the sip module can be found. On a distribution

with a traditional filesystem layout, that would not be necessary, you

just have the -sip module as a dependency to pyqt5 and its then its

available at a global path to be found. On Nix/Guix that doesn't work

so it has to be added every time, or linked in like this. Actually I'm

not sure if there is ever any case where one /doesn't/ need the sip

modules, but they're only 200KiB. The Nix developers chose to just

link it like this so I copied their way. Do you think it's fine?

The reason I added qtsvg was to try fix the Qt test. If you remove the

line (setenv "SKIP_QT_BUILD_TEST" "true"), this test fails for

multiple reasons. One of them was qtsvg missing. Another was the

get_exe_path bit. But a third reason I that its call to printtopdf in

pyqtwebegine returns an empty string instaed of b'Skia/PDF'. I had no

idea how to proceed with fixing that so I left it for now. But at

least fixed the other errors. I assume some SVG related functionality

will fail without it...

All good I think. My descriptions were much worse than I realised.

python-cchardet differs from in python-chardet in that its not written

/in/ python, but links to a fast C library to do it, but your

description/synopsis changes make it look like its all in

Python. Maybe make the description:

"cChardet is a character encoding detector, binding to the C

library uchardet for speed." ?

I fixed another one of my typos 'statical' -> 'statistical', and

removed the python-pyqt-builder input from python-pyqt

Just updated for Calibre 5.14.0 released 4 days ago also.

On Tue, Mar 30, 2021 at 12:45:18PM +0200, Brendan Tildesley wrote:

Thanks! I will review these today or tomorrow.

On Tue, Mar 30, 2021 at 08:23:43AM +0200, Brendan Tildesley wrote:

Okay. I adjusted the commit message to match your revision.

If I understand correctly, the issue that any package that uses

python-pyqt5 also needs to be able to find python-pyqt5-sip. Is that

right?

If so, it sounds like a case for propagated-inputs [0]. Concretely, I made

python-pyqt5-sip a propagated-input of python-pyqt and removed the

'pyqt5-sip' phase, and Calibre built successfully.

Does that seem like the right approach?

That's a good point. However, I checked if the built Calibre refers to

qtsvg, and it doesn't [1]. So, it's unlikely that Calibre will be able to

find and use qtsvg, regardless of whether or not it's an input. So, I'd

prefer to leave it out until we understand what it's for and how to make

sure that Calibre can use it.

No worries. Writing the synopses and descriptions is a completely

different type of work from packaging or programming. I often "finish"

some packages, but need to go back later to write the descriptions. I'm

happy to finish these tasks as part of the code review process.

Thanks, that helps. I amended the synopses and description based on

this.

I pushed my revisions of your updated branch, rebased on the current

master branch, to Savannah:

[0]

[1] This command be used:

$ guix gc --references $(./pre-inst-env guix build --no-grafts calibre) | grep qtsvg

[...]

Sounds good. I didn't realise propagated-inputs did that, I thought they were

just normal inputs that were installed along side the package in a profile,

but wouldn't make a difference during build time.

Does this mean all packages that depend on python-pyqt5 will have python-pyqt5-sip

added to its own list of inputs in their own package definition? If so

the manual doesn't mention that.

I see, that's a good trick for checking references.. Leave svg out for now then.

I find writing them the most stressful part because I sit there not knowing

what to write.

On Tue, Apr 06, 2021 at 03:30:08AM +0200, Brendan Tildesley wrote:

That's the idea: they are run-time dependencies of a package that lacks

the ability for recording references to its dependencies. We have to

help the package with our packaging tools.

In general, all Python packages in Guix use this mechanism.

Just to clarify, does Calibre work on your end with my latest Savannah

branch? I built it on CI, so you can get substitutes for it on x86_64.

The basics work for me: library management, conversion, etc.

I think we're almost done!

Don't hesitate to send in your patches with a note like, "I didn't know

what to put here".

Works for me.

While testing the dependents of packages changes in this patch series, I

found that QGIS fails to build as a result of these patches, like this:

------

[...]

[ 50%] Built target qgis_sqliteutilstest_autogen

make -f tests/src/core/CMakeFiles/qgis_layouthtmltest_autogen.dir/build.make tests/src/core/CMakeFiles/qgis_layouthtmltest_autogen.dir/depend

.sip5-real: Unable to find file "QtXml/QtXmlmod.sip"

make[2]: Entering directory '/tmp/guix-build-qgis-3.16.3.drv-0/build'

cd /tmp/guix-build-qgis-3.16.3.drv-0/build && /gnu/store/3dsl2jalrcyldkrsqab1hc6sv8pyag9z-cmake-minimal-3.16.5/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-qgis-3.16.3.drv-0/qgi

s-3.16.3 /tmp/guix-build-qgis-3.16.3.drv-0/qgis-3.16.3/tests/src/core /tmp/guix-build-qgis-3.16.3.drv-0/build /tmp/guix-build-qgis-3.16.3.drv-0/build/tests/src/core /tmp/guix-build-qgis-3.16.3

.drv-0/build/tests/src/core/CMakeFiles/qgis_layouthtmltest_autogen.dir/DependInfo.cmake --color=

Scanning dependencies of target qgis_layouthtmltest_autogen

make[2]: Leaving directory '/tmp/guix-build-qgis-3.16.3.drv-0/build'

make -f tests/src/core/CMakeFiles/qgis_layouthtmltest_autogen.dir/build.make tests/src/core/CMakeFiles/qgis_layouthtmltest_autogen.dir/build

make[2]: Entering directory '/tmp/guix-build-qgis-3.16.3.drv-0/build'

[ 50%] Automatic MOC for target qgis_layouthtmltest

cd /tmp/guix-build-qgis-3.16.3.drv-0/build/tests/src/core && /gnu/store/3dsl2jalrcyldkrsqab1hc6sv8pyag9z-cmake-minimal-3.16.5/bin/cmake -E cmake_autogen /tmp/guix-build-qgis-3.16.3.drv-0/build

/tests/src/core/CMakeFiles/qgis_layouthtmltest_autogen.dir/AutogenInfo.json RelWithDebInfo

make[2]: *** [python/CMakeFiles/python_module_qgis__core_autogen.dir/build.make:682: python/core/sip_corepart0.cpp] Error 1

make[2]: *** Deleting file 'python/core/sip_corepart0.cpp'

make[2]: Leaving directory '/tmp/guix-build-qgis-3.16.3.drv-0/build'

make[1]: *** [CMakeFiles/Makefile2:8003: python/CMakeFiles/python_module_qgis__core_autogen.dir/all] Error 2

[...]

builder for `/gnu/store/svp5sjdga02zngsrh3x613wjfqm2cwyi-qgis-3.16.3.drv' failed with exit code 1

------

I think the salient part is near the beginning:

.sip5-real: Unable to find file "QtXml/QtXmlmod.sip"

I tried using your original approach for pyqt5-sip, where you symlinked

it into the output of python-pyqt, but I got the same result.

I guess that we need to adjust the package python-pyqt+qscintilla. Any

ideas?

I found an upstream bug report that is superficially similar:

However, their solution is already done in our package: Make sure that

pyqt is available.

On Wed, Apr 07, 2021 at 08:05:00PM -0400, Leo Famulari wrote:

I also noticed this passage in the QGIS ChangeLog:

------

Daniel Minor <daniel.minor@gmail.com> 2020-07-14

Fix FindPyQt5 cmake and python scripts

As written, the FindPyQt5.cmake and FindPyQt5.py scripts will succeed even if

PyQt5 is not installed. In FindPyQt5.cmake, we have PYQT5_FIND_REQUIRED rather

than PyQt5_FIND_REQUIRED, so the package is always treated as though it is

optional. In FindPyQt5.py, the script will succeed with a default location for

the sip directory, even if the PyQt5 directory is not located.

For some systems, if enough other dependencies are installed, the build can

get about halfway complete without the main PyQt5 dependency, and then fail

with a message like:

sip: Unable to find file "QtXml/QtXmlmod.sip"

I hit this building on Ubuntu, and there have been a few similar bug reports in

the past.

------

Well, using a python-pyqt with the python-sip input set back to python-sip-4 fixes it. Do we want to commit to getting it working with python-sip@5. I'm still playing around with it trying to get it to build

Not sure where you see that sip error. The builds fail for me with

make[2]: Leaving directory '/tmp/guix-build-qgis-3.16.3.drv-0/build'

make[2]: *** [python/CMakeFiles/python_module_qgis__core_autogen.dir/build.make:682: python/core/sip_corepart0.cpp] Error 1

make[2]: *** Deleting file 'python/core/sip_corepart0.cpp'

make[2]: Leaving directory '/tmp/guix-build-qgis-3.16.3.drv-0/build'

make[1]: *** [CMakeFiles/Makefile2:8003: python/CMakeFiles/python_module_qgis__core_autogen.dir/all] Error 2

On Thu, Apr 08, 2021 at 06:11:55AM +0200, Brendan Tildesley wrote:

I think it's okay to use python-sip-4, unless you want to hunt down this

bug.

I see these lines too, but later. The QtXml error may be a few lines

above.

Fixed I think.

Also I deleted the unused python2-sip (in my notabug)

On Thu, Apr 08, 2021 at 01:17:43PM +0200, Brendan Tildesley wrote:

Alright, I pushed as f68bcc1bc3aa0a8d1829e2eb5d9ef256c817c17c

Thank you very much for tackling this complicated upgrade of such an

important package!