> 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
> 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
> I'm still trying to understand why you'd even need nested
For using QEMU’s virtualization features inside Hyper-V.