Python 3.5 EOL; when can require 3.6?

Python 3.5 EOL; when can require 3.6?

[Markus Armbruster]

We require Python 3.5.  It will reach its "end of life" at the end of
September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
already does for its Python parts.


[*] https://www.python.org/downloads/release/python-3510/

Re: Python 3.5 EOL; when can require 3.6?

[Philippe Mathieu-Daudé]

On 9/16/20 9:43 AM, Markus Armbruster wrote:
> We require Python 3.5.  It will reach its "end of life" at the end of
> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> already does for its Python parts.
> 
> 
> [*] https://www.python.org/downloads/release/python-3510/

Not answering your question, but it would help to start a table
of "oldest package released" versions, with our supported distributions
as columns and package names as row.

This way when new distributions are released (and oldest dropped from
our side) we can add/remove a column and see the oldest version we aim
to support.

Regards,

Phil.

Re: Python 3.5 EOL; when can require 3.6?

[Thomas Huth]

On 16/09/2020 09.43, Markus Armbruster wrote:
> We require Python 3.5.  It will reach its "end of life" at the end of
> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> already does for its Python parts.

I think the only reason for requiring Python 3.5 is that we still use
Ubuntu Xenial in Travis. We don't support Xenial according to our
support policy anymore, but we did not update to Bionic there since it
has that broken version of libssh.

Fortunately, since a couple of weeks, Travis now supports Focal, too, so
once we switched our .travis.yml to use Focal, I think we could start
requiring Python 3.6.

 Thomas

Re: Python 3.5 EOL; when can require 3.6?

[Thomas Huth]

On 16/09/2020 09.53, Philippe Mathieu-Daudé wrote:
> On 9/16/20 9:43 AM, Markus Armbruster wrote:
>> We require Python 3.5.  It will reach its "end of life" at the end of
>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>> already does for its Python parts.
>>
>>
>> [*] https://www.python.org/downloads/release/python-3510/
> 
> Not answering your question, but it would help to start a table
> of "oldest package released" versions, with our supported distributions
> as columns and package names as row.
> 
> This way when new distributions are released (and oldest dropped from
> our side) we can add/remove a column and see the oldest version we aim
> to support.

That's quite a bit of extra work - I think it's enough to look up the
versions on repology instead, e.g.:

https://repology.org/project/python/versions

 Thomas

Re: Python 3.5 EOL; when can require 3.6?

[Philippe Mathieu-Daudé]

On 9/16/20 10:02 AM, Thomas Huth wrote:
> On 16/09/2020 09.53, Philippe Mathieu-Daudé wrote:
>> On 9/16/20 9:43 AM, Markus Armbruster wrote:
>>> We require Python 3.5.  It will reach its "end of life" at the end of
>>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>>> already does for its Python parts.
>>>
>>>
>>> [*] https://www.python.org/downloads/release/python-3510/
>>
>> Not answering your question, but it would help to start a table
>> of "oldest package released" versions, with our supported distributions
>> as columns and package names as row.
>>
>> This way when new distributions are released (and oldest dropped from
>> our side) we can add/remove a column and see the oldest version we aim
>> to support.
> 
> That's quite a bit of extra work - I think it's enough to look up the
> versions on repology instead, e.g.:
> 
> https://repology.org/project/python/versions

Clever :) So maybe we can script that.

> 
>  Thomas
> 

Re: Python 3.5 EOL; when can require 3.6?

[Andrea Bolognani]

On Wed, 2020-09-16 at 09:53 +0200, Philippe Mathieu-Daudé wrote:
> On 9/16/20 9:43 AM, Markus Armbruster wrote:
> > We require Python 3.5.  It will reach its "end of life" at the end of
> > September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> > already does for its Python parts.
> 
> Not answering your question, but it would help to start a table
> of "oldest package released" versions, with our supported distributions
> as columns and package names as row.
> 
> This way when new distributions are released (and oldest dropped from
> our side) we can add/remove a column and see the oldest version we aim
> to support.

In case you're not already aware of it, https://repology.org/ is a
very valuable tool when it comes to figuring out minimum versions for
dependencies.

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: Python 3.5 EOL; when can require 3.6?

[Daniel P. Berrangé]

On Wed, Sep 16, 2020 at 09:43:10AM +0200, Markus Armbruster wrote:
> We require Python 3.5.  It will reach its "end of life" at the end of
> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> already does for its Python parts.

Note that upstream EOL dates aren't directly relevant. Our policy for
min versions of dependancies is driven by what is present in the various
distro platforms we're aiming to support, and its possible distros will
support it beyond official upstream EOL.

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

Re: Python 3.5 EOL; when can require 3.6?

[Daniel P. Berrangé]

On Wed, Sep 16, 2020 at 09:54:32AM +0200, Thomas Huth wrote:
> On 16/09/2020 09.43, Markus Armbruster wrote:
> > We require Python 3.5.  It will reach its "end of life" at the end of
> > September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> > already does for its Python parts.
> 
> I think the only reason for requiring Python 3.5 is that we still use
> Ubuntu Xenial in Travis. We don't support Xenial according to our
> support policy anymore, but we did not update to Bionic there since it
> has that broken version of libssh.
> 
> Fortunately, since a couple of weeks, Travis now supports Focal, too, so
> once we switched our .travis.yml to use Focal, I think we could start
> requiring Python 3.6.

Note we really should not be constrained by what Travis provides as
images. Travis images provide docker, so we can spawn our Travis
jobs inside containers to get arbitrary linux distros. We did this
for libvirt for a while until we switched to GitLab CI. So we
definitely don't need to care about Xenial from a Travis POV no
matter what.

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

Re: Python 3.5 EOL; when can require 3.6?

[Thomas Huth]

