On 7/6/20 8:33 PM, Matthias Klose wrote:

Python 3.8 upstream now has a common ABI for normal and debug extension builds,
so it is technically possible to load a debug extension in the normal interpreter, or to load a normal extension in the debug interpreter. In Debian,
debug extensions are shipped with a different name, and only loaded by the corresponding interpreter. We could change / simply the current setup, but I first wanted to know how many people are still using the debug builds. The reason for the separate debug builds allowed debugging of stuff in modules further down the Python stack, without having to rebuild the whole stack. There
are several solutions how to simplify the packaging, I'm not sure how much the
dbg extensions are still used ... There are several scenarios:

- Keep the current setup (-dbg packages need to be available to
run them).

- Allow the debug interpreter to load normal debug extensions (but
load a debug extension if it's available by default). That would
allow building debug extensions without having debug extensions
built for all it's dependencies, maybe requiring changes in the
dependencies of a package.

- Stop building debug extensions, and telling developers to
build extensions in debug mode, if they need them. That would
probably be inline with everything else shipped in Debian.

- Stop building debug extensions, and also stop building the Python
debug interpreter. You would need to rebuild the interpreter
itself to have meaningful debug sessions. I'm not preferring
this solution.

I'm currently tending to implement the second scenario, but if people think that
having the -dbg packages available is still useful, then also opt for the third
option.

Let's address this before we start adding Python 3.10 as a supported Python3 version. Starting with the third option. I'll file bug reports for the following packages:

basemap
bottleneck
cbflib
dbus-python
gpyfft
gst-python1.0
h5py
kiwisolver
libgpuarray
libkdtree++
libtorrent-rasterbar
libxml2
lxml
markupsafe
matplotlib
meliae
mpi4py
netifaces
nipy
numexpr
numpy
pairtools
pillow
pillow-sane
psycopg2
pyao
pycairo
pychm
pycuda
pycurl
pyepr
pyfai
pyfuse3
pygccjit
pygobject
pyicu
pymad
pymca
pynfft
pyopencl
pyqt5
pyqt5chart
pyqt5-sip
pyqt5webengine
pysendfile
pystemmer
pytables
python3-defaults
python3-stdlib-extensions
python-aiohttp
python-apsw
python-apt
python-bsddb3
python-cffi
python-djvulibre
python-dmidecode
python-fabio
python-fisx
python-gevent
python-greenlet
python-ldap
python-levenshtein
python-librtmp
python-llfuse
python-ltfatpy
python-multidict
python-mysqldb
python-psutil
python-pygraphviz
python-pylibacl
python-pyxattr
python-regex
python-reportlab
python-setproctitle
python-sfml
pyyaml
pyzmq
qscintilla2
reprozip
rrdtool
scipy
silx
simplejson
sip4
sip5
sip6
storm
thrift
twisted
uvloop
xrayutilities
zope.interface


dd-list:

Alexander Wirt <[email protected]>
rrdtool (U)

Alexandre Marie <[email protected]>
python-fisx (U)
silx (U)
xrayutilities (U)

Andreas Beckmann <[email protected]>
pycuda (U)
pyopencl (U)

Andrew Starr-Bochicchio <[email protected]>
libtorrent-rasterbar (U)

Antoni Villalonga <[email protected]>
pairtools (U)

Antonio Valentino <[email protected]>
numexpr (U)
pyepr (U)
pytables (U)
python-ltfatpy (U)

APT Development Team <[email protected]>
python-apt

Aron Xu <[email protected]>
libxml2 (U)

Brian May <[email protected]>
python-mysqldb (U)

Christoph Berg <[email protected]>
psycopg2 (U)

Colin Watson <[email protected]>
storm (U)

Cristian Greco <[email protected]>
libtorrent-rasterbar

Dave Beckett <[email protected]>
pycairo (U)

David Cournapeau <[email protected]>
scipy (U)

Debian Games Team <[email protected]>
python-sfml

Debian GIS Project <[email protected]>
pyepr

Debian GNOME Maintainers <[email protected]>
pygobject

Debian Med Packaging Team <[email protected]>
nipy
pairtools

Debian NVIDIA Maintainers <[email protected]>
pycuda

Debian OpenCL Maintainers <[email protected]>
pyopencl

Debian Python Modules Team <[email protected]>
bottleneck
kiwisolver (U)
markupsafe (U)
netifaces
pycairo
pychm (U)
pyicu (U)
pyqt5-sip
pysendfile (U)
python-dmidecode (U)
python-ldap
python-multidict (U)
python-mysqldb
python-regex (U)

Debian Python Team <[email protected]>
basemap (U)
matplotlib (U)
numpy (U)
psycopg2
pycurl
pyfuse3
pyqt5
pyqt5chart
pyqt5webengine
pystemmer
python-aiohttp
python-cffi
python-fisx
python-levenshtein (U)
python-llfuse (U)
python-psutil (U)
python-pygraphviz (U)
python-setproctitle
pyyaml
pyzmq
qscintilla2
scipy
simplejson
sip4
sip5
sip6
storm
twisted
uvloop (U)
zope.interface

Debian QA Group <[email protected]>
libkdtree++
python-bsddb3
python-djvulibre

Debian RRDtool Team <[email protected]>
rrdtool

Debian Science Maintainers <[email protected]>
cbflib
gpyfft
h5py
libgpuarray
mpi4py
numexpr
pyfai
pymca
pynfft
pytables
python-fabio
python-ltfatpy
reprozip
silx
xrayutilities

Debian XML/SGML Group <[email protected]>
libxml2

Dmitry Shachnev <[email protected]>
pyqt5 (U)
pyqt5-sip (U)
pyqt5webengine (U)
sip4 (U)
sip5 (U)
sip6 (U)

Eugen Wintersberger <[email protected]>
xrayutilities (U)

Fabio Tranchitella <[email protected]>
psycopg2 (U)

Francesco Paolo Lovergine <[email protected]>
pyfuse3 (U)

Ghe Rivero <[email protected]>
pysendfile

Ghislain Antony Vaillant <[email protected]>
bottleneck (U)
h5py (U)
libgpuarray (U)
pynfft (U)
reprozip (U)

Gordon Ball <[email protected]>
python-setproctitle (U)

Gudjon I. Gudjonsson <[email protected]>
qscintilla2 (U)

Iain Lane <[email protected]>
pygobject (U)

Iustin Pop <[email protected]>
python-pylibacl
python-pyxattr

James Cowgill <[email protected]>
python-sfml (U)

Jamie Wilkinson <[email protected]>
pyao
pymad

Jean-Michel Vourgère <[email protected]>
rrdtool (U)

Jelmer Vernooij <[email protected]>
meliae

Jeremy Bicha <[email protected]>
pygobject (U)

Jerome Kieffer <[email protected]>
pyfai (U)
python-fabio (U)
silx (U)

Joel Rosdahl <[email protected]>
python-apsw

Jonas Meurer <[email protected]>
python-mysqldb (U)

Julian Andres Klode <[email protected]>
python-apt (U)

Julian Taylor <[email protected]>
pyzmq (U)

Laszlo Boszormenyi (GCS) <[email protected]>
pyicu
python-gevent
python-greenlet
pyzmq (U)
thrift

Laurent Bigonville <[email protected]>
pygobject (U)

Loic Minier <[email protected]>
dbus-python (U)

Maintainers of GStreamer packages <[email protected]>
gst-python1.0

Mario Izquierdo (mariodebian) <[email protected]>
netifaces (U)

Matthew Grant <[email protected]>
python-setproctitle (U)

Matthias Klose <[email protected]>
lxml
pillow
pillow-sane
pygccjit
python-reportlab
python3-defaults
python3-stdlib-extensions
twisted (U)

Michael Hanke <[email protected]>
mpi4py (U)
nipy (U)

Michael Hudson-Doyle <[email protected]>
pyyaml (U)

Michael Vogt <[email protected]>
python-apt (U)

Mo Zhou <[email protected]>
h5py (U)

Morten Kjeldgaard <[email protected]>
cbflib (U)

Nikolaus Rath <[email protected]>
pyfuse3 (U)
python-llfuse

Ondrej Certik <[email protected]>
scipy (U)

Paul Tagliamonte <[email protected]>
python-aiohttp (U)

Picca Frédéric-Emmanuel <[email protected]>
gpyfft (U)
pyfai (U)
pymca (U)
python-fabio (U)
python-fisx (U)
silx (U)
xrayutilities (U)

Pierre-Elliott Bécue <[email protected]>
zope.interface (U)

Pietro Battiston <[email protected]>
bottleneck (U)

Piotr Ożarowski <[email protected]>
markupsafe
python-aiohttp (U)
python-multidict
python3-defaults (U)
simplejson (U)
uvloop

Rebecca N. Palmer <[email protected]>
libgpuarray (U)

Sandro Tosi <[email protected]>
basemap
kiwisolver
matplotlib
numpy
pychm
python-dmidecode
python-levenshtein
python-psutil
python-pygraphviz
python-regex

Scott Kitterman <[email protected]>
psycopg2 (U)
pyyaml (U)

Scott Talbert <[email protected]>
pycurl (U)

Sebastian Dröge <[email protected]>
dbus-python (U)
gst-python1.0 (U)

Sebastien Bacher <[email protected]>
pygobject (U)

Sebastien Delafond <[email protected]>
xrayutilities (U)

Simon McVittie <[email protected]>
dbus-python (U)

Sjoerd Simons <[email protected]>
dbus-python (U)

Stefan Breunig <[email protected]>
python-librtmp

Stefano Rivera <[email protected]>
pystemmer (U)
python-cffi (U)
python3-defaults (U)

Stephen Kitt <[email protected]>
pyqt5chart (U)

Teemu Ikonen <[email protected]>
cbflib (U)

Thomas Goirand <[email protected]>
netifaces (U)
python-mysqldb (U)
simplejson (U)

Tianon Gravi <[email protected]>
python-aiohttp (U)

Tomasz Rybak <[email protected]>
pycuda (U)
pyopencl (U)

Torsten Marek <[email protected]>
pycairo (U)
qscintilla2 (U)
sip4 (U)

Utopia Maintenance Team <[email protected]>
dbus-python

Varun Hiremath <[email protected]>
scipy (U)

Vincent Bernat <[email protected]>
pyzmq (U)

Wen Heping <[email protected]>
numexpr (U)

Willem van den Akker <[email protected]>
python-ldap (U)

William Grzybowski <[email protected]>
python-aiohttp (U)

Yaroslav Halchenko <[email protected]>
mpi4py (U)
nipy (U)
numexpr (U)
pytables (U)
reprozip (U)

YunQiang Su <[email protected]>
libxml2 (U)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 3 Sep 2021, Matthias Klose wrote:

Python 3.8 upstream now has a common ABI for normal and debug extension builds,
so it is technically possible to load a debug extension in the normal
interpreter, or to load a normal extension in the debug interpreter. In Debian,
debug extensions are shipped with a different name, and only loaded by the >> corresponding interpreter. We could change / simply the current setup, but I
first wanted to know how many people are still using the debug builds. The >> reason for the separate debug builds allowed debugging of stuff in modules >> further down the Python stack, without having to rebuild the whole stack. There
are several solutions how to simplify the packaging, I'm not sure how much the
dbg extensions are still used ... There are several scenarios:

- Keep the current setup (-dbg packages need to be available to
run them).

- Allow the debug interpreter to load normal debug extensions (but
load a debug extension if it's available by default). That would
allow building debug extensions without having debug extensions
built for all it's dependencies, maybe requiring changes in the
dependencies of a package.

- Stop building debug extensions, and telling developers to
build extensions in debug mode, if they need them. That would
probably be inline with everything else shipped in Debian.

- Stop building debug extensions, and also stop building the Python
debug interpreter. You would need to rebuild the interpreter
itself to have meaningful debug sessions. I'm not preferring
this solution.

I'm currently tending to implement the second scenario, but if people think that
having the -dbg packages available is still useful, then also opt for the third
option.

Let's address this before we start adding Python 3.10 as a supported Python3 version. Starting with the third option. I'll file bug reports for the following packages:

Just to confirm on this: if we currently have a python module that builds
a -dbg package, we can now drop this in favor of the automatically
generated -dbgsym package for debugging?

Scott

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/13/21 4:02 PM, Scott Talbert wrote:

On Fri, 3 Sep 2021, Matthias Klose wrote:

Python 3.8 upstream now has a common ABI for normal and debug extension builds,
so it is technically possible to load a debug extension in the normal
interpreter, or to load a normal extension in the debug interpreter.  In Debian,
debug extensions are shipped with a different name, and only loaded by the >>> corresponding interpreter.  We could change / simply the current setup, but I
first wanted to know how many people are still using the debug builds.  The
reason for the separate debug builds allowed debugging of stuff in modules >>> further down the Python stack, without having to rebuild the whole stack. There
are several solutions how to simplify the packaging, I'm not sure how much the
dbg extensions are still used ... There are several scenarios:

 - Keep the current setup (-dbg packages need to be available to
   run them).

 - Allow the debug interpreter to load normal debug extensions (but
   load a debug extension if it's available by default).  That would
   allow building debug extensions without having debug extensions
   built for all it's dependencies, maybe requiring changes in the
   dependencies of a package.

 - Stop building debug extensions, and telling developers to
   build extensions in debug mode, if they need them.  That would
   probably be inline with everything else shipped in Debian.

 - Stop building debug extensions, and also stop building the Python
   debug interpreter.  You would need to rebuild the interpreter
   itself to have meaningful debug sessions.  I'm not preferring
   this solution.

I'm currently tending to implement the second scenario, but if people think that
having the -dbg packages available is still useful, then also opt for the third
option.

Let's address this before we start adding Python 3.10 as a supported Python3 >> version. Starting with the third option.  I'll file bug reports for the
following packages:

Just to confirm on this: if we currently have a python module that builds a -dbg
package, we can now drop this in favor of the automatically generated -dbgsym package for debugging?

yes, ideally, if there are dependencies on your -dbg in the archive, these should be removed first. Sorry, I didn't file these bug reports yet.

Matthias

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/14/21 8:36 AM, Matthias Klose wrote:

On 9/13/21 4:02 PM, Scott Talbert wrote:

On Fri, 3 Sep 2021, Matthias Klose wrote:

Python 3.8 upstream now has a common ABI for normal and debug extension builds,
so it is technically possible to load a debug extension in the normal
interpreter, or to load a normal extension in the debug interpreter.  In Debian,
debug extensions are shipped with a different name, and only loaded by the >>>> corresponding interpreter.  We could change / simply the current setup, but I
first wanted to know how many people are still using the debug builds.  The
reason for the separate debug builds allowed debugging of stuff in modules >>>> further down the Python stack, without having to rebuild the whole stack. There
are several solutions how to simplify the packaging, I'm not sure how much the
dbg extensions are still used ... There are several scenarios:

 - Keep the current setup (-dbg packages need to be available to
   run them).

 - Allow the debug interpreter to load normal debug extensions (but
   load a debug extension if it's available by default).  That would >>>>    allow building debug extensions without having debug extensions
   built for all it's dependencies, maybe requiring changes in the
   dependencies of a package.

 - Stop building debug extensions, and telling developers to
   build extensions in debug mode, if they need them.  That would
   probably be inline with everything else shipped in Debian.

 - Stop building debug extensions, and also stop building the Python
   debug interpreter.  You would need to rebuild the interpreter
   itself to have meaningful debug sessions.  I'm not preferring
   this solution.

I'm currently tending to implement the second scenario, but if people think that
having the -dbg packages available is still useful, then also opt for the third
option.

Let's address this before we start adding Python 3.10 as a supported Python3
version. Starting with the third option.  I'll file bug reports for the >>> following packages:

Just to confirm on this: if we currently have a python module that builds a -dbg
package, we can now drop this in favor of the automatically generated -dbgsym
package for debugging?

yes, ideally, if there are dependencies on your -dbg in the archive, these should be removed first. Sorry, I didn't file these bug reports yet.

Now filed as https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pydbg-removal;[email protected]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Now filed as https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pydbg-removal;[email protected]

why "Severity: serious"? none of them violates the policy: https://www.debian.org/Bugs/Developer#severities; please adjust to
normal or important. thanks

--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)