Python 2 support for Bullseye

[Moritz Mühlenhoff]

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

[Matthias Klose]

Post by Moritz Mühlenhoff
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.

Post by Moritz Mühlenhoff
but exempt it from support (and then

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?

Post by Moritz Mühlenhoff
- 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.

Post by Moritz Mühlenhoff
- 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

[Moritz Muehlenhoff]

Post by Matthias Klose

Post by Moritz Mühlenhoff
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).

Post by Matthias Klose

Post by Moritz Mühlenhoff
but exempt it from support (and then

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.

Post by Matthias Klose

Post by Moritz Mühlenhoff
- 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

[Stefano Rivera]

Hi Moritz (2020.10.16_18:33:06_+0000)

Post by Moritz Muehlenhoff

Post by Matthias Klose
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

[Moritz Mühlenhoff]

Post by Matthias Klose

Post by Moritz Mühlenhoff
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

[Dmitry Shachnev]

Hi Moritz!

Post by Moritz Mühlenhoff
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

[Moritz Muehlenhoff]

This post might be inappropriate. Click to display it.