Re: [Qemu-devel] KVM call agenda for May, Tuesday 8th

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/08/2012 09:10 AM, Andreas Färber wrote:
> Am 07.05.2012 14:54, schrieb Anthony Liguori:
>> On 05/07/2012 06:47 AM, Juan Quintela wrote:
>>>
>>> Please send in any agenda items you are interested in covering.
>>
>> - Status of the 1.1 release
>
> Since it looked like the call is not going to take place lacking
> feedback from Anthony, I will provocatively go ahead and say the status
> of 1.1 is pretty bad, currently. ;)
>
> rc0 is available, but patches submitted for 1.1 shortly before rc0
> neither got review nor were applied. Neither did pulls or patches
> applied by Anthony get such a notice fwiw so that it's hard to
> distinguish what's missing for anyone but the patch author.

All pulls got handled before -rc0 was tagged.

>
> With rc0 not being provided as tarball, it would be nice to document the
> official, reproducible way of packaging a QEMU tarball on the Wiki. I
> have collected some steps from the Rob Landley mips thread, but the
> submodules complicate things a bit.

-rc0's are never provided as a tarball.  This is how the release process works 
and someone always complains about it :-(

> rc1 should've been released yesterday, but it's not available yet, no
> info and same issue with patches not being applied.

I missed a flight yesterday and spent the entire day at an airport so I didn't 
tag it yesterday.  I'm going to work on it today.

> In the current state of master, rc1 will not build on ppc due to an
> #error introduced since rc0 by malc - with its history, Darwin/ppc
> should not be a release blocker here and *some* fix to restore the build
> should please be applied soon.

So... what's the fix?

Regards,

Anthony Liguori

> And worse, there's more and more colliding patch series on the list -
> fixed-width visitors, realize, QBus, VMState, AREG0, CPU - for which we
> need a strategy to coordinate our ongoing development and post-1.1
> merging. Someone needs to rebase on someone else, question is whom.
>
> Some downstream feedback: I've so far been unable to do a static build
> of v1.1-rc0 in the openSUSE build system due to a -lpcre coming from
> gthread-2.0.pc Libs.private - an issue we don't see for v1.0.1. If
> another distro has encountered that issue I'd be grateful for feedback.
> Might be our own issue.
> In course of investigating though, I've noticed that lots of our
> configure checks are not limited to non-static/softmmu builds and will
> contribute cflags/libs to a static linux-user build even if unused.
>
> Regards,
> Andreas
>