[Nix-dev] How to help remedy build errors of Haskell packages in Nixpkgs

Peter Simons simons at cryp.to
Sun Aug 10 14:40:58 CEST 2014


Hi guys,

if you're using Nix to install Haskell packages, then please consider
contributing some time and effort to fix build failures! At the time of
this writing, we have about 120 packages that fail to build on Hydra.
You can see the complete list at this place:

  http://hydra.cryp.to/jobset/nixpkgs/haskell-updates

Just follow the link to the latest evaluation, and you'll see the exact
list of packages that don't compile in the "Still failing" tab. Now,
pick any one of those packages that you care about and look at the build
log. We typically have the following kinds of build errors:

 - Dependency version mismatch. These kind of errors mean that the
   configure stage fails with an error message along the lines of:

    | Configuring rest-types-1.10.1...
    | Setup: At least the following dependencies are missing:
    | aeson ==0.7.*

   We use aeson 0.8.0.0 by default, so this package won't compile
   because that version is too new. An error like this should always be
   reported upstream! Furthermore, you can try to add

     | jailbreak = true;

   into the failing packages Nix file, then run

     $ nix-build -o /tmp/haskell --option binary-caches http://hydra.cryp.to ~/src/nixpkgs -A haskellPackages.restClient

   to check whether that actually helped. If it did, we're fine! If it
   didn't help, then there's not much else we can do. You _may_ edit
   haskell-packages.nix to override the version of aeson passed to this
   package with an older one, i.e. 0.7.0.4, but this is almost never a
   good idea, because Haskell programs cannot mix different versions of
   the same library in the same executable. This means that having some
   parts of our package base link aeson 0.7.x and other part link 0.8.x
   is bound to cause trouble at some point. If in doubt, just mark the
   package as broken by adding the lines

    | hydraPlatforms = self.stdenv.lib.platforms.none;
    | broken = true;

   to the meta section.

 - Compile errors. Some packages cannot deal with current versions of
   GHC and/or 3rd party dependencies. These errors manifest in the form
   of genuine compiler errors. Errors of this kind must almost always be
   fixed upstream. The way to go in this case is to file a report and to
   mark the package as broken in Nixpkgs.

 - Test suite failures. Oftentimes, packages compile fine but fail
   during the "check" phase. The easiest way to remedy that problem is
   to disable the test suite by adding "doCheck = false;" to the Nix
   file. However, a test suite failure may very well indicate a serious
   error in the software, and we might actually prefer an older version
   over the one that fails. It's probably best to report the error
   upstream and ask for advice how to proceed.

 - Haddock failures. Believe it or not, but some packages cannot build
   their own documentation. This should be reported upstream, of course.
   Meanwhile, the issue can be worked around by adding "noHaddock =
   true;" to the Nix file. It's good to exercise caution here, though.
   Generally speaking, though, packages without documentation are highly
   undesirable, and using that hack to make a package build should not
   be used lightly.

Now, let's assume that you've edited many, many packages and fixed lots
of build errors. Before you run "git push", please run:

  $ hackage4nix ~/src/nixpkgs

That tool comes with "cabal2nix", and it will re-generate all Haskell
build in-place. Running that tool in a Nixpkgs check-out should always
be a no-op, i.e. no files should be modified by hackage4nix!

If there are modified files, then you should investigate the diffs. If
the change made by hackage4nix is purely cosmetic, then please amend
your commit to include those modifications. If the change is
significant, however, then this means that cabal2nix cannot generate a
proper build for that particular package! Please report any such issue
at <https://github.com/NixOS/cabal2nix/issues>.

You'll notice that hackage4nix also prints our a list of updates that
might be applied to the source tree (run "cabal update" to update your
package database!). Feel free to update packages, if you have the
chance, but please run test builds for important packages such as
git-annex, darcs, or hledger-web to make sure that your updates don't
break anything.

Attached to this e-mail you'll find a short shell script called
commit-haskell-update that scans the Nixpkgs tree for modified (updated)
packages and then generates git-commit calls ready for cut & paste for
your convenience.

Furthermore, there's a script called update-haskell-package-list that
uses [1] and [2] to generate an updated list of Haskell packages to-be
uploaded to the Hackage server so that they can advertise for each
package whether NixOS has it (and which version we have).

If you have any questions, please fire away!

Best regards,
Peter


[1] https://github.com/peti/package-list
[2] https://github.com/peti/hackage-db

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: commit-haskell-update
Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140810/0ea1d315/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: update-haskell-package-list
Url: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140810/0ea1d315/attachment.pl 


More information about the nix-dev mailing list