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
