#102 re-add official calibre package
Opened a year ago by mwilck. Modified 2 months ago

Leap used to have a calibre package up to 15.3. In 15.4 it was removed, probably because the python2 dependencies of the 15.3 package couldn't be met any more.

The most recent version of calibre (TW: 6.9.0) needs a bunch of very recent libraries and python packages; porting it to Leap is highly unrealistic.

The calibre maintainer (Eric Schirra - ecsos) maintains a package calibre4 (4.36) in his home repository. I have recently forked this into home:mwilck:Leap:15.4 and with slight modifications, I've made it build against stock Leap 15.4. "Only" 8 packages in Leap 15.4 are older than recommended by the upstream calibre author for 4.36.

I've tested the package built this way, and it seems to work well.
While for the "best" Calibre experience users will probably turn to Flatpak, I believe having an official Leap package would be desirable.

I discussed this with Eric via private email and he wasn't found of the idea for various reasons. Still, I'd like to propose it here to discuss it in a somewhat wider audience.


I'll ask Eric if he's willing to work on this. I'm bit afraid that any changes needed on the SLE side would otherwise be rejected, as we're too close to the feature drop deadline.

I'll ask Eric if he's willing to work on this. I'm bit afraid that any changes needed on the SLE side would otherwise be rejected, as we're too close to the feature drop deadline.

I think there is no chance to bring calibre in the latest version in 15.5.
There are too many dependencies in the meantime. So too many too old package versions in Leap.
And when you try to update necessary packages, you run into a wall, with always the same answer. The package comes from SLE and newer ones don't work etc. etc.
Even minor updates are rejected.
And the maximum version for calibre under Leap is 4.23.0.
But only if the above package updates went through.
In addition, several Python packages in 15.5 are currently older than in 15.4.

Besides dependencies I think device support is also important. I have tried to keep this support up to date in 15.0 with updates, backporting device drivers, but in the end the work was too much. So I gave up. Forcing user to use the flatpak or the official download is better, IMO.

Besides dependencies I think device support is also important. I have tried to keep this support up to date in 15.0 with updates, backporting device drivers, but in the end the work was too much. So I gave up. Forcing user to use the flatpak or the official download is better, IMO.

I think absolutely nothing of flatpack and for this reason alone would very much like to bring calibre into 15.5.
But that's not so easy or costs extreme work, time and nerves, sorry, lies entirely with openSUSE and the dependencies on SLE.
As far as devices are concerned, I have never missed anything.
In my home repo, calibre for 15.4 is built in version 4.23.0.
I think 15.5 would also be built if the Python packages in 15.5 were not older than those in 15.4.

Here are part dependencies for calibre 6.10.0 under Leap 15.5:
unresolvable: nothing provides freetype2-devel >= 2.11.0, (got version 2.10.4-150000.4.12.1), nothing provides graphite2-devel >= 1.3.14, (got version 1.3.11-2.12), nothing provides libpodofo-devel >= 0.9.7, (got version 0.9.6-150300.3.6.1), nothing provides podofo >= 0.9.7, (got version 0.9.6-150300.3.6.1), nothing provides qt6-core-private-devel >= 6.3.1, (got version 6.2.2-150400.2.8), nothing provides qt6-declarative-devel >= 6.3.1, (got version 6.2.2-150400.1.5), nothing provides qt6-gui-private-devel >= 6.3.1, (got version 6.2.2-150400.2.8), nothing provides qt6-imageformats-devel >= 6.3.1, (got version 6.2.2-bp155.2.10), nothing provides qt6-platformsupport-private-devel >= 6.3.1, (got version 6.2.2-150400.2.8), nothing provides qt6-wayland-devel >= 6.3.1, (got version 6.2.2-bp155.2.11), nothing provides pkgconfig(Qt6Core) >= 6.3.1, nothing provides pkgconfig(Qt6Gui) >= 6.3.1, nothing provides pkgconfig(Qt6Network) >= 6.3.1, nothing provides pkgconfig(Qt6Positioning) >= 6.3.1, nothing provides pkgconfig(Qt6Sensors) >= 6.3.1, nothing provides pkgconfig(Qt6ShaderTools) >= 6.3.1, nothing provides pkgconfig(Qt6Svg) >= 6.3.1, nothing provides pkgconfig(Qt6WebChannel) >= 6.3.1, nothing provides pkgconfig(Qt6WebEngineCore) >= 6.3.1, nothing provides pkgconfig(Qt6WebEngineWidgets) >= 6.3.1, nothing provides pkgconfig(Qt6Widgets) >= 6.3.1, nothing provides pkgconfig(dbus-glib-1) >= 0.112, (got version 0.108 provided by dbus-1-glib-devel), nothing provides pkgconfig(fontconfig) >= 2.13.94, (got version 2.13.1 provided by fontconfig-devel), (got version 2.13.1 provided by fontconfig-devel-32bit), nothing provides pkgconfig(gpg-error) >= 1.43, (got version 1.42 provided by libgpg-error-devel-32bit), (got version 1.42 provided by libgpg-error-devel), nothing provid