On 16/09/2020 10.33, Daniel P. Berrangé wrote:
> On Wed, Sep 16, 2020 at 09:54:32AM +0200, Thomas Huth wrote:
>> On 16/09/2020 09.43, Markus Armbruster wrote:
>>> We require Python 3.5.  It will reach its "end of life" at the end of
>>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>>> already does for its Python parts.
>>
>> I think the only reason for requiring Python 3.5 is that we still use
>> Ubuntu Xenial in Travis. We don't support Xenial according to our
>> support policy anymore, but we did not update to Bionic there since it
>> has that broken version of libssh.
>>
>> Fortunately, since a couple of weeks, Travis now supports Focal, too, so
>> once we switched our .travis.yml to use Focal, I think we could start
>> requiring Python 3.6.
> 
> Note we really should not be constrained by what Travis provides as
> images. Travis images provide docker, so we can spawn our Travis
> jobs inside containers to get arbitrary linux distros. We did this
> for libvirt for a while until we switched to GitLab CI. So we
> definitely don't need to care about Xenial from a Travis POV no
> matter what.

I hope we could finally exploit the possibility to use KVM on Travis ...
that won't be possible anymore once we use containers there.

 Thomas

Re: Python 3.5 EOL; when can require 3.6?

[Daniel P. Berrangé]

On Wed, Sep 16, 2020 at 11:50:06AM +0200, Thomas Huth wrote:
> On 16/09/2020 10.33, Daniel P. Berrangé wrote:
> > On Wed, Sep 16, 2020 at 09:54:32AM +0200, Thomas Huth wrote:
> >> On 16/09/2020 09.43, Markus Armbruster wrote:
> >>> We require Python 3.5.  It will reach its "end of life" at the end of
> >>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> >>> already does for its Python parts.
> >>
> >> I think the only reason for requiring Python 3.5 is that we still use
> >> Ubuntu Xenial in Travis. We don't support Xenial according to our
> >> support policy anymore, but we did not update to Bionic there since it
> >> has that broken version of libssh.
> >>
> >> Fortunately, since a couple of weeks, Travis now supports Focal, too, so
> >> once we switched our .travis.yml to use Focal, I think we could start
> >> requiring Python 3.6.
> > 
> > Note we really should not be constrained by what Travis provides as
> > images. Travis images provide docker, so we can spawn our Travis
> > jobs inside containers to get arbitrary linux distros. We did this
> > for libvirt for a while until we switched to GitLab CI. So we
> > definitely don't need to care about Xenial from a Travis POV no
> > matter what.
> 
> I hope we could finally exploit the possibility to use KVM on Travis ...
> that won't be possible anymore once we use containers there.

Do they forbid passing the /dev/kvm device node into the docker
container ? I would have though that would be allowed, since using
KVM inside docker is no worse than using it outside docker in the
Travis env.

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

Re: Python 3.5 EOL; when can require 3.6?

[Thomas Huth]

On 16/09/2020 11.54, Daniel P. Berrangé wrote:
> On Wed, Sep 16, 2020 at 11:50:06AM +0200, Thomas Huth wrote:
>> On 16/09/2020 10.33, Daniel P. Berrangé wrote:
>>> On Wed, Sep 16, 2020 at 09:54:32AM +0200, Thomas Huth wrote:
>>>> On 16/09/2020 09.43, Markus Armbruster wrote:
>>>>> We require Python 3.5.  It will reach its "end of life" at the end of
>>>>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>>>>> already does for its Python parts.
>>>>
>>>> I think the only reason for requiring Python 3.5 is that we still use
>>>> Ubuntu Xenial in Travis. We don't support Xenial according to our
>>>> support policy anymore, but we did not update to Bionic there since it
>>>> has that broken version of libssh.
>>>>
>>>> Fortunately, since a couple of weeks, Travis now supports Focal, too, so
>>>> once we switched our .travis.yml to use Focal, I think we could start
>>>> requiring Python 3.6.
>>>
>>> Note we really should not be constrained by what Travis provides as
>>> images. Travis images provide docker, so we can spawn our Travis
>>> jobs inside containers to get arbitrary linux distros. We did this
>>> for libvirt for a while until we switched to GitLab CI. So we
>>> definitely don't need to care about Xenial from a Travis POV no
>>> matter what.
>>
>> I hope we could finally exploit the possibility to use KVM on Travis ...
>> that won't be possible anymore once we use containers there.
> 
> Do they forbid passing the /dev/kvm device node into the docker
> container ? I would have though that would be allowed, since using
> KVM inside docker is no worse than using it outside docker in the
> Travis env.

Maybe ... I'm just a complete ignorant in this area ;-)

 Thomas

Re: Python 3.5 EOL; when can require 3.6?

[Peter Maydell]

On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
> We require Python 3.5.  It will reach its "end of life" at the end of
> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> already does for its Python parts.

I think these things really ought to start with the converse question:
what is the important new thing that 3.6 brings to the table that
makes it worth moving our minimum requirement forward ?
If our code still works on 3.5 and there's nothing we really want to
do to the code that would be awkward to do without insisting on
3.6, why should we irritate users by arbitrarily bumping the version
requirement ?

Also as Dan notes upstream's EOL policies aren't very relevant,
because our policy is based on what distros ship.

My broader point of view: C does not have any kind of infrastructure
like Rust's cargo or node's npm that makes it easy for a project to
say "we depend on these versions of these other packages" and
have them be satisified in a fairly painless-to-the-end-user/distro
way. So I prefer to take the approach of being as conservative as
possible about what we depend on, because the alternative tends
to be either pain for the person trying to compile QEMU (when they
have to scrabble around finding and building dependencies they
don't have conveniently to hand) or pain for us (when we have
to ship a dependency as a submodule). The default should be
"leave the version dependency where it is", not "bump the version
dependency as soon as we can".

thanks
-- PMM

Re: Python 3.5 EOL; when can require 3.6?

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
>> We require Python 3.5.  It will reach its "end of life" at the end of
>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>> already does for its Python parts.
>
> I think these things really ought to start with the converse question:
> what is the important new thing that 3.6 brings to the table that
> makes it worth moving our minimum requirement forward ?

I'm chiefly after PEP 526 "Syntax for Variable Annotations" for much
saner type hints.  John's "[PATCH 00/37] qapi: static typing conversion
pt1" already uses it, because not using it results in illegible code.

Nice to have: PEP 498 "Literal String Interpolation" may let us improve
QAPI code geneator readability.  I haven't tried, yet.

<https://www.python.org/dev/peps/pep-0494/#features-for-3-6> has the
full list of new features.

