Re: [Qemu-devel] [PULL 00/16] Migration pull request (v2)

[Alex Bennée]

Stefan Hajnoczi <address@hidden> writes:

> On Thu, May 07, 2015 at 11:40:50PM +0530, Amit Shah wrote:
>> On (Thu) 07 May 2015 [13:45:26], Peter Maydell wrote:
>> > On 7 May 2015 at 12:50, Juan Quintela <address@hidden> wrote:
>> > >
>> > >
>> > > Hi again
>> > >
>> > > For v2
>> > >
>> > > - fix 32bit compilation (as said, compiling for 64bit linux, 64bit
>> > >   windows and 32bit windows was not enough)
>> > >
>> > > - Now, we have versions 2.4 everywhere (thanks Eric)
>> > >
>> > > - Liang Li sent a new patch to the list to fix the update of a migration 
>> > > parameter, included.
>> > >
>> > > Please apply, and sorry for the inconvenience.
>> > 
>> > Fails to build on win32:
>> 
>> Does the buildbot try all these combinations?  I want to have a
>> 'stage' branch where I just push unapplied patches and receive
>> complaints before sending a pull req.
>
> The buildbot is dead and requires maintenance:
> http://buildbot.b1-systems.de/qemu/one_line_per_build
>
> There are two alternatives:
>
> 1. Travis (see .travis.yml) but it's missing mingw32.  It will never be
>    able to do builds for host operating systems that do not support
>    cross-compilation from Linux.

In theory you can get some cross compilers on Travis' trusty images. I
believe they have some docker based solution that might make it easier
to get cross compilation working for various (x86-based) distros.

>
> 2. patchew (http://qemu.patchew.org/) but it only has Fedora 20 x86_64
>    builds at the moment.  Adding mingw32 cross-compilation should be
>    possible but it scans the mailing list rather than git repos.
>
> The source code to patchew is available here:
> https://github.com/famz/patchew
>
> The trouble with continuous integration and build farms is that they
> require maintenance.  I think patchew is the best bet right now since
> Fam is developing it.

We build a few variants but the data is hard to mine. We've been
experimenting with kernelci.org to aggregate result for kernel builds
from various places internally.

One problem would be where the information on failures should be sent?

>
> Stefan

-- 
Alex Bennée