The following changes since commit 185b7ccc11354cbd69b6d53bf8d831dd964f6c88:

  Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190607-2' into staging (2019-06-07 15:24:13 +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 8297719709f1339506d6da93ec69e6118ace8676:

  travis: Make check-acceptance job more verbose (2019-06-07 18:11:02 -0300)

----------------------------------------------------------------
Python queue, 2019-06-07

* New boot_linux_console test cases (Philippe Mathieu-Daudé)
* Deprecate Python 2 support (Eduardo Habkost)
* Require python3 >= 3.5 (Eduardo Habkost)
* Make check-acceptance Travis job more verbose (Eduardo Habkost)

----------------------------------------------------------------

Eduardo Habkost (3):
  Deprecate Python 2 support
  configure: Require python3 >= 3.5
  travis: Make check-acceptance job more verbose

Philippe Mathieu-Daudé (5):
  tests/boot_linux_console: Let extract_from_deb handle various
    compressions
  BootLinuxConsoleTest: Do not log empty lines
  BootLinuxConsoleTest: Test the SmartFusion2 board
  BootLinuxConsoleTest: Test nanoMIPS kernels on the I7200 CPU
  BootLinuxConsoleTest: Run kerneltests BusyBox on Malta

 configure                              |  13 ++-
 .travis.yml                            |   4 +-
 qemu-deprecated.texi                   |   8 ++
 tests/acceptance/boot_linux_console.py | 145 ++++++++++++++++++++++++-
 4 files changed, 162 insertions(+), 8 deletions(-)

-- 
2.18.0.rc1.1.g3f1ff2140

On Fri, 7 Jun 2019 at 22:16, Eduardo Habkost <ehabkost@redhat.com> wrote:
>
> The following changes since commit 185b7ccc11354cbd69b6d53bf8d831dd964f6c88:
>
>   Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190607-2' into staging (2019-06-07 15:24:13 +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 8297719709f1339506d6da93ec69e6118ace8676:
>
>   travis: Make check-acceptance job more verbose (2019-06-07 18:11:02 -0300)
>
> ----------------------------------------------------------------
> Python queue, 2019-06-07
>
> * New boot_linux_console test cases (Philippe Mathieu-Daudé)
> * Deprecate Python 2 support (Eduardo Habkost)
> * Require python3 >= 3.5 (Eduardo Habkost)
> * Make check-acceptance Travis job more verbose (Eduardo Habkost)
>
> ----------------------------------------------------------------

Hi. This fails to build on one of my buildtest machines:

ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
       Use --python=/path/to/python to specify a supported Python.

The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
box; it's one of the gcc compile farm machines so upgrades to its
OS are not really under my control.)

The configure check also spits out deprecation warnings for
the NetBSD/FreeBSD/OpenBSD tests/vm configurations. It would be nice
to get those updated.

thanks
-- PMM

On Mon, 10 Jun 2019 at 13:58, Peter Maydell <peter.maydell@linaro.org> wrote:
> Hi. This fails to build on one of my buildtest machines:
>
> ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
>        Use --python=/path/to/python to specify a supported Python.
>
> The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> box; it's one of the gcc compile farm machines so upgrades to its
> OS are not really under my control.)

Rereading this, I realise that either the check or the error
message is wrong here. The machine has 2.7.6, which satisfies
"python 2 >= 2.7", so we should be OK to build. The bug
seems to be that we say "prefer python3 over plain python
on python2" early, but don't revisit that decision if the
python3 we found isn't actually good enough for us.

(I am also setting up to do builds on a different aarch64 box
which has a newer python3.)

thanks
-- PMM

On Tue, Jun 11, 2019 at 04:50:34PM +0100, Peter Maydell wrote:
> On Mon, 10 Jun 2019 at 13:58, Peter Maydell <peter.maydell@linaro.org> wrote:
> > Hi. This fails to build on one of my buildtest machines:
> >
> > ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
> >        Use --python=/path/to/python to specify a supported Python.
> >
> > The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> > box; it's one of the gcc compile farm machines so upgrades to its
> > OS are not really under my control.)
> 
> Rereading this, I realise that either the check or the error
> message is wrong here. The machine has 2.7.6, which satisfies
> "python 2 >= 2.7", so we should be OK to build. The bug
> seems to be that we say "prefer python3 over plain python
> on python2" early, but don't revisit that decision if the
> python3 we found isn't actually good enough for us.

Right.  The error message is technically correct, but misleading.
python3 is too old, but python2 would work.

We can make configure not use python3 by default if it's too old,
and fall back to python2 in this case.

