Hey everyone.

stackage nightly switched to ghc 9. Something we don‘t feel quite ready for. So I force pushed to switch to stackage LTS.

I am sorry for the fixes that had already happened. I have them saved locally so I can cherry-pick them, when they are necessary.

Is LTS on 8.10.5?

No, LTS is on 8.10.4, but I don‘t think that matters.

I guess they ran into the same issues as we did, as they also seem to care about tests.

@roberth With the bump to newest cachix, I think we can remove the custom cachix patch? At least it doesn‘t apply anymore. But without it I get compile errors on hercules-ci-agent. I guess it’s better you have a look at it.

Last other outstanding issue now are rel8 tests on darwin.

Hey @roberth, thank you for fixing that build error.

One remark just to be sure for the future. We now do hackage bumps more rarely, we try to do one bump at the beginning of the merge window and then stabilize everything. Doing random bumps in between has the danger of breaking new stuff. This time the risk was very low because I had done a bump just a few hours before, but in general

please don‘t just bump Hackage before coordinating with the person opening the haskell-updates PR.

please don‘t just bump Hackage before coordinating with the person opening the haskell-updates PR.

Noted. This time I had to make 4 releases, and based on the commits in the PR I inferred running those scripts was the way to go. Next time I'll ask.

Instead of the automatic commits, is git add --patch a good way to do it in the future?

Partial updates via hackage2nix won't work at all, unfortunately. Because running regenerate-hackage-packages.sh will revert the changes, unless all-cabal-hashes is updated as well. Thus updating only certain packages is only really possible via overriding at the moment.

I have been toying with a script to freeze the version bounds from hackage at a certain point in time which we would allow us to:

• Update all-cabal-hashes as we please
• Update certain packages beyond the freeze
• Update all of hackage by just deleting and regenerating the freeze

This would especially be great for the stable branch, so my proposal would be to experiment with that there first. (Also I'll have to find the time to actually do it).

I have this error:

$ nix -L build nixpkgs#haskell.packages.ghc901.haskell-language-server
error: attribute 'hlint_3_3_0' missing

       at /nix/store/b50frxkg7qzhsiinp6bd45n20jy1hjl2-source/pkgs/development/haskell-modules/configuration-ghc-9.0.x.nix:109:11:

          108|   # hlint 3.3 needs a ghc-lib-parser newer than the one from stackage
          109|   hlint = super.hlint_3_3_0.overrideScope (self: super: {
             |           ^
          110|     ghc-lib-parser = overrideCabal self.ghc-lib-parser_9_0_1_20210324 {
(use '--show-trace' to show detailed location information)

git blame points to a5052e1

As a quick fix, does this help?

diff --git a/pkgs/development/haskell-modules/configuration-ghc-9.0.x.nix b/pkgs/development/haskell-modules/configuration-ghc-9.0.x.nix
index 7731c73f0f6..20c64dbbccf 100644
--- a/pkgs/development/haskell-modules/configuration-ghc-9.0.x.nix
+++ b/pkgs/development/haskell-modules/configuration-ghc-9.0.x.nix
@@ -106,7 +106,7 @@ self: super: {
   retry = dontCheck super.retry;

   # hlint 3.3 needs a ghc-lib-parser newer than the one from stackage
-  hlint = super.hlint_3_3_0.overrideScope (self: super: {
+  hlint = super.hlint_3_3_1.overrideScope (self: super: {
     ghc-lib-parser = overrideCabal self.ghc-lib-parser_9_0_1_20210324 {
       doHaddock = false;
     };

@expipiplus1 yes, thanks! hlint now compiles, sadly haskell-language-server now stumbles upon:

@nix { "action": "setPhase", "phase": "configurePhase" }
configuring
configureFlags: --verbose --prefix=/nix/store/kp3vx1q1jr7gqh4p0izrzk3l751qz85b-ghc-api-compat-8.6 --libdir=$prefix/lib/$compiler --libsubdir=$abi/$libname --with-gcc=gcc --package-db=/build/package.conf.d --ghc-o
Using Parsec parser
Configuring ghc-api-compat-8.6...
Dependency ghc >=8.6: using ghc-9.0.1
Source component graph: component lib
Configured component graph:
    component ghc-api-compat-8.6-KZOn2hm6zj4DG9FVVGrAMa
        include ghc-9.0.1

Error:
    Problem with module re-exports:
      - The module 'GHC.Hs.Types'
        is not exported by any suitable package.
        It occurs in neither the 'exposed-modules' of this package,
        nor any of its 'build-depends' dependencies.
      - The module 'GHC.Platform.ARM64'
        is not exported by any suitable package.
        It occurs in neither the 'exposed-modules' of this package,
        nor any of its 'build-depends' dependencies.
      - The module 'GHC.Rename.Binds'
        is not exported by any suitable package.
        It occurs in neither the 'exposed-modules' of this package,
        nor any of its 'build-depends' dependencies.
      - The module 'GHC.Rename.Source'
        is not exported by any suitable package.
        It occurs in neither the 'exposed-modules' of this package,
        nor any of its 'build-depends' dependencies.
      - The module 'GHC.Rename.Types'
        is not exported by any suitable package.
        It occurs in neither the 'exposed-modules' of this package,
        nor any of its 'build-depends' dependencies.
      - The module 'GHC.Iface.Utils'
        is not exported by any suitable package.
        It occurs in neither the 'exposed-modules' of this package,
        nor any of its 'build-depends' dependencies.
      - The module 'GHC.Driver.Packages'
        is not exported by any suitable package.
        It occurs in neither the 'exposed-modules' of this package,
        nor any of its 'build-depends' dependencies.
    In the stanza library

Huh, I don‘t completely understand this error message, but this could actually be a packaging bug by upstream. i.e. an error in some cabal file.

Note, that not all plugins are yet supported on ghc 9.0 but I think we enable them all by default. So you will need to disable some cabal flags to have a chance for hls to compile.