It turns out I hardcoded the output path that qt's tarball extracts.
But that path is versioned (4.8.5 for example).
As I've already merged x-updates on my own system, my qt version was
different (4.8.4 vs 4.8.5). Made the path-guessing more flexible, so
now it should work with any 4.8.*
Upstream insists on using private qt headers.
We do not want nixpkgs' qt to export those.
So I provided a small hack to take them directly from qt's source tarball.
I made sure everything uses the normal system qt and headers, except for the
1 .so file (qt_hack) that needs these private headers.
Because of this, there is barely any increate in size or buildtime.
x-updates is supposed to merge after stdenv-updates, so let's test it
Conflicts:
pkgs/development/libraries/gtk+/2.x.nix (both updated, taking newer)
pkgs/development/libraries/mesa/default.nix (taking nativeBuildInputs)
The better way would be adding sqlite to
pythonPackages.sqlite3.propagatedBuildInputs but I don't want to touch this
code.
svn path=/nixpkgs/trunk/; revision=31197
* Removed some unused versions of those packages.
* Don't pass `lib' to packages (because we already have `stdenv.lib').
* Removed some `*_python26' variants because Python 2.6 is the default
now.
svn path=/nixpkgs/trunk/; revision=20782
I still have not been able to convert any single book to lrf with this calibre.
There may be some tool missing, but I don't guess what.
svn path=/nixpkgs/trunk/; revision=19310
- Adding podofo
- Adding some new python packages
- Making new pkgs attributes for python packages to build with python 2.6
- Updating some python packages expressions to allow python 2.6, and not only 2.5.
svn path=/nixpkgs/trunk/; revision=19303