-- 
Eduardo

On Tue, 11 Jun 2019 at 17:03, Eduardo Habkost <ehabkost@redhat.com> wrote:
>
> On Tue, Jun 11, 2019 at 04:50:34PM +0100, Peter Maydell wrote:
> > On Mon, 10 Jun 2019 at 13:58, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > Hi. This fails to build on one of my buildtest machines:
> > >
> > > ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
> > >        Use --python=/path/to/python to specify a supported Python.
> > >
> > > The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> > > box; it's one of the gcc compile farm machines so upgrades to its
> > > OS are not really under my control.)
> >
> > Rereading this, I realise that either the check or the error
> > message is wrong here. The machine has 2.7.6, which satisfies
> > "python 2 >= 2.7", so we should be OK to build. The bug
> > seems to be that we say "prefer python3 over plain python
> > on python2" early, but don't revisit that decision if the
> > python3 we found isn't actually good enough for us.
>
> Right.  The error message is technically correct, but misleading.
> python3 is too old, but python2 would work.
>
> We can make configure not use python3 by default if it's too old,
> and fall back to python2 in this case.

Sounds good. Since I have now managed to get my alternate
aarch64 box set up, how about I apply this pullreq and you
send a followup patch which does the fallback to python/python2 ?

thanks
-- PMM

On Tue, Jun 11, 2019 at 05:07:55PM +0100, Peter Maydell wrote:
> On Tue, 11 Jun 2019 at 17:03, Eduardo Habkost <ehabkost@redhat.com> wrote:
> >
> > On Tue, Jun 11, 2019 at 04:50:34PM +0100, Peter Maydell wrote:
> > > On Mon, 10 Jun 2019 at 13:58, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > > Hi. This fails to build on one of my buildtest machines:
> > > >
> > > > ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
> > > >        Use --python=/path/to/python to specify a supported Python.
> > > >
> > > > The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> > > > box; it's one of the gcc compile farm machines so upgrades to its
> > > > OS are not really under my control.)
> > >
> > > Rereading this, I realise that either the check or the error
> > > message is wrong here. The machine has 2.7.6, which satisfies
> > > "python 2 >= 2.7", so we should be OK to build. The bug
> > > seems to be that we say "prefer python3 over plain python
> > > on python2" early, but don't revisit that decision if the
> > > python3 we found isn't actually good enough for us.
> >
> > Right.  The error message is technically correct, but misleading.
> > python3 is too old, but python2 would work.
> >
> > We can make configure not use python3 by default if it's too old,
> > and fall back to python2 in this case.
> 
> Sounds good. Since I have now managed to get my alternate
> aarch64 box set up, how about I apply this pullreq and you
> send a followup patch which does the fallback to python/python2 ?

I will remove the python2/python3 patches and send a new pull
request.

-- 
Eduardo

Am 11.06.2019 um 19:12 hat Eduardo Habkost geschrieben:
> On Tue, Jun 11, 2019 at 05:07:55PM +0100, Peter Maydell wrote:
> > On Tue, 11 Jun 2019 at 17:03, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > >
> > > On Tue, Jun 11, 2019 at 04:50:34PM +0100, Peter Maydell wrote:
> > > > On Mon, 10 Jun 2019 at 13:58, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > > > Hi. This fails to build on one of my buildtest machines:
> > > > >
> > > > > ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
> > > > >        Use --python=/path/to/python to specify a supported Python.
> > > > >
> > > > > The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> > > > > box; it's one of the gcc compile farm machines so upgrades to its
> > > > > OS are not really under my control.)
> > > >
> > > > Rereading this, I realise that either the check or the error
> > > > message is wrong here. The machine has 2.7.6, which satisfies
> > > > "python 2 >= 2.7", so we should be OK to build. The bug
> > > > seems to be that we say "prefer python3 over plain python
> > > > on python2" early, but don't revisit that decision if the
> > > > python3 we found isn't actually good enough for us.
> > >
> > > Right.  The error message is technically correct, but misleading.
> > > python3 is too old, but python2 would work.
> > >
> > > We can make configure not use python3 by default if it's too old,
> > > and fall back to python2 in this case.
> > 
> > Sounds good. Since I have now managed to get my alternate
> > aarch64 box set up, how about I apply this pullreq and you
> > send a followup patch which does the fallback to python/python2 ?
> 
> I will remove the python2/python3 patches and send a new pull
> request.

What is the plan forward with this? Are the patches dropped for good?

