FTBFS on powerpc: thread.error: can't start new thread

[Timo Jyrinki]

Update 2015-03-12:

After two cherry-picked fixes, the remaining problem is that powerpc fails while other archs work. It might be a python problem.

--- original bug report ---

Calibre FTBFS:s when rebuilt against Qt 5.4.1:

https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+sourcepub/4827668/+listing-archive-extra
---
  File "/usr/lib/python2.7/dist-packages/PyQt5/uic/uiparser.py", line 757, in setZOrder
    getattr(self.toplevelWidget, elem.text).raise_()
TypeError: getattr(): attribute name must be string
---

The landing PPA (see https://wiki.ubuntu.com/Touch/QtTesting) has Qt 5.4.1 + pyqt5 5.4.1, the same that are in Debian experimental.

It has not been rebuilt against Debian experimental in Debian, but the same Calibre version 2.19.0 did rebuild successfully against Ubuntu's Qt 5.4.0 + pyqt5 5.4.0, so this bug is probably something changed in pyqt5 5.4.0 -> 5.4.1.

[Timo Jyrinki (timo-jyrinki)]

There's a recent upstream commit claiming to fix an Qt 5.4.1 issue - https://github.com/kovidgoyal/calibre/commit/72d47ba9377d70e786bf3d93b323544188c894bd - but that alone does not seem to fix this build issue: https://launchpadlibrarian.net/199907621/buildlog_ubuntu-vivid-amd64.calibre_2.19.0%2Bdfsg-1ubuntu1~vivid1~test1_BUILDING.txt.gz

[Timo Jyrinki (timo-jyrinki)]

As a pointer, even the 2.20.0 + the patch gives the same build failure, even though eg. Arch has pyqt5 5.4.1 + calibre 2.20.0 built.

[Timo Jyrinki (timo-jyrinki)]

I added a patch (remove_empty_zorder.patch) to remove the empty zorder field from metadata.ui as suggested by pyqt upstream. It resolves the problem and now all other archs build (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+sourcepub/4829743/+listing-archive-extra), _but_ unfortunately there is also an unrelated powerpc failure still happening:

https://launchpadlibrarian.net/200008007/buildlog_ubuntu-vivid-powerpc.calibre_2.19.0%2Bdfsg-1ubuntu1~vivid1~test2_BUILDING.txt.gz
---
####### Building extension podofo #######
Compiling podofo
Traceback (most recent call last):
  File "setup.py", line 99, in <module>
    sys.exit(main())
  File "setup.py", line 85, in main
    command.run_all(opts)
  File "/build/buildd/calibre-2.19.0+dfsg/setup/__init__.py", line 181, in run_all
    self.run_cmd(self, opts)
  File "/build/buildd/calibre-2.19.0+dfsg/setup/__init__.py", line 178, in run_cmd
    cmd.run(opts)
  File "/build/buildd/calibre-2.19.0+dfsg/setup/extensions.py", line 398, in run
    self.build(ext, dest)
  File "/build/buildd/calibre-2.19.0+dfsg/setup/extensions.py", line 442, in build
    if not parallel_build(jobs, self.info):
  File "/build/buildd/calibre-2.19.0+dfsg/setup/parallel_build.py", line 32, in parallel_build
    p = Pool(cpu_count)
  File "/usr/lib/python2.7/multiprocessing/dummy/__init__.py", line 151, in Pool
    return ThreadPool(processes, initializer, initargs)
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 718, in __init__
    Pool.__init__(self, processes, initializer, initargs)
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 159, in __init__
    self._repopulate_pool()
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 223, in _repopulate_pool
    w.start()
  File "/usr/lib/python2.7/multiprocessing/dummy/__init__.py", line 75, in start
    threading.Thread.start(self)
  File "/usr/lib/python2.7/threading.py", line 745, in start
    _start_new_thread(self.__bootstrap, ())
thread.error: can't start new thread
---

It's not solved by a simple rebuild.

[Timo Jyrinki (timo-jyrinki)]

_Second_ rebuild however fixed the problem. If it was not unstable before, possibly related to multiprocessing fix in the latest python2.7 upload.

[Martin Pitt (pitti)]

Right, calibre is unstable on powerpc right now, also on earlier versions, so that's nothing new. Let's use that bug to track this then.

[Launchpad Janitor (janitor)]

This bug was fixed in the package calibre - 2.19.0+dfsg-1ubuntu2

---------------
calibre (2.19.0+dfsg-1ubuntu2) vivid; urgency=medium

  * Rebuild against Qt 5.4.1
  * Cherry-pick a 5.4.1 fix from upstream:
    - debian/patches/Fix_incompatibility_with_PyQt_5.4.1.patch
      (LP: #1430663)
 -- Timo Jyrinki <email address hidden> Sat, 14 Mar 2015 06:41:11 +0000