Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
On 3/4/21 9:58 AM, Paul Gevers wrote: > Control: tag -1 moreinfo > > Hi Stefano, > > On 25-02-2021 07:17, Stefano Rivera wrote: >> Please unblock package python3-defaults and python3.9 > > The python3-defaults package is currently blocked by autopkgtest > regressions. As usual, I suspect these are transient failures (either > infrastructure or flaky tests). If your going to inspect, flaky tests > are RC and can be filed, all failures are retried after a day. Please > remove the moreinfo bug if there's something that needs our attention. The four remaining failures are triggered by the fix for https://security-tracker.debian.org/tracker/CVE-2021-23336 bugs for mercurial, python-furl, python-w3lib and twisted are filed. the vorta/ppc64el issue seems to be unrelated, and fixed with vorta 0.7.5-1.
Processed: Re: Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
Processing control commands: > tag -1 moreinfo Bug #983499 [release.debian.org] unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1 Ignoring request to alter tags of bug #983499 to the same tags previously set -- 983499: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983499 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
Control: tag -1 moreinfo Hi Stefano, On 25-02-2021 07:17, Stefano Rivera wrote: > Please unblock package python3-defaults and python3.9 The python3-defaults package is currently blocked by autopkgtest regressions. As usual, I suspect these are transient failures (either infrastructure or flaky tests). If your going to inspect, flaky tests are RC and can be filed, all failures are retried after a day. Please remove the moreinfo bug if there's something that needs our attention. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
Hi Matthias, On 26-02-2021 07:40, Matthias Klose wrote: > I'm planning to upload the upload as done to experimental, plus the final (no > changes) 3.9.2 release. Granted, refreshing the patches is not not > necessary, > but that's what is now tested in experimental. Ack. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
On 2/25/21 10:16 PM, Paul Gevers wrote: > Control: tags -1 confirmed > > Hi Stefano, > > On 25-02-2021 07:17, Stefano Rivera wrote: >> Please unblock package python3-defaults and python3.9 >> >> Adding a new binary package, -full, to both source packages. Both are >> currently in binNEW. > > We'll unblock with the understanding that the only difference is these > new meta packages. I'm planning to upload the upload as done to experimental, plus the final (no changes) 3.9.2 release. Granted, refreshing the patches is not not necessary, but that's what is now tested in experimental. Matthias python3.9 (3.9.2-1) unstable; urgency=medium * Python 3.9.2 release. No changes since 3.9.2~rc1-1. * Build idlelib/help.html from source, don't ship the pre-generated file. -- Matthias Klose Sat, 20 Feb 2021 12:05:08 +0100 python3.9 (3.9.2~rc1-1) experimental; urgency=medium * Python 3.9.2 release candidate 1. Changes since 3.9.1-4: - Fix issue #42967, web cache poisoning vulnerability. - Fix issue #42938, explicitly disable bracketed paste in the interactive interpreter. Closes: #979154. * Fix permissions and group for local directories. Closes: #962422. * Build a python3.9-full package. * idle-python3.9: Drop dependency on libjs-mathjax, Unused in 3.8 and 3.9. * python3.9-doc: Fix links to the documentation in /usr/share/doc/python3.9. * Refresh patches. -- Matthias Klose Wed, 17 Feb 2021 19:32:50 +0100
Processed: Re: Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
Processing control commands: > tags -1 confirmed Bug #983499 [release.debian.org] unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1 Added tag(s) confirmed. -- 983499: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983499 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
Control: tags -1 confirmed Hi Stefano, On 25-02-2021 07:17, Stefano Rivera wrote: > Please unblock package python3-defaults and python3.9 > > Adding a new binary package, -full, to both source packages. Both are > currently in binNEW. We'll unblock with the understanding that the only difference is these new meta packages. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
On Thu, 25 Feb 2021 09:58:36 +0100 Paul Gevers wrote: > > On 25-02-2021 07:17, Stefano Rivera wrote: > > TL;DR: Debian heard of some upstream Python grumpyness about our > > standard library splits, recently. > > We have more upstreams being grumpy how we handle things in Debian. > > > This is all very badly timed for the > > freeze. > > Exactly. To be clear, we acted as soon as upstream attempted to engage Debian. This was not raised directly to Debian until early January, when the freeze had already begun. Hence, our attempts to determine what would be feasible and not overly disruptive before and after freeze. We have been moving as quickly as possible. > > Including a python3-full and python3.x-full packages, that Depends on > > the entire stdlib, is a compromise position to help them to support > > Python users on Debian (and derivative) platforms. > > This is the piece we're missing. What is it in Debian that makes this > support difficult? Why do we need to rush this into bullseye now? Stefano has written more at length about this in the previous reply, but tl;dr: when developers `apt install python`, they tend to expect the full Python standard library to be present as following the upstream documentation, and not a split. Right now, we are failing those users by asking them to figure out which packages to install on their own. By adding a metapackage "python3-full" which installs everything automatically to match the upstream expectations, we will provide a much smoother and improved user experience. Since this is merely a metapackage and no packages are permitted to depend on it directly, it should be a minimally invasive/disruptive change, even during freeze. We are basically adding a user-friendly alias. > Also, that message 00035 mentions two items that were considered as too > disruptive. Does fixing only the third item really warrant the upload > now, considering it seems to hint that you'll want to rename things > again after the release: > """ > - It was requested that we differentiate between "system" Python and > what upstream considers core Python. A package rename (e.g. python3 -> > python3-system) will confuse everyone and take multiple releases to > implement, and cannot be targeted until bookworm at the earliest. > """ Yes, because there is no guarantee that we will actually make these changes as requested. I mentioned them for completeness (to document all the discussions we had), not necessarily because there's been any concrete decision to act on them. I think python3-full is an obvious improvement over the status quo, and a minimally invasive change to introduce in freeze. Any other Python packaging changes are is up for debate. - e signature.asc Description: PGP signature
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
Hi Paul (2021.02.25_08:58:36_+) > > Including a python3-full and python3.x-full packages, that Depends on > > the entire stdlib, is a compromise position to help them to support > > Python users on Debian (and derivative) platforms. > > This is the piece we're missing. What is it in Debian that makes this > support difficult? Beginner Python developers install "python" on their machine, and then get surprised when some standard library modules fail to import. The examples we've seen are most commonly distutils, venv, and lib2to3 (used by tools like black, apparently). The existence of "python3-full" doesn't immediately change this situation. But it does give people providing support a simple instruction to give the users. What they really would have liked is a "python" package that installs the full python developer environment, not the more minimal python that Debian packages need. But that's a *huge* change that would take multiple releases to achieve. I don't think the Debian Python community has the will to do that. This as an entirely political change. It's a peace offering, to try to improve communication with the grumpier parts of the upstream community. If we respond to their concerns, we can hope that they will bring them to us sooner, in the future. > Why do we need to rush this into bullseye now? Because this blew in up late Jan, and bullseye is the next release after that. We didn't rush to get it in before the freeze, to be sure that the Debian Python community was on board, and the upstream community agreed with the details. We have explained that bullseye was going into freeze, and making this change now may be difficult. So not forcing your hand, here. Feel free to reject it. It will come back to the Stable Release Team for .1, though. > Also, that message 00035 mentions two items that were considered as too > disruptive. Does fixing only the third item really warrant the upload > now, considering it seems to hint that you'll want to rename things > again after the release: > """ > - It was requested that we differentiate between "system" Python and > what upstream considers core Python. A package rename (e.g. python3 -> > python3-system) will confuse everyone and take multiple releases to > implement, and cannot be targeted until bookworm at the earliest. > """ As above, I think that change is a *huge* transition, that I don't think we have the will to push for in Debian. So, I wouldn't count on it happening. We're hoping to have a cross-distro Python packaging discussion at the next PyCon. That may push us towards wanting to take changes like that. But it'll still need people within Debian to drive it. Small steps. Hopefully they make things better. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Processed: Re: Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
Processing control commands: > tags -1 moreinfo Bug #983499 [release.debian.org] unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1 Added tag(s) moreinfo. -- 983499: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983499 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
Control: tags -1 moreinfo Hi Stefano, On 25-02-2021 07:17, Stefano Rivera wrote: > TL;DR: Debian heard of some upstream Python grumpyness about our > standard library splits, recently. We have more upstreams being grumpy how we handle things in Debian. > This is all very badly timed for the > freeze. Exactly. > Including a python3-full and python3.x-full packages, that Depends on > the entire stdlib, is a compromise position to help them to support > Python users on Debian (and derivative) platforms. This is the piece we're missing. What is it in Debian that makes this support difficult? Why do we need to rush this into bullseye now? Also, that message 00035 mentions two items that were considered as too disruptive. Does fixing only the third item really warrant the upload now, considering it seems to hint that you'll want to rename things again after the release: """ - It was requested that we differentiate between "system" Python and what upstream considers core Python. A package rename (e.g. python3 -> python3-system) will confuse everyone and take multiple releases to implement, and cannot be targeted until bookworm at the earliest. """ Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: d...@debian.org
Please unblock package python3-defaults and python3.9
Adding a new binary package, -full, to both source packages. Both are
currently in binNEW.
Sorry, should have probably filed this a couple of weeks ago. Once we
saw this coming.
[ Reason ]
The reason for this change is laid out in
https://lists.debian.org/debian-python/2021/02/msg00035.html
TL;DR: Debian heard of some upstream Python grumpyness about our
standard library splits, recently. This is all very badly timed for the
freeze.
Including a python3-full and python3.x-full packages, that Depends on
the entire stdlib, is a compromise position to help them to support
Python users on Debian (and derivative) platforms.
These packages would be dependency-only packages, and only directly
installed by end-users, not used as a dependency of other packages.
We intend to try to backport this to stable releases too.
[ Impact ]
Impact, if this isn't granted, is continuation of status-quo.
We'd probably attempt to add it in a point release.
[ Tests ]
Not relevant.
[ Risks ]
While the source packages at question are core to the system, this is
just the addition of leaf packages.
[ Checklist ]
unblock python3-defaults/3.9.2~rc1-1
unblock python3.9/3.9.2~rc1-1
diff --git a/.gitignore b/.gitignore
index 1f20116..0717416 100644
--- a/.gitignore
+++ b/.gitignore
@@ -22,6 +22,7 @@ debian/python3-dbg
debian/python3-dev
debian/python3-doc
debian/python3-examples
+debian/python3-full
debian/python3-minimal
debian/python3-venv
diff --git a/debian/changelog b/debian/changelog
index 19ee73a..f360209 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+python3-defaults (3.9.2~rc1-1) experimental; urgency=medium
+
+ * Bump version to 3.9.2 rc1.
+
+ [ Stefano Rivera ]
+ * Improve package descriptions, describing venv, stdlib, and lib2to3 package
+contents.
+
+ [ Matthias Klose ]
+ * Build a python3-full package.
+
+ -- Matthias Klose Thu, 18 Feb 2021 12:16:46 +0100
+
python3-defaults (3.9.1-1) unstable; urgency=medium
* Bump version to 3.9.1.
diff --git a/debian/control b/debian/control
index 59ed6f6..0087ed5 100644
--- a/debian/control
+++ b/debian/control
@@ -39,13 +39,19 @@ Architecture: any
Multi-Arch: allowed
Depends: python3.9-venv (>= 3.9.1-1~), python3 (= ${binary:Version}),
python3-distutils (>= 3.9.1-1~), ${misc:Depends}
-Description: pyvenv-3 binary for python3 (default python3 version)
- Python, the high-level, interactive object oriented language,
- includes an extensive class library with lots of goodies for
- network programming, system administration, sounds and graphics.
+Description: venv module for python3 (default python3 version)
+ This package contains the venv module for the Python language (default python3
+ version).
+ .
+ The venv module provides support for creating lightweight "virtual
+ environments" with their own site directories, optionally isolated from system
+ site directories. Each virtual environment has its own Python binary (which
+ matches the version of the binary that was used to create this environment)
+ and can have its own independent set of installed Python packages in its site
+ directories.
.
This package is a dependency package, which depends on Debian's default
- Python 3 version (currently v3.9).
+ Python 3 version's venv module (currently v3.9).
Package: python3-minimal
Architecture: any
@@ -68,7 +74,7 @@ Description: examples for the Python language (default
version)
the upstream Python distribution.
.
This package is a dependency package, which depends on Debian's default
- Python 3 version (currently v3.9).
+ Python 3 version's examples (currently v3.9).
Package: python3-dev
Architecture: any
@@ -83,7 +89,7 @@ Description: header files and a static library for Python
(default)
in applications.
.
This package is a dependency package, which depends on Debian's default
- Python 3 version (currently v3.9).
+ Python 3 version's headers (currently v3.9).
Package: libpython3-dev
Architecture: any
@@ -98,19 +104,18 @@ Description: header files and a static library for Python
(default)
in applications.
.
This package is a dependency package, which depends on Debian's default
- Python 3 version (currently v3.9).
+ Python 3 version's headers (currently v3.9).
Package: libpython3-stdlib
Architecture: any
Multi-Arch: same
Depends: libpython3.9-stdlib (>= 3.9.1-1~), ${misc:Depends}
Description: interactive high-level object-oriented language (default python3
version)
- Python, the high-level, interactive object oriented language,
- includes an extensive class library with lots of goodies for
- network programming, system administration, sounds and graphics.
+ This package contains the majority of the standard library for the Python
+ language (default python3 version).
.
This package is a
