Problems compiling calibre

[DOMBlogger]

I am attempting to compile calibre on CentOS 6.2 + EPEL fully patched.

I started with the Fedora src.rpm from Fedora 16 - all build dependencies met from CentOS and EPEL except 1 - python-cssutils - which I met by rebuilding the Fedora src.rpm (that is a platform independent python library)

When I saw that calibre-0.8.33-2.fc16.src.rpm was failing and would need some TLC to build in CentOS I started hacking at the rpm spec file, first thing I did was grab the latest source for calibre - 0.8.36.

It's not even getting past the setup, and what is choking the setup appears to be bits of python added since 0.8.33 - now I'm no expert in python, but it appears to me to just be sloppy code. For example, the following patch got me past one of the choke points:

diff -ur calibre/setup/check.py calibre.patched/setup/check.py
--- calibre/setup/check.py      2012-01-19 20:44:58.000000000 -0800
+++ calibre.patched/setup/check.py      2012-01-22 23:00:58.000000000 -0800
@@ -89,7 +89,7 @@
             self.info('\tChecking', f)
             errors = False
             ext = os.path.splitext(f)[1]
-            if ext in {'.py', '.recipe'}:
+            if ext in ('.py', '.recipe'):
                 w = check_for_python_errors(open(f, 'rb').read(), f)
                 if w:
                     errors = True

Why curly brackets were used in the original, I'm not sure - again I'm not a python guru but all my experience with python says parenthesis are what should have been used.

Current choke point is in calibre/setup/upload.py -

Traceback (most recent call last):
  File "setup.py", line 13, in <module>
    import setup.commands as commands
  File "/home/domblogger/rpm/BUILD/calibre/setup/commands.py", line 68, in <module>
    from setup.upload import (UploadUserManual, UploadDemo, UploadInstallers,
  File "/home/domblogger/rpm/BUILD/calibre/setup/upload.py", line 117
    files = {x:installer_description(x) for x in
                                          ^
SyntaxError: invalid syntax
error: Bad exit status from /home/domblogger/rpm/tmp/rpm-tmp.N9v9EI (%build)

Looking at that code -

files = {x:installer_description(x) for x in
                all_possible.intersection(available)}

Again, I'm no expert in python, but in any language that at least looks to be extremely sloppy and hard to understand and thus difficult to maintain.

Have the contents of the setup directory been run through a python lint tool?
What kind of checking is done before releases are pushed? Is the error bad python as I'm alleging, or is perhaps the python on my system (python-2.6.6) just too old?

If the issue is python version, might I suggest your coding standards specify that code needs to work on Python 2.6? A lot of enterprise Linux distributions (not just RHEL and clones) are currently running Python 2.6 and I would hate to see a project such as this excluded from those users.

Is there a project bugzilla where I can look to see if my issues are already being addressed?

Thank you, I've never actually used calibre or really any epub reader extensively, but I now have been given assignment of writing tools to generate epub content (epub 3 w/ 2 compat) and having calibre on my system would make testing the output of my code (php - not python) a lot easier, and for that I am very grateful.

[chaley]

Originally Posted by DOMBlogger

Why curly brackets were used in the original, I'm not sure - again I'm not a python guru but all my experience with python says parenthesis are what should have been used.

The curly brackets are correct. It means create a set instead of a list. This syntax is valid starting in python 2.7, which is the minimum version supported by calibre.

[DOMBlogger]

Well, that's a shame.

I guess I need to look for a different solution.

Is there a technical reason why such a recent version of python is required? And if 2.6.6 isn't new enough, shouldn't that have been caught at the beginning?

I'm a die hard FOSS fanatic but I guess the constant desire to use bleeding edge and ignore stable is the one weakness many FOSS projects have that commercial software with top down management demanding sane compatability with stable platforms don't have.

Oh well.