qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QEMU's Haiku CI image


From: Daniel P . Berrangé
Subject: Re: QEMU's Haiku CI image
Date: Wed, 16 Feb 2022 19:21:16 +0000
User-agent: Mutt/2.1.5 (2021-12-30)

On Wed, Feb 16, 2022 at 06:16:10PM +0100, Philippe Mathieu-Daudé via wrote:
> On 16/2/22 17:32, Thomas Huth wrote:
> > On 16/02/2022 16.52, Alexander von Gluck IV wrote:
> > > February 16, 2022 6:31 AM, "Thomas Huth" <thuth@redhat.com> wrote:
> > > > 
> > > > while researching the different "sed" options on our supported
> > > > build platform today, I started
> > > > "make vm-build-haiku.x86_64" in my QEMU build directory for the
> > > > first time since many months again.
> > > > And I had to discover that this is completely out of date. The
> > > > image does not contain any version
> > > > of Python 3 yet which we require for compilation since more than
> > > > a year now already, and the Haiku
> > > > version in there seems to be too old to do a "pkgman install -y
> > > > python3" ... so this has been
> > > > completely been bitrotting since more than a year now. Is
> > > > anybody still interested in keeping the
> > > > Haiku support in QEMU? If so, please help to get the VM image
> > > > updated. Thanks!
> > > 
> > > I submitted
> > > 20220216154208.2985103-1-kallisti5@unixzen.com/">https://patchwork.kernel.org/project/qemu-devel/patch/20220216154208.2985103-1-kallisti5@unixzen.com/
> > > 
> > > to fix this issue.  The build runs as expected after that patchset.
> > > 
> > > Likely cause is us no longer packing a "python" binary, deferring to
> > > "python2" vs "python3"
> > > 
> > > I'm still the most likely maintainer.  Are there still plans to
> > > automate the tests for Haiku to
> > > prevent this from happening again in the future?
> > 
> > AFAIK we still don't have a machine where we could properly run VM-based
> > tests in the CI, do we? Peter? Cleber?
> 
> We still have unused fosshost.org resources. What we don't have is a
> sysadmin willing to install the VM and maintain it over time.

I feel like there must be scope for sharing some of this burden with
libvirt since we've got essentially the same problem & requirements.

For libvirt we're using lcitool for building our VMs, and have worked
on a GitLab custom executor for launching throw-away VMs per CI job
from a read-only base template.

  https://gitlab.com/eskultety/libvirt-gitlab-executor

With this there's an admin burden setting up the gitlab executor on
the host and preparing the VM templates, but after that the admin
burden should be lightweight, as most of the risk of breakage is in
the VMs getting messed up, but they get thrown away after 1 job.

With QEMU's recent use of lcitool we're better ready  to share some
of this work than in the past. The main issue is that for non-Linux,
we don't have full automation for building the VM templates. We need
someone to prepare the image by getting it able to run and expose
SSH, whereupon we can provision the build-deps. We also only have
package mappings for FreeBSD, not Haiku, NetBSD or OpenBSD, but that's
fairly straightforward to address.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]