And here for calibre 4.23.0 under 15.5:
unresolvable: nothing provides python3-beautifulsoup4 >= 4.9.1, (got version 4.8.2-1.18), nothing provides python3-dnspython >= 2.0.0, (got version 1.15.0-150000.3.2.1), nothing provides python3-html2text >= 2020.1.16, (got version 2018.1.9-lp155.2.2), nothing provides python3-html5lib >= 1.1, (got version 1.0.1-1.22), nothing provides python3-ifaddr >= 0.1.7, (got version 0.1.6-bp155.2.7), nothing provides python3-msgpack >= 1.0.0, (got version 0.5.6-150100.3.3.1), nothing provides python3-netifaces >= 0.10.9, (got version 0.10.6-1.31), nothing provides python3-pycryptodome >= 3.9.8, (got version 3.9.0-6.1), nothing provides python3-regex >= 2020.07.14, (got version 2020.2.20-1.1), nothing provides python3-setuptools >= 49.6.0, (got version 44.1.1-150400.1.4), nothing provides python3-texttable >= 1.6.3, (got version 1.6.2-bp155.2.7), nothing provides python3-six >= 1.15.0, (got version 1.14.0-12.1), nothing provides python3-soupsieve >= 2.0.1, (got version 1.9.5-lp155.4.4), nothing provides python3-zeroconf >= 0.31.0, (got version 0.25.1-bp155.2.5)

Leap is just way too old because of the interlocking with SLE.
Even Debian, which is always said to be more modern, is now more modern.

There's no doubt that integrating Calibre 6.x in Leap 15.5 is not a realistic option. But looking at the distro list on GitHub, only very few distributions do. Did we ever ship an "up-to-date" calibre version with Leap?

My goal is to integrate the latest version we can realistically achieve. As @ecsos noted, he has 4.23 in his repo. That repo contains a lot of updated python packages, thus @ecsos' version can't be installed without pulling in some of them. I have a slightly modified copy of @ecsos 4.23 package in my OBS repo which is installable with stock 15.4 dependencies. Comments in the spec file show the deviations between upstream requirements and what Leap currently ships. "Only" 8 dependencies are older than recommended by upstream (4.23). Quite a few are newer, actually. I had to add 2 simple patches to avoid build errors with the original Leap packages for hunspell and python-msgpack.

