Closed pikajude closed 9 years ago
To be more specific: the cached package on Hydra contains a very old haddock.
I built GHC 7.8.2 with --option use-binary-caches false
to force a source build. Thankfully, it resulted in haddock 2.14, which means I can build haskell packages with it properly. Interestingly it has the same hash as the GHC installation shown in my paste above (1qjf79...
). Anyone have any enlightening ideas as to why the two different builds would produce the same hash with different products?
You are building on Darwin, I suppose? The Darwin stdenv is impure, i.e. builds rely on all kinds of tools and libraries that aren't packaged in Nix. As a result, Nix builds on Darwin cannot run in a chroot environment and thus are far less deterministic than builds on Linux.
Found that out yesterday. I built GHC myself from source and it resulted in the right haddock. Still trying to figure out why. It might be worth removing the success builds on hydra since they contain the wrong contents.
On May 19, 2014, at 4:48 AM, Peter Simons notifications@github.com wrote:
You are building on Darwin, I suppose? The Darwin stdenv is impure, i.e. builds rely on all kinds of tools and libraries that aren't packaged in Nix. As a result, Nix builds on Darwin cannot run in a chroot environment and thus are far less deterministic than builds on Linux.
— Reply to this email directly or view it on GitHub.
It looks like after 7.8.3, this causes thousands of missing binary packages on Hydra for ghc+darwin.
EDITED: looks independent of x-updates stuff.
Yes, this problem is serious. Maybe @edolstra has a chance to trigger a re-build of the GHC 7.8.3 derivation on Darwin? Hopefully, that would give us a working Haddock binary.
Just a "me too" - in that I've been bitten by this (OS X 10.8.5) - and am still trying to work around it...
I ended up needing to do something like this to disable Haddock completely to get it working:
let cfg = (pkgs : {
packageOverrides = pkgs : {
localHaskellPackages = pkgs.haskellPackages.override {
extension = self : super : {
cabal = super.cabal.override {
extension = self : super : {
noHaddock = true;
hyperlinkSource = false;
};
};
};
};
};
}); in
let pkgs = import <nixpkgs> {config = cfg;}; in
let localHaskellPackages = pkgs.localHaskellPackages; in
cabal.mkDerivation ...
This is still a problem with GHC 7.8.3.
I've just been bitten by this too. On OS X 10.9.2, just running:
$ nix-env -i cabal-install
triggers this. Got myself a 7.8.3 through nix right before running this command.
@jwiegley suggested the following work-around: wipe your ghc installation and reinstall using --option build-use-substitutes false
.
Doesn't seem to be working for me unfortunately. What do you mean by "wipe out", just nix-env -e ghc ...
or also ditching ~/.ghc
?
You have to remove the broken GHC package from the Nix store, i.e. by running:
nix-store --delete /nix/store/*-ghc-7.8.*
If this command refuses to do anything, you may have to add the --ignore-liveness
parameter. Be sure that your system and/or user environment doesn't contain anything that depends on GHC before running with --ignore-liveness, though, because that option may break existing profiles that do depend on GHC.
@peti Thanks, I confirm the workaround works on my machine too.
After wiping out, such as by rm -fr /nix/store/*ghc*
, make sure to re-install using --repair
.
Does this mean the hydra problem is fixed and we just need to redownload the new fixed package or is the build-use-substitutes
just a workaround to get it working on our local machines?
@CRogers: it's just a workaround, and Hydra binaries remain broken (I believe).
@peti thnks! solved the issue for me too! ...it really takes ages even on a fast machine :) Quite a stumbling point for new nixpkgs users like me. would be even more satisfying to know what went wrong!
Well, you've built your own GHC instead of using the binary from Hydra (which has an issue), that's why it took so long :)
Ran into this problem as well. But I was a little bit lazier so I just rebuilt a correct haddock and spliced it into:
/nix/store/5ck4382ba8dwrbpkh8g2bqq45vd3jsrw-ghc-7.8.3/lib/ghc-7.8.3/bin
That's very un-nix like, I know... but is it worse than the above work-around?
I just copied the correct binary into the store, too. I didn't have any problems so far and didn't have to wait for ages building from source.
Any hopes that this issue will be resolved soon? It's pretty serious for Haskell on Darwin with Nix.
Just a +1. (I also copied the binary into the store).
How would I build a correct haddock binary, if I have a completely empty nix-pkgs environment? Or is there some correct binary available for download anywhere?
I downloaded the binary distribution from haskell.org. I did a configure
/make
as in the INSTALL
instructions, but I'm not sure if that is necessary. It won't build everything from source, so it's a lot faster than asking Nix to build from source. Then I copied that Haddock binary into the Nix store.
Seems to work for me too. Thanks.
:+1: from me too
:+1: working for me on 10.10 DP8. The only way I could get it to work, though, was to extract the archive I downloaded from the above link, then ran ./configure --prefix=$(pwd)/built
and make install
. This will install to a folder called "built" in the current directory. Once that's done you'll have a haddock binary you can copy into nix.
I encountered the issue with the broken haddock when trying to install git-annex on Mac OS X 10.7.5. Then I tried:
nix-store --delete /nix/store/*-ghc-7.8.*
nix-env --option use-binary-caches false -i git-annex
This compiled fine for several hours, but then failed with
Preprocessing library hinotify-0.3.7...
INotify.hsc:35:25: fatal error: sys/inotify.h: No such file or directory
This is frustrating for me as a regular user. nix seemed so perfect at first, promising reproducible builds. Somehow there is a dependency which is not fulfilled, but nix never told me it wouldn't run on my system. This mess with undeclared dependencies is exactly what I hoped nix would solve!
Reproducibility works well on pure platforms, which are currently only linux ones.
On 5 October 2014 12:38, m-a-t notifications@github.com wrote:
sys/inotify.h
In that case it would fail reproducibly. nix doesn't solve dependency issues automatically and inotify is a linux-only feature.
Sorry, the picture is not clear to me yet. If inotify is a linux-only feature, why is the package available for darwin? As the error comes up only with deactivated binary caches, there must be a binary that was successfully built. Therefore, the build-function is not pure (successful at binary cache producer, failure for me). For the moment I give up. I guess it is not easy to make a pure nix platform on darwin. But it should be easy to give more help to to end-user if an error occurs. For example: "Create a ticket at xyz." Or: "Sorry, it turned out this package doesn't work on your platform."
@m-a-t, I've marked hinotify
Linux-only in 972808f, so now it's no longer possible to build it on Darwin.
The Darwin build of git-annex
was recently broken in Nixpkgs. I've guessed a fix in 06a62d4, but I don't have access to a Mac, so I cannot test whether it actually did the trick. If you still see build errors, please let me know.
Please note that the binary channel lags behind the master
branch, so it's not uncommon for builds to succeed (or fail) in the current version of Nixpkgs even though they fail (or succeed) in the version that's distributed in binary form. If you build the package from source using the exact same version of Nixpkgs that the channel is built from, you should have the exact same binary output.
I have a fix for git-annex
on darwin that needs to be folded into cabal2nix
. Here it is:
diff --git a/pkgs/development/libraries/haskell/fsnotify/default.nix b/pkgs/development/libraries/haskell/fsnotify/default.nix
index 4db72b3..f9fef85 100644
--- a/pkgs/development/libraries/haskell/fsnotify/default.nix
+++ b/pkgs/development/libraries/haskell/fsnotify/default.nix
@@ -1,6 +1,6 @@
# This file was auto-generated by cabal2nix. Please do NOT edit manually!
-{ cabal, async, hinotify, systemFileio, systemFilepath, tasty
+{ cabal, async, hinotify, hfsevents, systemFileio, systemFilepath, tasty
, tastyHunit, temporaryRc, text, time
}:
@@ -9,8 +9,8 @@ cabal.mkDerivation (self: {
version = "0.1.0.3";
sha256 = "0m6jyg45azk377jklgwyqrx95q174cxd5znpyh9azznkh09wq58z";
buildDepends = [
- async hinotify systemFileio systemFilepath text time
- ];
+ async systemFileio systemFilepath text time
+ ] ++ (if self.stdenv.isDarwin then [ hfsevents ] else [ hinotify ]);
testDepends = [
async systemFileio systemFilepath tasty tastyHunit temporaryRc
];
Modified pkgs/development/libraries/haskell/hakyll/default.nix
Modified pkgs/stdenv/nix/default.nix
Modified pkgs/top-level/haskell-packages.nix
diff --git a/pkgs/applications/version-management/git-and-tools/git-annex/default.nix b/pkgs/applications/version-management/git-and-tools/git-annex/default.nix
index d69e84d..cf5087c 100644
--- a/pkgs/applications/version-management/git-and-tools/git-annex/default.nix
+++ b/pkgs/applications/version-management/git-and-tools/git-annex/default.nix
@@ -3,7 +3,7 @@
{ cabal, aeson, async, blazeBuilder, bloomfilter, bup, byteable
, caseInsensitive, clientsession, cryptoApi, cryptohash, curl
, dataDefault, dataenc, DAV, dbus, dlist, dns, editDistance
-, exceptions, fdoNotify, feed, filepath, git, gnupg1, gnutls
+, exceptions, fdoNotify, feed, filepath, fsnotify, git, gnupg1, gnutls
, hamlet, hinotify, hS3, hslogger, httpClient, httpConduit
, httpTypes, IfElse, json, lsof, MissingH, monadControl, mtl
, network, networkInfo, networkMulticast, networkProtocolXmpp
@@ -23,16 +23,20 @@ cabal.mkDerivation (self: {
isExecutable = true;
buildDepends = [
aeson async blazeBuilder bloomfilter byteable caseInsensitive
- clientsession cryptoApi cryptohash dataDefault dataenc DAV dbus
- dlist dns editDistance exceptions fdoNotify feed filepath gnutls
- hamlet hinotify hS3 hslogger httpClient httpConduit httpTypes
+ clientsession cryptoApi cryptohash dataDefault dataenc DAV
+ dlist dns editDistance exceptions feed filepath gnutls
+ hamlet hS3 hslogger httpClient httpConduit httpTypes
IfElse json MissingH monadControl mtl network networkInfo
networkMulticast networkProtocolXmpp networkUri optparseApplicative
pathPieces QuickCheck random regexTdfa SafeSemaphore securemem SHA
shakespeare stm tasty tastyHunit tastyQuickcheck tastyRerun text
time transformers unixCompat utf8String uuid wai waiExtra warp
warpTls xmlTypes yesod yesodCore yesodDefault yesodForm yesodStatic
- ];
+ ] ++ (if self.stdenv.isDarwin then [
+ fsnotify
+ ] else [
+ dbus fdoNotify hinotify
+ ]);
buildTools = [ bup curl git gnupg1 lsof openssh perl rsync which ];
configureFlags = "-fAssistant -fProduction";
preConfigure = "export HOME=$TEMPDIR";
Modified pkgs/build-support/cabal/default.nix
Modified pkgs/development/libraries/haskell/conduit-extra/default.nix
Modified pkgs/development/libraries/haskell/fsnotify/default.nix
Modified pkgs/development/libraries/haskell/hakyll/default.nix
Modified pkgs/stdenv/nix/default.nix
Modified pkgs/top-level/haskell-packages.nix
I use to keep applying this to the git-annex
and fsnotify
expressions, but @peti asked me to stop doing that, and I simply haven't spent the time to learn cabal2nix
well enough to maintain the changes there. This is one reason why I don't like having expression details split between nixpkgs
and other projects, although I recognize that it makes maintaining zillions of Haskell packages much easier.
@jwiegley, if you have the chance, could you please test whether the fix from 06a62d44fb81d61a37f5189f0274cb7a87a1bbb1 works correctly, i.e. does git-annex
compile in the current master
branch?
I've been using it against the current master branch regularly, but I will try it again tonight.
@peti Seems to be working fine for me.
@peti git-annex
now breaks today with:
[310 of 470] Compiling Assistant.WebApp.Types ( Assistant/WebApp/Types.hs, dist/build/git-annex/git-annex-tmp/Assistant/WebApp/Types.o )
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_aca4N
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_aca4W
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_aca52
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_aca5j
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_aca5l
Use ViewPatterns to enable view patterns
Assistant/WebApp/Types.hs:40:1:
Illegal view pattern: fromPathPiece -> Just dyn_aca5m
Use ViewPatterns to enable view patterns
This is brand new, even though it seems to be the same version of git-annex
.
@peti Also, git-annex
still does not refer to fsnotify
, which means that the assistant will not notice changes on the filesystem.
@jwiegley, git-annex
refers to fsnotify
at https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/haskell-packages.nix#L3181. These build errors come from the Yesod 1.4 update. Upstream is aware of them and has a fix in https://github.com/joeyh/git-annex/. The next release is going to remedy that issue.
Ah, ok. In the meanwhile, this patch fixes it:
--- a/pkgs/applications/version-management/git-and-tools/git-annex/default.nix
+++ b/pkgs/applications/version-management/git-and-tools/git-annex/default.nix
@@ -35,7 +35,12 @@ cabal.mkDerivation (self: {
];
buildTools = [ bup curl git gnupg1 lsof openssh perl rsync which ];
configureFlags = "-fAssistant -fProduction";
- preConfigure = "export HOME=$TEMPDIR";
+ preConfigure = ''
+ sed -i 's/Extensions: PackageImports/Extensions: PackageImports, ViewPatterns/' git-annex.cabal
+ sed -i 's/{-# LANGUAGE TemplateHaskell, MultiParamTypeClasses #-}/{-# LANGUAGE TemplateHaskell, MultiParamTypeClasses, OverloadedStrings #-}/' Assistant/Threads/WebApp.hs
+
+ export HOME=$TEMPDIR
+ '';
installPhase = "./Setup install";
checkPhase = ''
@peti Since we're expecting a fix with the next release of git-annex
, is it ok to patch the default.nix
expression for git-annex
directly for a fix like this?
Sure, if the changes don't have to persists into the next update, it's fine to edit the expression manually.
Is this issue fixed? I was told this issue should be getting resolved soon since there is a new OS X build box and that I just needed to wait a few days, but am still having an issue. Right now I'm trying to setup a cache for my team to use, because having them all build ghc from source isn't a great option, but am not having luck getting nix to use ghc from my cache over the one on cache.nixos.org. Any idea when a fixed ghc for OS X package will appear on cache.nixos.org?
@purefn I had this issue a couple of days ago, Hydra is still serving GHC with a bad Haddock.
Perhaps it thinks it's already done the work, so doesn't bother rebuilding it?
Would be nice to trigger a rebuild then?
It's still broken for me. This issue is literally driving people away from using nix for OS X haskell development. I keep suggesting that people use nix then they run into this problem and have to spend ages rebuilding or copying over files. Eventually they just give up and do what they were doing before.
This issue also seems to be causing a number of haskell packages to fail for darwin on hydra:
http://hydra.nixos.org/build/15877320/ http://hydra.nixos.org/build/15877320/nixlog/1
I was under the impression that the update would be enough to fix it, at least that's what joelteon said.
Couldn't we at least set doHaddock to false based on platform until this is fixed?
I am not aware of any indication that the broken GHC binary for Darwin might be fixed any time soon.
It's still broken for me. This issue is literally driving people away from using nix for OS X haskell development. I keep suggesting that people use nix then they run into this problem and have to spend ages rebuilding or copying over files. Eventually they just give up and do what they were doing before.
Yeah I decided to give Nix a go yesterday and I this was the first thing I ran into, couldn't get it working. Think I'll stick with cabal sandboxes for now.
See
Using haddock version 0.14.0
in the output, where 0.14.0 is a bit more than 2 major versions behind the most recent2.14.2
.