ENH Fix musl64 bzip2

[luispedro]

Without this patch, I get build errors related to -lbz2 not being found when building NGLess in static mode:

/nix/store/xbi3yw5aj1fxf1vckmb6mf9n8k16a73y-x86_64-unknown-linux-musl-binutils-2.40/bin/x86_64-unknown-linux-musl-ld: cannot find -lbz2: No such file or directory

[angerman]

@luispedro which nixpkgs verison are you using? I'm a bit confused as to the conditional check not holding. While I will say that I've encountered the same issue before.

[luispedro]

This is using the version of nixpkgs that is used by haskell.nix. The relevant code is

  sources = {
    haskellNix = builtins.fetchTarball {
      name = "haskell-nix-snap";
      url = "https://github.com/input-output-hk/haskell.nix/archive/c689f01730e5b6c6c16d3947a15689569844c38c.tar.gz";
      sha256 = "09lw2419a5dd9g0ja31hjfqf6d4bzcgr5mrqx0vrvlksmp7a1kzk";
    };
  };

  haskellNix = import sources.haskellNix { };
  # Import nixpkgs and pass the haskell.nix provided nixpkgsArgs
  pkgs = import
    # haskell.nix provides access to the nixpkgs pins which are used by our CI,
    # hence you will be more likely to get cache hits when using these.
    # But you can also just use your own, e.g. '<nixpkgs>'.
    haskellNix.sources.nixpkgs-unstable
    # These arguments passed to nixpkgs, include some patches and also
    # the haskell.nix functionality itself as an overlay.
    haskellNix.nixpkgsArgs;

This works well for standard (dynamic link) packages, but is failing for static link (except when I add that patch)

[angerman]

@luispedro after quite a bit of prodding this with @hamishmack, can you try building your static component with

projectCross.musl64.pkgsStatic.hsPkgs.NGLess.components.exes.ngless

instead of

projectCross.musl64.hsPkgs.NGLess.components.exes.ngless

Because (on x86_64-linux) musl can be dynamic it defaults to dynamic in nixpkgs, unless you explicitly request musl64.pkgsStatic.

[luispedro]

Thanks for the suggestion. I cannot get it to work, though:

projectCross.musl64.pkgsStatic.hsPkgs.NGLess.components.exes.ngless

does not exist:

error: attribute 'pkgsStatic' in selection path 'projectCross.musl64.pkgsStatic.hsPkgs.NGLess.components.exes.ngless' not found

There is projectCross.musl64.pkgs.pkgsStatic, but it does not have an hsPkgs key (i.e., accessing projectCross.musl64.pkgs.pkgsStatic leads to error)

[hamishmack]

This PR will revert #2117

I think maybe the cut-off version in #2117 was set to 23.05 because 23.11 was not out yet.

If you are using nixpkgs 23.05. Does changing:

prev.lib.versionOlder prev.lib.trivial.release "23.05"

to

prev.lib.versionOlder prev.lib.trivial.release "23.11"

Work? I think that might be the correct change.

CC @jonringer

[hamishmack]

projectCross.musl64.pkgsStatic.hsPkgs.NGLess.components.exes.ngless

does not exist:

We should fix that.

For now you might need refactor your code to use pkgsCross instead of projectCross and do something like:

pkgs.pkgsCross.musl64.pkgsStatic.haskell-nix.cabalProject ...

[angerman]

Should we deprecate projectCross?

[jonringer]

Correct, at the time, the breaking change was on unstable roughly half way between releases. We can bump it now that 23.11 has been released.

[angerman]

now it's in both?

[hamishmack]

Well // would have replaced bzip2, but I have refactored it to make it clearer and added a comment.

[angerman]

LGTM

[hamishmack]

I think we need #2156 to fix the failing tests.

[jonringer]

I'm still super impressed by the granularity of your hydra CI 👀

[angerman]

I'm still super impressed by the granularity of your hydra CI 👀

you want it less granular? I with GH would allow filtering of succeeded/failed builds.

Btw, all of our hydra modifications are open.

The ci.zw3rk.com is still running the legacy from https://github.com/zw3rk/hydra-tools (just bare bones),
The ci.iog.io is a bit further advanced, and in https://github.com/input-output-hk/hydra-tools (including a GH App)

[michaelpj]

I think he's maybe just impressed by the 5.7k derivations that get built 😂

[jonringer]

I'm impressed that the number of checks scale in proportion to the downstream builds.

Still stuck in docker-based CI land for other things 😢