haskell.compiler.ghc963: drop#440410
Conversation
nixpkgs-ci
bot
added
10.rebuild-darwin: 501+
nix-owners
bot
requested review from
cdepillabout,
guibou,
maralorn and
sternenseemann
|
I'm always a little bit scared that using different versions of source built fallback and bindist GHC can obscure problems in the source built bootstrapping since that path is taken less. OTOH upgrading bindists is much riskier since they are more susceptible to weird issues as shown by 9.6.3… |
I'd say we update |
I pushed a commit to do that, but am still building on various systems now. |
nixpkgs-ci
bot
added
10.rebuild-linux: 501+
Unfortunately, this fails for GHC 9.8.4 on both linux archs. It works for GHC 9.8.4 on aarch64-darwin and for GHC 9.10.2 on aarch64-darwin, aarch64-linux and x86_64-linux. The errors I am getting on Linux are like this: We have multiple different options here:
WDYT? |
|
Is there a reason not to bootstrap 9.8 from the 9.8.4 binary, as is used on AArch64 + Musl? Presumably that does indeed work for Linux. |
Testing that now. |
So far, I was able to build everything that I threw at |
|
That makes sense to me. Now I’m wondering if the thing where 9.4 needs 9.0 to bootstrap got fixed and we don’t need |
wolfgangwalther
force-pushed
the
haskell-updates-drop-ghc963
branch
from
00b7721 to
83e41be
Compare
|
I replaced the "update ghc 9.6.3 bindist to 9.6.7" commit with "drop ghc 9.6.7 bindist" here. Still waiting on some builds to finish. I tested:
I did not test x86_64-darwin, yet. |
I think this was answered by @sternenseemann in #381265 (comment). Being a good citizen I still tried - and failed, ofc. So I do think we still need 9.0 to bootstrap 9.4. |
wolfgangwalther
force-pushed
the
haskell-updates-drop-ghc963
branch
from
83e41be to
51148ec
Compare
emilazy
left a comment
emilazy
left a comment
There was a problem hiding this comment.
Seems fine to me, but should this go to staging instead? It looks like it’d throw away a lot of the binaries on haskell-updates?
nixpkgs-ci
bot
added
the
12.approvals: 1
So the big thing here is visibility - and I think that plays into #427145. With the current setup of merging into staging, this significantly slows us down. If we were merging haskell-updates into master, we could potentially move much quicker, right? Edit: Which could potentially be done as early as this iteration. Which would potentially allow us to do this drop in the next iteration, and then hopefully having still enough time for @emilazy's follow up work? |
wolfgangwalther
force-pushed
the
haskell-updates-drop-ghc963
branch
from
bff1b83 to
16db36b
Compare
I rebased and will rebuild GHC 9.10.3 now, to then look into that kind of verification. |
nixpkgs-ci
bot
removed
the
2.status: merge conflict
I did the same steps of verification, here's the result: |
The schedule is here: #443568 The freeze for release critical packages is the 2025-10-04, so in 2,5 weeks. The freeze for general breaking changes one month later. So I assume we do have ~6 weeks for both this and #440774. I think that means we can either do them in this haskell-updates cycle or the next? tbh, I think it's more valuable to have this in earlier for any kind of feedback to get back to us before release, rather than have fewer changes in this cycle at once. So I'd vote to get this done ASAP. |
Two weeks, no? |
My bad, I misread "unrestrict breaking changes". With only 4 weeks to go I seriously question whether there is a good enough chance to even get this PR in in the next haskell-updates cycle. That being said, this kind of breaking change (dropping ghc minor version) is probably not too critical if we do it after the freeze date. But still... why delay it, if there is no need. |
|
I also have other things to attend to before the freeze so I would much rather be done with all this stuff sooner rather than later… (though the LLVM unbreak at least should be backportable – but if the drops happen after branch‐off then that’s more fuss…) |
I looked at the diff of one of the So this is only some ordering thing, and I would assume that the build with GHC 9.6.7 just fixed some ordering / possibly reproducibility issues. |
|
After reading through it again, it's unclear, @sternenseemann, whether you are still collecting information or whether you are blocking this PR right now. With https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#review-and-merge-conventions in mind, @sternenseemann please state explicitly whether, with all the information in this thread so far, you are blocking this PR or not. Without a "Requesting Changes" review according to the contribution guidelines I will assume you are not blocking and merge within the next two days. If you do have blocking concerns, please explicitly state them in a way that makes us be able to understand when they will be resolved. For example "Not in this haskell-updates cycle" would be clear enough to understand, so that we could merge it in the next cycle. |
|
I haven't had the time to review the relationship of this PR to the other ones by emily again. Overall, I do dislike this change, but I suppose there is not much risk involved since the source built GHCs tend to be very reliable. (I.e. I'm not concerned whether 9.6.7 and 9.6.3 produce the same result, but rather whether one may regress in the future, but not the other. For example, we may not immediately notice that 9.6.7 can't bootstrap 9.10.4 when 9.6.3 can.) Given that the bootstrap path with 9.6.7 is restricted to Darwin, I suppose it's whatever since we would see the failure eventually. Don't you think that it's better to merge this into staging? haskell-updates just means the change sits around even longer without doing anything as Darwin isn't even being built.
This is kind of annoying. I was thinking that going to 9.4.8 and 9.8.4 bindists would have been a good option for the future. |
Ah, thanks for that info, that helps shape my understanding of the potential consequences etc.
Merging into
I can try again with GHC 9.10.3 - maybe that already changed something. But I'd do that in a separate PR, not here. |
Sure. We should probably try and look into this soon since we'd ideally want to avoid |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Latest 9.6.x minor release is 9.6.7, which is also in Stackage 22.44. Thus, dropping according to the GHC Deprecation Policy. This requires to change the bootstrap for GHC 9.8.x and GHC 9.10.x on some platforms.
wolfgangwalther
force-pushed
the
haskell-updates-drop-ghc963
branch
from
16db36b to
a8e20b1
Compare
Should this really happen, and before we can figure out better bootstrap paths via GHC 9.8.4 or so, we can always go back and revert this commit. Targeted staging now, let's do it! |
Right. Instead of discussing over a darwin bootstrap path through 9.6.3 or 9.6.7 for ages, let's focus on that - that path is indeed too long, especially for the soon-to-be-default-version. Will start building a few things. |
nixpkgs-ci
bot
added
10.rebuild-darwin: 11-100
Did that in #444249. We should probably do that before or together with the haskell-updates merge to avoid that lengthy bootstrap path. |
3 participants
Latest 9.6.x minor release is 9.6.7, which is also in Stackage 22.44.
Thus, dropping according to the GHC Deprecation Policy.
This requires to change the bootstrap for GHC 9.8.x and GHC 9.10.x on some platforms.
Things done
ghc8107Binaryalready, so unrelated to this PR.Add a 👍 reaction to pull requests you find important.