On Sun, Jul 22, 2018 at 11:49:14AM +0200, Andreas Enge wrote: > Hello, > > I ended up disabling tests (see comments in the patch). > Now the package builds, but tries to install into the Qt directory; at the > end of the cmake phase, it prints: > -- Installing in the same prefix as Qt, adopting their path scheme. > The previous version of the package contains a phase to adapt this, > but the .pri files to be modified do not exist any more. > > I also tried to inherit from qtsvg like other qt* packages; but the > gnu-build-system does not work any more for qtwebkit, the build finishes > in a few seconds creating only the documentation and not compiling the code... > > At this point, I am giving up; it would be nice if someone else could take > a look, I am attaching the current patch.
Thanks for getting the patch this far! I switched the 'configure phase from (invoke qmake) to fully cmake with some necessary configure-flags. It seemed easier than trying to convince qmake to install to the correct location. I also left the tests disabled, 7+ hours compiling on my fast aarch64 board was quite long enough. I'm not opposed to re-enabling them but I don't want to debug failures. > > If there is no progress during the next few days, I would suggest to re-add > pyqt@5.9 for calibre. What do you think? After fixing a bug in optipng (bundling outdated copies of libraries is definately a bug) I was able to compile calibre on aarch64. I run it headless, so I wasn't able to test it but hopefully it's back to working. > Andreas > > PS: There is a thread from 2016 in which the Calibre author states that he > will stick with qtwebkit and in the worst case take over the maintenance > of a fork: > https://www.mobileread.com/forums/showthread.php?t=270258 If he's planning on going the same route as gnucash I assume its only a matter of time until he realizes distros will drop calibre rather than carry along his beloved cruft. -- Efraim Flashner <efr...@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted