haskell.compiler.ghc{8107{,Binary},928}: drop

[emilazy]

What can I say? I felt left out of all the fun…

This probably has issues since I don’t really know what I’m doing Haskell-package‐set‐wise, but I felt more like doing this than building another GHC 9.2 to validate #440271. It’s based on a rebased/fixed up version of #381265, which should of course land first.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[emilazy]

“GHC 9.4.8 does not have a binary” would be one of those issues, especially in light of #440410. I guess bootstrapping with a newer GHC than the one you’re building won’t work, so… they’d have to use 9.0.2 (if that works?) or else the source‐based 9.4.8?

[wolfgangwalther]

Comparing notes with my local branch on the same topic, see comments. I also have some changes in the docs to change haskell.packages.ghc92 to haskellPackages in various examples, as well as a mention of ghcName = "ghc92", which I changed to ghc910, might as well change it to ghc912 to last longer.

I think we should back out the drop of ghc924Binary for now to make progress on the remaining stuff.

Also needs a rebase, ofc.

[wolfgangwalther]

This should remove ghc-api-compat == 8.10.7 from pkgs/development/haskell-modules/configuration-hackage2nix/main.yaml (and then run maintainers/scripts/haskell/regenerate-hackage-packages.sh --fast)

[emilazy]

I should have known my attempt at getting some bonus removal fun would lead me to having to actually interact with the Haskell package stuff that frightens and confuses me.

Should I also be doing something about the integer-simple Hackage package that is, uh, marked broken? (Was any of that stuff actually working?)

[emilazy]

Why does that script want to build Nix 2.28…

Worked around with nixpkgs=flake:nixpkgs/nixpkgs-unstable; I guess you don’t want to use the CI pin because haskell-updates can bump the relevant tooling?

But then:

shion:~/Developer/nixpkgs  1  (no description set)
❭ maintainers/scripts/haskell/regenerate-hackage-packages.sh --fast
fetching path input 'path:/nix/store/ngghfaknb50axlvdnxclr6mwgkp9ym3b-source'
Obtaining Hackage data …
Generating compiler configuration …
Running hackage2nix to regenerate pkgs/development/haskell-modules/hackage-packages.nix …
hackage2nix: user error (cannot parse cabal file /nix/store/xk82157yf0986i80f19wvmwjq45jvgvf-unpacked-cabal-hashes/pty-mcp-server/0.0.5.0/pty-mcp-server.cabal)
hackage2nix: user error (cannot parse cabal file /nix/store/xk82157yf0986i80f19wvmwjq45jvgvf-unpacked-cabal-hashes/pms-ui-response/0.0.4.0/pms-ui-response.cabal)
hackage2nix: user error (cannot parse cabal file /nix/store/xk82157yf0986i80f19wvmwjq45jvgvf-unpacked-cabal-hashes/pms-ui-request/0.0.4.0/pms-ui-request.cabal)
hackage2nix: user error (cannot parse cabal file /nix/store/xk82157yf0986i80f19wvmwjq45jvgvf-unpacked-cabal-hashes/pms-ui-notification/0.0.3.0/pms-ui-notification.cabal)
hackage2nix: user error (cannot parse cabal file /nix/store/xk82157yf0986i80f19wvmwjq45jvgvf-unpacked-cabal-hashes/pms-infrastructure/0.0.4.0/pms-infrastructure.cabal)
hackage2nix: user error (cannot parse cabal file /nix/store/xk82157yf0986i80f19wvmwjq45jvgvf-unpacked-cabal-hashes/pms-infra-watch/0.0.3.0/pms-infra-watch.cabal)
hackage2nix: user error (cannot parse cabal file /nix/store/xk82157yf0986i80f19wvmwjq45jvgvf-unpacked-cabal-hashes/pms-infra-socket/0.0.1.0/pms-infra-socket.cabal)
hackage2nix: user error (cannot parse cabal file /nix/store/xk82157yf0986i80f19wvmwjq45jvgvf-unpacked-cabal-hashes/pms-infra-cmdrun/0.0.2.0/pms-infra-cmdrun.cabal)
hackage2nix: user error (cannot parse cabal file /nix/store/xk82157yf0986i80f19wvmwjq45jvgvf-unpacked-cabal-hashes/pms-infra-procspawn/0.0.1.0/pms-infra-procspawn.cabal)
hackage2nix: user error (cannot parse cabal file /nix/store/xk82157yf0986i80f19wvmwjq45jvgvf-unpacked-cabal-hashes/pms-domain-service/0.0.4.0/pms-domain-service.cabal)
hackage2nix: thread blocked indefinitely in an MVar operation

Is this a Darwin thing?

I’m going to push out the changes to the .yml but not actually update the .nix file until I figure out what’s going on here.

[wolfgangwalther]

Should I also be doing something about the integer-simple Hackage package that is, uh, marked broken? (Was any of that stuff actually working?)

No need to do anything here. This is just marked broken like many other hackage packages that are oold. I am working on removing these entirely from the package set.

