Open Atemu opened 2 years ago
sternenseemann
commented
2 years ago We are aware of this and it is not possible to fix this (downstream) at the moment, since GHC itself is incapable of producing deterministic compilation results (see e. g. the wiki page on the problem).
I've seen claims that certain flags can improve the situation, but seemed quite snakeoily impractical to me so far.
Edit: Relevant GHC tickets:
sternenseemann
commented
2 years ago Also inclined to close this, since it is basically non-actionable.
Artturin
commented
2 years ago Putting (haskell set | all sets) in to their own category on r13y would be useful as then users can find actionable packages easier
sternenseemann
commented
2 years ago I've seen claims that certain flags can improve the situation, but seemed quite snakeoily to me so far.
Seems like you can get determinism (to an extent at least), but only for single threaded builds. Haskell build performance is already worse than we would like, so I don't think it's worth pursuing this (although testing how much worse it'd be might be interesting).
Putting (haskell set | all sets) in to their own category on r13y would be useful as then users can find actionable packages easier
I guess so, linking to this issue would be good. Note that also packages outside of haskellPackages, like cachix or pandoc are affected by this problem.
DavHau
commented
1 year ago I have several examples of non deterministic haskell builds. I'm not sure if this is due to the issues mentioned here or another issue.
The same derivation can sometimes fail with: This package indirectly depends on multiple versions of the same package
... and other times start to compile.
Examples (scroll down on the page to see logs of different build attempts):
Please let me know in case I should open a new issue to track this.
sternenseemann
commented
1 year ago This is about GHC not producing deterministic native code, this seems related to Cabal, if a bug at all.
raboof
commented
1 year ago Also inclined to close this, since it is basically non-actionable.
Do we have a policy on whether we close nixpkgs issues when it is an upstream problem? I'd kind of like to keep it open, since it makes the reference to https://gitlab.haskell.org/ghc/ghc/-/issues/12935 easier to find :).
(of course this doesn't mean we should start copying issues from all upstream project issue trackers to nixpkgs issues - that would be silly - but keeping this here seems useful to me)
baloo
commented
1 year ago That seems to be fixed in ghc 9.4.1
sternenseemann
commented
1 year ago Seems like people get decent results with -j1, but I'm afraid that the performance hit is not worth it. Given that most packages are built with -j2 on Hydra, testing it could be interesting. Even then forcing -j1 on downstream users may be problematic.
For GHC we'll definitely not be able to pass -j1 (if that's even enough to get it to be deterministic).
raboof
commented
1 year ago That seems to be fixed in ghc 9.4.1
What do you mean by 'that'? https://gitlab.haskell.org/ghc/ghc/-/issues/12935 is still open, and the first package I tried, haskell.packages.ghc94.pem, still isn't reproducible.
Seems like people get decent results with
-j1, but I'm afraid that the performance hit is not worth it.
Yeah, that seems like a bit of a sledgehammer. It's interesting to note that some Haskell packages appear to be reproducible.
nixos-discourse
commented
1 year ago This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/new-nixos-reproducible-builds-overview-page/28046/3
Describe the bug
A clear and concise description of what the bug is.
In the GNOME ISO r13y report you can see a ton of haskellPackages that are not deterministic.
Judging by this, it looks like label names are somehow a bit random sometimes?