[Yocto-builds] buildbot failure in The Yocto Autobuilder on nightly-x32

[Darren Hart]

On 06/17/2013 09:28 AM, Richard Purdie wrote:
> On Fri, 2013-06-14 at 16:13 +0300, Riku Voipio wrote:
>> Hi,
>>
>> On 14 June 2013 01:03, Saul Wold <sgw at linux.intel.com> wrote:
>>> Looks like the newer version of Qemu 1.5,0 is not happy with x32!
>>> When I revert this change and use qemu 1.4.1 x32 boots fine with the same
>>> build.
>>
>> Sorry I can't deduce from the log what is happening here - are you
>> booting the x32 image with qemu, or do you mean that using qemu 1.5
>> bbuilding x32 images will fail? If the former, can you share image
>> that fails to boot and qemu command line used?
>>
>>> I built it locally and booted the image and got the following kernel panic,
>>> so I think there is something more going on, I have not dug into this yet,
>>> just reporting a follow-up.
>>
>>> This is why we like to get full testing across all arches of qemu updates
>>> even when the upsteam changes are no that major!
>>
>> For me or some other random developer building and testing qemu across
>> all architectures and permutations of images is not really feasible.
>> Would it be possible to contribute potentially disruptive changes like
>> this to separate branch that is then tried out by the buildbots ?
> 
> This is effectively what Saul does with the MUT test branch I do with
> master-next. With something as problematic as qemu it does usually need
> special care though. In this case we missed the x32 failure due to other
> changes getting tested at the same time (e.g. gcc 4.8 which is still
> broken on arm).
> 
> In this case x32 is now broken in master, each build is now failing and
> I'm having trouble finding anyone to step in and fix it. Do I therefore
> revert the qemu update? I think that would also upset people. So I'm in
> an impossible position again :(.

I don't envy you the juggling act RP!

In my opinion, this is a regression. QEMU used to work, and after the
update it is found that it does not. While keeping current is a core goal,
I *believe* that such a regression is justification for a revert until
the issue can be resolved.

Of course, that depends on the priority of x32 support vs. whatever new
features this QEMU version brings. Is there something particularly
compelling with this version of QEMU that trumps x32 support?

If not, the most expedient approach may be to just revert the QEMU change.

(Obviously the ideal would be for someone to jump in and fix it properly
now, but alas, bugs abound and resources are scant).

Just my 0.02 USD.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel