[bug#42885] [PATCH 23/27] gnu: calibre: Update to 5.13.0.

[Brendan Tildesley <mail@brendan.scot>]

> On 04/05/2021 9:58 PM Leo Famulari <leo@famulari.name> wrote:

[...]

> 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?
> 

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.

> > 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...
> 
> 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.

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

> 
> > All good I think. My descriptions were much worse than I realised.
> 
> 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.
> 
I find writing them the most stressful part because I sit there not knowing
what to write.

> > 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." ?
> 
> 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:
> 
> https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-update-calibre
> 
> [0]
> https://guix.gnu.org/manual/en/html_node/package-Reference.html
> 
> [1] This command be used:
> $ guix gc --references $(./pre-inst-env guix build --no-grafts calibre) | grep qtsvg