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