Re: Python3.6 plans for Buster
On 29.06.2017 05:19, Scott Kitterman wrote: > On Friday, June 23, 2017 02:09:34 PM Scott Kitterman wrote: >> On Saturday, June 17, 2017 04:20:27 AM Scott Kitterman wrote: >>> Python3.6 is already in Unstable and I expect to see it in Testing soon >>> after Stretch is released. >>> >>> I've just now uploaded a version of python3-defaults to Experimental that >>> adds python3.6 as as supported (but not default) python3. If you have >>> binary extensions packaged, please start testing with this version to make >>> sure your package builds correctly with both python3.5 and python3.6 as >>> supported. >>> >>> As a reminder (and for anyone new) we'll do the transition to python3.6 in >>> >>> three stages: >>> - Add python3.6 as supported and rebuild all binary extensions to support >>> >>> both python3.5 and python3.6 >>> >>> - Switch to python3.6 as default >>> >>> - Drop python3.5 from supported and rebuild again to remove python3.5 >>> >>> support. >> >> Unless I've missed something, I've not heard back from anyone indicating >> significant issues that would warrant not taking the first step in this plan >> (I'm aware astropy may have some problems, but that's it). >> >> My plan is to ask the release team for a transition tracker and start the >> first part of this in Unstable once they've agreed. If anyone thinks this >> is premature, please let me know. > > Unless I brown bagged the upload somehow, this is started now. > > https://release.debian.org/transitions/html/python3.6.html The defaults change to 3.6 is now available in unstable, pending issues can be seen here: https://release.debian.org/transitions/html/python3.6-default.html - cantor: fixed in experimental - libkolab: fixed in experimental - python-escript: #878496, test failures on 32bit - pyside: multiple RC issues - s3ql: #877204, test failures - yt: #873511, fixed in new upstream Matthias
Re: Bug#866335: Python3.6 plans for Buster
On Wednesday, July 05, 2017 10:24:26 AM Emilio Pozuelo Monfort wrote:
> Hi Scott,
>
> On 05/07/17 06:25, Scott Kitterman wrote:
> > On Wednesday, June 28, 2017 11:19:37 PM Scott Kitterman wrote:
> >> On Friday, June 23, 2017 02:09:34 PM Scott Kitterman wrote:
> >>> On Saturday, June 17, 2017 04:20:27 AM Scott Kitterman wrote:
> > ...
> >
> As a reminder (and for anyone new) we'll do the transition to python3.6
>
> in three stages:
> - Add python3.6 as supported and rebuild all binary extensions to
> support
> >
> > ...
> >
> >>> Unless I've missed something, I've not heard back from anyone indicating
> >>> significant issues that would warrant not taking the first step in this
> >>> plan (I'm aware astropy may have some problems, but that's it).
> >>>
> >>> My plan is to ask the release team for a transition tracker and start
> >>> the
> >>> first part of this in Unstable once they've agreed. If anyone thinks
> >>> this
> >>> is premature, please let me know.
> >>
> >> Unless I brown bagged the upload somehow, this is started now.
> >>
> >> https://release.debian.org/transitions/html/python3.6.html
> >
> > Status update:
> Thanks for the update. Very comprehensive.
>
> > Python3-defaults with python3.5 and python3.6 as supported versions is in
> > Buster, but python3.6 for the entire ecosystem is not.
> >
> > All binNMUs have been scheduled and the one arch:all sourceful upload
> > that's needed is complete. According to the release team's tracker the
> > transition is 85% complete. There are roughly five classes of things in
> > the remaining 15%:
> >
> > 1. Builds for leaf packages that are scheduled, but not complete.
> > Nothing
> > needs to be done for these. The slow architectures will catch up
> > eventually.
> >
> > 2. Packages which are RC buggy because they can't currently be built on
> > some (or all archs) for reasons unrelated to python3.6. It would be good
> > to NMU to fix these if people have time, but they might not be the best
> > use of Python packaging oriented people's time.
> > #866536 jpy FTBFS on mips/mipsel: 1 Python unit test(s) failed.
> > Installation is likely broken.
> > #839760 xcffib: FTBFS on big-endian architectures: assert reply.value.
> > to_atoms() == (wm_delete_window, )
> > #839314 xcffib: FTBFS: xcffibgen: Invalid bitCase: QName {qName =
> > "required_start_align", qURI = Nothing, qPrefix = Nothing}
> > #866543 xcffib: FTBFS after switch to having python3.6 supported
> > #867018 python-pysam FTBFS with libhts-dev 1.4.1-2
> > #813083 pyviennacl: FTBFS: src/ viennacl/vector.h:225:34: error: no
> > matches
> > converting function ‘project’ to type ‘class viennacl::vector ...
> > #854195 yt FTBFS on armel/armhf: testsuite MemoryErrors
> > #867197 yt: FTBFS on ppc64el: test failure
> > #864443 pytables: ftbfs on armhf
> > #867028 uvloop FTBFS on armel/armhf: Test_UV_UnixSSL.
> > test_create_unix_server_ssl_1 fails
> >
> > 3. Packages which now FTBFS due to adding python3.6.
> > #866575 libapache2-mod-wsgi-py3: Impossible depends when built with more
> > then one supported python3 version
> > #862380 khmer: FTBFS with Python 3.6
> > #862805 protobuf: tests fail with Python 3.6
> > #866694 pythonmagick: FTBFS with python3.6 as a supported python3
> > #866696 python-pyeclib: FTBFS on mips64el due to test failures after
> > rebuild with python3.6
> > #865224 uwsgi: ftbfs with multiple supported python3 versions
> > #866547 python-biomaj3: FTBFS with python3.6 as a supported version
> > #864327 shiboken: extend test skipping hack to python 3.6
> >
> > 4. Packages which declare build-depends on python3-all-dev but do not
> > build for all python3 verions or don't set their dependencies correctly.
> > #866412 cinnamon-screensaver: Excessive and hard coded depends complicate
> > python3 transition
> > #866504 django-compat: Excessive build-depends complicate python3
> > transition (maybe rm is the best solution here)
> > #866555 gpgme1.0: Build for all python3 versions or change build-dep
> > #866514 ngs.sdk: Excessive build-depends complicate python3 transition
> > #866700 pcp: Only builds for default python3 version
> > #866528 python-biotools: Inappropriate use of arch:any vice arch:all
> > #799635 python-characteristic: Uses python3-all-dev build-dep when
> > python3-all is all that's needed
> > #866533 python-dictobj: Package is arch any when it should be arch all
> > #867010 python-cassandra-river: Please build for all supported python3
> > versions
> > #800709 gcc-python-plugin: Should build-dep on python3-dev vice all-dev
> > #867243 python3-astroml: Missing python3 interpreter depends
> >
> > 5. Things needing further research/work:
> > python-pbr, nuitka, and pyopenssl are all packages with arch:all content
> > that need access to Python.h. Is there a way to have them not show up as
> > part of transition?
>
> We can't filter by architecture afaik. We can hardcode some packages but I'd
> rather not do that.
>
Re: Bug#866335: Python3.6 plans for Buster
Hi Scott,
On 05/07/17 06:25, Scott Kitterman wrote:
> On Wednesday, June 28, 2017 11:19:37 PM Scott Kitterman wrote:
>> On Friday, June 23, 2017 02:09:34 PM Scott Kitterman wrote:
>>> On Saturday, June 17, 2017 04:20:27 AM Scott Kitterman wrote:
> ...
As a reminder (and for anyone new) we'll do the transition to python3.6
in three stages:
- Add python3.6 as supported and rebuild all binary extensions to
support
> ...
>>> Unless I've missed something, I've not heard back from anyone indicating
>>> significant issues that would warrant not taking the first step in this
>>> plan (I'm aware astropy may have some problems, but that's it).
>>>
>>> My plan is to ask the release team for a transition tracker and start the
>>> first part of this in Unstable once they've agreed. If anyone thinks this
>>> is premature, please let me know.
>>
>> Unless I brown bagged the upload somehow, this is started now.
>>
>> https://release.debian.org/transitions/html/python3.6.html
>
> Status update:
Thanks for the update. Very comprehensive.
>
> Python3-defaults with python3.5 and python3.6 as supported versions is in
> Buster, but python3.6 for the entire ecosystem is not.
>
> All binNMUs have been scheduled and the one arch:all sourceful upload that's
> needed is complete. According to the release team's tracker the transition
> is
> 85% complete. There are roughly five classes of things in the remaining 15%:
>
> 1. Builds for leaf packages that are scheduled, but not complete. Nothing
> needs to be done for these. The slow architectures will catch up eventually.
>
> 2. Packages which are RC buggy because they can't currently be built on some
> (or all archs) for reasons unrelated to python3.6. It would be good to NMU
> to
> fix these if people have time, but they might not be the best use of Python
> packaging oriented people's time.
> #866536 jpy FTBFS on mips/mipsel: 1 Python unit test(s) failed. Installation
> is likely broken.
> #839760 xcffib: FTBFS on big-endian architectures: assert reply.value.
> to_atoms() == (wm_delete_window, )
> #839314 xcffib: FTBFS: xcffibgen: Invalid bitCase: QName {qName =
> "required_start_align", qURI = Nothing, qPrefix = Nothing}
> #866543 xcffib: FTBFS after switch to having python3.6 supported
> #867018 python-pysam FTBFS with libhts-dev 1.4.1-2
> #813083 pyviennacl: FTBFS: src/ viennacl/vector.h:225:34: error: no matches
> converting function ‘project’ to type ‘class viennacl::vector ...
> #854195 yt FTBFS on armel/armhf: testsuite MemoryErrors
> #867197 yt: FTBFS on ppc64el: test failure
> #864443 pytables: ftbfs on armhf
> #867028 uvloop FTBFS on armel/armhf: Test_UV_UnixSSL.
> test_create_unix_server_ssl_1 fails
>
> 3. Packages which now FTBFS due to adding python3.6.
> #866575 libapache2-mod-wsgi-py3: Impossible depends when built with more then
> one supported python3 version
> #862380 khmer: FTBFS with Python 3.6
> #862805 protobuf: tests fail with Python 3.6
> #866694 pythonmagick: FTBFS with python3.6 as a supported python3
> #866696 python-pyeclib: FTBFS on mips64el due to test failures after rebuild
> with python3.6
> #865224 uwsgi: ftbfs with multiple supported python3 versions
> #866547 python-biomaj3: FTBFS with python3.6 as a supported version
> #864327 shiboken: extend test skipping hack to python 3.6
>
> 4. Packages which declare build-depends on python3-all-dev but do not build
> for all python3 verions or don't set their dependencies correctly.
> #866412 cinnamon-screensaver: Excessive and hard coded depends complicate
> python3 transition
> #866504 django-compat: Excessive build-depends complicate python3 transition
> (maybe rm is the best solution here)
> #866555 gpgme1.0: Build for all python3 versions or change build-dep
> #866514 ngs.sdk: Excessive build-depends complicate python3 transition
> #866700 pcp: Only builds for default python3 version
> #866528 python-biotools: Inappropriate use of arch:any vice arch:all
> #799635 python-characteristic: Uses python3-all-dev build-dep when
> python3-all
> is all that's needed
> #866533 python-dictobj: Package is arch any when it should be arch all
> #867010 python-cassandra-river: Please build for all supported python3
> versions
> #800709 gcc-python-plugin: Should build-dep on python3-dev vice all-dev
> #867243 python3-astroml: Missing python3 interpreter depends
>
> 5. Things needing further research/work:
> python-pbr, nuitka, and pyopenssl are all packages with arch:all content that
> need access to Python.h. Is there a way to have them not show up as part of
> transition?
We can't filter by architecture afaik. We can hardcode some packages but I'd
rather not do that.
> Some packages that depend on python3-all-dev, but don't end up depending on
> python3 (<< python3.7) after binNMU still need investigation: eccodes, grib-
> api, python-escript, lasagne, sunpy
> pycuda (contrib) needs binary upload to rebuild, not autobuilt
>
> Note: becaus
Re: Python3.6 plans for Buster
On Wednesday, June 28, 2017 11:19:37 PM Scott Kitterman wrote:
> On Friday, June 23, 2017 02:09:34 PM Scott Kitterman wrote:
> > On Saturday, June 17, 2017 04:20:27 AM Scott Kitterman wrote:
...
> > > As a reminder (and for anyone new) we'll do the transition to python3.6
> > > in three stages:
> > > - Add python3.6 as supported and rebuild all binary extensions to
> > > support
...
> > Unless I've missed something, I've not heard back from anyone indicating
> > significant issues that would warrant not taking the first step in this
> > plan (I'm aware astropy may have some problems, but that's it).
> >
> > My plan is to ask the release team for a transition tracker and start the
> > first part of this in Unstable once they've agreed. If anyone thinks this
> > is premature, please let me know.
>
> Unless I brown bagged the upload somehow, this is started now.
>
> https://release.debian.org/transitions/html/python3.6.html
Status update:
Python3-defaults with python3.5 and python3.6 as supported versions is in
Buster, but python3.6 for the entire ecosystem is not.
All binNMUs have been scheduled and the one arch:all sourceful upload that's
needed is complete. According to the release team's tracker the transition is
85% complete. There are roughly five classes of things in the remaining 15%:
1. Builds for leaf packages that are scheduled, but not complete. Nothing
needs to be done for these. The slow architectures will catch up eventually.
2. Packages which are RC buggy because they can't currently be built on some
(or all archs) for reasons unrelated to python3.6. It would be good to NMU to
fix these if people have time, but they might not be the best use of Python
packaging oriented people's time.
#866536 jpy FTBFS on mips/mipsel: 1 Python unit test(s) failed. Installation
is likely broken.
#839760 xcffib: FTBFS on big-endian architectures: assert reply.value.
to_atoms() == (wm_delete_window, )
#839314 xcffib: FTBFS: xcffibgen: Invalid bitCase: QName {qName =
"required_start_align", qURI = Nothing, qPrefix = Nothing}
#866543 xcffib: FTBFS after switch to having python3.6 supported
#867018 python-pysam FTBFS with libhts-dev 1.4.1-2
#813083 pyviennacl: FTBFS: src/ viennacl/vector.h:225:34: error: no matches
converting function ‘project’ to type ‘class viennacl::vector ...
#854195 yt FTBFS on armel/armhf: testsuite MemoryErrors
#867197 yt: FTBFS on ppc64el: test failure
#864443 pytables: ftbfs on armhf
#867028 uvloop FTBFS on armel/armhf: Test_UV_UnixSSL.
test_create_unix_server_ssl_1 fails
3. Packages which now FTBFS due to adding python3.6.
#866575 libapache2-mod-wsgi-py3: Impossible depends when built with more then
one supported python3 version
#862380 khmer: FTBFS with Python 3.6
#862805 protobuf: tests fail with Python 3.6
#866694 pythonmagick: FTBFS with python3.6 as a supported python3
#866696 python-pyeclib: FTBFS on mips64el due to test failures after rebuild
with python3.6
#865224 uwsgi: ftbfs with multiple supported python3 versions
#866547 python-biomaj3: FTBFS with python3.6 as a supported version
#864327 shiboken: extend test skipping hack to python 3.6
4. Packages which declare build-depends on python3-all-dev but do not build
for all python3 verions or don't set their dependencies correctly.
#866412 cinnamon-screensaver: Excessive and hard coded depends complicate
python3 transition
#866504 django-compat: Excessive build-depends complicate python3 transition
(maybe rm is the best solution here)
#866555 gpgme1.0: Build for all python3 versions or change build-dep
#866514 ngs.sdk: Excessive build-depends complicate python3 transition
#866700 pcp: Only builds for default python3 version
#866528 python-biotools: Inappropriate use of arch:any vice arch:all
#799635 python-characteristic: Uses python3-all-dev build-dep when python3-all
is all that's needed
#866533 python-dictobj: Package is arch any when it should be arch all
#867010 python-cassandra-river: Please build for all supported python3
versions
#800709 gcc-python-plugin: Should build-dep on python3-dev vice all-dev
#867243 python3-astroml: Missing python3 interpreter depends
5. Things needing further research/work:
python-pbr, nuitka, and pyopenssl are all packages with arch:all content that
need access to Python.h. Is there a way to have them not show up as part of
transition?
Some packages that depend on python3-all-dev, but don't end up depending on
python3 (<< python3.7) after binNMU still need investigation: eccodes, grib-
api, python-escript, lasagne, sunpy
pycuda (contrib) needs binary upload to rebuild, not autobuilt
Note: because shiboken FTBFS, pyside has not been binNMUed.
Many of these packages are team maintained. Please jump in and help out where
you can.
Scott K
signature.asc
Description: This is a digitally signed message part.
Re: Python3.6 plans for Buster
On Friday, June 23, 2017 02:09:34 PM Scott Kitterman wrote: > On Saturday, June 17, 2017 04:20:27 AM Scott Kitterman wrote: > > Python3.6 is already in Unstable and I expect to see it in Testing soon > > after Stretch is released. > > > > I've just now uploaded a version of python3-defaults to Experimental that > > adds python3.6 as as supported (but not default) python3. If you have > > binary extensions packaged, please start testing with this version to make > > sure your package builds correctly with both python3.5 and python3.6 as > > supported. > > > > As a reminder (and for anyone new) we'll do the transition to python3.6 in > > > > three stages: > > - Add python3.6 as supported and rebuild all binary extensions to support > > > > both python3.5 and python3.6 > > > > - Switch to python3.6 as default > > > > - Drop python3.5 from supported and rebuild again to remove python3.5 > > > > support. > > Unless I've missed something, I've not heard back from anyone indicating > significant issues that would warrant not taking the first step in this plan > (I'm aware astropy may have some problems, but that's it). > > My plan is to ask the release team for a transition tracker and start the > first part of this in Unstable once they've agreed. If anyone thinks this > is premature, please let me know. Unless I brown bagged the upload somehow, this is started now. https://release.debian.org/transitions/html/python3.6.html Scott K signature.asc Description: This is a digitally signed message part.
Re: Python3.6 plans for Buster
On 24 June 2017 at 06:09, Scott Kitterman wrote: > On Saturday, June 17, 2017 04:20:27 AM Scott Kitterman wrote: > > Python3.6 is already in Unstable and I expect to see it in Testing soon > > after Stretch is released. > > > > I've just now uploaded a version of python3-defaults to Experimental that > > adds python3.6 as as supported (but not default) python3. If you have > > binary extensions packaged, please start testing with this version to > make > > sure your package builds correctly with both python3.5 and python3.6 as > > supported. > > > > As a reminder (and for anyone new) we'll do the transition to python3.6 > in > > three stages: > > > > - Add python3.6 as supported and rebuild all binary extensions to > support > > both python3.5 and python3.6 > > > > - Switch to python3.6 as default > > > > - Drop python3.5 from supported and rebuild again to remove python3.5 > > support. > > Unless I've missed something, I've not heard back from anyone indicating > significant issues that would warrant not taking the first step in this > plan > (I'm aware astropy may have some problems, but that's it). > > My plan is to ask the release team for a transition tracker and start the > first part of this in Unstable once they've agreed. If anyone thinks this > is > premature, please let me know. > As I'm currently going through all this in Ubuntu, I'd much rather be able to work on the problems in Debian rather than having lots of delta pile up so the sooner the better from my POV! Cheers, mwh
Re: Python3.6 plans for Buster
On Saturday, June 17, 2017 04:20:27 AM Scott Kitterman wrote: > Python3.6 is already in Unstable and I expect to see it in Testing soon > after Stretch is released. > > I've just now uploaded a version of python3-defaults to Experimental that > adds python3.6 as as supported (but not default) python3. If you have > binary extensions packaged, please start testing with this version to make > sure your package builds correctly with both python3.5 and python3.6 as > supported. > > As a reminder (and for anyone new) we'll do the transition to python3.6 in > three stages: > > - Add python3.6 as supported and rebuild all binary extensions to support > both python3.5 and python3.6 > > - Switch to python3.6 as default > > - Drop python3.5 from supported and rebuild again to remove python3.5 > support. Unless I've missed something, I've not heard back from anyone indicating significant issues that would warrant not taking the first step in this plan (I'm aware astropy may have some problems, but that's it). My plan is to ask the release team for a transition tracker and start the first part of this in Unstable once they've agreed. If anyone thinks this is premature, please let me know. Scott K
Re: Python3.6 plans for Buster
On Jun 17, 2017, at 04:20 AM, Scott Kitterman wrote: >Last time I compared my understanding of the Buster schedule with the >python3.7 schedule, I recall concluding that we'd likely be on python3.6 for >the Buster release (not sure that's still true). If so, we only have to do >this once this cycle andI think the sooner the better. Thanks for bringing this up Scott, and thanks for the additional information about Ubuntu's transition Steve. For sure, Debian should make 3.6 default as soon as possible in Buster. But we may indeed get to 3.7 by the time Buster is released. According to PEP 537 [*], 3.7.0 final is schedule for almost exactly 1 year from now, on 2018-06-15. So if Buster is approximately 2 years out from now, then we'll need to do more transition, and have plenty of time for it. (Aside: it does mean Ubuntu's next LTS will carry 3.6.) Cheers, -Barry [*] https://www.python.org/dev/peps/pep-0537/
Re: Python3.6 plans for Buster
On Friday, June 16, 2017 10:27:34 PM Steve Langasek wrote: > On Fri, Jun 16, 2017 at 10:23:06PM -0700, Steve Langasek wrote: > > [1] pytables is a failure specific to Ubuntu armhf buildds which raise > > SIGBUS, this should not affect Debian. python-astropy rebuilds with no > > problem, but doesn't pick up python3.6 support. > > To clarify: python-astropy builds an astropy-utils package that winds up > with /usr/bin/python3.5 as an interpreter instead of /usr/bin/python3. So > that's a bug, and worth fixing, but it seemed non-trivial and the package > could be dealt with by just having one extra no-change rebuild later in the > transition. Thanks, Please document this in the Debian BTS (if you haven't - it's late here and I"m tired, so not checking right now), so we'll have it documented when the time comes. Scott K signature.asc Description: This is a digitally signed message part.
Re: Python3.6 plans for Buster
On Fri, Jun 16, 2017 at 10:23:06PM -0700, Steve Langasek wrote: > [1] pytables is a failure specific to Ubuntu armhf buildds which raise > SIGBUS, this should not affect Debian. python-astropy rebuilds with no > problem, but doesn't pick up python3.6 support. To clarify: python-astropy builds an astropy-utils package that winds up with /usr/bin/python3.5 as an interpreter instead of /usr/bin/python3. So that's a bug, and worth fixing, but it seemed non-trivial and the package could be dealt with by just having one extra no-change rebuild later in the transition. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Python3.6 plans for Buster
On Sat, Jun 17, 2017 at 04:20:27AM +, Scott Kitterman wrote: > Python3.6 is already in Unstable and I expect to see it in Testing soon > after Stretch is released. > I've just now uploaded a version of python3-defaults to Experimental that > adds python3.6 as as supported (but not default) python3. If you have > binary extensions packaged, please start testing with this version to make > sure your package builds correctly with both python3.5 and python3.6 as > supported. > As a reminder (and for anyone new) we'll do the transition to python3.6 in > three stages: > - Add python3.6 as supported and rebuild all binary extensions to support >both python3.5 and python3.6 > - Switch to python3.6 as default > - Drop python3.5 from supported and rebuild again to remove python3.5 >support. > Last time I compared my understanding of the Buster schedule with the > python3.7 schedule, I recall concluding that we'd likely be on python3.6 > for the Buster release (not sure that's still true). If so, we only have > to do this once this cycle andI think the sooner the better. FYI, Ubuntu has already started this transition for the upcoming 17.10 release. Python3.6 has been added as a supported version, and a transition tracker (à la the Debian release team) of the remaining issues - with some false positives - can be found here: https://people.canonical.com/~ubuntu-archive/transitions/html/python3.5-6.html A more detailed analysis of the remaining packages can be found here: http://pad.ubuntu.com/q0xuETZmdn This basically comes down to only three packages that need fixed in both Debian and Ubuntu - uwsgi, pandas, and photutils.[1] All other packages that FTBFS with python3.6 added as supported should already have patches filed in the Debian BTS. The rebuild with python3.6 as default is also now in progress for Ubuntu; test build results can be seen here: https://launchpad.net/~canonical-foundations/+archive/ubuntu/python3.6-as-default Hope that helps, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] pytables is a failure specific to Ubuntu armhf buildds which raise SIGBUS, this should not affect Debian. python-astropy rebuilds with no problem, but doesn't pick up python3.6 support. signature.asc Description: PGP signature
Python3.6 plans for Buster
Python3.6 is already in Unstable and I expect to see it in Testing soon after Stretch is released. I've just now uploaded a version of python3-defaults to Experimental that adds python3.6 as as supported (but not default) python3. If you have binary extensions packaged, please start testing with this version to make sure your package builds correctly with both python3.5 and python3.6 as supported. As a reminder (and for anyone new) we'll do the transition to python3.6 in three stages: - Add python3.6 as supported and rebuild all binary extensions to support both python3.5 and python3.6 - Switch to python3.6 as default - Drop python3.5 from supported and rebuild again to remove python3.5 support. Last time I compared my understanding of the Buster schedule with the python3.7 schedule, I recall concluding that we'd likely be on python3.6 for the Buster release (not sure that's still true). If so, we only have to do this once this cycle andI think the sooner the better. Scott K