> If our code still works on 3.5 and there's nothing we really want to
> do to the code that would be awkward to do without insisting on
> 3.6, why should we irritate users by arbitrarily bumping the version
> requirement ?
>
> Also as Dan notes upstream's EOL policies aren't very relevant,
> because our policy is based on what distros ship.
>
> My broader point of view: C does not have any kind of infrastructure
> like Rust's cargo or node's npm that makes it easy for a project to
> say "we depend on these versions of these other packages" and
> have them be satisified in a fairly painless-to-the-end-user/distro
> way. So I prefer to take the approach of being as conservative as
> possible about what we depend on, because the alternative tends
> to be either pain for the person trying to compile QEMU (when they
> have to scrabble around finding and building dependencies they
> don't have conveniently to hand) or pain for us (when we have
> to ship a dependency as a submodule). The default should be
> "leave the version dependency where it is", not "bump the version
> dependency as soon as we can".

Understood.

Anyone writing Python code in QEMU has paid a price for this policy.  I
certainly did.  I'm okay with that as long as it helps more than it
hurts.

Lack of sane type hints is hurting QAPI developement.

I believe requiring 3.6 will hurt QEMU less than hobbled QAPI
development.

Re: Python 3.5 EOL; when can require 3.6?

[Alex Bennée]

Thomas Huth <thuth@redhat.com> writes:

> On 16/09/2020 09.53, Philippe Mathieu-Daudé wrote:
>> On 9/16/20 9:43 AM, Markus Armbruster wrote:
>>> We require Python 3.5.  It will reach its "end of life" at the end of
>>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>>> already does for its Python parts.
>>>
>>>
>>> [*] https://www.python.org/downloads/release/python-3510/
>> 
>> Not answering your question, but it would help to start a table
>> of "oldest package released" versions, with our supported distributions
>> as columns and package names as row.
>> 
>> This way when new distributions are released (and oldest dropped from
>> our side) we can add/remove a column and see the oldest version we aim
>> to support.
>
> That's quite a bit of extra work - I think it's enough to look up the
> versions on repology instead, e.g.:
>
> https://repology.org/project/python/versions

Hmm are there any magic runes to limit the list to only the distros we
care about?

-- 
Alex Bennée

Re: Python 3.5 EOL; when can require 3.6?

[Daniel P. Berrangé]

On Wed, Sep 16, 2020 at 02:53:55PM +0100, Alex Bennée wrote:
> 
> Thomas Huth <thuth@redhat.com> writes:
> 
> > On 16/09/2020 09.53, Philippe Mathieu-Daudé wrote:
> >> On 9/16/20 9:43 AM, Markus Armbruster wrote:
> >>> We require Python 3.5.  It will reach its "end of life" at the end of
> >>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> >>> already does for its Python parts.
> >>>
> >>>
> >>> [*] https://www.python.org/downloads/release/python-3510/
> >> 
> >> Not answering your question, but it would help to start a table
> >> of "oldest package released" versions, with our supported distributions
> >> as columns and package names as row.
> >> 
> >> This way when new distributions are released (and oldest dropped from
> >> our side) we can add/remove a column and see the oldest version we aim
> >> to support.
> >
> > That's quite a bit of extra work - I think it's enough to look up the
> > versions on repology instead, e.g.:
> >
> > https://repology.org/project/python/versions
> 
> Hmm are there any magic runes to limit the list to only the distros we
> care about?

No, thats the hard bit. Basically have to search through the list looking
for the two most recent versions of RHEL, Ubuntu, Debian, Fedora, etc

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

Re: Python 3.5 EOL; when can require 3.6?

[Thomas Huth]

On 16/09/2020 14.30, Peter Maydell wrote:
> On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
>> We require Python 3.5.  It will reach its "end of life" at the end of
>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>> already does for its Python parts.
[...]
> The default should be
> "leave the version dependency where it is", not "bump the version
> dependency as soon as we can".

OTOH, if none of our supported build systems uses python 3.5 by default
anymore, it also will not get tested anymore, so bugs might creep in,
which will of course end up in a bad experience for the users, too, that
still try to build with such an old version. So limiting the version to
the level that we also test is IMHO very reasonable.

Let's have a look at the (older) systems that we support and the python
versions according to repology.org:

- RHEL7 / CentOS 7 : 3.6.8
- Ubuntu 18.04 (Bionic) : >= 3.6.5
- openSUSE Leap 15.0 : >= 3.6.5
- OpenBSD Ports : >= 3.7.9
- FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer
- Homebrew : >= 3.7.9

... so I think it should be fine to retire 3.5 nowadays.

 Thomas

Re: Python 3.5 EOL; when can require 3.6?

[Daniel P. Berrangé]

On Wed, Sep 16, 2020 at 04:00:14PM +0200, Thomas Huth wrote:
> On 16/09/2020 14.30, Peter Maydell wrote:
> > On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
> >> We require Python 3.5.  It will reach its "end of life" at the end of
> >> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> >> already does for its Python parts.
> [...]
> > The default should be
> > "leave the version dependency where it is", not "bump the version
> > dependency as soon as we can".
> 
> OTOH, if none of our supported build systems uses python 3.5 by default
> anymore, it also will not get tested anymore, so bugs might creep in,
> which will of course end up in a bad experience for the users, too, that
> still try to build with such an old version. So limiting the version to
> the level that we also test is IMHO very reasonable.
> 
> Let's have a look at the (older) systems that we support and the python
> versions according to repology.org:
> 
> - RHEL7 / CentOS 7 : 3.6.8
> - Ubuntu 18.04 (Bionic) : >= 3.6.5
> - openSUSE Leap 15.0 : >= 3.6.5
> - OpenBSD Ports : >= 3.7.9
> - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer

"pkg install python3" will give you python 3.7 right now.

> - Homebrew : >= 3.7.9
> 
> ... so I think it should be fine to retire 3.5 nowadays.

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

Re: Python 3.5 EOL; when can require 3.6?

[John Snow]

