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