I think the plan was to drop Python 2 after QEMU 4.2, and then it
becomes really relevant what our minimum Python 3 version is. We've just
had another Python version discussion in the context of iotests (John
suggested using function annotations, but these are >= 3.5 only).

Also, the fallback to Python 2 obviously makes no sense any more then,
so maybe it's not that important to add for a single QEMU release?

As Peter seems to have indicated above that he found a replacement for
the test machine with an OS that isn't out of support, can we just
revive this patch as it is?

Kevin

On Tue, Sep 17, 2019 at 03:57:26PM +0200, Kevin Wolf wrote:
> Am 11.06.2019 um 19:12 hat Eduardo Habkost geschrieben:
> > On Tue, Jun 11, 2019 at 05:07:55PM +0100, Peter Maydell wrote:
> > > On Tue, 11 Jun 2019 at 17:03, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > >
> > > > On Tue, Jun 11, 2019 at 04:50:34PM +0100, Peter Maydell wrote:
> > > > > On Mon, 10 Jun 2019 at 13:58, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > > > > Hi. This fails to build on one of my buildtest machines:
> > > > > >
> > > > > > ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
> > > > > >        Use --python=/path/to/python to specify a supported Python.
> > > > > >
> > > > > > The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> > > > > > box; it's one of the gcc compile farm machines so upgrades to its
> > > > > > OS are not really under my control.)
> > > > >
> > > > > Rereading this, I realise that either the check or the error
> > > > > message is wrong here. The machine has 2.7.6, which satisfies
> > > > > "python 2 >= 2.7", so we should be OK to build. The bug
> > > > > seems to be that we say "prefer python3 over plain python
> > > > > on python2" early, but don't revisit that decision if the
> > > > > python3 we found isn't actually good enough for us.
> > > >
> > > > Right.  The error message is technically correct, but misleading.
> > > > python3 is too old, but python2 would work.
> > > >
> > > > We can make configure not use python3 by default if it's too old,
> > > > and fall back to python2 in this case.
> > > 
> > > Sounds good. Since I have now managed to get my alternate
> > > aarch64 box set up, how about I apply this pullreq and you
> > > send a followup patch which does the fallback to python/python2 ?
> > 
> > I will remove the python2/python3 patches and send a new pull
> > request.
> 
> What is the plan forward with this? Are the patches dropped for good?
> 
> I think the plan was to drop Python 2 after QEMU 4.2, and then it
> becomes really relevant what our minimum Python 3 version is. We've just
> had another Python version discussion in the context of iotests (John
> suggested using function annotations, but these are >= 3.5 only).
> 
> Also, the fallback to Python 2 obviously makes no sense any more then,
> so maybe it's not that important to add for a single QEMU release?
> 
> As Peter seems to have indicated above that he found a replacement for
> the test machine with an OS that isn't out of support, can we just
> revive this patch as it is?

My plan is to remove Python 2 support in QEMU 4.2 (making the
fallback to Python 2 a non-issue), and require Python >= 3.5.

Now, even if my plan is rejected and we keep supporting Python 2
when building QEMU 4.2, my suggestion for the iotest maintainers
is to make it require Python 3.5+ immediately, just like we do
for tests/acceptance.  I don't see why we should keep wasting our
energy supporting ancient Python versions in a test suite that is
not a requirement for building QEMU.

-- 
Eduardo