On 9/16/20 10:00 AM, Thomas Huth wrote:
> On 16/09/2020 14.30, Peter Maydell wrote:
>> On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
>>> We require Python 3.5.  It will reach its "end of life" at the end of
>>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>>> already does for its Python parts.
> [...]
>> The default should be
>> "leave the version dependency where it is", not "bump the version
>> dependency as soon as we can".
> 
> OTOH, if none of our supported build systems uses python 3.5 by default
> anymore, it also will not get tested anymore, so bugs might creep in,
> which will of course end up in a bad experience for the users, too, that
> still try to build with such an old version. So limiting the version to
> the level that we also test is IMHO very reasonable.
> 
> Let's have a look at the (older) systems that we support and the python
> versions according to repology.org:
> 
> - RHEL7 / CentOS 7 : 3.6.8
> - Ubuntu 18.04 (Bionic) : >= 3.6.5
> - openSUSE Leap 15.0 : >= 3.6.5
> - OpenBSD Ports : >= 3.7.9
> - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer
> - Homebrew : >= 3.7.9
> 
> ... so I think it should be fine to retire 3.5 nowadays.
> 
>   Thomas
> 

Thanks for researching this! I am going to transplant this into my 
commit message in my QAPI typing series.

Thank you very much!

--js

Re: Python 3.5 EOL; when can require 3.6?

[Eduardo Habkost]

On Wed, Sep 16, 2020 at 09:53:21AM +0200, Philippe Mathieu-Daudé wrote:
> On 9/16/20 9:43 AM, Markus Armbruster wrote:
> > We require Python 3.5.  It will reach its "end of life" at the end of
> > September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> > already does for its Python parts.
> > 
> > 
> > [*] https://www.python.org/downloads/release/python-3510/
> 
> Not answering your question, but it would help to start a table
> of "oldest package released" versions, with our supported distributions
> as columns and package names as row.
> 
> This way when new distributions are released (and oldest dropped from
> our side) we can add/remove a column and see the oldest version we aim
> to support.

I had built this table when we were discussing requiring
Python >= 3.5:
https://wiki.qemu.org/Supported_Build_Platforms

It's outdated, but it shouldn't be difficult to bring it up to
date based on the info Thomas and others posted in this thread.

-- 
Eduardo

Re: Python 3.5 EOL; when can require 3.6?

[Thomas Huth]

On 16/09/2020 16.00, Thomas Huth wrote:
> On 16/09/2020 14.30, Peter Maydell wrote:
>> On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
>>> We require Python 3.5.  It will reach its "end of life" at the end of
>>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>>> already does for its Python parts.
> [...]
>> The default should be
>> "leave the version dependency where it is", not "bump the version
>> dependency as soon as we can".
> 
> OTOH, if none of our supported build systems uses python 3.5 by default
> anymore, it also will not get tested anymore, so bugs might creep in,
> which will of course end up in a bad experience for the users, too, that
> still try to build with such an old version. So limiting the version to
> the level that we also test is IMHO very reasonable.
> 
> Let's have a look at the (older) systems that we support and the python
> versions according to repology.org:
> 
> - RHEL7 / CentOS 7 : 3.6.8
> - Ubuntu 18.04 (Bionic) : >= 3.6.5
> - openSUSE Leap 15.0 : >= 3.6.5
> - OpenBSD Ports : >= 3.7.9
> - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer
> - Homebrew : >= 3.7.9
> 
> ... so I think it should be fine to retire 3.5 nowadays.

Sorry, I forgot to check Debian. If I got that right, Debian 9 still
uses Python 3.5 by default. So I guess that means we can not deprecate
Python 3.5 yet?

 Thomas

Re: Python 3.5 EOL; when can require 3.6?

[Eduardo Habkost]

On Wed, Sep 16, 2020 at 02:57:37PM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 16, 2020 at 02:53:55PM +0100, Alex Bennée wrote:
> > 
> > Thomas Huth <thuth@redhat.com> writes:
> > 
> > > On 16/09/2020 09.53, Philippe Mathieu-Daudé wrote:
> > >> On 9/16/20 9:43 AM, Markus Armbruster wrote:
> > >>> We require Python 3.5.  It will reach its "end of life" at the end of
> > >>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> > >>> already does for its Python parts.
> > >>>
> > >>>
> > >>> [*] https://www.python.org/downloads/release/python-3510/
> > >> 
> > >> Not answering your question, but it would help to start a table
> > >> of "oldest package released" versions, with our supported distributions
> > >> as columns and package names as row.
> > >> 
> > >> This way when new distributions are released (and oldest dropped from
> > >> our side) we can add/remove a column and see the oldest version we aim
> > >> to support.
> > >
> > > That's quite a bit of extra work - I think it's enough to look up the
> > > versions on repology instead, e.g.:
> > >
> > > https://repology.org/project/python/versions
> > 
> > Hmm are there any magic runes to limit the list to only the distros we
> > care about?
> 
> No, thats the hard bit. Basically have to search through the list looking
> for the two most recent versions of RHEL, Ubuntu, Debian, Fedora, etc

I'm using the following command to query Repology from the command line:

 $ curl -s 'https://repology.org/api/v1/project/python' |  \
   jq -r 'group_by(.repo) | .[] | "\(.[0].repo): \(map(.version))"' | \
   egrep -i 'fedora|ubuntu|debian|rhel|centos|bsd|suse|sles'

-- 
Eduardo

Re: Python 3.5 EOL; when can require 3.6?

[Daniel P. Berrangé]

On Thu, Sep 17, 2020 at 04:10:55PM +0200, Thomas Huth wrote:
> On 16/09/2020 16.00, Thomas Huth wrote:
> > On 16/09/2020 14.30, Peter Maydell wrote:
> >> On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
> >>> We require Python 3.5.  It will reach its "end of life" at the end of
> >>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> >>> already does for its Python parts.
> > [...]
> >> The default should be
> >> "leave the version dependency where it is", not "bump the version
> >> dependency as soon as we can".
> > 
> > OTOH, if none of our supported build systems uses python 3.5 by default
> > anymore, it also will not get tested anymore, so bugs might creep in,
> > which will of course end up in a bad experience for the users, too, that
> > still try to build with such an old version. So limiting the version to
> > the level that we also test is IMHO very reasonable.
> > 
> > Let's have a look at the (older) systems that we support and the python
> > versions according to repology.org:
> > 
> > - RHEL7 / CentOS 7 : 3.6.8
> > - Ubuntu 18.04 (Bionic) : >= 3.6.5
> > - openSUSE Leap 15.0 : >= 3.6.5
> > - OpenBSD Ports : >= 3.7.9
> > - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer
> > - Homebrew : >= 3.7.9
> > 
> > ... so I think it should be fine to retire 3.5 nowadays.
> 
> Sorry, I forgot to check Debian. If I got that right, Debian 9 still
> uses Python 3.5 by default. So I guess that means we can not deprecate
> Python 3.5 yet?

