On Tue, Nov 05, 2019 at 08:25:03PM +0000, Alex Bennée wrote:
>
> Eduardo Habkost <ehabk...@redhat.com> writes:
>
> > On Thu, Oct 31, 2019 at 08:12:01AM +0000, Peter Maydell wrote:
> >> On Fri, 25 Oct 2019 at 21:34, Eduardo Habkost <ehabk...@redhat.com> wrote:
> >> >
> >> > The following changes since commit
> >> > 03bf012e523ecdf047ac56b2057950247256064d:
> >> >
> >> > Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into
> >> > staging (2019-10-25 14:59:53 +0100)
> >> >
> >> > are available in the Git repository at:
> >> >
> >> > git://github.com/ehabkost/qemu.git tags/python-next-pull-request
> >> >
> >> > for you to fetch changes up to d24e417866f85229de1b75bc5c0a1d942451a842:
> >> >
> >> > configure: Require Python >= 3.5 (2019-10-25 16:34:57 -0300)
> >> >
> >> > ----------------------------------------------------------------
> >> > Require Python >= 3.5 to build QEMU
> >> >
> >> > ----------------------------------------------------------------
> >>
> >> I can't apply this until we've fixed the tests/vm netbsd setup to
> >> not use Python 2.
> >
> > Fixing tests/vm/netbsd is being tricky. It looks like the
> > configure patch will have to wait until after QEMU 4.2.0. :(
>
> I've posted fixes for the netbsd serial install but there are still
> problems with the tests including what looks like a fairly serious
> failure in the async code.
This sounds like a known "feature": QEMU expects clients to be
constantly reading from chardev sockets until the socket is
closed. Otherwise, VCPU threads may block waiting for the socket
to be writeable.
>
> >
> >>
> >> Have you tried a test run with Travis/etc/etc to check that none of
> >> those CI configs need updating to have python3 available ?
> >
> > I have tested this pull request on Shippable, and I will take a
> > look at Travis. I'd appreciate help from the CI system
> > maintainers (CCed) for the rest, as I don't have accounts in all
> > our CI systems.
>
> Setting up accounts on the others doesn't take long. I use the
> CustomCIStatus template to instantiate all the buttons for my various
> maintainer branches on the wiki, e.g.:
>
>
> {{CustomCIStatus|user=stsquad|repo=qemu|branch=testing/next|ship_proj=5885eac43b653a0f00fa97f5}}
>
> which means I just have to glance at the button state rather than going
> through each individual CI's status pages.
This is awesome. Thanks for the tip!
>
> > Do we expect maintainers to test their pull requests in all CI
> > systems listed at the QEMU wiki[1]? Do we have an official list
> > of CI systems that you consider to be pull request blockers?
>
> Well they all catch various things but none of them catch all the things
> Peter's PR processing does. Historically Travis has been allowed to
> slide because of test instability and timeouts. Having said that last I
> checked everything was green so breaking any of the main CIs
> (Travis/Shippable/Cirrus/Gitlab) indicates there is a problem that needs
> to be fixed.
Manually checking if 5 different CI systems are green wouldn't be
reasonable to me, but the CustomCIStatus template will be useful.
--
Eduardo