On 9/17/19 5:48 PM, Eduardo Habkost wrote:
> On Tue, Sep 17, 2019 at 03:57:26PM +0200, Kevin Wolf wrote:
>> Am 11.06.2019 um 19:12 hat Eduardo Habkost geschrieben:
>>> On Tue, Jun 11, 2019 at 05:07:55PM +0100, Peter Maydell wrote:
>>>> On Tue, 11 Jun 2019 at 17:03, Eduardo Habkost <ehabkost@redhat.com> wrote:
>>>>>
>>>>> On Tue, Jun 11, 2019 at 04:50:34PM +0100, Peter Maydell wrote:
>>>>>> On Mon, 10 Jun 2019 at 13:58, Peter Maydell <peter.maydell@linaro.org> wrote:
>>>>>>> Hi. This fails to build on one of my buildtest machines:
>>>>>>>
>>>>>>> ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
>>>>>>>        Use --python=/path/to/python to specify a supported Python.
>>>>>>>
>>>>>>> The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
>>>>>>> box; it's one of the gcc compile farm machines so upgrades to its
>>>>>>> OS are not really under my control.)
>>>>>>
>>>>>> Rereading this, I realise that either the check or the error
>>>>>> message is wrong here. The machine has 2.7.6, which satisfies
>>>>>> "python 2 >= 2.7", so we should be OK to build. The bug
>>>>>> seems to be that we say "prefer python3 over plain python
>>>>>> on python2" early, but don't revisit that decision if the
>>>>>> python3 we found isn't actually good enough for us.
>>>>>
>>>>> Right.  The error message is technically correct, but misleading.
>>>>> python3 is too old, but python2 would work.
>>>>>
>>>>> We can make configure not use python3 by default if it's too old,
>>>>> and fall back to python2 in this case.
>>>>
>>>> Sounds good. Since I have now managed to get my alternate
>>>> aarch64 box set up, how about I apply this pullreq and you
>>>> send a followup patch which does the fallback to python/python2 ?
>>>
>>> I will remove the python2/python3 patches and send a new pull
>>> request.
>>
>> What is the plan forward with this? Are the patches dropped for good?
>>
>> I think the plan was to drop Python 2 after QEMU 4.2, and then it
>> becomes really relevant what our minimum Python 3 version is. We've just
>> had another Python version discussion in the context of iotests (John
>> suggested using function annotations, but these are >= 3.5 only).
>>
>> Also, the fallback to Python 2 obviously makes no sense any more then,
>> so maybe it's not that important to add for a single QEMU release?
>>
>> As Peter seems to have indicated above that he found a replacement for
>> the test machine with an OS that isn't out of support, can we just
>> revive this patch as it is?
> 
> My plan is to remove Python 2 support in QEMU 4.2 (making the
> fallback to Python 2 a non-issue), and require Python >= 3.5.
> 
> Now, even if my plan is rejected and we keep supporting Python 2
> when building QEMU 4.2, my suggestion for the iotest maintainers
> is to make it require Python 3.5+ immediately, just like we do
> for tests/acceptance.  I don't see why we should keep wasting our
> energy supporting ancient Python versions in a test suite that is
> not a requirement for building QEMU.
> 

It's unfortunately now part of the 'make check' target which we use in
the vm tests as a default target ... but I think we can make the push to
change the build requires to 3.5+.

--js

On Tue, Sep 17, 2019 at 07:10:13PM -0400, John Snow wrote:
> On 9/17/19 5:48 PM, Eduardo Habkost wrote:
> > On Tue, Sep 17, 2019 at 03:57:26PM +0200, Kevin Wolf wrote:
> >> Am 11.06.2019 um 19:12 hat Eduardo Habkost geschrieben:
> >>> On Tue, Jun 11, 2019 at 05:07:55PM +0100, Peter Maydell wrote:
> >>>> On Tue, 11 Jun 2019 at 17:03, Eduardo Habkost <ehabkost@redhat.com> wrote:
> >>>>>
> >>>>> On Tue, Jun 11, 2019 at 04:50:34PM +0100, Peter Maydell wrote:
> >>>>>> On Mon, 10 Jun 2019 at 13:58, Peter Maydell <peter.maydell@linaro.org> wrote:
> >>>>>>> Hi. This fails to build on one of my buildtest machines:
> >>>>>>>
> >>>>>>> ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
> >>>>>>>        Use --python=/path/to/python to specify a supported Python.
> >>>>>>>
> >>>>>>> The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> >>>>>>> box; it's one of the gcc compile farm machines so upgrades to its
> >>>>>>> OS are not really under my control.)
> >>>>>>
> >>>>>> Rereading this, I realise that either the check or the error
> >>>>>> message is wrong here. The machine has 2.7.6, which satisfies
> >>>>>> "python 2 >= 2.7", so we should be OK to build. The bug
> >>>>>> seems to be that we say "prefer python3 over plain python
> >>>>>> on python2" early, but don't revisit that decision if the
> >>>>>> python3 we found isn't actually good enough for us.
> >>>>>
> >>>>> Right.  The error message is technically correct, but misleading.
> >>>>> python3 is too old, but python2 would work.
> >>>>>
> >>>>> We can make configure not use python3 by default if it's too old,
> >>>>> and fall back to python2 in this case.
> >>>>
> >>>> Sounds good. Since I have now managed to get my alternate
> >>>> aarch64 box set up, how about I apply this pullreq and you
> >>>> send a followup patch which does the fallback to python/python2 ?
> >>>
> >>> I will remove the python2/python3 patches and send a new pull
> >>> request.
> >>
> >> What is the plan forward with this? Are the patches dropped for good?
> >>
> >> I think the plan was to drop Python 2 after QEMU 4.2, and then it
> >> becomes really relevant what our minimum Python 3 version is. We've just
> >> had another Python version discussion in the context of iotests (John
> >> suggested using function annotations, but these are >= 3.5 only).
> >>
> >> Also, the fallback to Python 2 obviously makes no sense any more then,
> >> so maybe it's not that important to add for a single QEMU release?
> >>
> >> As Peter seems to have indicated above that he found a replacement for
> >> the test machine with an OS that isn't out of support, can we just
> >> revive this patch as it is?
> > 
> > My plan is to remove Python 2 support in QEMU 4.2 (making the
> > fallback to Python 2 a non-issue), and require Python >= 3.5.
> > 
> > Now, even if my plan is rejected and we keep supporting Python 2
> > when building QEMU 4.2, my suggestion for the iotest maintainers
> > is to make it require Python 3.5+ immediately, just like we do
> > for tests/acceptance.  I don't see why we should keep wasting our
> > energy supporting ancient Python versions in a test suite that is
> > not a requirement for building QEMU.
> > 
> 
> It's unfortunately now part of the 'make check' target which we use in
> the vm tests as a default target ... but I think we can make the push to
> change the build requires to 3.5+.