FWIW, Debian 9 EOL was July this year, if you only count the regular
lifetime, not the LTS.

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

Re: Python 3.5 EOL; when can require 3.6?

[Thomas Huth]

On 17/09/2020 16.55, Daniel P. Berrangé wrote:
> On Thu, Sep 17, 2020 at 04:10:55PM +0200, Thomas Huth wrote:
>> On 16/09/2020 16.00, Thomas Huth wrote:
>>> On 16/09/2020 14.30, Peter Maydell wrote:
>>>> On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
>>>>> We require Python 3.5.  It will reach its "end of life" at the end of
>>>>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>>>>> already does for its Python parts.
>>> [...]
>>>> The default should be
>>>> "leave the version dependency where it is", not "bump the version
>>>> dependency as soon as we can".
>>>
>>> OTOH, if none of our supported build systems uses python 3.5 by default
>>> anymore, it also will not get tested anymore, so bugs might creep in,
>>> which will of course end up in a bad experience for the users, too, that
>>> still try to build with such an old version. So limiting the version to
>>> the level that we also test is IMHO very reasonable.
>>>
>>> Let's have a look at the (older) systems that we support and the python
>>> versions according to repology.org:
>>>
>>> - RHEL7 / CentOS 7 : 3.6.8
>>> - Ubuntu 18.04 (Bionic) : >= 3.6.5
>>> - openSUSE Leap 15.0 : >= 3.6.5
>>> - OpenBSD Ports : >= 3.7.9
>>> - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer
>>> - Homebrew : >= 3.7.9
>>>
>>> ... so I think it should be fine to retire 3.5 nowadays.
>>
>> Sorry, I forgot to check Debian. If I got that right, Debian 9 still
>> uses Python 3.5 by default. So I guess that means we can not deprecate
>> Python 3.5 yet?
> 
> FWIW, Debian 9 EOL was July this year, if you only count the regular
> lifetime, not the LTS.

Do we support Debian LTS? ... If not, we should maybe add a proper
remark about that to our support policy...?

Also, some of our docker containers (tests/docker/dockerfiles/debian9*)
are still using Debian 9 and are now used in our Gitlab-CI for our MinGW
cross-compiler builds (I think also in the Shippable-CI, but I don't use
that, so not sure about that one) ... if we don't support Debian 9
anymore, we should update these to a newer version. Any volunteers?

 Thomas

Re: Python 3.5 EOL; when can require 3.6?

[Markus Armbruster]

Thomas Huth <thuth@redhat.com> writes:

> On 16/09/2020 16.00, Thomas Huth wrote:
>> On 16/09/2020 14.30, Peter Maydell wrote:
>>> On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
>>>> We require Python 3.5.  It will reach its "end of life" at the end of
>>>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>>>> already does for its Python parts.
>> [...]
>>> The default should be
>>> "leave the version dependency where it is", not "bump the version
>>> dependency as soon as we can".
>> 
>> OTOH, if none of our supported build systems uses python 3.5 by default
>> anymore, it also will not get tested anymore, so bugs might creep in,
>> which will of course end up in a bad experience for the users, too, that
>> still try to build with such an old version. So limiting the version to
>> the level that we also test is IMHO very reasonable.
>> 
>> Let's have a look at the (older) systems that we support and the python
>> versions according to repology.org:
>> 
>> - RHEL7 / CentOS 7 : 3.6.8
>> - Ubuntu 18.04 (Bionic) : >= 3.6.5
>> - openSUSE Leap 15.0 : >= 3.6.5
>> - OpenBSD Ports : >= 3.7.9
>> - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer
>> - Homebrew : >= 3.7.9
>> 
>> ... so I think it should be fine to retire 3.5 nowadays.
>
> Sorry, I forgot to check Debian. If I got that right, Debian 9 still
> uses Python 3.5 by default. So I guess that means we can not deprecate
> Python 3.5 yet?

Discussed before:

    Subject: Re: [PATCH] qapi: Fix code generation with Python 3.5
    Date: Sat, 18 Jan 2020 07:54:18 +0100
    Message-ID: <87lfq5s19h.fsf@dusky.pond.sub.org>
    https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg03855.html

Short version: Debian != Debian LTS.  We support Debian until EOL, not
LTS.  Debian 9 reached EOL in July.

Re: Python 3.5 EOL; when can require 3.6?

[Daniel P. Berrangé]

On Thu, Sep 17, 2020 at 05:24:15PM +0200, Thomas Huth wrote:
> On 17/09/2020 16.55, Daniel P. Berrangé wrote:
> > On Thu, Sep 17, 2020 at 04:10:55PM +0200, Thomas Huth wrote:
> >> On 16/09/2020 16.00, Thomas Huth wrote:
> >>> On 16/09/2020 14.30, Peter Maydell wrote:
> >>>> On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
> >>>>> We require Python 3.5.  It will reach its "end of life" at the end of
> >>>>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> >>>>> already does for its Python parts.
> >>> [...]
> >>>> The default should be
> >>>> "leave the version dependency where it is", not "bump the version
> >>>> dependency as soon as we can".
> >>>
> >>> OTOH, if none of our supported build systems uses python 3.5 by default
> >>> anymore, it also will not get tested anymore, so bugs might creep in,
> >>> which will of course end up in a bad experience for the users, too, that
> >>> still try to build with such an old version. So limiting the version to
> >>> the level that we also test is IMHO very reasonable.
> >>>
> >>> Let's have a look at the (older) systems that we support and the python
> >>> versions according to repology.org:
> >>>
> >>> - RHEL7 / CentOS 7 : 3.6.8
> >>> - Ubuntu 18.04 (Bionic) : >= 3.6.5
> >>> - openSUSE Leap 15.0 : >= 3.6.5
> >>> - OpenBSD Ports : >= 3.7.9
> >>> - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer
> >>> - Homebrew : >= 3.7.9
> >>>
> >>> ... so I think it should be fine to retire 3.5 nowadays.
> >>
> >> Sorry, I forgot to check Debian. If I got that right, Debian 9 still
> >> uses Python 3.5 by default. So I guess that means we can not deprecate
> >> Python 3.5 yet?
> > 
> > FWIW, Debian 9 EOL was July this year, if you only count the regular
> > lifetime, not the LTS.
> 
> Do we support Debian LTS? ... If not, we should maybe add a proper
> remark about that to our support policy...?

