Add FreeBSD and OpenBSD CI jobs to GitHub Actions - #367
Merged
Conversation
added 3 commits
August 11, 2026 10:08
Nothing has reported a FreeBSD result on this repository since 2026-05-25. The last commit carrying one is 96d65e5, which has main freebsd_instance:family/freebsd-14-3 success main freebsd_instance:family/freebsd-15-0-amd64-zfs success Each of the 18 commits after it, 8ed9501 (2026-06-10) through abd5ba4 (2026-07-24), carries 14 to 17 check-runs and commit statuses -- the two linux jobs, macos, and eleven ci/circleci contexts -- and not one freebsd context among them. So the dialect 00DIALECTS lists first, and README calls "fully maintained and tested on Cirrus CI", currently has no build or test coverage here at all. This adds a job that runs the same two build paths .cirrus.yml covered, in a FreeBSD VM on a GitHub-hosted runner, for 15.1 and 14.3: autotools autoreconf -vif; configure; make; make check legacy ./Configure -n freebsd; make; bash ./check.bash freebsd Both paths need the kernel sources. AC_CHECK_TYPES for struct lockf_entry succeeds on both releases -- the type is visible from userland through <sys/lockf.h> -- so HEADER_GENERATE always runs and cuts struct lock_owner out of ${FREEBSD_SYS}/kern/kern_lockf.c. The release images ship an empty /usr/src, so without the fetch the autotools path stops at configure: WARNING: No kernel sources in /usr/src/sys or /sys configure: error: can't read /kern/kern_lockf.c and the legacy path stops at the matching FATAL ERROR: can't read /kern/kern_lockf.c FATAL ERROR: ./lockf_owner.h creation failed (see 00FAQ) Unpacking only usr/src/sys out of the release source set takes about 15 seconds and 580MB of VM disk, so the job does that rather than cloning git.FreeBSD.org. The autotools build runs out of tree, which keeps the source tree clean for the legacy Configure run and removes the need for the "git clean -fdx ." that .cirrus.yml used between its two build paths. Verified on GitHub Actions. On both releases and both paths: make check TOTAL 21 PASS 18 SKIP 3 FAIL 0 check.bash successful: 12 skipped: 2 failed: 0 All 14 test cases are passed successfully Wall clock is 2.8 minutes for 15.1 and 3.1 minutes for 14.3, next to 3.6 minutes for the existing linux (ubuntu-24.04) job.
Configure's OpenBSD version table stops at 7.3. Anything above it falls
into the "*)" arm, which configures for LSOF_VERS=3090 -- OpenBSD 3.9,
released in 2006. On 7.9:
Unknown OpenBSD release: 7.9
Assuming OpenBSD 3.9
cc -DOPENBSDV=3090 ... -DLSOF_VSTR="7.9" ...
WARNING: unsupported dialect or version
and the classic test suite then refuses to run at all:
This suite has not been validated on:
LT_CC LT_DIAL_openbsd LT_VERS=3090
*** Error 1 in tests (Makefile:28 'all': @./CkTestDB; ...)
so bash ./check.bash openbsd exits 1.
Two things go wrong together. The "*)" arm is the only arm in the table
that does not set LSOF_TSTBIGF, so -DLT_BIGF is dropped and the big-file
test is quietly disabled; and LSOF_TSTKMEM is 0 for this dialect, so
-DLT_KMEM is absent as well. The line CkTestDB builds is therefore
LT_CC LT_DIAL_openbsd LT_VERS=3090
which matches neither the 3090 row in tests/TestDB -- that one carries
both LT_BIGF and LT_KMEM -- nor the 7020 and 7030 rows.
This adds a 7.9 arm and a 7.x catch-all written the way the 2.x and 3.x
series already are, plus the single TestDB row the result produces.
Because the catch-all puts 7.4 through 7.8 on the same LSOF_VERS as 7.9,
one row covers the whole series instead of one row per release.
OPENBSDV is not read anywhere in the C sources; grep finds it only in
Configure and 00FAQ, so no compiled code changes here. What changes is
which test flags get set and which TestDB row matches. FREEBSDV and
NETBSDV, by contrast, are both used in #if tests in their dialects'
headers.
Verified in an OpenBSD 7.9 VM on GitHub Actions.
Before:
config.cflags = -DLT_DIAL_openbsd -DLT_CC -DLT_VERS=3090
bash ./check.bash openbsd -> exit 1
After:
config.cflags = -DLT_DIAL_openbsd -DLT_BIGF -DLT_CC -DLT_VERS=7090
compiler flags: -DOPENBSDV=7090 ... -DLSOF_VSTR="7.9"
bash ./check.bash openbsd -> exit 0
successful: 14
skipped: 0
failed: 0
All 14 test cases are passed successfully
.builds/openbsd.yml last produced a passing result on 2023-11-10. The
job after that, #1520293 on 2025-06-28, failed, and nothing has run on
builds.sr.ht since; the SourceHut badge in README currently reads
"builds: failure". No sr.ht context appears on any of the last 19
commits here either, so even when those builds did run, their result was
never visible on a commit or a pull request in this repository.
This adds a job that runs the build in an OpenBSD 7.9 VM on a
GitHub-hosted runner:
autotools autoreconf -vif; configure; make
legacy ./Configure -n openbsd; make; bash ./check.bash openbsd
libtool has to come from packages. OpenBSD's base /usr/bin/libtool is a
different program and brings no GNU libtool m4 files, so without the
package aclocal cannot find LT_INIT and autoreconf stops at
Makefile.am:100: you'll need to arrange for the Libtool m4 files
Makefile.am:100: to be found by aclocal
autoreconf-2.72: error: automake failed with exit status: 1
after which the half-written configure dies with
configure[3882]: syntax error: `disable-fast-install' unexpected
.builds/openbsd.yml installs libtool for the same reason. autoconf and
automake are pinned to a package version because pkg_add reports both
names as ambiguous -- 7.9 packages eighteen autoconf versions and twelve
automake versions -- and AUTOCONF_VERSION / AUTOMAKE_VERSION have to
agree with whichever is installed.
"make check" is deliberately not run on the autotools build. It fails
tests/LTbasic2 there with "opened regular file wasn't found"; that test
is not part of the legacy suite, and the two paths end up with very
different flag sets, since configure.ac's openbsd arm sets only
LSOF_VERS while Configure also sets HASIPv6, HAS_SYS_PIPEH and
HAS_STRFTIME. That is left for a separate change.
Verified on GitHub Actions, OpenBSD 7.9:
bash ./check.bash openbsd
successful: 14
skipped: 0
failed: 0
All 14 test cases are passed successfully
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Nothing has reported a FreeBSD, NetBSD or OpenBSD result on this
repository in a long time, so the three dialects README describes as
"fully maintained and tested" have no build or test coverage here:
FreeBSD The last commit carrying a Cirrus result is 96d65e5
(2026-05-25):
OpenBSD builds.sr.ht #1091651 (2023-11-10) is the last openbsd.yml
build that passed. #1520293 (2025-06-28) failed and
nothing has run there since. The SourceHut badge in
README reads "builds: failure" today.
NetBSD Same shape: #1091650 passed 2023-11-10, #1520292 failed
2025-06-28.
No sr.ht context appears on any of those 19 commits either, so even
while those builds were running their result was never visible on a
commit or a pull request here.
This adds FreeBSD and OpenBSD jobs to .github/workflows/build.yml,
running in VMs on GitHub-hosted runners. Three commits, one thing
each; the reasoning is in the commit logs rather than here.
NetBSD is deliberately left out; see the last section.
What the jobs run
FreeBSD 15.1 and 14.3, both build paths, matching what .cirrus.yml
covered:
OpenBSD 7.9:
Results, from
https://github.com/neilpang/lsof/actions/runs/31451478135 :
against 3.4 min for the existing linux (ubuntu-24.04) job. The three
skips on FreeBSD are LTnfs and the two JSON cases that want python3.
FreeBSD needs the kernel sources: AC_CHECK_TYPES for struct
lockf_entry succeeds on both releases, so HEADER_GENERATE always runs
and cuts struct lock_owner out of ${FREEBSD_SYS}/kern/kern_lockf.c,
and the release images ship an empty /usr/src. The job unpacks only
usr/src/sys out of the release source set, which costs about 15
seconds. Both builds are done out of tree, so the source tree stays
clean for the legacy Configure run and the "git clean -fdx ."
.cirrus.yml needed between its two paths is not necessary.
The one source change
Configure's OpenBSD version table stops at 7.3; everything above falls
into the "*)" arm, which configures for OpenBSD 3.9 (2006). On 7.9
the classic suite then refuses to run at all:
That arm is also the only one in the table that does not set
LSOF_TSTBIGF, so -DLT_BIGF is dropped and the big-file test is quietly
disabled; with LSOF_TSTKMEM already 0 for this dialect, the line
CkTestDB builds matches neither the 3090 row in tests/TestDB (which
carries LT_BIGF and LT_KMEM) nor the 7020 and 7030 rows.
The fix adds a 7.9 arm and a 7.x catch-all written the way the 2.x and
3.x series already are, plus the single TestDB row that produces.
Because the catch-all puts 7.4 through 7.8 on the same LSOF_VERS, one
row covers the whole series. OPENBSDV is not read anywhere in the C
sources -- grep finds it only in Configure and 00FAQ -- so no compiled
code changes; FREEBSDV and NETBSDV, by contrast, are used in #if tests
in their dialects' headers.
Before and after, in an OpenBSD 7.9 VM:
The macos job
macos is red on this branch, and it is red for a reason that predates
it. The failure is
the runner's own .local name not resolving. An earlier push to the
same fork, which added nothing but a scratch workflow file and touched
no source at all, failed at the identical log lines with the identical
message and a different runner name. Nothing in the macos log
mentions CkTestDB or TestDB, so the tests/TestDB row added here is not
involved.
Found while doing this, not fixed here
Happy to open separate issues for any of these if you would rather
track them that way.
NetBSD 11.0 builds clean and the autotools suite passes 19 of 21
-- the two skips are "python3 not available" -- but only when the
build directory is not on tmpfs. Built under /tmp, which is
tmpfs on NetBSD, two cases fail:
Same VM, same binary, build directory moved to ffs: both pass.
The build does define HASTMPFS.
NetBSD's legacy path still fails. tests/TestDB has no netbsd row
past LT_VERS=3099000 while 11.0 produces LT_VERS=11000000, but
adding that row was not enough on its own -- check.bash netbsd
still exits 1 and I did not chase it further.
On OpenBSD the autotools build fails tests/LTbasic2 with "opened
regular file wasn't found", which is why the job above builds
that path but does not "make check" it. The two paths also end
up with very different feature sets: configure.ac's openbsd arm
sets only LSOF_VERS, while Configure also sets HASIPv6,
HAS_SYS_PIPEH and HAS_STRFTIME.
README still says FreeBSD is "tested on Cirrus CI" and NetBSD /
OpenBSD are "tested on SourceHut CI", and carries badges for
both. I left README, .cirrus.yml and .builds/ untouched, since
what you want to do with them is your call.
The runner warns on every job in this repository:
The new jobs use actions/checkout@v7. I did not touch the
existing jobs, to keep each commit to one thing.