In the worst case, we can make "make check" skip iotests if
Python 2 is detected (after printing a warning).  But requiring
3.5+ for the build would really be the best option.

I've just restarted the thread about Python 2 in tests/vm:
https://lore.kernel.org/qemu-devel/20190917233140.GK4082@habkost.net/

-- 
Eduardo

Am 17.09.2019 um 23:48 hat Eduardo Habkost geschrieben:
> On Tue, Sep 17, 2019 at 03:57:26PM +0200, Kevin Wolf wrote:
> > Am 11.06.2019 um 19:12 hat Eduardo Habkost geschrieben:
> > > On Tue, Jun 11, 2019 at 05:07:55PM +0100, Peter Maydell wrote:
> > > > On Tue, 11 Jun 2019 at 17:03, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > > >
> > > > > On Tue, Jun 11, 2019 at 04:50:34PM +0100, Peter Maydell wrote:
> > > > > > On Mon, 10 Jun 2019 at 13:58, Peter Maydell <peter.maydell@linaro.org> wrote:
> > > > > > > Hi. This fails to build on one of my buildtest machines:
> > > > > > >
> > > > > > > ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
> > > > > > >        Use --python=/path/to/python to specify a supported Python.
> > > > > > >
> > > > > > > The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> > > > > > > box; it's one of the gcc compile farm machines so upgrades to its
> > > > > > > OS are not really under my control.)
> > > > > >
> > > > > > Rereading this, I realise that either the check or the error
> > > > > > message is wrong here. The machine has 2.7.6, which satisfies
> > > > > > "python 2 >= 2.7", so we should be OK to build. The bug
> > > > > > seems to be that we say "prefer python3 over plain python
> > > > > > on python2" early, but don't revisit that decision if the
> > > > > > python3 we found isn't actually good enough for us.
> > > > >
> > > > > Right.  The error message is technically correct, but misleading.
> > > > > python3 is too old, but python2 would work.
> > > > >
> > > > > We can make configure not use python3 by default if it's too old,
> > > > > and fall back to python2 in this case.
> > > > 
> > > > Sounds good. Since I have now managed to get my alternate
> > > > aarch64 box set up, how about I apply this pullreq and you
> > > > send a followup patch which does the fallback to python/python2 ?
> > > 
> > > I will remove the python2/python3 patches and send a new pull
> > > request.
> > 
> > What is the plan forward with this? Are the patches dropped for good?
> > 
> > I think the plan was to drop Python 2 after QEMU 4.2, and then it
> > becomes really relevant what our minimum Python 3 version is. We've just
> > had another Python version discussion in the context of iotests (John
> > suggested using function annotations, but these are >= 3.5 only).
> > 
> > Also, the fallback to Python 2 obviously makes no sense any more then,
> > so maybe it's not that important to add for a single QEMU release?
> > 
> > As Peter seems to have indicated above that he found a replacement for
> > the test machine with an OS that isn't out of support, can we just
> > revive this patch as it is?
> 
> My plan is to remove Python 2 support in QEMU 4.2 (making the
> fallback to Python 2 a non-issue), and require Python >= 3.5.

Then I think it would be best to make (or propose at least) that change
early in the release cycle. In other words, now. :-)

> Now, even if my plan is rejected and we keep supporting Python 2
> when building QEMU 4.2, my suggestion for the iotest maintainers
> is to make it require Python 3.5+ immediately, just like we do
> for tests/acceptance.  I don't see why we should keep wasting our
> energy supporting ancient Python versions in a test suite that is
> not a requirement for building QEMU.

