Allow GHCup to build & run on OpenBSD #1138
Conversation
habibalamin
changed the title
|
@habibalamin You need to rebase against master. Please let me know if there's anything else blocking you. |
|
@habibalamin we're planning a new release... before the end of the year. Do you think we can get this in? |
|
Hey, yeah sorry. I'll try and get that done in a bit. You might be interested to hear that Greg Steuck and I finally got GHC working to run on and produce (seemingly working) binaries for OpenBSD/arm64, by cross-compiling from OpenBSD/amd64. It should, God willing, land in the OpenBSD 7.7 release, which is the upcoming one. |
`libarchive` (the Haskell package, not its upstream C library) vendors the `config.h` header files generated by autoconf for each platform it supports instead of using autoconf (or even CMake, which the C library offers as an option). So apart from those specific platforms, just use `tar` & `zip`. `lzma-static` currently does the same, but we're gonna fix it upstream then update the minimum version bounds on our dependency of it.
habibalamin
force-pushed
the
add-openbsd-support
branch
from
1905069
to
0273670
Compare
| "mingw32" -> pure PlatformResult { _platform = Windows, _distroVersion = Nothing } | ||
| what -> throwE $ NoCompatiblePlatform what | ||
| lift $ logDebug $ "Identified Platform as: " <> T.pack (prettyShow pfr) | ||
| pure pfr | ||
| where | ||
| getOpenBSDVersion = lift $ fmap _stdOut $ executeOut "uname" ["-r"] Nothing |
There was a problem hiding this comment.
Are you sure uname is the OpenBSD version and not just the kernel?
What are the outputs? Are they purely numeric? Otherwise we will have a hard time matching on them.
There was a problem hiding this comment.
I don't think the BSDs have a kernel version distinct from the OS version, since they're all developed by the same people under a single umbrella; a release is the kernel, plus base packages (userland), plus ports (package repository for that version).
I developed these changes on my real OpenBSD/amd64 machine and tested the uname -r command after reading the man page at the time.
OpenBSD's man page for uname says:
-r Print the operating system release. On OpenBSD, the format is digit.digit.
(and digit.digit is underlined, but (GitHub's) Markdown doesn't seem to support that, nor setting monospace font quote without a code block which makes things literal anyway.)
However, I just realised the man page doesn't specify, and I hadn't considered, what would happen on OpenBSD-snapshot or -current (which are non-stable tracks that some OpenBSD users do prefer)? I'm gonna check on a VM now.
There was a problem hiding this comment.
This is what I get on my -snapshot VM:
OpenBSD 7.6-current (GENERIC.MP) #243: Mon Nov 18 13:30:33 MST 2024 Welcome to OpenBSD: The proactively secure Unix-like operating system. Please use the sendbug(1) utility to report bugs in the system. Before reporting a bug, please try to reproduce it with the latest version of the code. With bug reports, please try to ensure that enough information to reproduce the problem is enclosed, and if a known fix for it exists, include that as well. You have new mail. foo# uname -r 7.6
I generally stick to release, but I do think the login message starting with 7.6-current is correct, even though it's -snapshot, because according to the docs I just checked, -current is essentially following trunk and can only be done by building from source oneself, and -snapshot is just a snapshot of -current compiled for release as non-stable.
So yeah, -r is always a release number and nothing else.
There was a problem hiding this comment.
Comments on this Reddit thread basically confirm that there's no such thing as a -snapshot track, so that was my bad; snapshots are just compiled releases of the -current track.
GHCup currently doesn't run on OpenBSD (or any platform not explicitly supported), even if it builds. This adds explicit support for OpenBSD. We may later not block it from running on unsupported platforms, even when we don't explicitly make sure our build scripts work for them or provide bindists or CI for them.
habibalamin
force-pushed
the
add-openbsd-support
branch
from
0273670
to
175da25
Compare
|
How do I test these changes? I have private freebsd runners with pots. Afaiu there is a way to have OpenBSD pots, is there? |
|
I don't understand what you mean by pots. |
|
|
I mean, the site mentions that you can use jails or VMs, so I suppose you could have an OpenBSD pot if you virtualise it, but the documentation seems to only focus on jails for now. Last I used FreeBSD, their hypervisor was far more developed than OpenBSD, and it should definitely be able to virtualise OpenBSD. |
Just clarifying why this is necessary. Is this to boot up a fresh FreeBSD runner for each CI run?, |
|
The CI runner runs inside a manually created FreeBSD jail. |
|
I tried with beehyve and beehyve-vm with no success. |
|
SourceHut supports OpenBSD latest and one version behind (multiple architectures). They have an API you can use to submit builds. I don't know if that works for you. |
|
CI is generally a waste of time without having local access to the platform, where you can do proper step-by-step analysis. VirtualBox VMs are awfully slow and waste tons of space, so I was hoping to get it done via beehyve, but it does not have good UX. So I'm not sure how much time I can invest. |
|
This page from a BSD blog I've seen before has a guide which seems decent, though I haven't tried it. They show two methods to run both FreeBSD and OpenBSD in a bhyve VM; one using stock bhyve, one using a package to make it easier to work with called vm-bhyve. |
Fix #707.
This doesn't ensure that GHCup's GHC build scripts/manifests work for OpenBSD, merely that it itself builds and runs on OpenBSD.