I think there is a difference between building OpenBSD "on real hardware" and building port binaries for ARMv7 which are intended to run across all of the ARMv7 target ports.
And I think the concern should be less about “OS bugs and emulator bugs” since (1.) you’re not building the OS, and (2.) ARM emulation is quite mature with several standard platform configurations which may be targeted (including ARMv7). A dual-Xeon-quad-core server (8 cores, 16 threads) with 48G of RAM can easily host 10 or more VMs, and do a distributed build across QEMU/ARM running on each of the VMs. The resulting compiled code for a port ‘binary’ distribution should be no different regardless of where it was actually built. So, what then is the reason (other than philosophical) that an OpenBSD port does not yet exist for QEMU/ARM ? If you can no longer blame the hardware to such a degree, then either your port builds should become more reliable, or there is still a problem with the OS arch. The behavior of emulated hardware is repeatable and fairly predictable, especially if it’s a mature emulation platform (i.e. having been pounded on and considered stable already for multiple OS). Taking the hardware (excuse) out of the equation, you could move forward with efforts to continuously build and validate ARMv7 ports with every iteration of OpenBSD. And yes, the native building of the OS itself is still a great stress test for these up-and- coming ARMv7 hardware platforms. But the building of port packages -- or the choice of making excuses to not build or provide them -- is really a very separate issue. On 2015-05-23, Stuart Henderson wrote: > Not particularly. If the machines and/or OS arch are reliable in the > first place it's not a problem to spread builds across more machines. > But in reality, it's not very reliable, so 1) adding machines just > means babysitting additional crashes, and 2) if emulation is used > instead of real machines, then you're dealing with both OS bugs and > emulator bugs.