Okay, if you as the Python maintainer say so, I'll gladly follow your
advice.

Maybe we can modify iotests so that it just skips Python tests if the
minimum version isn't available to keep the impact of deviating from the
global minimum version as small as possible. Of course, this will only
be necessary if your proposal to make 3.5 the minimum for all of QEMU is
rejected.

Kevin

On Mon, Jun 10, 2019 at 01:58:50PM +0100, Peter Maydell wrote:
> On Fri, 7 Jun 2019 at 22:16, Eduardo Habkost <ehabkost@redhat.com> wrote:
> >
> > The following changes since commit 185b7ccc11354cbd69b6d53bf8d831dd964f6c88:
> >
> >   Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190607-2' into staging (2019-06-07 15:24:13 +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 8297719709f1339506d6da93ec69e6118ace8676:
> >
> >   travis: Make check-acceptance job more verbose (2019-06-07 18:11:02 -0300)
> >
> > ----------------------------------------------------------------
> > Python queue, 2019-06-07
> >
> > * New boot_linux_console test cases (Philippe Mathieu-Daudé)
> > * Deprecate Python 2 support (Eduardo Habkost)
> > * Require python3 >= 3.5 (Eduardo Habkost)
> > * Make check-acceptance Travis job more verbose (Eduardo Habkost)
> >
> > ----------------------------------------------------------------
> 
> Hi. This fails to build on one of my buildtest machines:
> 
> ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
>        Use --python=/path/to/python to specify a supported Python.
> 
> The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> box; it's one of the gcc compile farm machines so upgrades to its
> OS are not really under my control.)

Ubuntu 16.04 LTS (Xenial) was released in April 2016.  Doesn't
that mean Trusty is not a supported build platform since April
2018?

> 
> The configure check also spits out deprecation warnings for
> the NetBSD/FreeBSD/OpenBSD tests/vm configurations. It would be nice
> to get those updated.

I'll take a look.

-- 
Eduardo

On Mon, 10 Jun 2019 at 14:11, Eduardo Habkost <ehabkost@redhat.com> wrote:
>
> On Mon, Jun 10, 2019 at 01:58:50PM +0100, Peter Maydell wrote:
> > Hi. This fails to build on one of my buildtest machines:
> >
> > ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
> >        Use --python=/path/to/python to specify a supported Python.
> >
> > The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> > box; it's one of the gcc compile farm machines so upgrades to its
> > OS are not really under my control.)
>
> Ubuntu 16.04 LTS (Xenial) was released in April 2016.  Doesn't
> that mean Trusty is not a supported build platform since April
> 2018?

Possibly, but as I say the gcc compile farm is what it is.
Regardless of the strict letter of the deprecation policy,
when we start running into issues with the set of build test
machines I tend to feel we may be being a bit over-hasty in
deprecating things.

PS: re the BSD VMs, you probably want to start with Alex's
recent update which did a fairly major overhaul there (he
sent a pullreq but it didn't pass build tests so isn't merged yet).

thanks
-- PMM

On Mon, Jun 10, 2019 at 02:21:57PM +0100, Peter Maydell wrote:
> On Mon, 10 Jun 2019 at 14:11, Eduardo Habkost <ehabkost@redhat.com> wrote:
> >
> > On Mon, Jun 10, 2019 at 01:58:50PM +0100, Peter Maydell wrote:
> > > Hi. This fails to build on one of my buildtest machines:
> > >
> > > ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
> > >        Use --python=/path/to/python to specify a supported Python.
> > >
> > > The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> > > box; it's one of the gcc compile farm machines so upgrades to its
> > > OS are not really under my control.)
> >
> > Ubuntu 16.04 LTS (Xenial) was released in April 2016.  Doesn't
> > that mean Trusty is not a supported build platform since April
> > 2018?
> 
> Possibly, but as I say the gcc compile farm is what it is.
> Regardless of the strict letter of the deprecation policy,
> when we start running into issues with the set of build test
> machines I tend to feel we may be being a bit over-hasty in
> deprecating things.

There's been two new LTS releases of Ubuntu since then
with Xenial and Bionic, so IMHO, it is pretty reasonable
to want to drop Trusty rather than continuing to spend time
on software versions from 2014 and before. Both our Travis
and Docker setups use Xenial as minimum and the number of
our developers stuck using Trusty is likely negligible.

What gap is your gcc compile farm filling & can we find an
alternate way to address that gap that's viable ?