I didn't define Debian situation very well in the support policy
because I didn't realize it had separate normal and LTS EOL
dates. I had originally thought it was LTS only.

In libvirt we have since clarified the language I originally
wrote (and then copied to QEMU), to remove the LTS distinction.
Instead libvirt now says:

 "The project aims to support the most recent major version at all
  times. Support for the previous major version will be dropped 2
  years after the new major version is released or when the vendor
  itself drops support, whichever comes first. In this context,
  third-party efforts to extend the lifetime of a distro are not
  considered, even when they are endorsed by the vendor (eg. Debian
  LTS)."

I'd suggest we copy this updated terminolgy into QEMU as it simplifies
the current language used.

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

Re: Python 3.5 EOL; when can require 3.6?

[Thomas Huth]

On 17/09/2020 17.30, Markus Armbruster wrote:
> Thomas Huth <thuth@redhat.com> writes:
> 
>> On 16/09/2020 16.00, Thomas Huth wrote:
>>> On 16/09/2020 14.30, Peter Maydell wrote:
>>>> On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
>>>>> We require Python 3.5.  It will reach its "end of life" at the end of
>>>>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>>>>> already does for its Python parts.
>>> [...]
>>>> The default should be
>>>> "leave the version dependency where it is", not "bump the version
>>>> dependency as soon as we can".
>>>
>>> OTOH, if none of our supported build systems uses python 3.5 by default
>>> anymore, it also will not get tested anymore, so bugs might creep in,
>>> which will of course end up in a bad experience for the users, too, that
>>> still try to build with such an old version. So limiting the version to
>>> the level that we also test is IMHO very reasonable.
>>>
>>> Let's have a look at the (older) systems that we support and the python
>>> versions according to repology.org:
>>>
>>> - RHEL7 / CentOS 7 : 3.6.8
>>> - Ubuntu 18.04 (Bionic) : >= 3.6.5
>>> - openSUSE Leap 15.0 : >= 3.6.5
>>> - OpenBSD Ports : >= 3.7.9
>>> - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer
>>> - Homebrew : >= 3.7.9
>>>
>>> ... so I think it should be fine to retire 3.5 nowadays.
>>
>> Sorry, I forgot to check Debian. If I got that right, Debian 9 still
>> uses Python 3.5 by default. So I guess that means we can not deprecate
>> Python 3.5 yet?
> 
> Discussed before:
> 
>     Subject: Re: [PATCH] qapi: Fix code generation with Python 3.5
>     Date: Sat, 18 Jan 2020 07:54:18 +0100
>     Message-ID: <87lfq5s19h.fsf@dusky.pond.sub.org>
>     https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg03855.html
> 
> Short version: Debian != Debian LTS.  We support Debian until EOL, not
> LTS.  Debian 9 reached EOL in July.

Ok, so could you please add a remark to docs/system/build-platforms.rst
that states that we do not support Debian LTS ... otherwise I guess we
will have discussion again once Debian 10 reaches its EOL.

 Thanks,
  Thomas

Re: Python 3.5 EOL; when can require 3.6?

[Thomas Huth]

On 17/09/2020 17.39, Daniel P. Berrangé wrote:
> On Thu, Sep 17, 2020 at 05:24:15PM +0200, Thomas Huth wrote:
>> On 17/09/2020 16.55, Daniel P. Berrangé wrote:
>>> On Thu, Sep 17, 2020 at 04:10:55PM +0200, Thomas Huth wrote:
>>>> On 16/09/2020 16.00, Thomas Huth wrote:
>>>>> On 16/09/2020 14.30, Peter Maydell wrote:
>>>>>> On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
>>>>>>> We require Python 3.5.  It will reach its "end of life" at the end of
>>>>>>> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
>>>>>>> already does for its Python parts.
>>>>> [...]
>>>>>> The default should be
>>>>>> "leave the version dependency where it is", not "bump the version
>>>>>> dependency as soon as we can".
>>>>>
>>>>> OTOH, if none of our supported build systems uses python 3.5 by default
>>>>> anymore, it also will not get tested anymore, so bugs might creep in,
>>>>> which will of course end up in a bad experience for the users, too, that
>>>>> still try to build with such an old version. So limiting the version to
>>>>> the level that we also test is IMHO very reasonable.
>>>>>
>>>>> Let's have a look at the (older) systems that we support and the python
>>>>> versions according to repology.org:
>>>>>
>>>>> - RHEL7 / CentOS 7 : 3.6.8
>>>>> - Ubuntu 18.04 (Bionic) : >= 3.6.5
>>>>> - openSUSE Leap 15.0 : >= 3.6.5
>>>>> - OpenBSD Ports : >= 3.7.9
>>>>> - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer
>>>>> - Homebrew : >= 3.7.9
>>>>>
>>>>> ... so I think it should be fine to retire 3.5 nowadays.
>>>>
>>>> Sorry, I forgot to check Debian. If I got that right, Debian 9 still
>>>> uses Python 3.5 by default. So I guess that means we can not deprecate
>>>> Python 3.5 yet?
>>>
>>> FWIW, Debian 9 EOL was July this year, if you only count the regular
>>> lifetime, not the LTS.
>>
>> Do we support Debian LTS? ... If not, we should maybe add a proper
>> remark about that to our support policy...?
> 
> I didn't define Debian situation very well in the support policy
> because I didn't realize it had separate normal and LTS EOL
> dates. I had originally thought it was LTS only.
> 
> In libvirt we have since clarified the language I originally
> wrote (and then copied to QEMU), to remove the LTS distinction.
> Instead libvirt now says:
> 
>  "The project aims to support the most recent major version at all
>   times. Support for the previous major version will be dropped 2
>   years after the new major version is released or when the vendor
>   itself drops support, whichever comes first. In this context,
>   third-party efforts to extend the lifetime of a distro are not
>   considered, even when they are endorsed by the vendor (eg. Debian
>   LTS)."
> 
> I'd suggest we copy this updated terminolgy into QEMU as it simplifies
> the current language used.

