Haskell packages that contain non-ascii characters in their .cabal file
or somewhere else in their haddock documentation fail to compile under
nixpkgs and usually flagged with noHaddock = true. I wanted to do the
same for modularArithmentic, when I realized that we just have to set
the locale to some UTF-8 compatible locale in build-support/cabal to fix
this issue correctly.
The bash scripts of elixir contain some references to `erl'. This
patch wraps the scripts and extends PATH so `erl' is available.
Signed-off-by: Moritz Ulrich <moritz@tarn-vedra.de>
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.*
And name the desktop file "eagle.desktop", not "Eagle.desktop". The user
facing application name is still "Eagle"; it has nothing to do with the
name of the desktop file.
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.
Running 1 test suites...
Test suite hoogle-test: RUNNING...
hoogle-test: datadir/testdata.txt: openFile: does not exist (No such file or directory)
Test suite hoogle-test: FAIL
Test suite logged to: dist/test/hoogle-4.2.19-hoogle-test.log
0 of 1 test suites (0 of 1 test cases) passed.
This commit also fixes an issue where pkgconfig was only added as a
dependency when gtk support was enabled. This made ./configure unable
to find other libraries (libtiff, libxml2, gnutls, and others).