Path: csiph.com!goblin3!goblin2!goblin.stu.neva.ru!aioe.org!bofh.it!news.nic.it!robomod
From: Scott Kitterman <debian@kitterman.com>
Newsgroups: linux.debian.maint.python
Subject: Re: Bug#866335: Python3.6 =?UTF-8?B?cGxhbnPigIs=?= for Buster
Date: Wed, 05 Jul 2017 14:10:02 +0200
Message-ID: <tZRi2-62l-11@gated-at.bofh.it>
References: <tTdwZ-1P2-1@gated-at.bofh.it> <tZK6R-1kH-11@gated-at.bofh.it> <tZNR8-3Oe-15@gated-at.bofh.it>
Old-Return-Path: <debian@kitterman.com>
User-Agent: KMail/4.13.3 (Linux/3.13.0-121-generic; KDE/4.13.3; x86_64; ; )
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Approved: robomod@news.nic.it
Lines: 160
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
Xref: csiph.com linux.debian.maint.python:9612

On Wednesday, July 05, 2017 10:24:26 AM Emilio Pozuelo Monfort wrote:
> Hi Scott,
>=20
> 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:
> > ...
> >=20
> >>>> As a reminder (and for anyone new) we'll do the transition to py=
thon3.6
> >>>>=20
> >>>> in three stages:
> >>>>  - Add python3.6 as supported and rebuild all binary extensions =
to
> >>>>  support
> >=20
> > ...
> >=20
> >>> Unless I've missed something, I've not heard back from anyone ind=
icating
> >>> significant issues that would warrant not taking the first step i=
n this
> >>> plan (I'm aware astropy may have some problems, but that's it).
> >>>=20
> >>> My plan is to ask the release team for a transition tracker and s=
tart
> >>> the
> >>> first part of this in Unstable once they've agreed.  If anyone th=
inks
> >>> this
> >>> is premature, please let me know.
> >>=20
> >> Unless I brown bagged the upload somehow, this is started now.
> >>=20
> >> https://release.debian.org/transitions/html/python3.6.html
> >=20
> > Status update:
> Thanks for the update. Very comprehensive.
>=20
> > Python3-defaults with python3.5 and python3.6 as supported versions=
 is in
> > Buster, but python3.6 for the entire ecosystem is not.
> >=20
> > All binNMUs have been scheduled and the one arch:all sourceful uplo=
ad
> > that's needed is complete.  According to the release team's tracker=
 the
> > transition is 85% complete.  There are roughly five classes of thin=
gs in
> > the remaining 15%:
> >=20
> > 1.  Builds for leaf packages that are scheduled, but not complete.=20=

> > Nothing
> > needs to be done for these.  The slow architectures will catch up
> > eventually.
> >=20
> > 2.  Packages which are RC buggy because they can't currently be bui=
lt on
> > some (or all archs) for reasons unrelated to python3.6.  It would b=
e 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.val=
ue.
> > to_atoms() =3D=3D (wm_delete_window, )
> > #839314 xcffib: FTBFS: xcffibgen: Invalid bitCase: QName {qName =3D=

> > "required_start_align", qURI =3D Nothing, qPrefix =3D 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 =C3=A2=E2=82=AC=CB=9Cproject=C3=A2=E2=82=AC=E2=84=
=A2 to type =C3=A2=E2=82=AC=CB=9Cclass 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
> >=20
> > 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 afte=
r
> > 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
> >=20
> > 4.  Packages which declare build-depends on python3-all-dev but do =
not
> > build for all python3 verions or don't set their dependencies corre=
ctly.
> > #866412 cinnamon-screensaver: Excessive and hard coded depends comp=
licate
> > 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-de=
p
> > #866514 ngs.sdk: Excessive build-depends complicate python3 transit=
ion
> > #866700 pcp: Only builds for default python3 version
> > #866528 python-biotools: Inappropriate use of arch:any vice arch:al=
l
> > #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 pyth=
on3
> > versions
> > #800709 gcc-python-plugin: Should build-dep on python3-dev vice all=
-dev
> > #867243 python3-astroml: Missing python3 interpreter depends
> >=20
> > 5.  Things needing further research/work:
> > python-pbr, nuitka, and pyopenssl are all packages with arch:all co=
ntent
> > that need access to Python.h.  Is there a way to have them not show=
 up as
> > part of transition?
>=20
> We can't filter by architecture afaik. We can hardcode some packages =
but I'd
> rather not do that.
>=20
> > Some packages that depend on python3-all-dev, but don't end up depe=
nding
> > on
> > python3 (<< python3.7) after binNMU still need investigation: eccod=
es,
> > grib- api, python-escript, lasagne, sunpy
> > pycuda (contrib) needs binary upload to rebuild, not autobuilt
> >=20
> > Note: because shiboken FTBFS, pyside has not been binNMUed.
> >=20
> > Many of these packages are team maintained.  Please jump in and hel=
p out
> > where you can.
>=20
> Did you usertag these bugs?

I have now.  I added them to the existing debian-python@lists.debian.or=
g=20
python3.6 usertag.

Scott K