03:28 <tnks> I'm not sure what changed, but I feel like before, I'd be able to `nix show-derivation` to check a materialization, and it wasn't fast, but it didn't have to build a ton of Haskell. But now... that same action is building quite a lot.

03:32 <tnks> My gut feeling is that less things changed in code, but that your CI didn't cache something with recent changes.

03:42 <tnks> I just noticed what I think is `haskell-language-server` in the haskell.nix build. Are you building and caching the GHC versions in the table? Because if so, then I think my `nix-haskell-hls` project should align with the haskell-language-server in there to get a cache hit.

03:55 <tnks> Man... cruising around the code, I had no idea that you could do "latest" for a hackage build. That is so convenient, because I was looking this stuff up all the time.

04:50 <tnks> Anyway, I appreciate help figuring out how to check this materialization without having to build so much.

04:51 <tnks> I suppose I could bisect haskell.nix to find out when this problem occurred. So much work, though, to do that.

05:53 <tnks> Okay, so I'm noticing that to check the materialization of what I'm actually trying to build, it's also checking the materialization of the dummy-ghc. But not sure the latter is why it's building all these uncached things.

05:54 <tnks> I mean... where in the world is hnix coming into play?

05:55 <tnks> ah man... am I building nix-tools?

05:56 <tnks> I think that's it. I think I'm getting a cache miss on nix-tools. Hopefully not GHC as well, though.

05:56 <tnks> I'm only trying to do a `show-derivation` to check the materialization. After that I was going to let GitHub Actions do the real build.

09:36 <michaelpj> tnks: you're probably building nix-tools. Note that for cabal projects those also get built with your GHC and index-state to avoid having too many duplicate dependencies, so you may be less likely to get cache hits. You should make sure you build `project.roots` in your CI, because that pins all the stuff that's needed at eval-time

09:39 <tnks> michaelpj: I was relying on what IOHK is building. I turned out an update of Haskell.nix with a recent index-state got me hitting IOHK's cache again.

09:40 <tnks> For now, I'm just going to settle for what GHC versions IOHK is building, testing, and caching. I could support more with my own CI, but I kind of don't want to.

09:52 <michaelpj> yeah, building your own GHCs sucks

14:08 <tnks> Okay... I just noticed that the `updateMaterialized` script is now available as a passthru, so I can `nix run` it. This is great!

14:11 <__monty__> Ah, how do you call it? I've been piping to bash >.<

14:18 <tnks> `nix run --file . myPackageAttr.updateMaterialized --command updateMaterialized` is what I'm trying. But I seem to be building ghc this way. :(

14:21 <michaelpj> that seems odd

19:40 <__monty__> Trying to build xmonad-contrib. It's failing because of a missing header from libXss. How do I provide this? Should haskell.nix pick up the right C dependencies from the cabal file or something?

19:44 <__monty__> Ah, looks like I'm in luck and the docs happened to have an example precisely for the X11 package.

20:47 <michaelpj> hmm, I thought we fixed a bunch of the missing X libs recently

21:46 <__monty__> My pin is probably over a month old.