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 KAttachment:
signature.asc
Description: This is a digitally signed message part.