Sounds good, could you (or Markus) please provide a patch?

 Thanks,
  Thomas

Re: Python 3.5 EOL; when can require 3.6?

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

On Thu, Sep 17, 2020 at 9:37 AM Markus Armbruster <armbru@redhat.com> wrote:

> Thomas Huth <thuth@redhat.com> writes:
>
> > On 16/09/2020 16.00, Thomas Huth wrote:
> >> On 16/09/2020 14.30, Peter Maydell wrote:
> >>> On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com>
> wrote:
> >>>> We require Python 3.5.  It will reach its "end of life" at the end of
> >>>> September 2020[*].  Any reason not to require 3.6 for 5.2?
> qemu-iotests
> >>>> already does for its Python parts.
> >> [...]
> >>> The default should be
> >>> "leave the version dependency where it is", not "bump the version
> >>> dependency as soon as we can".
> >>
> >> OTOH, if none of our supported build systems uses python 3.5 by default
> >> anymore, it also will not get tested anymore, so bugs might creep in,
> >> which will of course end up in a bad experience for the users, too, that
> >> still try to build with such an old version. So limiting the version to
> >> the level that we also test is IMHO very reasonable.
> >>
> >> Let's have a look at the (older) systems that we support and the python
> >> versions according to repology.org:
> >> - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer
>

FreeBSD Ports can specify, on a per-port basis, which version of Python to
use:

USES= python:3.6+

So we're good there for all supported FreeBSD versions (11.x, 12.x and
-current).

Warner

