Re: Python 2 support for Bullseye
Hi Moritz (2020.10.16_18:33:06_+) > > not ok. That would mean removing pypy3 from the archive as well. If you > > don't > > want to support Python2, then why do you care about it's removal for > > bullseye+1? > > Ok. I assumed the need for Py2 in pypy3 was a temporary thing? If it's needed > for longer (is there an estimate of sorts?), I'm also fine with keeping > it longer. Sorry, rather late to this thread. PyPy upstream is looking at converting the rpython toolchain to python3, but I wouldn't expect progress any time to. So, I'll continue to need some form of python2.7 (python2.7 or pypy) to build pypy3 for the foreseeable future. pypy (2.7) uses python2.7 to build itself on architectures where that's faster than using pypy (architectures where pypy has no JIT). But pypy could be entirely self-hosted and then python2.7 could be dropped from the archive. Downside: manual bootstrapping of pypy would be required on new archs & after certain build failures. I assume this will have to happen at some point. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Python 2 support for Bullseye
> On 10/16/20 8:04 PM, Moritz Mühlenhoff wrote: > > There will be few core packages build-depending on Python 2 (for tests > > or building) which won't be ready for Python 3 for Bullseye (Chromium, > > qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very > > small set of support packages like setuptools/jinja) to build and > > run their tests. > > > > Apart from those there's only a handful of packages still in testing > > which have a run time dependency on Python 2 packages (and most are > > actively being worked on (e.g. Xen)). > > > > All packages (and their test suites) shipped in Debian are trusted > > anyway (and consequently don't need any kind of updates during the > > bullseye cycle), so a lack of updates/upstream EOL doesn't matter. > > > > As such, I'd propose to include Python 2 (plus the small set of > > support packages) in Bullseye > > ok. I think you should explicitly name all these packages. I'll file a bug against debian-security-support to list cython, python2.7 and python-stdlib-extensions as unsupported except for building (these are Py2-only and debian-security-support only operates on source packages, so we can't mark binary packages like python-setuptools, but that's fine. In addition I'm planning to submit the following for release notes: | Debian Bullseye includes a version of Python 2.7 (and a short list of | related packages like setuptools still built Python 2 packages). However, these | are only included for building a few applications which still require | Python 2 as part of their build process. Python 2 is not supported for | running applications and there won't be any security updates for Python | 2 in Bullseye. Cheers, Moritz
Re: Python 2 support for Bullseye
On Fri, Oct 16, 2020 at 09:36:09PM +0300, Dmitry Shachnev wrote: > Hi Moritz! > > On Fri, Oct 16, 2020 at 08:04:56PM +0200, Moritz Mühlenhoff wrote: > > There will be few core packages build-depending on Python 2 (for tests > > or building) which won't be ready for Python 3 for Bullseye (Chromium, > > qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very > > small set of support packages like setuptools/jinja) to build and > > run their tests. > > Small correction: s/qtwebkit/qtwebengine/. Ack, that one, they keep changing names to often :-) > There are also patches from the FreeBSD maintainer [2], but they are huge > (2200 lines in total) and the author reports that they cause some JS errors, > so I would better not apply them and wait for an official port. Definitely. > Qt WebEngine in Debian is not supported from security point of view anyway, > so I think it should be fine to let it use Python 2 in Bullseye. Yeah, given that it's only at build time for sources we control it's entirely fine. Cheers, Moritz
Re: Python 2 support for Bullseye
Hi Moritz! On Fri, Oct 16, 2020 at 08:04:56PM +0200, Moritz Mühlenhoff wrote: > There will be few core packages build-depending on Python 2 (for tests > or building) which won't be ready for Python 3 for Bullseye (Chromium, > qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very > small set of support packages like setuptools/jinja) to build and > run their tests. Small correction: s/qtwebkit/qtwebengine/. QtWebEngine bundles Chromium whose upstream is actively working on Python 3 port [1]. Most probably it won't be ready in time for Bullseye, but for Bookworm it should be ready (or rather, Qt WebEngine 6 will use Python 3, and we will remove Qt WebEngine 5). There are also patches from the FreeBSD maintainer [2], but they are huge (2200 lines in total) and the author reports that they cause some JS errors, so I would better not apply them and wait for an official port. Qt WebEngine in Debian is not supported from security point of view anyway, so I think it should be fine to let it use Python 2 in Bullseye. [1]: https://bugs.chromium.org/p/chromium/issues/detail?id=1112471 [2]: https://mail.kde.org/pipermail/distributions/2020-September/000860.html -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Python 2 support for Bullseye
On Fri, Oct 16, 2020 at 08:21:09PM +0200, Matthias Klose wrote: > > As such, I'd propose to include Python 2 (plus the small set of > > support packages) in Bullseye > > ok. I think you should explicitly name all these packages. Yeah. I think the final list is still TBD (e.g. depends on whether Chromium still gets a Py3 port in time for the freeze). > > but exempt it from support (and then > > remove it for good after the Bullseye release): > > not ok. That would mean removing pypy3 from the archive as well. If you don't > want to support Python2, then why do you care about it's removal for > bullseye+1? Ok. I assumed the need for Py2 in pypy3 was a temporary thing? If it's needed for longer (is there an estimate of sorts?), I'm also fine with keeping it longer. > > - Mark src:python (plus related support packages) as unsupported in > > debian-security-support and with a README.Debian in the source > > package (and given how prominent Python is, also in the release notes) > > That should list the binary packages, there's no src:python package. I acually meant src:python2.7, debian-security-support only operates on source packages (and then flags all installed binary packages). Cheers, Moritz
Re: Python 2 support for Bullseye
On 10/16/20 8:04 PM, Moritz Mühlenhoff wrote: > There will be few core packages build-depending on Python 2 (for tests > or building) which won't be ready for Python 3 for Bullseye (Chromium, > qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very > small set of support packages like setuptools/jinja) to build and > run their tests. > > Apart from those there's only a handful of packages still in testing > which have a run time dependency on Python 2 packages (and most are > actively being worked on (e.g. Xen)). > > All packages (and their test suites) shipped in Debian are trusted > anyway (and consequently don't need any kind of updates during the > bullseye cycle), so a lack of updates/upstream EOL doesn't matter. > > As such, I'd propose to include Python 2 (plus the small set of > support packages) in Bullseye ok. I think you should explicitly name all these packages. > but exempt it from support (and then > remove it for good after the Bullseye release): not ok. That would mean removing pypy3 from the archive as well. If you don't want to support Python2, then why do you care about it's removal for bullseye+1? > - Mark src:python (plus related support packages) as unsupported in > debian-security-support and with a README.Debian in the source > package (and given how prominent Python is, also in the release notes) That should list the binary packages, there's no src:python package. > - Bump the severity of the few remaining packages in testing to RC > state (and force them out testing if auto removals were blocked > for some reason) See above, I think it's unfriendly to push out pypy3. Matthias
Python 2 support for Bullseye
There will be few core packages build-depending on Python 2 (for tests or building) which won't be ready for Python 3 for Bullseye (Chromium, qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very small set of support packages like setuptools/jinja) to build and run their tests. Apart from those there's only a handful of packages still in testing which have a run time dependency on Python 2 packages (and most are actively being worked on (e.g. Xen)). All packages (and their test suites) shipped in Debian are trusted anyway (and consequently don't need any kind of updates during the bullseye cycle), so a lack of updates/upstream EOL doesn't matter. As such, I'd propose to include Python 2 (plus the small set of support packages) in Bullseye but exempt it from support (and then remove it for good after the Bullseye release): - Mark src:python (plus related support packages) as unsupported in debian-security-support and with a README.Debian in the source package (and given how prominent Python is, also in the release notes) - Bump the severity of the few remaining packages in testing to RC state (and force them out testing if auto removals were blocked for some reason) Thoughts? Cheers, Moritz
