tree-wide: disable doCheck and doInstallCheck where it fails

[oxij]

(the trivial part)

Motivation for this change

#33599. I implemented that issue for fun and giggles and now run a system that is "fully-tested". Turns out, not unexpectedly, an enormous number of packages fail to check. This is the first patch from that patchset. This patch disables many things that fail, but I couldn't (even partially) fix them. I.e. this patch contains only trivial doCheck = false changes and a couple of cleanups. The rest is coming later.

Note that I started documenting error messages too late, hence many changes here just disable tests without comments. I'm too lazy to repeat the effort to document the "doCheck = false; # fails" lines as rebuilding and fixing everything multiple times with 33599-patchset took almost two weeks.

Note: For most packages you won't be able to check why they actually fail with just doCheck = true; without some more patches from the patchset because the patchset adds checkTraget autodetection to stdenv.

Things done

• When combined with other patches in the series the system builds.
• Fits CONTRIBUTING.md.

---

[oxij]

For checkTarget autodetection see #39464.

[7c6f434c]

I think might be interested: @grahamc @Profpatsch @Ekleog

Have tried to check that all the cleanups are pure layout changes (toward more uniformity). I think I have read every change; the cleanups are pure cleanups.

Please remind me in a few days where few is more than a couple, if nobody merges it before.

[peti]

This PR adds doCheck = false to GHC version 8.2.2, but not to any of the other versions we have even though they'll surely need the same setting. I suppose this PR cannot be expected to be "complete" since that would be a lot of packages to compile, but still it might be worthwhile to point out that switching to doCheck = true would break a lot of packages -- even after these changes.

[Profpatsch]

Ugh, this leads to rebuilds because mkDerivation is still not declarative enough. In a perfect world this patch would be a no-op. :(

[7c6f434c]

This PR would be a rebuild anyway: there are some cleanups in the layout of the shell script parts of some expressions.

[oxij]

@peti

This PR adds doCheck = false to GHC version 8.2.2, but not to any of the other versions we have even though they'll surely need the same setting.

Interestingly, no, at least not for the older ones. I compiled a bunch of them and only this one was broken for some reason.

I suppose this PR cannot be expected to be "complete"

This PR is maybe a third of all the changes. And even then I didn't try to recompile every single thing, so there are going to be errors even after (and if) the whole patchset is merged.

Also I wouldn't recommend switch doCheck to true for Hydra by default (unless we make that into an impurity), but ofborg could totally do selective doCheck by default.

@7c6f434c

This PR would be a rebuild anyway: there are some cleanups in the layout of the shell script parts of some expressions.

In the perfect world mkDerivation would normalize shell scripts that that would be a noop too :)

[7c6f434c]

This PR is maybe a third of all the changes. And even then I didn't try to recompile every single thing, so there are going to be errors even after (and if) the whole patchset is merged.

I think breakage level below the breakage of an allegedely minor bump in a highly-used library should be considered acceptable — obviously, as a proponent of tristates I say that the current PR is useful regardless of the eventual default value of doCheck.

In the perfect world `mkDerivation` would normalize shell scripts that that would be a noop too :)

At that point we have to just go full-Guix-style with a language for builders. I mean, the builder text is accessible to the build, so technically it is possible to copy it to $out…

[7c6f434c]

@peti do I understand your comment as «not complete but an OK step in the general direction»? Looking at the feedback I am inclined to just merge it before we get a formatting-based merge conflict or something like that.

[peti]

@7c6f434c, yes, sure. I am happy with the direction of this PR.

[oxij]

Nice. I updated #39464 with most of the infrastructure. See the OP there.