[-- Attachment #2: Type: text/html, Size: 2234 bytes --]

Re: Python 3.5 EOL; when can require 3.6?

[Andrea Bolognani]

On Thu, 2020-09-17 at 17:30 +0200, Markus Armbruster wrote:
> Thomas Huth <thuth@redhat.com> writes:
> > Sorry, I forgot to check Debian. If I got that right, Debian 9 still
> > uses Python 3.5 by default. So I guess that means we can not deprecate
> > Python 3.5 yet?
> 
> Discussed before:
> 
>     Subject: Re: [PATCH] qapi: Fix code generation with Python 3.5
>     Date: Sat, 18 Jan 2020 07:54:18 +0100
>     Message-ID: <87lfq5s19h.fsf@dusky.pond.sub.org>
>     https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg03855.html
> 
> Short version: Debian != Debian LTS.  We support Debian until EOL, not
> LTS.  Debian 9 reached EOL in July.

FWIW, this is the same policy the libvirt project follows, and we
have formalized it at

  https://libvirt.org/platforms.html

with Debian LTS being called out explicitly as not supported.

It would be *fantastic* if we could keep the platform support policy
used by QEMU and libvirt as aligned as reasonably possible.

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: Python 3.5 EOL; when can require 3.6?

[Eduardo Habkost]

On Wed, Sep 16, 2020 at 04:00:14PM +0200, Thomas Huth wrote:
> On 16/09/2020 14.30, Peter Maydell wrote:
> > On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
> >> We require Python 3.5.  It will reach its "end of life" at the end of
> >> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> >> already does for its Python parts.
> [...]
> > The default should be
> > "leave the version dependency where it is", not "bump the version
> > dependency as soon as we can".
> 
> OTOH, if none of our supported build systems uses python 3.5 by default
> anymore, it also will not get tested anymore, so bugs might creep in,
> which will of course end up in a bad experience for the users, too, that
> still try to build with such an old version. So limiting the version to
> the level that we also test is IMHO very reasonable.
> 
> Let's have a look at the (older) systems that we support and the python
> versions according to repology.org:
> 
> - RHEL7 / CentOS 7 : 3.6.8
> - Ubuntu 18.04 (Bionic) : >= 3.6.5
> - openSUSE Leap 15.0 : >= 3.6.5
> - OpenBSD Ports : >= 3.7.9
> - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer
> - Homebrew : >= 3.7.9
> 
> ... so I think it should be fine to retire 3.5 nowadays.

Thank you very much for the summary.  I've added this info to
https://wiki.qemu.org/Supported_Build_Platforms

Has anybody been able to find information om SLES Python
versions?  I can't find this anywhere.

-- 
Eduardo

Re: Python 3.5 EOL; when can require 3.6?

[Daniel P. Berrangé]

On Thu, Sep 17, 2020 at 12:19:19PM -0400, Eduardo Habkost wrote:
> On Wed, Sep 16, 2020 at 04:00:14PM +0200, Thomas Huth wrote:
> > On 16/09/2020 14.30, Peter Maydell wrote:
> > > On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
> > >> We require Python 3.5.  It will reach its "end of life" at the end of
> > >> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> > >> already does for its Python parts.
> > [...]
> > > The default should be
> > > "leave the version dependency where it is", not "bump the version
> > > dependency as soon as we can".
> > 
> > OTOH, if none of our supported build systems uses python 3.5 by default
> > anymore, it also will not get tested anymore, so bugs might creep in,
> > which will of course end up in a bad experience for the users, too, that
> > still try to build with such an old version. So limiting the version to
> > the level that we also test is IMHO very reasonable.
> > 
> > Let's have a look at the (older) systems that we support and the python
> > versions according to repology.org:
> > 
> > - RHEL7 / CentOS 7 : 3.6.8
> > - Ubuntu 18.04 (Bionic) : >= 3.6.5
> > - openSUSE Leap 15.0 : >= 3.6.5
> > - OpenBSD Ports : >= 3.7.9
> > - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer
> > - Homebrew : >= 3.7.9
> > 
> > ... so I think it should be fine to retire 3.5 nowadays.
> 
> Thank you very much for the summary.  I've added this info to
> https://wiki.qemu.org/Supported_Build_Platforms
> 
> Has anybody been able to find information om SLES Python
> versions?  I can't find this anywhere.

It is slightly tedious, but I was pointed at

  https://scc.suse.com/api/package_search/products

where you find the product ID.

eg SLES 15  is ID 1609

which you can plug into

https://scc.suse.com/api/package_search/packages?product_id=1609&amp;query=python

and that somes some package names like "libpython3_6" so 3.6.5
looks like a match,

This looks like it matches openSUSE Leap 15, which suggest we
probably don't need to look at SLES directly.


SLES 15 was released in July 2018, so with our 2 year overlap for the
previous release, we can consider SLES 12sp2 unsupported from this
release cycle.

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

Re: Python 3.5 EOL; when can require 3.6?

[Daniel P. Berrangé]

On Thu, Sep 17, 2020 at 06:07:00PM +0200, Andrea Bolognani wrote:
> On Thu, 2020-09-17 at 17:30 +0200, Markus Armbruster wrote:
> > Thomas Huth <thuth@redhat.com> writes:
> > > Sorry, I forgot to check Debian. If I got that right, Debian 9 still
> > > uses Python 3.5 by default. So I guess that means we can not deprecate
> > > Python 3.5 yet?
> > 
> > Discussed before:
> > 
> >     Subject: Re: [PATCH] qapi: Fix code generation with Python 3.5
> >     Date: Sat, 18 Jan 2020 07:54:18 +0100
> >     Message-ID: <87lfq5s19h.fsf@dusky.pond.sub.org>
> >     https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg03855.html
> > 
> > Short version: Debian != Debian LTS.  We support Debian until EOL, not
> > LTS.  Debian 9 reached EOL in July.
> 
> FWIW, this is the same policy the libvirt project follows, and we
> have formalized it at
> 
>   https://libvirt.org/platforms.html
> 
> with Debian LTS being called out explicitly as not supported.
> 
> It would be *fantastic* if we could keep the platform support policy
> used by QEMU and libvirt as aligned as reasonably possible.

The current QEMU policy was a copy+paste of the same policy I wrote for
libvirt originally, just adding OpenBSD/NetBSD.

I've just posted an update for QEMU which matches the latest libvirt
policy, again just adding the extra BSDs.

https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg06371.html

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

Re: Python 3.5 EOL; when can require 3.6?

[Eduardo Habkost]

On Thu, Sep 17, 2020 at 05:33:15PM +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 17, 2020 at 12:19:19PM -0400, Eduardo Habkost wrote:
> > On Wed, Sep 16, 2020 at 04:00:14PM +0200, Thomas Huth wrote:
> > > On 16/09/2020 14.30, Peter Maydell wrote:
> > > > On Wed, 16 Sep 2020 at 08:43, Markus Armbruster <armbru@redhat.com> wrote:
> > > >> We require Python 3.5.  It will reach its "end of life" at the end of
> > > >> September 2020[*].  Any reason not to require 3.6 for 5.2?  qemu-iotests
> > > >> already does for its Python parts.
> > > [...]
> > > > The default should be
> > > > "leave the version dependency where it is", not "bump the version
> > > > dependency as soon as we can".
> > > 
> > > OTOH, if none of our supported build systems uses python 3.5 by default
> > > anymore, it also will not get tested anymore, so bugs might creep in,
> > > which will of course end up in a bad experience for the users, too, that
> > > still try to build with such an old version. So limiting the version to
> > > the level that we also test is IMHO very reasonable.
> > > 
> > > Let's have a look at the (older) systems that we support and the python
> > > versions according to repology.org:
> > > 
> > > - RHEL7 / CentOS 7 : 3.6.8
> > > - Ubuntu 18.04 (Bionic) : >= 3.6.5
> > > - openSUSE Leap 15.0 : >= 3.6.5
> > > - OpenBSD Ports : >= 3.7.9
> > > - FreeBSD Ports : >= 3.5.10 - but there is also 3.6 or newer
> > > - Homebrew : >= 3.7.9
> > > 
> > > ... so I think it should be fine to retire 3.5 nowadays.
> > 
> > Thank you very much for the summary.  I've added this info to
> > https://wiki.qemu.org/Supported_Build_Platforms
> > 
> > Has anybody been able to find information om SLES Python
> > versions?  I can't find this anywhere.
> 
> It is slightly tedious, but I was pointed at
> 
>   https://scc.suse.com/api/package_search/products
> 
> where you find the product ID.
> 
> eg SLES 15  is ID 1609
> 
> which you can plug into
> 
> https://scc.suse.com/api/package_search/packages?product_id=1609&amp;query=python

Thanks!

> 
> and that somes some package names like "libpython3_6" so 3.6.5
> looks like a match,

$ curl -s 'https://scc.suse.com/api/package_search/packages?product_id=1609&query=python' | \
  jq -r '.data[] | select(.name | match("^python[0-9]*$")) | "\(.name) \(.version) \(.arch)"'
python 2.7.17 x86_64
python 2.7.14 x86_64
python 2.7.14 x86_64
python 2.7.14 x86_64
python 2.7.14 x86_64
python 2.7.14 x86_64
python 2.7.14 x86_64
python 2.7.14 x86_64
python 2.7.14 x86_64
python3 3.6.9 x86_64
python3 3.6.8 x86_64
python3 3.6.8 x86_64
python3 3.6.5 x86_64
python3 3.6.5 x86_64
python3 3.6.5 x86_64
python3 3.6.5 x86_64
python3 3.6.10 x86_64

I've updated the wiki with 3.6.10.

> 
> This looks like it matches openSUSE Leap 15, which suggest we
> probably don't need to look at SLES directly.
> 
> 
> SLES 15 was released in July 2018, so with our 2 year overlap for the
> previous release, we can consider SLES 12sp2 unsupported from this
> release cycle.

I've updated the wiki to indicate that.  Thanks for the reminder.

-- 
Eduardo

Re: Python 3.5 EOL; when can require 3.6?

[Andrea Bolognani]

On Thu, 2020-09-17 at 17:35 +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 17, 2020 at 06:07:00PM +0200, Andrea Bolognani wrote:
> > It would be *fantastic* if we could keep the platform support policy
> > used by QEMU and libvirt as aligned as reasonably possible.
> 
> The current QEMU policy was a copy+paste of the same policy I wrote for
> libvirt originally, just adding OpenBSD/NetBSD.
> 
> I've just posted an update for QEMU which matches the latest libvirt
> policy, again just adding the extra BSDs.
> 
> https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg06371.html

That's even better than I hoped for! Thank you so much :)

-- 
Andrea Bolognani / Red Hat / Virtualization