I would be satisfied with having 4.23 in Leap, which would be far better than nothing. If some python deps are updated in 15.5 (I haven't double-checked) perhaps we could even provide a 5.x version?

People who want the latest calibre on Leap will have to resort to the Flatpak, obviously. But flatpak doesn't work for everyone (what about non-x86_64 archs?) My personal use case is a small RasPi-like home server which runs calibre-server to serve my local ebook library. Installing a flatpak for this purpose on such a small system doesn't make much sense. I have been running my 4.23 package on this system for a while now without any issues.

@mwilck Is not the easiest solution that you become the maintainter of a leap version of calibre? I find your use case a good reason.

I would be willing to do some testing, but for me 5.44 would then be better, to see how well it does with my ereader and plugins and how I use it.

@mwilck Is not the easiest solution that you become the maintainter of a leap version of calibre?

I could only do that with @ecsos' blessing, as he has much more experience with the package. I am aware that getting upstream support for such an outdated package is basically impossible, and that the upstream calibre community is difficult to work with (but unlike ecsos I haven't tried myself).

Thus users of the package would need to understand that it can only be "supported" to some extent. We have a similar situation with other Leap packages too, so I don't think it'd be a no-go.

I could only do that with @ecsos' blessing

I realize that this sentence might be easily misunderstood. I'd be willing to fill the maintainer role for Leap, and I would try hard not to resort to @ecsos' experience for any Leap issues.

Yet I would want him to at least agree with me trying this.

Just to illustrate the plight of Leap.
I had tried to minimize the too old python packages by a request from devel:backport to Leap:15.5.
But there is no chance. Because then a bot comes and says you should take it from SLE. How then, if they are too old.
One can answer though. But no one is interested, because there is probably only a bot behind it.
Factory I have then not even tried, because they are usually too new.
My time is now used up for this.
In my opinion, you can forget the process to bring newer package in not yet published Leaps.
Or I have not understood something.

In the course of this I noticed that calibre 4.23.0 under Leap 15.4 now after years no longer builds. Worked now for years. Suddenly no longer. Why, no idea. Evl a python package now too new.
Because, I also noticed, are in backport sometimes renewed packages, but with python 3.6 no longer work at all. Build maybe. But to serve as a module to build other modules or to run independently they are broken.

In the course of this I noticed that calibre 4.23.0 under Leap 15.4 now after years no longer builds

Strange, my branch still builds.

@mwilck did the calibre situation improve with python3.11 avaialaibility in 15.5? We could aim for 15.6. If we know any missing pices, now is the time to open jiras for SLES 15 SP5 (see my early feature call on factory@lists.opensuse.org)

Metadata Update from @lkocman:
- Issue close_status updated to: Completed
- Issue status updated to: Closed (was: Open)

9 months ago

Metadata Update from @lkocman:
- Issue status updated to: Open (was: Closed)

9 months ago

Metadata Update from @lkocman:
- Issue set to the milestone: 15.6

9 months ago

I also tried to build calibre under Leap 15.5 with python3.11. But that does not work either.
Because the needed macro: %sle15_python_module_pythons()
I would need like this

%sle15_python_module_pythons() %%global pythons python311 python3

in the ProjektConfig to get pyton3 and python3.11. But if a package cannot be built with 3.6, the package will not be built at all. Also not with 3.11, even if it would work.

I have also reported this to the packaging mailing list but have not received any feedback yet.

I can only update from 15.4 to 15.5 if I have a python3 package. Only then you could make an update to a python3.11.
So I need several REpos. And 100s of python packages. And these then also still depending on the python version.

I am in the process. But still waiting for an answer in the mailinglist.
Maybe I am on the wrong way. Or am missing something.

And one more note about calibre itself.
The developer let's say is a bit special.
And I would advise not to use any older packages so upstream prescribes. You will get zero help from upstream. So you more or less have to develop the whole thing yourself.
Currently for example he uses a library which is not yet officially released.
This is not available in Factory from suse. And I can't make it build either.
For this reason also calibre in Tumbleweed is a bit outdated.
The current versions are not built by almost any distribution.

I hope I could bring the problems a little bit over.

@ecsos, thanks for your comment and continued dedication to work on this package for openSUSE.

I have to confess that (unlike you) I haven't followed up closely. My use case (calibre server on a home server) works nicely with the calibre 4.23 package from my home project, I've had zero issues with it over the past months. (Although I just found out that this package has ceased to build some time ago. Will have to look into that).

