Re: Python3 -dbg packages
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
Multiple package versions in PPA
Hi, I've added a python package called python3-pyarmnn to Debian (https://tracker.debian.org/pkg/armnn) but also have it pushed to a Ubuntu Launchpad PPA (https://launchpad.net/~armnn/+archive/ubuntu/ppa/+packages). When I push new versions of the packaging it seems to overwrite the previous, I'm assuming this is by design as the archive should only have one version of the software at a time. However, this python3-pyarmnn package is just a wrapper for a C++ library libarmnn26, 26 being its major version. So from the PPA the user can apt install libarmnn26 or libarmnn25 etc, but if they install python3-pyarmnn it's always the latest and so that drags in the latest libarmnn i.e 26. I tried installing python3-pyarmnn while specifying a version, but it appears only one is visible: apt-cache policy python3-pyarmnn python3-pyarmnn: Installed: 21.08-1 Candidate: 21.08-1 Version table: *** 21.08-1 500 500 http://ppa.launchpad.net/armnn/ppa/ubuntu focal/main arm64 Packages 100 /var/lib/dpkg/status I understand this is Ubuntu launchpad rather than Debian but I'm trying to follow Debian's python policy. As shown above there is python3-pyarmnn version 21.08-1 which is the package version, the python __version__ of the module is 26.0.0, the previous being 21.05-1 and 25.0.0 respectively. Any help would be appreciated. Francis. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: Python3 -dbg packages
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
