Repository files navigation

N.B.: now boot, next build, new binaries, no biggie.

For increasingly arbitrary combinations of...

• Unixy host/guest OSes
• hardware architectures
• emulation and virtualization tools

...we have a consistent shell UI...

• forhost to control headless guest VMs:nb
• forguest to perform various in-system actions:nbvm
• foreither to perform various pkgsrc-specific steps:nbpkg

(There are also a few miscellaneous supporting scripts waiting to be properly integrated into these.)

I use this, at present, for a couple purposes:

• Manage a variety of pkgsrc platforms on which to test-build packages
• Do weekly rebuilds of all packages for my server

In principle, when I'm responsible for outcomes, I want to encounter problems myself as early as possible, so as to:

1. Narrow them down with minimal time and brain, and
2. Consider mitigation options with maximal time and brain.

In practice, this repo helps me:

• As a pkgsrc developer, to make sure all my packages work on a wide variety of platforms.
• As a server administrator, to update every week to a fresh-built set of the latest packages I rely on (not only mine).

I should probably evaluate the following to see if they can run my free choice of guest OS/architecture (for instance, NetBSD/mac68k) on my free choice of host OS/architecture (for instance, macOS/arm64).

• quickemu
• vagrant
• virsh

• Automate more manual steps
• Add non-qemu guests(such asNetBSD/vax)
• Pick a console server to catchnb boot output

• Connect two hosts (such asaarch64 andx86_64) in tandem:for any guest, run where virtualized, else run where emulationis probably "faster"
• Learn how to do a (limited) bulk build and publish (for myself) the results
• Iterate over all guests

• Have these tools adopted as official pkgsrc build infrastructure
• Allow pkgsrc developers to submit proposed changesbefore committing, to see how they build across a wide variety of platforms
• Build a GitHub Action backed by these tools