Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #9570 > unrolled thread

Python3.6 plans​ for Buster

Back to article view | Back to linux.debian.maint.python

Contents

  Python3.6 plans​ for Buster Scott Kitterman <debian@kitterman.com> - 2017-06-17 06:30 +0200
    Re: Python3.6 plans​ for Buster Steve Langasek <vorlon@debian.org> - 2017-06-17 07:30 +0200
      Re: Python3.6 plans​ for Buster Steve Langasek <vorlon@debian.org> - 2017-06-17 07:30 +0200
        Re: Python3.6 plans​ for Buster Scott Kitterman <debian@kitterman.com> - 2017-06-17 08:00 +0200
    Re: Python3.6 plans  for Buster Barry Warsaw <barry@debian.org> - 2017-06-17 08:50 +0200
    Re: Python3.6 plans​ for Buster Scott Kitterman <debian@kitterman.com> - 2017-06-23 20:10 +0200
      Re: Python3.6 plans​ for Buster Michael Hudson-Doyle <michael.hudson@canonical.com> - 2017-06-26 04:10 +0200
      Re: Python3.6 plans​ for Buster Scott Kitterman <debian@kitterman.com> - 2017-06-29 05:20 +0200
        Re: Python3.6 plans​ for Buster Scott Kitterman <debian@kitterman.com> - 2017-07-05 06:30 +0200
          Bug#866335: Python3.6 plans​ for Buster Emilio Pozuelo Monfort <pochu@debian.org> - 2017-07-05 10:30 +0200
            Re: Bug#866335: Python3.6 plans​ for Buster Scott Kitterman <debian@kitterman.com> - 2017-07-05 14:10 +0200
        Re: Python3.6 plans​ for Buster Matthias Klose <doko@debian.org> - 2017-10-22 12:50 +0200

#9570 — 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 and​I think the sooner the better.

Scott K

[toc] | [next] | [standalone]

#9571

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jun 17, 2017 at 04:20:27AM +0000, 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 and​I 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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@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.

[toc] | [prev] | [next] | [standalone]

#9572

[Multipart message — attachments visible in raw view] — view raw

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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[toc] | [prev] | [next] | [standalone]

#9573

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#9574 — 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 and​I 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/

[toc] | [prev] | [next] | [standalone]

#9584

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

[toc] | [prev] | [next] | [standalone]

#9588

[Multipart message — attachments visible in raw view] — view raw

On 24 June 2017 at 06:09, Scott Kitterman <debian@kitterman.com> 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

[toc] | [prev] | [next] | [standalone]

#9597

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#9606

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#9608 — 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: because shiboken FTBFS, pyside has not been binNMUed.
> 
> Many of these packages are team maintained.  Please jump in and help out where 
> you can.  

Did you usertag these bugs?

Cheers,
Emilio

[toc] | [prev] | [next] | [standalone]

#9612 — 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.
> 
> > 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.
> 
> Did you usertag these bugs?

I have now.  I added them to the existing debian-python@lists.debian.org 
python3.6 usertag.

Scott K

[toc] | [prev] | [next] | [standalone]

#9945

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web