It is understood that calibre is a prime example of dependency hell in a modern distribution. It is basically impossible to reconcile its requirements with a standard set of stable python modules like a distribution would deliver, whether it's a rolling distro or a more conservative one like Leap.

I guess that even if I don't like the thought too much, Flatpak is probably the way to go for the calibre desktop application in the future.

For my use case, flatpak isn't useful though. I guess I'll have to look into some containerized approach. Ideally I'd go for the server functionality only, but that doesn't seem to be an easy thing to do, either. For the time being, an old calibre version that still builds under Leap 15.4 is quite enough for my needs.

News for calibre under Leap and Tumblweed.
Version 6.22.0 from upstream is out.

And also calibre for Tumbleweed and Leap 15.5.

Under Tumbleweed the last version now is 6.21.0 because of old podofo which should not updated till now because of api changes. See my corspondence to podofo request.

And for calibre under Leap 15.5 you need many new packages and a lot of work and diskussion. With and without luck.
And i must many many request do for the new macro.

Partly, however, the request was not accepted.
Partly because it was not wanted. Partly because they still wanted to discuss whether to do it or not. Partly just arrogantly rejected.
But let's say 95% of the requests were accepted.
Why there but some oppose I do not understand.
And why this was not integrated automatically by means of a mass change in all packages, if one already refers to it in the release notes, is also not clear to me.

But I did it.
At least in my home repo:
https://build.opensuse.org/package/show/home:ecsos:python:applications/calibre

Here are the latest versions of calibre for Tumbleweed
and for Leap 15.5
Both are installable and executable.
I have tested both in a VM.

If podofo is accepted at some point, the latest version will also officially appear in Tumbleweed.
And if Documentation:Tools is configured "correctly", it might be possible to build for Leap there too.

But please understand me that I don't feel like having any nonsensical and everlasting discussion regarding all the packages in Leap itself.
My time is too valuable for that.

@ecsos, WOW, you maintain no less than 820 python packages in your repo. That's truly impressive. I am not sure whether a 15.5 installment using your repo could still be called "Leap 15.5" with so many packages replaced, but it is a superb piece of work either way.

FTR, the podofo request: https://build.opensuse.org/request/show/1096116

I think podofo will need to be discussed on the factory ML. They can't reject 0.10.0 forever in Tumbleweed, so so some sort of plan must (and will, I suppose) emerge sooner or later to make the update happen. But that's obviously OT for this issue here.

@ecsos, WOW, you maintain no less than 820 python packages in your repo. That's truly impressive. I am not sure whether a 15.5 installment using your repo could still be called "Leap 15.5" with so many packages replaced, but it is a superb piece of work either way.

FTR, the podofo request: https://build.opensuse.org/request/show/1096116

Why should this no longer be called Leap 15.5? The old and dead python 3.6 packages still exist.

And wasn't that exactly what was announced in the release news?
Namely that the long dead python 3.6 can now be replaced.

Only on one point I can only repeat myself. Why was the macros not automatically inserted by script in all python packages? So you have to fight with maintainers who do not want to accept this. For whatever reason. Whereas 98% agree. The others you have to ignore then. Even if it is not right in my opinion.

So you don't supersede any openSUSE packages? I didn't realize that, sorry.

Hello team, what's the status of this issue? Any particular blockers, or did you change mind about Calibre?

Thank you!

Michal suchanek was able to get it working https://build.opensuse.org/project/monitor/home:michals:Calibre?arch_x86_64=1&defaults=0&repo_15_6L=1&succeeded=1

We're updating all necessary components in SLES 15 SP6.

Metadata Update from @lkocman:
- Custom field SUSE Jira - SUSE Linux Enterprise adjusted to https://jira.suse.com/browse/PED-7572

2 months ago

Login to comment on this ticket.

Metadata