-
-
Notifications
You must be signed in to change notification settings - Fork 15.5k
haskell-language-server, stylish-haskell: Fix build on GHC 8.10.* #97744
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you change this to target the haskell-updates
branch instead of master
?
Other than the branch and the the one suggestion below, this looks good to me!
cc @maralorn and @GuillaumeDesforges
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
}: | ||
mkDerivation { | ||
pname = "ghcide"; | ||
version = "0.2.0"; | ||
version = "0.3.0"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if that's an issue in itself, but having a single update.sh makes fixing or extending with other libs (like this PR) into one non-atomic commit. While nixpkgs is a bit blurry about its "atomic changes" policy, I think it is still a good idea to split package update and build fixes.
@cdepillabout do you consider it to not be an issue?
Should this PR be split into more atomic commits manually? (my preference)
Do we change the workflow by splitting the update scripts?
Anything else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I split out the commits and added a note to update.sh to remind others to do the same. I don't think the script should be split out; you'll probably want to test the binary with all the automated updates applied, and you'll probably want to commit only after the binary works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't particularly worry about it that much. I agree that it is a good idea to have atomic changes, but there is some trade-off with making it unreasonably challenging for people to contribute.
If you don't split out your commits, I guess you run the risk of having a whole bunch of unrelated changes reverted if something in one of your commits needs to be reverted.
I would be fine with the HLS stuff all going into one commit, since it is all basically related anyway.
c3e7f4b
to
fb06974
Compare
Sorry, that was a mistake... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
If this builds, this should be fine. Thanks!
@GrahamcOfBorg build haskellPackages.haskell-language-server |
1 similar comment
@GrahamcOfBorg build haskellPackages.haskell-language-server |
Can you have another look at those tests? There seems to be a wrong hash error going on? |
I can't reproduce the
On aarch64 the hash fails to validate, but on x86_64-linux the build just... fails? I can't tell why (maybe the download failed?).
|
The failed tests are a problem with the build machines, not with the expressions. On aarch64, the wrong hash is computed for the
Sometimes accompanied by this:
There's no indication as to which dependencies actually fail, however. |
6061c5a
to
9066102
Compare
@GrahamcOfBorg build haskellPackages.haskell-language-server |
bd1911c
to
10ec99b
Compare
Ouch |
@Galagora It looks like on aarch64 #97407 still applies which means there's no working GHC on that platform so you can probably ignore it. For the hash-mismatch - a hash returned by You should be able to reproduce it locally if you delete the result of |
The patch is merged into master
0.6.2 -> 0.6.3.2
9066102
to
5175a89
Compare
There's still a hash mismatch in |
Motivation for this change
Haskell Language Server uses a fork of
brittany
that compiles on GHC 8.10.*. In addition,stylish-haskell
forgot to update theirCabal
version bounds in the test suite, causing a hard-to-debug build failure.Closes #97743.
Closes #97745.
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)