ghcup does not install on FreeBSD13.1
ghcup aborts during install with the following error:
13.1-RELEASE-p2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 67.3M 100 67.3M 0 0 4401k 0 0:00:15 0:00:15 --:--:-- 4608k
ld-elf.so.1: Shared object "libncursesw.so.8" not found, required by "ghcup"
"_eghcup config set downloader Curl" failed!The package ncurses is installed. I can see that it installs /usr/local/lib/libncursesw.so but not with the suffix .8.
Activity
Yes, FreeBSD support at the moment is not working well, because the FreeBSD runners on gitlab are chronically broken.
The vagrant images are outdated and cause failure to invoke cabal even. The same bug happened here: https://github.com/haskell/bytestring/pull/550
-
I'm going to be frank and say that GHC gitlab is still a disaster for me as an end user.
CI can't even build all the bindists that it used to build. This is a regression.
I'm also concerned that GHC HQ seems to think this is low priority, despite it affecting:
- cabal
- HLS
- GHCup
- Stack (yes, even stack)
It may be time to migrate all those tools away from gitlab. Because even if you eventually fix it, I don't trust that CI issues are correctly prioritized. So my builds may be affected the next day again and no one cares.
Eh... I started drafting something, but it'll have to wait because I am sick today. Maybe I can whip up something shorter.
This issue is totally the wrong place for this message, sorry
In my opinion the number one issue with GHC CI is that it is often incorrect. It generates false positives: it claims code has failed to pass when it hasn't. My current mission is to address this problem.
One strategy I am using is to reduce the number of features CI has. E.g. I am marking tests as allowed to fail without really looking into what is wrong.
In fact, I think GHC CI has overreached itself and needs to reduce features to be maintainable. This is why FreeBSD support may be a little further down the list for me. I need to fix the systemic problems before reintroducing more complexity. (I just looked. The FreeBSD runners are Vagrant machines on a box I don't have access to, which is chronically overworked anyway. I am honestly surprised to see FreeBSD bindists on the GHC downloads page.)
As for prioritization, I don't speak for GHC HQ. They are mostly paid to work on other things. CI is something they rely on but don't have time to work on. I, however, am specifically paid to work on it. If it regresses, I definitely want to fix it. It's just such a huge system with so many dark corners that it will take months for me to stabilize it. Furthermore, I am only adopting responsibility slowly and sustainably so I can stay sane.
Oh yeah, my priorities!
- GHC is the "user"/"market segment" that I want to satisfy first.
- Mitigate spurious failures
- Migrate some GitLab infrastructure to new servers (ops work due to provider migrations)
- Implement notarization for MacOS (with the assumption that this is actually a requirement for new Macs, i.e. a regression if it isn't done. I would actually put it off if that assumption turns out to be incorrect.)
- Upgrade GitLab and make upgrades routine (with the assumption that migrating to hosted GitLab is a much bigger and potentially contentious project).
- Replace chronically unreliable servers used for CI runners (if funds permit)
There's a lot more to be done, but that's already months of work so I think it's sufficient for now. And all of it is maintenance, not feature development!
Sorry for all the short sentences, my brain is fuzzy and I'm gonna drink some tea now
-
Thanks for the insights. I'm putting forward a proposal of migrating some CI and tooling to Github: https://gist.github.com/hasufell/c26f6bb1897bf98ef73a48bb1cf9a9c4
We'll discuss this tomorrow in the HLS monthly meeting.
Some of the decisions that were made when this topic came up among GHC maintainers on Tuesday:
Although FreeBSD is listed as a Tier 2 platform (https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms), that isn't very actionable information. In reality, FreeBSD builds have only been made during release --- there's no ongoing CI. We agreed that it is a meaningless guarantee and effectively FreeBSD is not supported at all. I consider that a serious miscommunication on GHC's part, and I would like to change the Platform Tier Policy to fix it.
Furthermore, the server where the FreeBSD Vagrant machines ran, which few people have access to and which continually had other reliability problems, has been removed from the CI pool. I consider that a positive step towards making CI more maintainable and usable. (I now have access to every single machine hosting CI runners on this GitLab instance.)
Next, here are some personal (i.e., my own) observations on your proposal:
The whole Haskell ecosystem starts with the compiler, which is why I'm focusing on fixing problems there first. But my real mission is the ecosystem. I think with some time and coordination, we can make Haskell (not just GHC, but also the other tools!) support a wide range of platforms, and I mean really support them. But that, of course, that would mean that CI for the various systems get more integrated.
And on that note, I'm sticking with GitLab because it's already where GHC is, it's what I know best, and I am not yet ready for Microsoft to own every aspect of my life as a developer. By the same token, I'm wary of lock-in and I certainly won't add more hard dependencies on GitLab specifics when I can avoid it. But nonetheless, if moving to GitHub works better for you, then I think it's the right choice! I'll still be working on GHC for a while, so do what you gotta do.
-
We agreed that it is a meaningless guarantee and effectively FreeBSD is not supported at all.
Well, GHCup will likely build its own FreeBSD bindists then.
The whole Haskell ecosystem starts with the compiler, which is why I'm focusing on fixing problems there first. But my real mission is the ecosystem.
Well, I'm not sure focussing on only a single part will make people have the confidence that their projects are taken care of here.
But if you think that will have the biggest impact on the ecosystem as a whole, who am I to argue?
And on that note, I'm sticking with GitLab because it's already where GHC is, it's what I know best, and I am not yet ready for Microsoft to own every aspect of my life as a developer. By the same token, I'm wary of lock-in and I certainly won't add more hard dependencies on GitLab specifics when I can avoid it. But nonetheless, if moving to GitHub works better for you, then I think it's the right choice! I'll still be working on GHC for a while, so do what you gotta do.
Most of Haskell ecosystem is on github. I'm confused how you can have the Haskell ecosystem as a mission, but have strong adversion against Github.
At any rate, I'm guessing that is a signal that you won't be helping with runners that we are, with the help of Moritz, connecting to github sometime soon?
I also had the impression that the Haskell Foundation as a body is actively working with GitHub to fulfill it's mission statement. I find all of this somewhat confusing, hearing this from their first employee.
But again, this might not be my business.
Edited by Julian Ospald -
I also want to point out: just because GHC HEAD does not support FreeBSD anymore, doesn't mean the entire ecosystem has stopped supporting it as well.
There are still many GHC versions that support FreeBSD and neither GHCup, cabal, nor HLS or stack can just stop having binaries for this platform. Similarly, I moved the 'filepath' package to gitlab too, which I now can't test on FreeBSD.
So if your metrics is "only keep CI for GHC HEAD" then I'm very certain that will send a signal to projects to stick with GitHub.
added typebug label
-
I'm in the process of moving GHCup to GitHub and will have access to Cirrus CI FreeBSD runners there.
Edited by Julian Ospald
