Unable to install GHC head version #93
Comments
|
It's using deb9 because that's what was used at the time and iirc was closest to the ubuntu 18.04 that was the default? It's a bit of a hacky hardcoded url and it'd be nice if it was supported "natively" with ghcup rather than taking advantage of knowing the right magic gitlab url to grab a CI job, but that's fine. I'll update the url soon (or a PR would be equally welcome) |
- Looks like automake is no longer bundled with the Windows
environment, so that has to be installed explicitly.
- The meaning of "ghc head" appears to have changed and no longer
pulls from ppa:hvr/ghc. Given that there is a bug with this new
feature ( haskell/actions#93 ), we may as
well just switch everything to latest, which is a little more stale
but probably better supported.
- Looks like autoconf and automake are no longer bundled with the
Windows environment, so they need to be installed explicitly. In
particular, autoconf is NOT a run-time dependency of automake in
MSYS2, so both need to be specified.
BTW, the pacman command needs to be in a new GitHub Action step
because the addition of MSYS2 to GITHUB_PATH needs to take effect.
- The meaning of "ghc head" appears to have changed and no longer
pulls from ppa:hvr/ghc. Given that there is a bug with this new
feature ( haskell/actions#93 ), we may as
well just switch everything to latest, which is a little more stale
but probably better supported.
- Looks like cabal v1-update no longer exists. This command doesn't
seem to differ too much between v1 and v2, so I think it's OK to
just drop the version prefix.
|
A potential future solution for this might be via ghcup release channels, as suggested in #108 (but that would require GHC CI to generate a ghcup metadata file at a well-known URL). As an alternative, how about leaving the weird hard-coded URL decision to the user, by making the GHC download URL an input (and even dropping explicit HEAD support?). I.e., leave it to the user to set which would translate into a call of |
|
I like that. The behavior could depend entirely on if If we're going to do that, it might be nice to potentially support ghc-download-url as either a string or an object so that windows/linux/macos URLs can be specified. But that might be better done indirectly by supporting ghcup release channels? |
|
@robx wrote: This URL is broken as of today (2022-12-22): $ wget https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-deb10-linux-integer-simple.tar.xz?job=validate-x86_64-linux-deb10-integer-simple
--2022-12-22 12:16:10-- https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-deb10-linux-integer-simple.tar.xz?job=validate-x86_64-linux-deb10-integer-simple
Resolving gitlab.haskell.org (gitlab.haskell.org)... 145.40.64.137
Connecting to gitlab.haskell.org (gitlab.haskell.org)|145.40.64.137|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2022-12-22 12:16:12 ERROR 404: Not Found.(Same for This issue has a new reincarnation here: Please continue discussion there. |
|
Solved by #279. |
The following error occurs (https://github.com/composewell/streamly/runs/5014667413?check_suite_focus=true):
The deb9 install link that it is using does not work manually as well. However, the following deb10 link works:
Not sure why it is using deb9, gitlab runners do not even have any deb9 based ubuntu I guess.
The text was updated successfully, but these errors were encountered: