> On 13 Feb 2018, at 18:12, Kurt H Maier <k...@sciops.net> wrote: > > On Tue, Feb 13, 2018 at 05:01:35PM +0000, Rui Carmo wrote: >> >> A full build environment (the way I’m used to having it) comprises the >> end-to-end automation for creating a full build, > > A full build of what? It's one command to rebuild the whole OS. Is > that the goal?
Yes. And to deliver an image for the Pi, built on Intel systems. >> triggered by an external code repository > > This pretty significantly reduces the scope of the problem, since only a > couple of the forks use version control. This simplifies the task > somewhat, at least. I struggle to understand how version control is not more actively used. >> and (when possible) doing automated testing. > > I think this is probably the most useful part of what you describe. Do > you intend to write the tests? At least the basic ones regarding whether the result boots, yes. >> I understand that you might be used to manually bootstrap things, > > Please don't start making assumptions. I'm just trying to clarify what > you're after. > >> but I tend to go for fully reproducible builds and that usually requires a >> minimal degree of automation. I did that for my Inferno builds for the Pi >> (which, alas, are now lost) and do rely on Linux tools for building, because >> that’s what I can host in the public cloud (which is also what I do for >> work). > > Plenty of us run Plan 9 on public cloud providers. There's even been > some success on running it with crippled providers like AWS and GCE. > Obviously, the task is easier when you use providers that offer full KVM > services. We've had virtio drivers for a while, and it makes the job > much easier. Well, for full disclosure, I work at Microsoft. I do have extensive AWS and GCE experience, and hardly find them “crippled”. It’s just that the world has moved on and prioritised certain kinds of hardware virtualisation. >> Fortunately, I have access to machines with nested virtualisation, so I >> might be able to get Plan9 running inside QEMU inside a modern Linux kernel >> with fair performance - but that does not preclude the need to automate >> things. > > I'm still trying to understand why you'd even need nested > virtualization. For using QEMU’s virtualization features inside Hyper-V. R.