Does the gcc compile farm include Docker to let us run the
build in a container from the compile farm. Or can we use
a Docker container on a modern x86_64 host to test the same
thing. We have docker containers for all Linux OS we need
to target, and docker containers for non-x86_64 arches that
cross compile.

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 :|

On Mon, 10 Jun 2019 at 18:12, Daniel P. Berrangé <berrange@redhat.com> wrote:
> There's been two new LTS releases of Ubuntu since then
> with Xenial and Bionic, so IMHO, it is pretty reasonable
> to want to drop Trusty rather than continuing to spend time
> on software versions from 2014 and before. Both our Travis
> and Docker setups use Xenial as minimum and the number of
> our developers stuck using Trusty is likely negligible.
>
> What gap is your gcc compile farm filling & can we find an
> alternate way to address that gap that's viable ?

In this case, it's the aarch64 host. I can probably
find something else to run this on, but it's not going
to happen immediately.

> docker containers for non-x86_64 arches that cross compile.

You need to actually run the tests, so merely cross
compiling doesn't suffice. (Running 'make check' catches
a fair number of bugs.)

I've asked the gcc farm admins if they have plans for an
OS upgrade on those boxes.

thanks
-- PMM

On Mon, Jun 10, 2019 at 06:15:46PM +0100, Peter Maydell wrote:
> On Mon, 10 Jun 2019 at 18:12, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > There's been two new LTS releases of Ubuntu since then
> > with Xenial and Bionic, so IMHO, it is pretty reasonable
> > to want to drop Trusty rather than continuing to spend time
> > on software versions from 2014 and before. Both our Travis
> > and Docker setups use Xenial as minimum and the number of
> > our developers stuck using Trusty is likely negligible.
> >
> > What gap is your gcc compile farm filling & can we find an
> > alternate way to address that gap that's viable ?
> 
> In this case, it's the aarch64 host. I can probably
> find something else to run this on, but it's not going
> to happen immediately.

Do you have access to any machine in the compile farm or is access
granted on a per-machine basis ?   If i'm reading this page right:

  https://cfarm.tetaneutral.net/machines/list/

there is now one aarch64 machine (gcc117) that is running
Debian 9 / Stretch and another (gcc118) with OpenSUSE Leap 15.
In terms of OS version at least, either of those could be viable
for QEMU, if it is possible for you to access them.

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 :|

On Mon, 10 Jun 2019 at 18:30, Daniel P. Berrangé <berrange@redhat.com> wrote:
> Do you have access to any machine in the compile farm or is access
> granted on a per-machine basis ?   If i'm reading this page right:
>
>   https://cfarm.tetaneutral.net/machines/list/
>
> there is now one aarch64 machine (gcc117) that is running
> Debian 9 / Stretch and another (gcc118) with OpenSUSE Leap 15.
> In terms of OS version at least, either of those could be viable
> for QEMU, if it is possible for you to access them.

They're all available, but those machines have less RAM and
fewer CPUs; I think the A1100 is also not as powerful as the X-Gene.
I'm pretty sure Linaro has access to something better than that,
but it will take me a bit to find out and set up to use it.
(I do actually have a Mustang board myself but it's running
the aarch32 builds and I'd prefer not to make it also do the
aarch64 builds at the same time.)

thanks
-- PMM

On Mon, Jun 10, 2019 at 06:38:05PM +0100, Peter Maydell wrote:
> On Mon, 10 Jun 2019 at 18:30, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > Do you have access to any machine in the compile farm or is access
> > granted on a per-machine basis ?   If i'm reading this page right:
> >
> >   https://cfarm.tetaneutral.net/machines/list/
> >
> > there is now one aarch64 machine (gcc117) that is running
> > Debian 9 / Stretch and another (gcc118) with OpenSUSE Leap 15.
> > In terms of OS version at least, either of those could be viable
> > for QEMU, if it is possible for you to access them.
> 
> They're all available, but those machines have less RAM and
> fewer CPUs; I think the A1100 is also not as powerful as the X-Gene.
> I'm pretty sure Linaro has access to something better than that,
> but it will take me a bit to find out and set up to use it.
> (I do actually have a Mustang board myself but it's running
> the aarch32 builds and I'd prefer not to make it also do the
> aarch64 builds at the same time.)

Ok, thanks for the explanation.


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 :|

