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

[Brendan Tildesley]

> On 03/30/2021 1:05 AM Leo Famulari <leo@famulari.name> wrote:
> 
>  
> On Wed, Mar 24, 2021 at 03:13:26AM +0100, Brendan Tildesley wrote:
> > https://notabug.org/Brendan/guix/src/calibre-5.13.0
> 
> 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?

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.

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

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?

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

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

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

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

https://notabug.org/Brendan/guix/src/wip-update-calibre