qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 0/8] Python queue, 2019-06-07


From: John Snow
Subject: Re: [Qemu-devel] [PULL 0/8] Python queue, 2019-06-07
Date: Tue, 17 Sep 2019 19:10:13 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0


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 <address@hidden> wrote:
>>>>>
>>>>> On Tue, Jun 11, 2019 at 04:50:34PM +0100, Peter Maydell wrote:
>>>>>> On Mon, 10 Jun 2019 at 13:58, Peter Maydell <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]