On Mon, Jun 10, 2019 at 02:21:57PM +0100, Peter Maydell wrote:
> On Mon, 10 Jun 2019 at 14:11, Eduardo Habkost <ehabkost@redhat.com> wrote:
> >
> > On Mon, Jun 10, 2019 at 01:58:50PM +0100, Peter Maydell wrote:
> > > Hi. This fails to build on one of my buildtest machines:
> > >
> > > ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
> > >        Use --python=/path/to/python to specify a supported Python.
> > >
> > > The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> > > box; it's one of the gcc compile farm machines so upgrades to its
> > > OS are not really under my control.)
> >
> > Ubuntu 16.04 LTS (Xenial) was released in April 2016.  Doesn't
> > that mean Trusty is not a supported build platform since April
> > 2018?
> 
> Possibly, but as I say the gcc compile farm is what it is.
> Regardless of the strict letter of the deprecation policy,
> when we start running into issues with the set of build test
> machines I tend to feel we may be being a bit over-hasty in
> deprecating things.

I understand this as a request to make Trusty a supported build
platform.  Can we please update the documentation to reflect
that, then?

-- 
Eduardo

On Mon, Jun 10, 2019 at 01:58:50PM +0100, Peter Maydell wrote:
> On Fri, 7 Jun 2019 at 22:16, Eduardo Habkost <ehabkost@redhat.com> wrote:
> >
> > The following changes since commit 185b7ccc11354cbd69b6d53bf8d831dd964f6c88:
> >
> >   Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190607-2' into staging (2019-06-07 15:24:13 +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 8297719709f1339506d6da93ec69e6118ace8676:
> >
> >   travis: Make check-acceptance job more verbose (2019-06-07 18:11:02 -0300)
> >
> > ----------------------------------------------------------------
> > Python queue, 2019-06-07
> >
> > * New boot_linux_console test cases (Philippe Mathieu-Daudé)
> > * Deprecate Python 2 support (Eduardo Habkost)
> > * Require python3 >= 3.5 (Eduardo Habkost)
> > * Make check-acceptance Travis job more verbose (Eduardo Habkost)
> >
> > ----------------------------------------------------------------
> 
> Hi. This fails to build on one of my buildtest machines:
> 
> ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
>        Use --python=/path/to/python to specify a supported Python.
> 
> The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> box; it's one of the gcc compile farm machines so upgrades to its
> OS are not really under my control.)
> 
> The configure check also spits out deprecation warnings for
> the NetBSD/FreeBSD/OpenBSD tests/vm configurations. It would be nice
> to get those updated.

CCing the test/vm maintainers.

Fam, Alex, are you able to fix this and create new BSD VM images
with Python 3 available?  I thought the VM image configurations
were stored in the source tree, but they are downloaded from
download.patchew.org.

-- 
Eduardo

On Mon, Jul 01, 2019 at 07:25:27PM -0300, Eduardo Habkost wrote:
> On Mon, Jun 10, 2019 at 01:58:50PM +0100, Peter Maydell wrote:
> > On Fri, 7 Jun 2019 at 22:16, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > >
> > > The following changes since commit 185b7ccc11354cbd69b6d53bf8d831dd964f6c88:
> > >
> > >   Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190607-2' into staging (2019-06-07 15:24:13 +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 8297719709f1339506d6da93ec69e6118ace8676:
> > >
> > >   travis: Make check-acceptance job more verbose (2019-06-07 18:11:02 -0300)
> > >
> > > ----------------------------------------------------------------
> > > Python queue, 2019-06-07
> > >
> > > * New boot_linux_console test cases (Philippe Mathieu-Daudé)
> > > * Deprecate Python 2 support (Eduardo Habkost)
> > > * Require python3 >= 3.5 (Eduardo Habkost)
> > > * Make check-acceptance Travis job more verbose (Eduardo Habkost)
> > >
> > > ----------------------------------------------------------------
> > 
> > Hi. This fails to build on one of my buildtest machines:
> > 
> > ERROR: Cannot use 'python3', Python 2 >= 2.7 or Python 3 >= 3.5 is required.
> >        Use --python=/path/to/python to specify a supported Python.
> > 
> > The machine has python 2.7.6 and 3.4.3. (It's an Ubuntu trusty
> > box; it's one of the gcc compile farm machines so upgrades to its
> > OS are not really under my control.)
> > 
> > The configure check also spits out deprecation warnings for
> > the NetBSD/FreeBSD/OpenBSD tests/vm configurations. It would be nice
> > to get those updated.
> 
> CCing the test/vm maintainers.
> 
> Fam, Alex, are you able to fix this and create new BSD VM images
> with Python 3 available?  I thought the VM image configurations
> were stored in the source tree, but they are downloaded from
> download.patchew.org.

Fam, Alex, can you help us on this?  Python 2 won't be supported
anymore, so we need the VM images to be updated.

-- 
Eduardo