@cdepillabout Any hints on where to look regarding the issue of the missing lsp-test that ofborg complains? This prevents me from starting my own CI build of all packages.

@mgttlinger Ah, I'm pretty sure that the lsp-test thing is unrelated to this PR, and instead caused by one of the normal haskell package set updates. You should be able to ignore it for now.

Also, I thought about this a little more, and it might be asking too much to have you run this against all unbroken packages.

Why don't you take this off "draft" and we'll see what @peti has to say about merging it.

I set a decent machine as CI runner who will compile all packages over the weekend (hopefully) so that should be fine.

How should I ignore that lsp-test thing? It prevents your script from evaluating?

How should I ignore that lsp-test thing? It prevents your script from evaluating?

Oh, I see.

If you wanted to figure out what the problem is, you could grep for where lsp-test_0_8_2_0 is used somewhere in pkgs/development/haskell/ and fix it so it is no longer broken.

The haskell-updates branch gets automatic updates to Haskell packages from Hackage. For packages that are in Stackage LTS, but also have a later version Hackage, two versions of the package get created. So the normal lsp-test package is probably the normal version from Stackage LTS, while a later derivation matching the latest version on Hackage is also created. It appears to used to be named `lsp-test_0_8_2_0.

What probably happened is that the automatic updates to haskell-updates created a more recent version of lsp-test, probably called something like lsp-test_0_9_0_0 or something.

What you can do is to find where lsp-test_0_8_2_0 is incorrectly being used and update it to use lsp-test_0_9_0_0. This will hopefully work.

If you find that this fixes everything, we'd really appreciate if you send a PR to the haskell-updates branch with your fix.

These types of problems happen every once in a while, and we are really grateful with any help we can get fixing things.

Ok I fixed that in #76087 but now I am unable to build all packages given that something which is not marked broken apparently depends on something broken.

I am unable to build all packages given that something which is not marked broken apparently depends on something broken.

I think I understand what is going on, but unfortunately I don't have any good ideas on ways to fix this for you.

For any given package, you might be able to discard it from your list of packages to test if one of it's transitive dependencies is marked broken.

This might require a substantial change to the script I wrote though.

@peti Do you want to make a call on whether or not to merge this in?

I'm slightly in favor of merging it in as-is, and fixing up any breakage later.

Merged in 14f29c4.

The Hydra evaluation https://hydra.nixos.org/eval/1562201 will show what effect this change has on the package set.

The change breaks builds with ghc-8.4.4, presumably because the older compiler ships a version of haddock that does not support this flag. See the Hydra build logs I mention above for more details. We cannot merge the change as-is, I'm afraid. There needs to be some version guard added to the patch.

I see. Any pointers howto accomplish such a version check? I'll try to fix this tomorrow if I manage to figure out how to do that.

@peti Thanks for creating an evaluation on Hydra for this. It was easy to see what ended up breaking.

@mgttlinger If you look in the generic-builder.nix file, you can see a couple different version checks for the ghc version.

Here's one you could use as an example:

(You'll of course be checking for 8.6 instead of 8.4 though)

@peti @cdepillabout Anything else I should do here or is this good now?

@mgttlinger Could you instead add the condition on the doHaddockQuickJump function argument?

That will make it easier for people to override (in case they are doing something tricky like using a recent version of haddock with an older compiler). It is also similar to how a lot of the other arguments work.

Once you make this change, I will test it out.

@cdepillabout Done

@mgttlinger Thanks!

Using this PR, I built the docs for conduit, and the doc-index.json file (which I believe is created with the --quickjump option) was created as expected:

$ nix-build -A haskellPackages.conduit.doc
/nix/store/p6jlyqnxshc85z1d6a8vgkil3aw3my2a-conduit-1.3.1.2-doc
$ find /nix/store/p6jlyqnxshc85z1d6a8vgkil3aw3my2a-conduit-1.3.1.2-doc/ -name doc-index.json
/nix/store/p6jlyqnxshc85z1d6a8vgkil3aw3my2a-conduit-1.3.1.2-doc/share/doc/conduit-1.3.1.2/html/doc-index.json

I then tried building dlist with ghc-8.4.4 and it appears to not have the doc-index.json file:

$ nix-build -A haskell.packages.ghc844.dlist.doc
/nix/store/djihj1a0aimi79ahnlwny02rww6vf3d6-dlist-0.8.0.7-doc
$ find /nix/store/djihj1a0aimi79ahnlwny02rww6vf3d6-dlist-0.8.0.7-doc -iname doc-index.json
$ # no results

@peti I think this should be good to merge in, but you might want to just cherry-pick the three relevant commits:

• a6ec12d
• b14b358
• 0533844

Should I fix the conflicts with the main branch or is that unneeded given that it seems the relevant changes have already been included in the above force pushed commits?

No need to fix anything. Thanks!