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

[Mateusz Kowalczyk]

On 08/10/2014 02:40 PM, Peter Simons wrote:
> 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.

Say a package version no longer builds with <recent GHC version> and
upstream won't fix it or can't fix it to work with that version for some
reason, what's the way to go about only blacklisting the broken GHC
versions? I can think of most packages using GHC API being sensitive to
this.

>  - 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
> 
> 
> 
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 

My question is as to what the recommended way to edit the Haskell
package expressions is. I usually just drop in and make whatever changes
are needed but I have seen a couple of times recommendation that any
changes should be made in cabal2nix to ensure our changes are not lost
the next time cabal2nix is ran. What's the workflow here? Should we
check out cabal2nix HEAD, packageOverride it with ‘src’, hack that to
consider changes and then use cabal2nix? Also I'm unsure whether it's
possible to specify extra package arguments that the package needs to
take, say we need actual GTK C libraries, can cabal2nix handle that?

I'll see whether I can't thin the broken package list a bit today,
thanks for instructions.

-- 
Mateusz K.