I'm not sure whether / how the integer-simple hackage package is connected to the "compile GHC 8.10 with the integer-simple feature". I think they are unrelated, so the fact that this is broken.. just means that integer-simple doesn't work on newer GHCs - unsurprisingly.

Worked around with nixpkgs=flake:nixpkgs/nixpkgs-unstable; I guess you don’t want to use the CI pin because haskell-updates can bump the relevant tooling?

Correct, we need to use unstable cabal2nix.

Is this a Darwin thing?

I'm not sure, could be.

[sternenseemann]

The fun has to stop somewhere! Unfortunately, Hackage packages are case sensitive and the database hackage2nix uses is file system based, so it is very difficult to regenerate the package set on Darwin. (The database cabal-install uses has since added cryptographic hashes for the tarballs, so we can potentially switch to that in the future though I suspect we need to remove packages first since hashes are only tracked for packages uploaded after some point in time, it seems.)

Should I also be doing something about the integer-simple Hackage package that is, uh, marked broken? (Was any of that stuff actually working?)

integer-simple works fine, it's just bundled with GHC 8.10.7.

[emilazy]

Unfortunately, Hackage packages are case sensitive and the database hackage2nix uses is file system based, so it is very difficult to regenerate the package set on Darwin.

I do use a case‐sensitive /nix/store with a case‐sensitive temp-dir = /nix/tmp. So depending on where the database is, I could potentially make it work by setting $TMPDIR appropriately, I suppose.

[wolfgangwalther]

“GHC 9.4.8 does not have a binary” would be one of those issues, especially in light of #440410. I guess bootstrapping with a newer GHC than the one you’re building won’t work, so… they’d have to use 9.0.2 (if that works?) or else the source‐based 9.4.8?

For the fun of it, I tried both. Of course, the newer bootstrap compiler won't work :D. Also 9.0 to bootstrap 9.6 failed, because configure rejects that explicitly.

Dropping ghc928Binary doesn't seem to give us much benefit right now, I think. Dropping ghc902Binary would probably have more relevance, but that won't happen because of GHC 9.4.

[emilazy]

Sorry for stealing your branch 😆

hackage2nix needs figuring out. I don’t mind if you just run it on the two commits that touch that stuff and force‐push to my branch, though. (Good excuse to avoid ending up accidentally ending up a maintainer for an ecosystem I don’t really use any more…)

I’ve dropped the ghc924Binary stuff for now. I was wondering if it might make sense to just use the 9.4.8 source build to bootstrap those versions, though. GHC 9.4.8 is a fixture for now, and if the cross‐compiled bindists thing is done, we’ll presumably be creating our own ghc948Binarys, and we’ll want a path from 9.4.8 to all other compiler versions.

I’m not sure if we’d want to package the official 9.4.8 bindists and use those for platforms where we don’t do that, but in general I envision that the bootstrap chain would look like if lib.meta.availableOn stdenv.buildPlatform bb.packages.ghcXXXBinary then bb.packages.ghcXXXBinary else bb.packages.ghcXXX for all compilers past 9.4.8 itself. Right now, we can treat lib.meta.availableOn stdenv.buildPlatform bb.packages.ghc948Binary as just always false, because there is no such binary package yet, and we don’t have to worry about the length of the bootstrap chain much because these compilers aren’t used for much in Nixpkgs anyway.

We can have that discussion on a separate PR to drop the bindist, but does that make sense to you?

[emilazy]

FWIW, my preference is to land this before #440774 (or #440273 if the unpins get moved there), just to reduce some of the churn and save me from having to test the 9.2 build. So if any of this is controversial / not ready to land ASAP it’d be good to know so I can plan appropriately.

[wolfgangwalther]

my preference is to land this before #440774 (or #440273 if the unpins get moved there)

Mine as well.

hackage2nix needs figuring out. I don’t mind if you just run it on the two commits that touch that stuff and force‐push to my branch, though. (Good excuse to avoid ending up accidentally ending up a maintainer for an ecosystem I don’t really use any more…)

Can do, and also run treefmt while at it.

[emilazy]

Can do, and also run treefmt while at it.

Thanks. (Sorry, I need to set up an alias to jj fix my commits before they get pushed; relying on CI for reasonable eval timing makes my Nixpkgs workflow sloppy…)

[emilazy]

FWIW, my preference is to land this before #440774 (or #440273 if the unpins get moved there),

(Er, I meant #440271 here. But now there should be no textual conflict between the two, as the LLVM pinning changes will be moved to #440273. So I’d still like to see this land soon so I can rebase #440273, or else know that it won’t land soon. Of course, I’ll also rebase #440774 once the master‐targeting churn is merged and makes its way to haskell-updates.)

[wolfgangwalther]

LGTM; here's the diff of the changes I made, if you want to double check: https://github.com/NixOS/nixpkgs/compare/47535768ad5fc10f72e2db33a6e2c2bcdb356bd6..a5e9d9ce6f011e9b7e620d17d6c745d5a36bab96

addressed

[emilazy]

Everything good to move forward with merging this and #440271 so I can rebase #440273, then?

[wolfgangwalther]

I'm happy with this one here, if we find anything else to cleanup we can do so later.