qemu-devel
[Top][All Lists]
Advanced

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

Re: "make check-acceptance" takes way too long


From: Daniel P . Berrangé
Subject: Re: "make check-acceptance" takes way too long
Date: Tue, 1 Feb 2022 16:19:21 +0000
User-agent: Mutt/2.1.5 (2021-12-30)

On Tue, Feb 01, 2022 at 11:01:43AM -0500, Cleber Rosa wrote:
> On Tue, Feb 1, 2022 at 6:25 AM Alex Bennée <alex.bennee@linaro.org> wrote:
> >
> > We have up to now tried really hard as a project to avoid building and
> > hosting our own binaries to avoid theoretical* GPL compliance issues.
> > This is why we've ended up relying so much on distros to build and host
> > binaries we can use. Most QEMU developers have their own personal zoo of
> > kernels and userspaces which they use for testing. I use custom kernels
> > with a buildroot user space in initramfs for example. We even use the
> > qemu advent calendar for a number of our avocado tests but we basically
> > push responsibility for GPL compliance to the individual developers in
> > that case.
> >
> > *theoretical in so far I suspect most people would be happy with a
> > reference to an upstream repo/commit and .config even if that is not to
> > the letter of the "offer of source code" required for true compliance.
> >
> 
> Yes, it'd be fine (great, really!) if a lightweight distro (or
> kernels/initrd) were to
> be maintained and identified as an "official" QEMU pick.  Putting the binaries
> in the source tree though, brings all sorts of compliance issues.

All that's really needed is to have the source + build recipes
in a separate git repo. A pipeline can build them periodically
and publish artifacts, which QEMU can then consume in its pipeline.

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]