Use latest calibre release? Or the packaged Debian version?

[chaley]

Originally Posted by eschwartz

Because Kovid packages Qt 5.4.0...
And he added fixed it.

(How would they install it if not from source -- vs from precompiled binaries?)

(and further posts)

You said that there are no problems if one "installs from source". There have been several bug reports from users of Arch linux. You further say "How would they install it if not from source ...". You are contradicting yourself.

I think we are close to entering a OS/distro religious battle, something that has no interest for me. I gave that up in the 70s shortly after we released Unix V7.

[eschwartz]

I didn't realize there was a religious battle on the horizon, I just think I was maybe mildly unclear, and this is bordering on the semantically dull.

Just saying, Kovid has an official "INSTALL" readme which says, in part:

Originally Posted by git/calibre/INSTALL

calibre supports installation from source, only on Linux.

...

On Linux, there are two kinds of installation from source possible.
Note that both kinds require lots of dependencies as well as a
full development environment (compilers, headers files, etc.)

Trying to build any package with different software versions than the ones tested upstream sometimes results in bugs, which hopefully get fixed upstream, and says nothing either for or against downstream packaging.

All I said was you get the same results Kovid would get, in a very duplicable manner. Not that there will never be bugs.
(And whenever he may decide to upgrade the Qt that calibre shipped, he'd get the same error, very duplicable.)

So it is perfectly possible to run that perfect Arch Linux calibre-from-source build, assuming you use the same versions of stuff and nothing was broken downstream, etc... all of which are reasons to let distro maintainers slave away to test things (or not), or use Kovid's binaries.

[DiapDealer]

Originally Posted by eschwartz

So no matter where your distro is or what they do or how much they tend to laaaaaaaaaaaaaaaag, calibre works and is at the latest version, without clashing with anything else. Most packages IMHO could use a version like that, especially what with most distros freezing the system at a certain point.

No argument from me. I frankly find today's open source distro packaging systems to be way too scatter-brained and more than a little stifling. Too much time spent quibbling about what's happening "upstream." I use distros for common piddly things when it's convenient, but have no qualms about stepping outside that box when it wants to force me into using ancient software.

I just thought I remembered Kovid mention (to someone trying to build calibre from source) that he had "fixed" something in Qt. I must've been wrong.

[eschwartz]

Hear, hear.

[Queso]

I installed the latest version in my home directory on Wheezy. It loads fine, but when I try to open the included manual it throws a Python traceback at me and won't display it...

calibre, version 2.20.0
ERROR: Could not open ebook: [Errno 5] Input/output error

Traceback (most recent call last):
  File "site-packages/calibre/gui2/viewer/main.py", line 38, in run
  File "threading.py", line 763, in run
  File "site-packages/calibre/ebooks/oeb/iterator/book.py", line 99, in __enter__
  File "site-packages/calibre/customize/conversion.py", line 241, in __call__
  File "site-packages/calibre/ebooks/conversion/plugins/epub_input.py", line 228, in convert
  File "site-packages/calibre/ebooks/conversion/plugins/epub_input.py", line 105, in rationalize_cover
  File "site-packages/calibre/utils/logging.py", line 162, in __call__
  File "site-packages/calibre/utils/logging.py", line 154, in prints
  File "site-packages/calibre/utils/logging.py", line 45, in prints
  File "site-packages/calibre/__init__.py", line 224, in prints
IOError: [Errno 5] Input/output error

Worked fine when I was testing around in a Jessie virtual machine in VirtualBox. Ugh.

[kovidgoyal]

Originally Posted by Queso

But it is a bit scary to just run scripts directly downloaded from github...

As opposed to directly running code in the actual program you download from a distribution's servers, which in turn have downloaded it from either github or the source tarballs I publish? I've never understood this crazy meme that runs around the internet about how it is "scary" to run installer scripts downloaded from the internet. It reeks of security theatre. The installer script typically runs as root, but so what, the actual program has access to all *your* data, which is what is truly important on your computer.

The calibre install script is downloaded using https from github, it downloads the binary tarball from my servers using http and then verifies that download's integrity against a sha512 hash downloaded securely (and by securely I mean it uses a pinned SSL certificate -- i.e. no certificate authorities are involved).

And if for some reason you dont want to run the script directly from the internet, you can download it first, then inspect it and then run it, you can even run it as a normal user, not root, if you want.

EDIT: As for your error, use the --detach flag or make sure you run the program in a context that has a working stdout/stderr. That is dont start it from a terminal and then close the terminal. If you want to do that, use --detach

[kovidgoyal]

Originally Posted by DiapDealer

I just thought I remembered Kovid mention (to someone trying to build calibre from source) that he had "fixed" something in Qt. I must've been wrong.

Almost all Qt bugs are worked around in calibre's source code (grep the code for QTBUG). There are a couple that require patches against Qt itself. These (along with dozens of others) have all been reported by me to Digia -- just search for bugs reported by me in the Qt bug tracker.

The bundled version of Qt that calibre uses is not the typical Qt a distro will install. For instance, it removes large parts of Qt that calibre does not use (QtQuick, WebEngine, OpenGL, etc.). It also disables some specific Qt plugins that cause problems on some distros, in particular, the gtk style plugin (causes crashes on Ubuntu). And it contains patches for bugs that Digia has not yet fixed in the bundled version of Qt (currently 5.3.1).

[DiapDealer]

Thanks for the info. I thought I remembered something being mentioned about a couple of patches to the Qt sources.

[Queso]

Originally Posted by kovidgoyal

As opposed to directly running code in the actual program you download from a distribution's servers, which in turn have downloaded it from either github or the source tarballs I publish? I've never understood this crazy meme that runs around the internet about how it is "scary" to run installer scripts downloaded from the internet. It reeks of security theatre.

The distribute that I use, Debian, has package maintainers and security teams that provide "peer review" of the source code, you could call it. Different distributions obviously have different practices. The benefit with Debian, as I see it, is an entire separate set of eyes reviewing the code. If there is a security issue detected, the distribution's security team ensures the issue is addressed -- even if it is not addressed upstream. This is a good thing. And although the versions of the packages get outdated over time (in the stable release of the distro), they are at least proven to be stable and secure. For these reasons, I stick with Debian. Some of the software that I use, though, is less strict and I use non-Debian packages so I can stay more up-to-date (for me this includes Firefox [well, this is still a Debian team], VirtualBox, and now calibre). But, to each their own, this is my take on things.

Originally Posted by kovidgoyal

EDIT: As for your error, use the --detach flag or make sure you run the program in a context that has a working stdout/stderr. That is dont start it from a terminal and then close the terminal. If you want to do that, use --detach

That was exactly the problem. Thank you very much for your help!

EDIT: Oh, you are the creator of calibre! Let me just say, thank you very much for your hard work! Although I am a new user, so far I really like what I see and am looking forward to getting more acquainted with it. I am myself a Python developer, but in the world of web applications.

[kovidgoyal]

@Queso: You are of course welcome to do whatever you find most comfortable. I do not support distro provided calibre packages for good reasons, but, if you prefer them, feel free to use them, the only caveat being that you wont get help from me

Personally, I find the idea that a small team of distribution package maintainers can effectively (and continuously!) review thousands of packages for bugs whether security or stability related, better than the developers that created the software to be rather incredible. It may well be true for software that is not actively maintained, but for software that is actively maintained, it just doesn't seem very likely.

And, in practice, I have found that distro maintainers introduce far more bugs than they fix. But, YMMV.

[Queso]

Ya'll convinced me to use your release, so that's what I'll be doing. And I promise to read the manual before asking questions.

[kovidgoyal]

Originally Posted by Queso

EDIT: Oh, you are the creator of calibre! Let me just say, thank you very much for your hard work! Although I am a new user, so far I really like what I see and am looking forward to getting more acquainted with it. I am myself a Python developer, but in the world of web applications.

You're welcome

[signum]

Originally Posted by Queso

Can you comment on ease of upgrading your library from one version to another? If I sit on 2.5 for a year and decide, hey, the latest version has a compelling to feature, will my Calibre Library/ upgrade safely? Is that supported? Or should it be upgraded from a more recent version? Or is that directory/format very stable and there are rarely changes? Thanks!

The official Calibre upgrade is always complete in itself. It doesn't depend upon any previous release. It has all the stuff it needs to run (specifically, the minimal needed Qt5 libraries and others), as if it were a complete new install. The Calibre library isn't touched but used if found, nor is the user configuration directory, also used if found, which is buried in a "hidden" directory underneath your home directory. New versions come out every Friday, not because Calibre is so buggy, but rather due to active development of new features. Many people scan the "what's new" web page (essentially, a change log) to see if anything changed that they might be interested in. If not, they will skip that week's update. If you find a bug, Kovid often fixes them within a day, sometimes within hours, and it will appear in the next Friday's update. I call this an extremely high level of support.

[kacir]

Originally Posted by Queso

Question: Or, is there a compelling reason that I should instead track with the release version of calibre and not use the Debian packages? Keep in mind I'm completely new to calibre and haven't used it for anything yet! Thanks for your help.

I use Calibre on Mint Linux (built on Ubuntu (built on Debian)).
After starting to use Calibre [for more than a very occasional conversion job] I have very soon discovered that it is a very good idea to run Calibre installed from official Calibre site.
There is usually a new version available every Friday and it often brings very interesting features and improvements. Calibre will prompt you for update by default.
Version from official distro packages is most of the time hopelessly outdated.

[eschwartz]

Originally Posted by kovidgoyal

@Queso: You are of course welcome to do whatever you find most comfortable. I do not support distro provided calibre packages for good reasons, but, if you prefer them, feel free to use them, the only caveat being that you wont get help from me

Personally, I find the idea that a small team of distribution package maintainers can effectively (and continuously!) review thousands of packages for bugs whether security or stability related, better than the developers that created the software to be rather incredible. It may well be true for software that is not actively maintained, but for software that is actively maintained, it just doesn't seem very likely.

And, in practice, I have found that distro maintainers introduce far more bugs than they fix. But, YMMV.

I am sure it is very useful simply because if a package finds its way into the repos in the first place, it can be assumed the package is not malicious (I hope it is safe to assume they get properly vetted the first time even if later they slack off due to overload). After that, feel free to use the developer recommended installation. After all, the only service the repos perform is vetting for downright malicious code (usually not applicable) and package management with debundled deps -- which can be a bad thing depending on the patches.