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 <ehabk...@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.mayd...@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.gk4...@habkost.net/ -- Eduardo
