cabal2nix evaluation failures #73
Comments
|
Hey Gabriel, thanks for the report. The problem is in this line: static-haskell-nix/survey/default.nix Line 460 in d24dea3 The issue here seems to be that, probably via Now I just need to find out what to do about it... |
|
It's going to be this: {
zlib = (super.zlib.override {
static = true;
shared = false;
# Don’t use new stdenv zlib because
# it doesn’t like the --disable-shared flag
stdenv = super.stdenv;
}).static;
}This was already accidentally fixed in nixpkgs master with https://github.com/NixOS/nixpkgs/pull/74485/files#diff-d125f8cf97a8da782a42f2f648415cd9L92 which removes the use of |
|
FYI @malbarbo @dtzWill @matthewbauer Check out the above and the previous two comments, it appears that we must never use |
|
When I cherry-pick that, or use nixpkgs |
|
I think I found the problem: the revision of Here is the change to the reproducing code that now instantiates successfully: let
compiler = "ghc865";
nixpkgs = builtins.fetchTarball {
url = "https://github.com/nh2/nixpkgs/archive/83fd89945d355892e0e95747c9a2c519491c1600.tar.gz";
sha256 = "05jybj66gdzdmjgawa2a72b6pf669rfb6pljhlc3lpyq6dlnw87d";
};
static-haskell-nix = builtins.fetchTarball {
url = "https://github.com/nh2/static-haskell-nix/archive/c360f2a15f6947b411ecbd7ebaea925f6dbd68df.tar.gz";
sha256 = "0y6ppiagh6dbvdhhnrq572xnw2yzn6d0gcmajrfdgdfwhsl21g95";
};
overlay = pkgsNew: pkgsOld: {
haskell = pkgsOld.haskell // {
packages = pkgsOld.haskell.packages // {
"${compiler}" = pkgsOld.haskell.packages."${compiler}".override (old: {
overrides = pkgsNew.haskell.lib.packageSourceOverrides {
dhall = "1.29";
};
}
);
};
};
};
normalPkgs = import nixpkgs {
system = "x86_64-linux";
config = { };
overlays = [ overlay ];
};
staticHaskell = import "${static-haskell-nix}/survey/default.nix" {
inherit compiler normalPkgs;
};
in
staticHaskell.all.dhall |
|
@Gabriel439 Ah that's great. Do you happen to know which I currently cannot (trivially / have not tried yet) upgrade to latest nixpkgs master because my nightly CI shows that the latest master has important Haskell packages like https://buildkite.com/nh2/static-haskell-nix/builds/341#438409a8-05e1-48a6-8000-b30d5511679f My plan so far was to wait until nixpkgs has figured that out, but if it happens to be darcs-specific (as evaluations show only the first error), we could also just disable that for now. |
|
@nh2: |
|
@Gabriel439 No I mean whether you happen to know which specific commit got rid of the infinite recursion (then I could consider picking it to not break darcs and whatever other Haskell stuff may be broken in current |
|
Sorry, that was for the |
|
Looking into this, I hit NixOS/nixpkgs#83825, but you already took care of that.
@Gabriel439 That doesn't work for me: |
|
@nh2: Yeah, I didn't get that far yet (I got stuck on the |
|
@nh2: Also, for that specific error you can probably fix it by |
Thanks, that's what I needed indeed.
I bisected it; it is commit NixOS/nixpkgs@2645e1a by @madjar that fixed it, merged as part of NixOS/nixpkgs#82345. Cherry-picking it on top of my current |
@Gabriel439 What's your plan for that? I'm pretty sure that these days you can use the nix sandbox and nix-daemon also on non-NixOS. |
|
I now got stuck at a This was reproducible every time. This worked around it: Very suspicious. Edit: Probably this: cachix/cachix#251 (comment) |
|
The next error I encounter is due to |
Problem: As soon as I try to fix that with (edit: actually it needs 2 patches) diff --git a/pkgs/development/libraries/kerberos/krb5.nix b/pkgs/development/libraries/kerberos/krb5.nix
index 42965c0ad07..8ec04e313f9 100644
--- a/pkgs/development/libraries/kerberos/krb5.nix
+++ b/pkgs/development/libraries/kerberos/krb5.nix
@@ -1,4 +1,5 @@
{ stdenv, fetchurl, pkgconfig, perl, yacc, bootstrap_cmds
+, fetchpatch
, openssl, openldap, libedit, keyutils
# Extra Arguments
@@ -22,6 +23,14 @@ stdenv.mkDerivation rec {
sha256 = "121c5xsy3x0i4wdkrpw62yhvji6virbh6n30ypazkp0isws3k4bk";
};
+ patches = [
+ (fetchpatch {
+ url = "https://github.com/krb5/krb5/commit/b009cca2026b615ef5386faa4c0230bc27c4161d.patch";
+ name = "krb5-Fix-typo-in-musl-build-fix.patch";
+ sha256 = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
+ })
+ ];
+
outputs = [ "out" "dev" ];
configureFlags = [ "--with-tcl=no" "--localstatedir=/var/lib"]I get Perhaps the fix of NixOS/nixpkgs@2645e1a just made us lucky by removing something similar to |
PR in https://github.com/benaco/benaco/issues/1196 |
|
The next nixpkgs Details from
|
|
@nh2: Also, is there any reason why Hydra's CI does not check that these things build correctly? It seems like it would make your life easier if people couldn't introduce nixpkgs changes that break musl builds |
|
@nh2 Here's the PR where the boot compiler was updated: NixOS/nixpkgs#83048 As far as I know, no one is testing that GHC builds with musl when merging in things like this. For testing things like this, is there some attribute I can give to ofborg to test stuff like this? For example, on NixOS/nixpkgs#83048, should I have run something like |
|
@nh2 I've deleted the offending store path, make sure to use Cachix 0.3.7 as it avoids this rare but quite annoying problem :) |
@Gabriel439 Absolutely, it would make it a lot easier. I guess it would double the amount of building that Hydra would have to do. I imagine in the future we can gather enough musl supporters or infrastructure to make it happen nevertheless. |
@cdepillabout That's probably right!
I think that would work, yes. The only problem with ofborg is that it limits builds to 3600 seconds or so. So some larger builds may not complete. What I'd really want would be to hook my community-sponsored builder into the PR/ofborg infrastructure and have it automatically build the relevant musl musl things. But ofborg currently does not support that. |
@domenkozar Thank you! I'm on 0.3.7 now. |
|
Using a MWE #include <stdio.h>
int main() {
FILE *f = fopen("conftest.out", "w");
return ferror(f) || fclose(f) != 0;
}Compiling with (That
|
|
NixOS/nixpkgs#49071 might be our issue here? |
|
After chasing issues down, it looks like NixOS/nixpkgs#84741 fixed this problem, and applying NixOS/nixpkgs@acfccf7 to |
|
Cloning Aura & running |
This is a revamp of our use of [fully static Haskell executables](NixOS/nixpkgs#43795). The main changes are: * We can now use a newer revision of Nixpkgs The current revision we're using corresponds to Nixpkgs 20.03 * We can now more easily update Nixpkgs The logic in this repository more closely tracks how `static-haskell-nix` works, so whenever that repository updates Nixpkgs we can pick up the change here, too. Note that we cannot currently use Nixpkgs `master` due to [this issue](NixOS/nixpkgs#85924), but once that is fixed when we can track Nixpkgs `master` more freely. * We no longer need to keep track of separate Nixpkgs revisions for static vs. non-static builds The two builds can also share dependencies, too. Only the top-level derivations differ now. The reason that this doesn't use `static-haskell-nix` directly is because of [`cabal2nix` evaluation failures](nh2/static-haskell-nix#73), so this change works by lifting just the minimum logic that we need from the `static-haskell-nix` repository until we can finally use that repository (or Nixpkgs directly when it's upstreamed).
This is a revamp of our use of [fully static Haskell executables](NixOS/nixpkgs#43795). The main changes are: * We can now use a newer revision of Nixpkgs The current revision we're using corresponds to Nixpkgs 20.03 * We can now more easily update Nixpkgs The logic in this repository more closely tracks how `static-haskell-nix` works, so whenever that repository updates Nixpkgs we can pick up the change here, too. Note that we cannot currently use Nixpkgs `master` due to [this issue](NixOS/nixpkgs#85924), but once that is fixed when we can track Nixpkgs `master` more freely. * We no longer need to keep track of separate Nixpkgs revisions for static vs. non-static builds The two builds can also share dependencies, too. Only the top-level derivations differ now. The reason that this doesn't use `static-haskell-nix` directly is because of [`cabal2nix` evaluation failures](nh2/static-haskell-nix#73), so this change works by lifting just the minimum logic that we need from the `static-haskell-nix` repository until we can finally use that repository (or Nixpkgs directly when it's upstreamed).
Here's the reproduction:
Here's the evaluation failure:
I believe this is not the same thing as #9 since that is a build failure whereas this is an evaluation failure.
The text was updated successfully, but these errors were encountered: