Bug#960548: python3-pyparsing: DeprecationWarning in collections import (will be failure with python3.9)
Package: python3-pyparsing Version: 2.4.7-1 Severity: normal Currently there is just a warning, but once we switch to python3.9 the following line will fail: from collections import MutableMapping, Mapping This is already fixed upstream [1]. It's an easy enough fix (probably much easier than jumping to pyparsing 3.0), so we ought to go ahead and do it. Note that the upstream fix may not be compatible with the pypy package, so we may want something slightly different, similar to [2]. Scott K [1] https://github.com/pyparsing/pyparsing/blob/master/pyparsing_archive.py#L109 [2] https://patch-diff.githubusercontent.com/raw/mozilla/bleach/pull/533.diff
Bug#930781: python3-socks: Deprecation warning emitted on import
On Thu, 20 Jun 2019 09:53:06 -0400 Jamie Bliss wrote: > Package: python3-socks > Version: 1.6.8+dfsg-1 > Severity: normal > > Dear Maintainer, > > PySocks 1.6.8 has a deprecated import and a warning is emitted on import. This > is triggered by importing requests, an extremely common HTTP library. It has > been fixed in upstream 1.7.0 > > This happens for any software that uses requests, whether or not they depend on > PySocks. It just happens for every application that uses it as soon as > python3-socks is installed on a system. > > In addition, this warning becomes user-visible if the application surfaces > warnings in some way (in a log or on stdout). Assuming the warning in question is: /usr/lib/python3/dist-packages/socks.py:58 /usr/lib/python3/dist-packages/socks.py:58: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working from collections import Callable It'll become fatal as soon as we go to python3.9, so this package really should be updated. Scott K signature.asc Description: This is a digitally signed message part.
Bug#960537: [Python-modules-team] Bug#960537: python3-html5lib: DeprecationWarning in collections import (will be failure with python3.9)
On Wednesday, May 13, 2020 1:14:54 PM EDT Scott Kitterman wrote: > Package: python3-html5lib > Version: 1.0.1-3 > Severity: normal > > Currently with python3.7 or 3.8: > DeprecationWarning: Using or importing the ABCs from 'collections' instead > of from 'collections.abc' is deprecated, and in 3.9 it will stop working > from collections import Mapping > > When we get python3.9 it'll be: > > Python 3.9.0a2+ (heads/master:b0d4949, Dec 20 2019, 11:38:30) > [GCC 8.3.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > > >>> import html5lib > > Traceback (most recent call last): > File "", line 1, in > File > "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/__in > it__.py", line 25, in from .html5parser import HTMLParser, parse, > parseFragment > File > "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/html > 5parser.py", line 8, in from . import _tokenizer > File > "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_tok > enizer.py", line 16, in from ._trie import Trie > File > "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_tri > e/__init__.py", line 3, in from .py import Trie as PyTrie > File > "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_tri > e/py.py", line 6, in from ._base import Trie as ABCTrie > File > "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_tri > e/_base.py", line 3, in from collections import Mapping > ImportError: cannot import name 'Mapping' from 'collections' > (/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/collections/__init__.py) > > I noticed this because python-bleach is looking into updating their > vendored copy (we don't use it) [1]. This change has been in html5lib > for some time [2], but with no release coming, I think we should fix it in > Debian. It looks like there is also: src/pip/_vendor/html5lib/treebuilders/dom.py:from collections import MutableMapping which will be a problem. Scott K signature.asc Description: This is a digitally signed message part.
Bug#960537: python3-html5lib: DeprecationWarning in collections import (will be failure with python3.9)
Package: python3-html5lib Version: 1.0.1-3 Severity: normal Currently with python3.7 or 3.8: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.9 it will stop working from collections import Mapping When we get python3.9 it'll be: Python 3.9.0a2+ (heads/master:b0d4949, Dec 20 2019, 11:38:30) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import html5lib Traceback (most recent call last): File "", line 1, in File "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/__init__.py", line 25, in from .html5parser import HTMLParser, parse, parseFragment File "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/html5parser.py", line 8, in from . import _tokenizer File "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_tokenizer.py", line 16, in from ._trie import Trie File "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_trie/__init__.py", line 3, in from .py import Trie as PyTrie File "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_trie/py.py", line 6, in from ._base import Trie as ABCTrie File "/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/site-packages/html5lib/_trie/_base.py", line 3, in from collections import Mapping ImportError: cannot import name 'Mapping' from 'collections' (/home/pi/.pyenv/versions/3.9-dev/lib/python3.9/collections/__init__.py) I noticed this because python-bleach is looking into updating their vendored copy (we don't use it) [1]. This change has been in html5lib for some time [2], but with no release coming, I think we should fix it in Debian. Scott K [1] https://patch-diff.githubusercontent.com/raw/mozilla/bleach/pull/533.diff [2] https://github.com/html5lib/html5lib-python/blob/master/html5lib/_trie/_base.py#L3
Bug#954907: [Python-modules-team] Bug#954907: python3-dateparser: Warning with autopkgtest when python3.8 is default
On Monday, May 11, 2020 4:18:45 PM EDT Emmanuel Arias wrote: > El lun., 11 de may. de 2020 a la(s) 17:10, Antoine Beaupré > > (anar...@debian.org) escribió: > > On 2020-05-11 14:53:29, Scott Kitterman wrote: > > > On Monday, May 11, 2020 2:39:30 PM EDT Antoine Beaupré wrote: > > >> On 2020-05-11 15:18:53, Emmanuel Arias wrote: > > >> > Hi, > > >> > > > >> > The upstream and pristine-tar branches are not generated on salsa for > > >> > any particular reason.? > > >> > > >> I'm not sure what question you are asking here. This package doesn't > > >> use > > >> pristine-tar or upstream branches right now, if that's what you're > > >> asking. > > > > > > Which it should since part of the DPMT standard repository layout. > > > Please fix.> > > I just found the time to update half a dozen Debian packages last > > night. I have no time for administrative details like this. I'm happy if > > some other folks in the team have time for that and won't stand in their > > way. > > > > I just hope my contributions to the team are otherwise appreciated. That > > package doesn't have pristine-tar and I don't plan to add it myself. If > > that's a problem for the team, I'm happy to move it to collab-maint or > > stop maintaining it. > > Sorry, my intention was not introduce noises. I did just asking just for be > sure if that package need help or not. I will happy to add upstream and > pristine-tar branches :) Thank you. Please do. This is not just administrivia. People who interact with the team repositories expect a certain layout and it causes confusion when it is not used. When following the standard team processes (that we've all agreed to do), this amount of extra time it takes to do it correctly is virtually nil. Scott K signature.asc Description: This is a digitally signed message part.
Bug#954907: [Python-modules-team] Bug#954907: python3-dateparser: Warning with autopkgtest when python3.8 is default
On Monday, May 11, 2020 2:39:30 PM EDT Antoine Beaupré wrote: > On 2020-05-11 15:18:53, Emmanuel Arias wrote: > > Hi, > > > > The upstream and pristine-tar branches are not generated on salsa for > > any particular reason.? > > I'm not sure what question you are asking here. This package doesn't use > pristine-tar or upstream branches right now, if that's what you're > asking. Which it should since part of the DPMT standard repository layout. Please fix. Scott K signature.asc Description: This is a digitally signed message part.
Bug#937769: [Python-modules-team] Bug#938756: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On Thursday, May 7, 2020 2:00:58 PM EDT peter green wrote: > I got a failure too when I cloned that branch and tried to build it, but > once I added in the changes from the previous NMU it built fine. I would > push that addition back to the branch but i'm not currently a member of the > python modules team, I requested to join but no response yet. That part is fixed (waiting to join the team). Scott K signature.asc Description: This is a digitally signed message part.
Bug#959797: ITP: python-tomlkit -- style-preserving TOML library for Python
Package: wnpp Severity: wishlist Owner: Scott Kitterman * Package name: python-tomlkit Version : 0.6.0 Upstream Author : Sébastien Eustace * URL : https://pypi.org/project/tomlkit * License : Expat Programming Lang: Python Description : style-preserving TOML library for Python TOML Kit is a 1.0.0rc1-compliant TOML (Tom's Obvious, Minimal Language) library. . It includes a parser that preserves all comments, indentations, whitespace and internal element ordering, and makes them accessible and editable via an intuitive API. . You can also create new TOML documents from scratch using the provided helpers. I intend to maintain this package in the DPMT. Upstream Python is moving to use of TOML in package configuration files. There are three major TOML implementations used by various tools. This is the only one not in Debian. It is the most feature complete (it is the only one that can round trip TOML that includes comments) and will be needed for packaging Python development tools. Scott K
Bug#956332: Python2 Removal Is Intentional
On Fri, 10 Apr 2020 02:40:07 + Scott Kitterman wrote: > This is not a bug. Python2 is no longer supported upstream and we are in the process of removing it. For anyone coming along looking for additional information, as of pip 20.1, which as I write this is about to be uploaded to Debian, building a python2 virtualenv from python3 is fully functional. It's as simple as: virtualenv --python=python2.7 $NAME This should be supported as long as we have a pip version that supports python2 (planned for removal by upstream in pip 21.0) and the python2 interpreter is still in Debian. Scott K signature.asc Description: This is a digitally signed message part.
Bug#959407: dh-python: pybuild without setup.py
On May 2, 2020 4:17:20 AM UTC, Drew Parsons wrote: >> pybuild will want to support it > >Some discussion has started on the mailing list, > >https://lists.debian.org/debian-python/2020/04/msg00061.html As mentioned in the thread, there's a pybuild plugin for packages that use flit to build based on pyproject.toml. It's in git, staged for the next upload. The pep517 package can also build packages using pyproject.toml, but it isn't, IMO, suitable for integration with pybuild because it's to heavy weight. Scott K
Bug#959397: ITP: python-resolvelib -- module to resolve abstract dependencies into concrete ones
Package: wnpp Severity: wishlist Owner: Scott Kitterman * Package name: python-resolvelib Version : 0.3.0 Upstream Author : Tzu-ping Chung * URL : https://github.com/sarugaku/resolvelib * License : ISC Programming Lang: Python Description : module to resolve abstract dependencies into concrete ones python3-resolvelib provides a `Resolver` class that includes dependency resolution logic. You give it some things, and a little information on how it should interact with them, and it will spit out a resolution result. This is a new dependency for the next version of python-pip (upstream vendors it, but does support unvendored packages which this will provide). It is used to support pip's new dependency resolver (not used by default, yet). This package will be maintained in the DPMT. Scott K
Bug#959150: [Pkg-clamav-devel] Bug#959150: Add support for Prelude
According to the prelude web site: Prelude OSS is the open source edition of Prelude SIEM . Prelude OSS is aimed for evaluation, research and test purpose on very small environments. Please note that Prelude OSS performances are way lower than the Prelude SIEM edition. What testing have you done to determine the performance implications of the proposed change? Scott K On April 29, 2020 11:15:43 PM UTC, Thomas Andrejak wrote: >Package: clamav > >Version: 0.102.2 > >Please enable Prelude support: > >* d/control: Add libprelude-dev Build-Depends > >* d/rule: Add --enable-prelude to the ./configure > >Thanks > >Regards > >Thomas
Bug#958764: [Python-modules-team] Bug#958764: closed by Scott Kitterman (re: python3-pip: debundled _vendor packaging approach breaks usage of pip in environments)
I do have something that might address this, but I'm reluctant to promise anything until I test it. Scott K
Bug#958816: re Bug 958816: pipx makes unsupported use of pip internals
Additional feedback from pip upstream: > what pipx is doing is actually a bit more interesting than I > thought they're actually running pip via the command line as > expected, but they're sort of creating a weird custom installed version in > a way > they're creating a virtual environment without pip > installed into it, and then using a .pth file it appears to magic it up so > that "import pip" inside that virtualenv, actually pulls from the base > python install > it doesn't really change my answer, I wouldn't > call that supported by upstream and if that ticket had opened up on pip's > repo due to a change we made, I would have shrugged and said sorry and > closed it That said, while I don't think this is a pip bug, we'll take a look and see if we can resolve the issue as he had some suggestions for that as well. Scott K signature.asc Description: This is a digitally signed message part.
Bug#958666: lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning
On Friday, April 24, 2020 12:08:46 PM EDT Shengjing Zhu wrote: > On Fri, Apr 24, 2020 at 11:44 PM gregor herrmann wrote: > [...] > > > > Could this wiki page be more useful? > > > https://wiki.debian.org/Salsa/AliothMigration#Import_mailing_list > > > > Not really; the lists we are talking about _are_ migrated to > > alioth-lists.debian.net which will continue to accept mail for > > @lists.alioth.debian.org. > > And like Andreas, I see no point in changing the mail addresses in > > thousands of packages and various tools and parts of infrastructure. > > So your expectation is alioth-lists.d.n will become a long term service. > > However I read the announcement[1] 2 years ago differently. > > [1] https://lists.debian.org/debian-devel-announce/2018/01/msg3.html > > > This is not intended to supercede the advice to make use of other > > services where appropriate, such as lists.debian.org for eligible > lists, tracker.debian.org or salsa, but does enable other lists > such as package team maintenance lists, to have a home in _the > short term_ > > Also it writes, > > > The service will be reviewed for viability and > > usefulness after one release cycle > > I'm not sure how the one release cycle is counted. > We have released buster since then. And we are close to bullseye now. > > Probably it's time to start thinking about this. True, but this is useless as a lintian check. Packaging teams need to decide what they are going to do and then migrate. There's nothing individual packages (or package maintainers) can do except decide to remove their package from team maintenance to 'fix' this issue. That's not what we want. In the Python Applications Packaging Team we've already had multiple package uploaded with the wrong address that have had to be fixed in new uploads. This test is not just pointless, it's actively harmful. Lintian checks need to be actionable by the package maintainer and this one is not. Scott K signature.asc Description: This is a digitally signed message part.
Bug#958182: mailing-list-obsolete-in-debian-infrastructure tag considered harmful
Thanks. I don't have a good solution to the overall problem. I'm mostly concerned about not having to fix packages with wrong maintainer addresses due to people trying to fix this 'issue'. Personally, I think it's inclusion is premature, but as long as the priority is lowered, I guess I can live with it. Scott K
Bug#958182: mailing-list-obsolete-in-debian-infrastructure tag considered harmful
... > lintian (2.67.0) unstable; urgency=medium > . >* Summary of tag changes: > + Added: ... >- mailing-list-obsolete-in-debian-infrastructure ... What is the recommended action to resolve this warning? For lists that aren't suitable to transition to lists.debian.org there isn't one. Unsolvable warnings don't help anyone. We've already had to have someone reupload multiple packages for PAPT because they 'fixed' this problem by using the wrong mailing list. Until this is actionable, this should be info at most. Pedantic even better. Scott K
Bug#958471: src:kineticstools: Non-free data included in source
Package: src:kineticstools Version: 0.6.1+20161222-1 Severity: serious Justification: Policy 2.1 All versions of kineticstools in the archive include a non-free data file: doc/whitepaper/kinetics.tex The file includes the following statement: For Research Use Only. Not for use in diagnostic procedures. © Copyright 2012, Pacific Biosciences of California, Inc. All rights reserved. Information in this document is subject to change without notice. Pacific Biosciences assumes no responsibility for any errors or omissions in this document. Certain notices, terms, conditions and/or use restrictions may pertain to your use of Pacific Biosciences products and/or third party products. Please refer to the applicable Pacific Biosciences Terms and Conditions of Sale and to the applicable license terms at http://www.pacificbiosciences.com/licenses.html. The license on the linked page includes "non-exclusive, non-transferable, non-sublicensable license" and specifically mentions documentation, so this file is non-free and must be removed from the tarball. It's non-distributable, so it wouldn't even be suitable for non-free. Note that there are references in README.Source about repacking the tarball to remove non-free material that seem to be obsolete. Those should be updated when this is done. Scott K
Bug#955603: Please don't remove these drivers
On April 21, 2020 1:09:47 AM UTC, Vlad wrote: >Please keep these drivers. They work as just fine, and many people >still use them. They have not been dropped by upstream X.org, and there >is no reason to drop them from Debian. Without these drivers, it will >make running Debian desktop on this hardware impossible. One of the >things that makes Debian great is the backward compatibility. It's very >sad to see destructive actions like this being taken. Please don't just >throw away all the work that people have put into these drivers over >the years, and please don't orphan their users! The removal was already done over 2 weeks ago. At this point an interested party would have to package them and get them back in. Scott K
Bug#958318: src:python-setuptools: Incomplete debian/copyright
Actually I was slightly wrong about the changes due to the upcoming policy change. A copy of the license will still be needed in debian/copyright for pkg_resources/_vendor/pyparsing.py: setuptools/_vendor/pyparsing.py: pkg_resources/_vendor/six.py: setuptools/_vendor/six.py: It's only the missing copyright attributions that wouldn't be a problem under the upcoming change. Scott K
Bug#958324: src:setuptools: Please document status of prebuilt Windows binaries in source
Package: src:setuptools Version: 45.2.0-1 Severity: minor Tags: patch As discussed on IRC it would be good to document the status of the prebuilt Windows binaries in the source package. Please see the attached patch. Except for needing the bug number, it should be complete and ready to apply. Scott K diff -Nru setuptools-45.2.0/debian/changelog setuptools-45.2.0/debian/changelog --- setuptools-45.2.0/debian/changelog 2020-02-25 07:20:41.0 -0500 +++ setuptools-45.2.0/debian/changelog 2020-04-20 10:39:00.0 -0400 @@ -1,3 +1,10 @@ +setuptools (45.2.0-2) UNRELEASED; urgency=medium + + * Add lintian overrides for source-contains-prebuilt-windows-binary +to document why these files are acceptable for Debian (Closes: nn) + + -- Scott Kitterman Mon, 20 Apr 2020 10:39:00 -0400 + setuptools (45.2.0-1) unstable; urgency=medium * New upstream version, Python3 only. Keep building the Python2 and diff -Nru setuptools-45.2.0/debian/source/lintian-overrides setuptools-45.2.0/debian/source/lintian-overrides --- setuptools-45.2.0/debian/source/lintian-overrides 1969-12-31 19:00:00.0 -0500 +++ setuptools-45.2.0/debian/source/lintian-overrides 2020-04-20 10:38:47.0 -0400 @@ -0,0 +1,9 @@ +# Source is included for these files, they can be built in Debian with the +# mingw toolchain, and the are not shipped in the binary, so this is OK for +# Debian. It is not worth repacking the tarball just for this. +setuptools source: source-contains-prebuilt-windows-binary setuptools/cli-32.exe +setuptools source: source-contains-prebuilt-windows-binary setuptools/cli-64.exe +setuptools source: source-contains-prebuilt-windows-binary setuptools/cli.exe +setuptools source: source-contains-prebuilt-windows-binary setuptools/gui-32.exe +setuptools source: source-contains-prebuilt-windows-binary setuptools/gui-64.exe +setuptools source: source-contains-prebuilt-windows-binary setuptools/gui.exe
Bug#958318: src:python-setuptools: Incomplete debian/copyright
Package: src:python-setuptools Version: 40.8.0-1 Severity: serious Justification: Policy 2.3 While reviewing src:setuptools in New, I noticed a number of omissions from debian/copyright which apply to this package as well. Copyright and license information from the following files is missing. Under current Debian Policy (4.5.0) these are all required. An upcoming policy change will relax the requirement so that license text and copyright attributions that are shipped in text form in the package are not required to be in debian/copyright. Once that change is part of policy, then only the changes relative to LICENSE and pkg_resources/_vendor/ appdirs.py will be required (the license text is missing from appdirs.py). Scott K LICENSE: Copyright (C) 2016 Jason R Coombs Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. pkg_resources/_vendor/pyparsing.py: setuptools/_vendor/pyparsing.py: # Copyright (c) 2003-2018 Paul T. McGuire pkg_resources/_vendor/six.py: setuptools/_vendor/six.py: # Copyright (c) 2010-2015 Benjamin Peterson # Copyright (c) 2010-2015 Benjamin Peterson # # Permission is hereby granted, free of charge, to any person obtaining a copy # of this software and associated documentation files (the "Software"), to deal # in the Software without restriction, including without limitation the rights # to use, copy, modify, merge, publish, distribute, sublicense, and/or sell # copies of the Software, and to permit persons to whom the Software is # furnished to do so, subject to the following conditions: # # The above copyright notice and this permission notice shall be included in all # copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE # AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE # SOFTWARE. pkg_resources/_vendor/appdirs.py: # Copyright (c) 2005-2010 ActiveState Software Inc. # Copyright (c) 2013 Eddy Petrișor According to the link in the file, the license is: # This is the MIT license Copyright (c) 2010 ActiveState Software Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Bug#937144: [Python-modules-team] Bug#938756: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On Monday, April 20, 2020 8:51:10 AM EDT peter green wrote: > On 20/04/2020 08:57, Thomas Goirand wrote: > >> Option 1: fix all four packages to be python 2 free. > >> > >> Option 2: Remove python2 stuff from traceback2, python-funcsigs and > >> numba. Break the dependencies of nipype in sid. > >> > >> Option 3: Remove python2 stuff from traceback2, modify python-funcsigs > >> so it still builds the python2 package but does not run tests with > >> python 2. > > > > Funcsigs is a backport of the PEP 362 function signature features from > > Python 3.3's inspect module. > > Thanks for the info. > > > Python 2 has never been removed from this > > package. Though instead, we shall remove this source package entirely > > from Debian. > > # Broken Depends: > nipype: python-nipype > pytest: pypy-pytest > python-logfury: python3-logfury > python-oslo.utils: python3-oslo.utils > > # Broken Build-Depends: > beaker: python3-funcsigs > kombu: python3-funcsigs > nipype: python-funcsigs > pagure: python3-funcsigs > pytest: pypy-funcsigs > python-oslo.log: python3-funcsigs > python-oslo.utils: python3-funcsigs (>= 0.4) > ripe-atlas-cousteau: python3-funcsigs > > If what you say is correct then it sounds like the python3-funcsigs revese > depedencies could be dealt with fairly easily. > > But that still leaves the question of what to do about the dependency of > pytest on pypy-funcsigs ? should pypy modules be removed from pytest and > it's reverse-dependencies in the same way that regular python2 modules > were? how feasible is that? are pypy-* packages only useful with python2 > pypy or are they also useful with python3 pypy? The Python 2 pypy variant isn't being dropped, so if pypy-funcsigs has rdepends, it should probably stay. In the interest of maintaining momentum on the Python 2, I think it would be better to just drop python-funcsigs and sort out the future of pypy-funcsigs and python3-funcsigs later. > > Traceback2 *already* has Python 2 support removed in Sid. I uploaded > > this on the 21st of march, pressured by its potential autoremoval. > > Sorry it seems I got my package names mixed up when writing the list of > options. I said traceback2 where I meant unittest2. > > There's no other choice but to fix nipype at this point, or wait until > > it gets autoremoved from Testing. > > It already was autoremoved from testing. > > > IMO, it'd be fine to NMU a new > > upstream release if you contact the current maintainer and/or using the > > delayed queue. > > A new upstream release for a package I do not use is not something I feel > comfortable NMUing. I was hoping that my initial mail would prompt action > on the parts of the nipype maintainers but if they don't respond then I > tend towards ignoring breakage of sid-only packages that need non-trivial > fixes. The current nipype maintainer is well aware of the issue. AIUI they are holding off on uploading to Unstable until they are confident the Python 3 port is sufficiently mature. Since it's already out of Testing and uninstallable in Sid, you can ignore causing further breakage (it won't get any more uninstallable). > > IMO, we should get unittest2 free of Py2 support ASAP, and open an FTP > > team bug to get funcsigs removed from Debian. I think the original option 2 still makes the most sense. Scott K signature.asc Description: This is a digitally signed message part.
Bug#937144: [Python-modules-team] Bug#938756: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On April 20, 2020 2:36:00 AM UTC, peter green wrote: >(using -quiet aliases where multiple involved packages have the same >maintainer listed. > >Hi > >I have just been running some self-contained buildability tests on >bullseye and these tests indicated that the python-linecache2 and >python-traceback2 source packages have been unbuildable in testing for >170+ days. Both are fixed in unstable by removing python 2 support, but >can't migrate to testing because the python-unittest2 binary package >depends on the python-traceback2 binary package. The python2 removal >bug for python-traceback2 lists python-funcsigs as a blocker. The >python2 removal bug for python-traceback2 lists nipype and numba as >blockers. > >unittest2 and python-funcsigs seem to be just module packages, so >dropping python2 support should be simple. numba seems to be a case of >leftover recommends and test-triggers so that should be a pretty easy >job to clean up too. > >nipype on the other hand looks like it needs a new upstream release. It >seems this was previously blocked on a package passing new, but said >package has now passed new. > >python-funcsigs seems to have a build-dependency on python-traceback2 >but not a binary dependency, this suggests that the dependency is only >used to run tests at build time. > >nipype and numba are not currently in testing. > >This IMO leaves three potential ways forward > >Option 1: fix all four packages to be python 2 free. > >Option 2: Remove python2 stuff from traceback2, python-funcsigs and >numba. Break the dependencies of nipype in sid. > >Option 3: Remove python2 stuff from traceback2, modify python-funcsigs >so it still builds the python2 package but does not run tests with >python 2. > >If the maintainers of nipype are willing to upload a python 3 version >soon, then option 1 is IMO the preffered way forward, but a new >upstream version is not something I would be prepared to NMU. > >Otherwise I am inclined towards option 2. Depending on what responses I >get to this mail I may implement this option through NMUs later. Nipype in Unstable is already all kinds of broken. I'd ignore further breaking it your analysis. I'd suggest move forward with option 2. Scott K
Bug#958166: closed by Scott Kitterman (Re: [Python-modules-team] [critical] #958166 - python3-all has had python3.7 removed)
On April 19, 2020 1:55:20 PM UTC, Luke Kenneth Casson Leighton wrote: >On Sun, Apr 19, 2020 at 1:36 PM Debian Bug Tracking System > wrote: > >> #958166: python3-all: python3 can't import gmpy2 >> Python3.7 is no longer supported in Debian Unstable and Testing and >will be removed shortly. > >if you were talking about python 3.6, there would be absolutely no >problem, because python 3.6 is not the default version of python3 >that's installed in the current LTS stable release (debian 10). > >the fact that python 3.7 is the default LTS stable *and is being >removed* leaves an extremely serious situation for anyone that >attempts to dist-upgrade from debian 10 to debian 11. > >that was the lesson learned - the mistake made - by the ubuntu team, >made all the more serious that the entire apt packaging system was >critically dependent on a version of python that was *being removed* >(!!) > >forget for one moment that i'm using debian/testing (which you should >not in any way find it "acceptable" to callously dismiss people in the >position that i am in such an unthinking fashion) - people doing >*stable* dist-upgrades will end up with broken systems. > >and it's part of debian that stable-to-stable dist-upgrades must >*always work*, ok? you should know this. > >and *that* is why i raised this as a critical bugreport, ok? > >*please think* before arbitrarily closing critical bugreports, ok? > >l. That's completely wrong. The existence proof is the aforementioned Debian 10. It only supports python3.7. Not the version that was in Debian 9. If you need more, look at Debian 9; it only supports python3.5, which is not the version in Debian 8 (the actual LTS release). Scott K
Bug#958043: [Python-modules-team] [critical] #958166 - python3-all has had python3.7 removed
Alternately, you could just update python3-gmpy2 to the latest version of the package, which is built to support python3.8: https://packages.debian.org/sid/amd64/python3-gmpy2/filelist Python3.7 is no longer supported in Debian Unstable and Testing and will be removed shortly. What you are observing is a perfectly normal transition to a newer version of python3. If such things bother you this much, you should probably stick to a Debian Stable release. This is the 7th time we've done this for Python3. It happens once or twice a release cycle. There's no bug at all here. Scott K
Bug#954812: [Python-modules-team] Bug#954812: pythonmagick: autopkgtest regression: cannot import name '_PythonMagick'
On April 18, 2020 10:03:01 AM UTC, Adrian Bunk wrote: >On Mon, Mar 23, 2020 at 09:43:19PM +0100, Paul Gevers wrote: >> Source: pythonmagick >> Version: 0.9.19-6 >> X-Debbugs-CC: debian...@lists.debian.org >> Severity: serious >> User: debian...@lists.debian.org >> Usertags: regression >> >> Dear maintainer(s), >> >> With a recent upload of pythonmagick the autopkgtest of pythonmagick >> fails in testing when that autopkgtest is run with the binary >packages >> of pythonmagick from unstable. It passes when run with only packages >> from testing. In tabular form: >> >>passfail >> pythonmagick from testing0.9.19-6 >> versioned deps [0] from testingfrom unstable >> all others from testingfrom testing >> >> I copied some of the output at the bottom of this report. >> >> Currently this regression is blocking the migration to testing [1]. >Can >> you please investigate the situation and fix it? >>... >> Testing with python3.7: >> + python3.7 >> Traceback (most recent call last): >> File "", line 1, in >> File "/usr/lib/python3/dist-packages/PythonMagick/__init__.py", >line >> 1, in >> from . import _PythonMagick >> ImportError: cannot import name '_PythonMagick' from 'PythonMagick' >>... > >This is not a regression in the package, the root cause is: >https://lists.debian.org/debian-release/2020/04/msg00228.html No. This one started to early to be caused by that issue. In this case the issue was that the autopkgtest was run for all installed python3 versions, but the package only builds for the default version. It's trivially fixable by making the autopkgtest run only for the default version, but it would be much better to solve it by having the package build for all supported python3 versions and running the autopkgtest against all of them. Scott K
Bug#956933: tpm2-tools: Invalid Maintainer Email Address
Package: tpm2-tools Version: 4.1.1-1 Severity: serious Justification: Policy 3.3 Policy requires a valid maintainer email address. Please see below: A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: mathieu.trudel-lapie...@canonical.com host mx.canonical.com [91.189.95.10] SMTP error from remote mail server after RCPT TO:: 550 5.1.1 : Recipient address rejected: User unknown in virtual alias table To: mathieu.trudel-lapie...@canonical.com From: Debian FTP Masters Subject: Processing of tpm2-tools_4.2-1_source.changes Date: Thu, 16 Apr 2020 21:00:10 + X-Debian: DAK X-DAK: DAK Precedence: bulk Auto-Submitted: auto-generated X-Debian-Package: tpm2-tools Message-Id: Scott K
Bug#956903: clang-tidy-6.0: Depends on cruft package python-yaml
Package: clang-tidy-6.0 Version: 1:6.0.1-14 Severity: serious The clang-tidy-6.0 package depends on python-yaml, which is now NBS and will be removed from Testing at some point. I understand that llvm 6.0 is sticking around to support ghc, but is clang-tidy needed for that? If that binary could be dropped it would help with moving the python2-rm transition forward. Scott K
Bug#956902: python-reclass: Depends on cruft package python-yaml
Package: python-reclass Version: 1.4.1-3.1 Severity: serious Python-yaml is now NBS and will be removed from Testing at some point. Python-reclass either needs to drop the python-yaml depends (I haven't investigated if this is feasible) or move to python3 and depend on python3-yaml. I'm aware based on the discussion in #938340 that there is a preference not to remove reclass entirely to support boxer, but removing it from Testing won't affect that. Scott K
Bug#515634: python-yaml: YAML loader complains about non-unique anchors
The proposed change in https://github.com/yaml/pyyaml/pull/394 resolves this issue. Scott K signature.asc Description: This is a digitally signed message part.
Bug#902180: RM: golang-github-docker-engine-api -- ROM; obsolete
> The new version of kubernetes is not a reverse build-dependency anymore. > There are individual RM requests for the remaining blockers: #956741 and > #956743. I removed the moreinfo tag to signal that the FTP masters can go > ahead and remove golang-github-docker-engine-api in the same batch with > those two. Thank you for taking the time to get it sorted out. Scott K signature.asc Description: This is a digitally signed message part.
Bug#515634: Unable to replicate Debian Bug report
Still a problem:
File "/usr/lib/python3/dist-packages/yaml/__init__.py", line 114, in load
return loader.get_single_data()
File "/usr/lib/python3/dist-packages/yaml/constructor.py", line 49, in
get_single_data
node = self.get_single_node()
File "/usr/lib/python3/dist-packages/yaml/composer.py", line 36, in
get_single_node
document = self.compose_document()
File "/usr/lib/python3/dist-packages/yaml/composer.py", line 55, in
compose_document
node = self.compose_node(None, None)
File "/usr/lib/python3/dist-packages/yaml/composer.py", line 82, in
compose_node
node = self.compose_sequence_node(anchor)
File "/usr/lib/python3/dist-packages/yaml/composer.py", line 111, in
compose_sequence_node
node.value.append(self.compose_node(node, index))
File "/usr/lib/python3/dist-packages/yaml/composer.py", line 75, in
compose_node
raise ComposerError("found duplicate anchor %r; first occurrence"
yaml.composer.ComposerError: found duplicate anchor 'anchor'; first occurrence
in "test.yml", line 1, column 5
second occurrence
in "test.yml", line 2, column 5
signature.asc
Description: This is a digitally signed message part.
Bug#956698: lintian: package-from-other-python-variant exception: python-pip-whl
On Tuesday, April 14, 2020 9:22:37 AM EDT Mattia Rizzolo wrote: > On Tue, Apr 14, 2020 at 08:41:01AM -0400, Scott Kitterman wrote: > > The package python-pip-whl is a special case of a Python package built > > to work with either python or python3. Currently python3-vertualenv > > gets the following lintian warning: > > > > W: python3-virtualenv: > > python-package-depends-on-package-from-other-python-variant Depends: > > python-pip-whl > > > > While this is a great warning in general, in this case it's wrong. > > Would it be OK to special case python-pip-whl and have it not trigger > > this check? > > I would wager that this is the exact use case for an override? I've added on for python3-virtualenv pointing to this bug. If that's the preference of the lintian maintainers, I have no objection, please close the bug and we have it documented why it's an override. Scott K signature.asc Description: This is a digitally signed message part.
Bug#956698: lintian: package-from-other-python-variant exception: python-pip-whl
Package: lintian Version: 2.65.0 Severity: normal The package python-pip-whl is a special case of a Python package built to work with either python or python3. Currently python3-vertualenv gets the following lintian warning: W: python3-virtualenv: python-package-depends-on-package-from-other-python-variant Depends: python-pip-whl While this is a great warning in general, in this case it's wrong. Would it be OK to special case python-pip-whl and have it not trigger this check? Scott K
Bug#956425: RM: python-trollius -- RoQA; python2-only; backport of a another project; deprecated upstream; no rdeps
Actually nevermind. Once I decrufted uswgi it was fine. Scott K signature.asc Description: This is a digitally signed message part.
Bug#955005: Seconded.
Looks good. Scott K signature.asc Description: This is a digitally signed message part.
Bug#956184: RFP: python3-sphinx-better-theme -- modified version of the default Sphinx theme
Package: wnpp Severity: wishlist * Package name: python3-sphinx-better-theme Version : 0.1.5 Upstream Author : Steve Johnson * URL : https://pypi.org/project/sphinx-better-theme * License : Expat Programming Lang: Python Description : modified version of the default Sphinx theme This theme is now used by psycopg2 for its documentation, so it would be nice to see it in Debian so we could use it (instead of patching to use the default Sphinx Theme. sphinx-better-theme is an update to the default Sphinx theme with the following goals: . - Remove frivolous colors, especially hard-coded ones - Improve readability by limiting width and using more whitespace - Encourage visual customization through CSS, not themeconf Use semantic markup
Bug#955005: Relax requirements to copy copyright notices into d/copyright
On Tuesday, April 7, 2020 7:18:42 PM EDT Guillem Jover wrote: > > +#. the distribution license for those files requires that copyright > > + information be included in all copies and/or binary distributions; > > I'm assuming the entire list is supposed to hold at the same time? If > so perhaps adding an «and» here would make this completely unambiguous. Actually I think it would be the opposite. If we had: > + information be included in all copies and binary distributions; then I can see people claiming that since $LICENSE didn't explicitly require copyright information in both copies and binaries, they didn't have to do it. Keep in mind the example license text that I used to frame this part of the proposed change: > The above copyright notice and this permission notice shall be included in > all copies or substantial portions of the Software. I think what you are proposing would produce the opposite of the desired policy. If you don't like and/or, then I think or is better: > + information be included in all copies or binary distributions; Scott K signature.asc Description: This is a digitally signed message part.
Bug#956110: sabnzbdplus: Depends on cruft packages
Package: sabnzbdplus Version: 2.3.6+dfsg-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag since it is the closest one we have. sabnzbdplus depends on python-cheetah, which is not longer built by cheetah. Once it is decrufted, the package will be uninstallable. This is also true for python-configobj, no longer built by configobj. Since we can't release with cruft packages, this is an RC issue. Please update the package to drop these dependencies (I have not assessed if this is feasible short of a Python 3 port). Scott K
Bug#954579: datalad-container: FTBFS: build-dependency not installable: datalad (>= 0.11.5~)
What's the status on getting this fixed? This is causing quite a backlog on Testing migration. requests Migrates after: datalad-container python-urllib3 Migrates after: requests python-certifi Migrates after: requests python-pip Migrates after: python-certifi, python-urllib3, requests Those I the ones I know of since I'm tyring to get python-pip to migrate. Scott K signature.asc Description: This is a digitally signed message part.
Bug#955650: python-tablib: FTBFS: E NotImplementedError: DataFrame Format requires `pandas` to be installed. Try `pip install tablib[pandas]`.
On Fri, 3 Apr 2020 21:55:04 +0200 Lucas Nussbaum wrote:
> Source: python-tablib
> Version: 0.13.0-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200402 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_auto_test -- --system=custom --test-args="{interpreter} -m pytest
test_tablib.py"
> > I: pybuild base:217: python3.7 -m pytest test_tablib.py
... I cannot reproduce this in an up to date Sid chroot, so downgrading to
normal.
Scott K
signature.asc
Description: This is a digitally signed message part.
Bug#955005: Relax requirements to copy copyright notices into d/copyright
On Sat, 04 Apr 2020 14:36:57 -0700 Sean Whitton wrote: > Hello Scott, > > On Thu 26 Mar 2020 at 03:01PM -04, Scott Kitterman wrote: > > > On Thursday, March 26, 2020 1:31:31 PM EDT Scott Kitterman wrote: > >> 4. License requires copyright notice but doesn't specify anything about > >> source or binary (didn't look for an example, but I can totally see this > >> happening): I think this case is unclear with your revised wording. With > >> the current policy wording copyright notices would be required in > >> debian/copyright and I think that's correct. The current wording does seem > >> harsh, so it could probably be better while not leaving an ambiguity. > > > > Here's a specific example I am looking at in New: > > > > The above copyright notice and this permission notice shall be included in >> all copies or substantial portions of the Software. > > I agree with you that in such a case we would want the copyright notices > in d/copyright, but I disagree that my text leaves any room for doubt. > > The text you quote would seem clearly to "require that copyright > information be included in all binary distributions". > > Perhaps you could suggest an amendation to my text so I can better see > what you mean about ambiguity. Is a compilation a copy? Literally, it's not. It's a transformation based on the original, but the original is not there, so it's not a 'copy'. Currently, in the last paragraph, you are suggesting: "... when the license requires that copyright information be included in all binary distributions." As an alternative, I'd suggest: "... when the license requires that copyright information be included in all copies and/or binary distributions." Scott K signature.asc Description: This is a digitally signed message part.
Bug#892744: python3-pip: breaks with venv --system-site-packages
On Mon, 12 Mar 2018 14:53:11 +0100 Bernhard Reiter wrote: > Package: python3-pip > Version: 9.0.1-2 > Severity: normal > > Hi Maintainers, > > according to `pip help install`:: > > --user > [..] > On Debian systems, this is the default when running outside of a > virtual environment and not as root. > > However when using the recommended virtual environment `venv`, > the detection does not work. Example: > >python3 -m venv --system-site-packages x_env >. x_env/in/activate.fish >pip install vdirsyncer > > will end up with installed files > in .local/bin and .local/lib/python3.5/site-packages/ > While they should have been below x_env. > > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876145 > the problems is also mentioned. Looking at how #876145 was resolved, it should have taken care of this too. If you can still reproduce this problem in Debian 10 (Buster), please reopen. Scott K signature.asc Description: This is a digitally signed message part.
Bug#928767: pip regression
On Fri, 10 May 2019 19:30:58 +0200 =?UTF-8?Q?Josu=c3=a9_Tille?= wrote: > Package: python-pip > > Hello, > > > > Debian version : 9.9 > > probable package : python-pip 9.0.1-2+deb9u1 > > > I detected that since some days the install of package with pip fail > randomly with this stacktrace: > ... > After some research I found that this patch have been applied to pip : > https://sources.debian.org/patches/python-pip/9.0.1-2+deb9u1/Properly_catch_ > requests_HTTPError_in_index.py.patch/ > > I suspect that this patch break something. ... I don't believe that was the problem. It was a backport of an upstream change that is still in use. This problem does not occur with the version in Debian Unstable, so I am going to close the bug. Scott K signature.asc Description: This is a digitally signed message part.
Bug#955624: [Python-modules-team] Bug#955624: python3-pip: depend on python3.8 instead of python3.7
On Friday, April 3, 2020 10:57:10 AM EDT Jörg-Volker Peetz wrote: > Package: python3-pip > Version: 20.0.2-3 > Severity: wishlist > > Dear Debian Python Modules Team, > > this package is one of two on my system which still depends on > python3.7. When is the shift to dependency on python3.8 scheduled? This is due to an oddity in dh_python3. Details are in Bug #955632. I have a work-around and will include it in the next upload. Scott K signature.asc Description: This is a digitally signed message part.
Bug#955632: dh-python: Unfortunate entry points processing leads to wrong interpreter dependency
Package: dh-python
Version: 4.20200315
Severity: important
Currently (with python3.7 and 3.8 supported and python3.8 as default),
dh_python3 generates a python3.7 dependency for python3-pip. This is
not needed and actively harmful.
Please see the attached verbose dh_python3 log. It shows the entry_points.txt
file that makes it into the package is the one from python3.7, which
leads to the python3.7 dependency because of the entry point.
I can work around this by build-depending on python3 instead of
python3-all, but then the package isn't byte compiled against all
supported versions during build, so we may end up hiding problems.
Two related points:
If a version specific entry point is going to make it into the binary,
then it should be the default version.
For an arch:all package we shouldn't have version specific entry points
because that will lead to needing to rebuild the package when the
default version changes.
Currently we get the following entry points (note: we only ship the pip3
entry point):
python3.7 build:
[console_scripts]
pip = pip._internal.cli.main:main
pip3 = pip._internal.cli.main:main
pip3.7 = pip._internal.cli.main:main
This is what makes it in the package.
python3.8 build:
[console_scripts]
pip = pip._internal.cli.main:main
pip3 = pip._internal.cli.main:main
pip3.8 = pip._internal.cli.main:main
This would be an improvement since at least the version specific depends
would be on the default interpreter.
What I would really like to be able to do is:
[console_scripts]
pip3 = pip._internal.cli.main:main
I don't think this is urgent because I can work around the problem, but
it should be addressed at some point.
Thanks,
Scott K
dh_python3 -v
D: dh_python3 dh_python3:161: version: 4.20200315
D: dh_python3 dh_python3:162: argv: ['/usr/bin/dh_python3', '-v']
D: dh_python3 dh_python3:163: options: {'guess_deps': True, 'skip_private':
False, 'verbose': True, 'arch': None, 'package': None, 'no_package': None,
'compile_all': False, 'vrange': None, 'regexpr': None,
'accept_upstream_versions': False, 'depends': None, 'depends_section': None,
'recommends': None, 'recommends_section': None, 'suggests': None,
'suggests_section': None, 'requires': None, 'shebang': None, 'ignore_shebangs':
False, 'clean_dbg_pkg': True, 'no_ext_rename': False, 'no_shebang_rewrite':
False, 'O': None}
D: dh_python3 dh_python3:164: args: []
D: dh_python3 dh_python3:165: supported Python versions: 3.7,3.8 (default=3.8)
D: dh_python3 debhelper:107: skipping package: python-pip-whl
D: dh_python3 debhelper:152: source=python-pip, binary packages=['python3-pip']
D: dh_python3 dh_python3:183: processing package python3-pip...
D: dh_python3 fs:49: moving files from
debian/python3-pip/usr/lib/python3.7/dist-packages to
debian/python3-pip/usr/lib/python3/dist-packages/
D: dh_python3 tools:232: invoking: /usr/bin/python3.7 -c 'import sysconfig as
s;print("__SEP__".join(i or "" for i in s.get_config_vars("SOABI", "MULTIARCH",
"INCLUDEPY", "LIBPL", "LDLIBRARY")))'
D: dh_python3 fs:49: moving files from
debian/python3-pip/usr/lib/python3.8/dist-packages to
debian/python3-pip/usr/lib/python3/dist-packages/
W: dh_python3 fs:113: Paths differ:
debian/python3-pip/usr/lib/python3.8/dist-packages/pip-20.0.2.egg-info/entry_points.txt
and
debian/python3-pip/usr/lib/python3/dist-packages/pip-20.0.2.egg-info/entry_points.txt
---
debian/python3-pip/usr/lib/python3.8/dist-packages/pip-20.0.2.egg-info/entry_points.txt
+++
debian/python3-pip/usr/lib/python3/dist-packages/pip-20.0.2.egg-info/entry_points.txt
@@ -1,5 +1,5 @@
[console_scripts]
pip = pip._internal.cli.main:main
pip3 = pip._internal.cli.main:main
-pip3.8 = pip._internal.cli.main:main
+pip3.7 = pip._internal.cli.main:main
D: dh_python3 fs:260: package python3-pip details = {'requires.txt': set(),
'egg-info': set(), 'nsp.txt': set(), 'shebangs': {/usr/bin/python3,
/usr/bin/python3, /usr/bin/python3.7, /usr/bin/python3}, 'public_vers':
{Version('3.8'), Version('3')}, 'private_dirs': {}, 'compile': True,
'ext_vers': set(), 'ext_no_version': set()}
D: dh_python3 depends:117: generating dependencies for package python3-pip
D: dh_python3 depends:275: D={'python3:any', 'python3.7:any'}; R=[]; S=[];
E=[], B=[]; RT=[]
rm -f debian/python3-pip/usr/bin/pip
rm -f debian/python3-pip/usr/bin/pip3.?
rm -rf debian/python3-pip/usr/lib/python3.?
Bug#954256: python-pip-whl: Editable installs broken: can't find __main__ module
On Tue, 31 Mar 2020 15:03:30 -0400 Scott Kitterman wrote: > On Fri, 27 Mar 2020 08:50:28 -0400 Scott Kitterman > wrote: > > On Fri, 27 Mar 2020 01:39:04 -0400 Scott Kitterman > > wrote: > > > On Fri, 27 Mar 2020 01:25:28 -0400 Scott Kitterman > > > wrote: > > > > I can replicate this with the current pip in unstable (which is the > > current > > > > upstream release). We kept pep517 at version 0.7.0 because that's the > > > version > > > > that pip bundles and there are no other users of it in the archive. I > > > > upgraded pep517 to the current release and the problem went away. I > think > > > > this is a pep517 problem. I even see what looks like a relevant commit > > > > (although I'm not sure). > > > > > > I've uploaded the updated pep517. This problem won't be fully solved > until > > > python-pip is rebuilt to update the provided wheel. I'll do that > tomorrow. > > > > Testing this again with the updated pep517 it still fails, just in a > slightly > > different way, so I reopened the bug. I still think this is something in > > pep517, so the reassignment was correct. > > I have confirmed that if we aren't using a debundled pep517 (the path is > different), it all works. Upstream supports debundling so there is a bug here > somewhere and I still think it's in pep517. I intend to leave this open to > track the issue, but I am changing our pip package to use the bundled pep517 > to work around this for now. The newer pep517 made changes to make it zip safe, but they were incomplete. That's why the error changes with the current pep517 release. It almost works. Scott K signature.asc Description: This is a digitally signed message part.
Bug#912379: Bug #912379: /usr/bin/pip3: TypeError on "list --outdated": uses different Version implementations
On Tue, 30 Oct 2018 21:50:36 +0100 Ben Wiederhake wrote: > Package: python3-pip > Version: 9.0.1-2.3 > Severity: normal > File: /usr/bin/pip3 > > Dear Maintainer, > > I'm having trouble running this command: > > pip3 list --outdated > > Expected behavior: A list of outdated, local packages > Actual behavior: TypeError > > Full error message: > > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/pip/basecommand.py", line 215, in > main > status = self.run(options, args) > File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 157, in > run > packages = self.get_outdated(packages, options) > File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 168, in > get_outdated > dist for dist in self.iter_packages_latest_infos(packages, options) > File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 169, in > > if dist.latest_version > dist.parsed_version > TypeError: '>' not supported between instances of 'Version' and 'Version' > > This is not Debian #878082. > > Arch had a similar problem, there it was a packaging error: > > https://github.com/pypa/pip/issues/5429 > > Could it be that the Debian package has a similar issue? The problem turns out to be that setuptools and pip have different approaches for managing the namespace for packages they vendor and they are incompatible. Thanks to the incomparable dstufft for figuring it out. The attached patch works around this incompatibility. I've tested it with pip 20.2 on unstable and it resolves the issue. This or something similar should work on earlier versions too. Scott K--- a/src/pip/_internal/commands/list.py 2019-12-09 04:01:21.0 + +++ b/src/pip/_internal/commands/list.py 2020-04-01 03:10:23.480796645 + @@ -22,6 +22,8 @@ ) from pip._internal.utils.packaging import get_installer +from pip._vendor.packaging.version import parse + logger = logging.getLogger(__name__) @@ -164,13 +166,13 @@ def get_outdated(self, packages, options): return [ dist for dist in self.iter_packages_latest_infos(packages, options) -if dist.latest_version > dist.parsed_version +if parse(str(dist.latest_version)) > parse(str(dist.parsed_version)) ] def get_uptodate(self, packages, options): return [ dist for dist in self.iter_packages_latest_infos(packages, options) -if dist.latest_version == dist.parsed_version +if parse(str(dist.latest_version)) == parse(str(dist.parsed_version)) ] def get_not_required(self, packages, options): signature.asc Description: This is a digitally signed message part.
Bug#912379: Please update the pip package
On Tue, 17 Mar 2020 10:38:23 -0400 Scott Kitterman wrote: > On Fri, 10 Jan 2020 00:02:12 -0800 Nye Liu wrote: > > this bug is now more than a year old. > > > > Please update python3-pip and python-pip packages to >19.1 > > The same problem still exists with 20.2 in unstable. It appears that the > fundamental problem is that pip uses a modified pkg_resources copy (despite > their own rules to not modify vendored code) and then blames downstreams for > unbundling (which they do support). This turned out to be nonsense. Please ignore. Scott K signature.asc Description: This is a digitally signed message part.
Bug#955414: python3-pip: pip fails to install packages with pyproject.toml
On Tue, 31 Mar 2020 14:31:40 +0200 Christoph Reiter wrote: > Package: python3-pip > Version: 20.0.2-2 > Severity: important > > Dear Maintainer, > > (Note: This doesn't affect upstream pip, only the Debian/Ubuntu version) > > pip in Debian (and Ubuntu focal) fails to install Python packages which contain > a pyproject.toml > file. I've initially reported this upstream, but it turns out this is only > broken in the Debian version of pip. > > Related upstream issues: > > * https://github.com/pypa/pip/issues/7946 > * https://github.com/pypa/pip/issues/7874 > > I've created a minimal reproducer: > > https://github.com/lazka/pip-pyproject-bug This looks like another instance of #954256 [1]. It looks like it is related to unvendoring pep517, but I don't have it entirely figured out yet. Scott K [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954256
Bug#955388: src:python-bleach: Regular expression denial of service (CVE-2020-6817)
Package: src:python-bleach
Version: 3.1.2-0+deb10u1
Severity: important
Tags: security
Once again with a python-bleach security issue...
https://github.com/mozilla/bleach/security/advisories/GHSA-vqhp-cxgc-6wmm
Title
regular expression denial-of-service (ReDoS) in
BleachSanitizerFilter.sanitize_css gauntlet regular expression
Impact
bleach.clean behavior parsing style attributes could result in a regular
expression denial of service (ReDoS).
Calls to bleach.clean with an allowed tag with an allowed style attribute are
vulnerable to ReDoS. For example, bleach.clean(..., attributes={'a':
['style']}).
Fixed In
3.1.4
Workarounds
do not whitelist the style attribute in bleach.clean calls
limit input string length
References
https://bugzilla.mozilla.org/show_bug.cgi?id=1623633
https://www.regular-expressions.info/redos.html
https://blog.r2c.dev/posts/finding-python-redos-bugs-at-scale-using-dlint-and-r2c/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6817
Bug#954478: Acknowledgement (src:python-pbkdf2: Autopkgtest failure due to use of py3versions -i)
I intend to upload an NMU to address this issue. NMU diff attached. Scott Kdiff -Nru python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/changelog python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/changelog --- python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/changelog 2019-12-23 16:51:11.0 -0500 +++ python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/changelog 2020-03-28 17:45:23.0 -0400 @@ -1,3 +1,11 @@ +python-pbkdf2 (1.3+20110613.git2a0fb15~ds0-3.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix autopkgtest to reliably test all supported python3 versions (Closes: +#954478) + + -- Scott Kitterman Sat, 28 Mar 2020 17:45:23 -0400 + python-pbkdf2 (1.3+20110613.git2a0fb15~ds0-3.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/control python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/control --- python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/control 2019-12-23 16:51:04.0 -0500 +++ python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/control 2020-03-28 17:45:23.0 -0400 @@ -1,2 +1,2 @@ Tests: python3-pbkdf2 -Depends: python3-pbkdf2 +Depends: python3-all, python3-pbkdf2 diff -Nru python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/python3-pbkdf2 python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/python3-pbkdf2 --- python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/python3-pbkdf2 2013-07-05 16:07:24.0 -0400 +++ python-pbkdf2-1.3+20110613.git2a0fb15~ds0/debian/tests/python3-pbkdf2 2020-03-28 17:45:23.0 -0400 @@ -6,6 +6,6 @@ cp -r test "$WORKDIR/" cd "$WORKDIR/" -for python in $(py3versions -i); do +for python in $(py3versions -s); do PYTHONWARNINGS=d $python -m unittest discover -s test/ 2>&1 done signature.asc Description: This is a digitally signed message part.
Bug#954469: src:pyrlp: Autopkgtest failure due to use of py3versions -i
On Wed, 25 Mar 2020 22:18:52 -0300 eamanu wrote: > Hi, > > I attach a NMU patch. Please, consider apply it. I intend to sponsor this. Scott K signature.asc Description: This is a digitally signed message part.
Bug#954468: src:pyethash: Autopkgtest failure due to use of py3versions -i
On Wed, 25 Mar 2020 22:01:38 -0300 eamanu wrote: > Hi, > > I attach a NMU patch. Please, consider apply it. RC bug with no maintainer response for 7 days, so I intend to sponsor this. Scott K signature.asc Description: This is a digitally signed message part.
Bug#954461: Autopkgtest failure due to use of py3versions -i
On Wed, 25 Mar 2020 14:16:23 -0300 eamanu wrote: > Hi, > > I attach a NMU patch. Please consider apply it. RC bug with no maintainer response for 7 days, so I intend to sponsor this. Scott K signature.asc Description: This is a digitally signed message part.
Bug#954480: python-tinyrpc: Autopkgtest failure due to use of py3versions -i
On Wed, 25 Mar 2020 11:07:49 -0300 eamanu wrote: > Hi, > > I attach a NMU patch. Please, consider apply it. RC bug with no response from the maintainer for a week, so I intend to sponsor this. Scott K signature.asc Description: This is a digitally signed message part.
Bug#954154: [Pkg-salt-team] Bug#954154: src:salt: Requires a package outside of Main
On Friday, March 27, 2020 12:53:41 PM EDT Benjamin Drung wrote: > Hi, > > Am Dienstag, den 17.03.2020, 09:47 -0400 schrieb Scott Kitterman: > > Package: src:salt > > Version: 3000+dfsg1-3 > > Severity: serious > > Justification: Policy 2.2.1 > > > > This package uses python pip to download and install packages from > > outside the > > Debian archive to run autopkgtests. Main is required to be self- > > contained, > > including for tests. See the FTP Master's reject FAQ [1] item Non- > > Main II. > > I disabled all test cases that need Internet access. So no pip install > should be executed. Great. That's the most serious part of the bug. > > == > > ERROR: test_install_requirements_parsing ... > > -- > > This test that you mention just tests the parsing done by pip. The > download part is mocked in this test case. I cannot reproduce this > import exception on Debian unstable with python3-pip 20.0.2-2. Also the > test cases succeed in debci. Which version of python3-pip did you use? It would have been 20.0.2-1, but between -1 and -2 the only changes were to the pip autopkgtests, so it shouldn't affect things. If you can't reproduce it, then I wouldn't worry about it for now. If your autopkgtest passes and there's no downloading from outside Main, then I would be fine with considering the issue resolved. Scott K signature.asc Description: This is a digitally signed message part.
Bug#954256: python-pip-whl: Editable installs broken: can't find __main__ module
On Fri, 27 Mar 2020 01:39:04 -0400 Scott Kitterman wrote: > On Fri, 27 Mar 2020 01:25:28 -0400 Scott Kitterman > wrote: > > I can replicate this with the current pip in unstable (which is the current > > upstream release). We kept pep517 at version 0.7.0 because that's the > version > > that pip bundles and there are no other users of it in the archive. I > > upgraded pep517 to the current release and the problem went away. I think > > this is a pep517 problem. I even see what looks like a relevant commit > > (although I'm not sure). > > I've uploaded the updated pep517. This problem won't be fully solved until > python-pip is rebuilt to update the provided wheel. I'll do that tomorrow. Testing this again with the updated pep517 it still fails, just in a slightly different way, so I reopened the bug. I still think this is something in pep517, so the reassignment was correct. Scott K signature.asc Description: This is a digitally signed message part.
Bug#954256: [Python-modules-team] Bug
On Thu, 19 Mar 2020 12:20:05 + Scott Kitterman
wrote:
> Thanks. The virtualenv package needs updating following the recent pip
update. I'm working on it.
I can still replicate this with the new virtualenv. Here's the verbose
version for posterity:
Installing collected packages: setuptools, wheel
Created temporary directory: /tmp/pip-unpacked-wheel-w3e1u2qx
Creating /tmp/pip-build-env-htd82usc/overlay/bin
changing mode of /tmp/pip-build-env-htd82usc/overlay/bin/easy_install to
755
changing mode of /tmp/pip-build-env-htd82usc/overlay/bin/easy_install-3.8
to 755
Created temporary directory: /tmp/pip-unpacked-wheel-_pm79f2o
changing mode of /tmp/pip-build-env-htd82usc/overlay/bin/wheel to 755
Successfully installed setuptools-46.1.3 wheel-0.34.2
Cleaning up...
Removed build tracker: '/tmp/pip-req-tracker-e53aaqlu'
Installing build dependencies ... done
Running command /tmp/venv/bin/python3 /tmp/venv/share/python-wheels/
pep517-0.7.0-py2.py3-none-any.whl/pep517/_in_process.py
get_requires_for_build_wheel /tmp/tmpqmbnti16
/tmp/venv/bin/python3: can't find '__main__' module in '/tmp/venv/share/
python-wheels/pep517-0.7.0-py2.py3-none-any.whl/pep517/_in_process.py'
Getting requirements to build wheel ... error
Cleaning up...
Removed file:///home/pypa from build tracker '/tmp/pip-req-tracker-e53aaqlu'
Removed build tracker: '/tmp/pip-req-tracker-e53aaqlu'
ERROR: Command errored out with exit status 1: /tmp/venv/bin/python3 /tmp/
venv/share/python-wheels/pep517-0.7.0-py2.py3-none-any.whl/pep517/
_in_process.py get_requires_for_build_wheel /tmp/tmpqmbnti16 Check the logs
for full command output.
Exception information:
Traceback (most recent call last):
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/cli/
base_command.py", line 186, in _main
status = self.run(options, args)
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/commands/
install.py", line 357, in run
resolver.resolve(requirement_set)
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/
legacy_resolve.py", line 177, in resolve
discovered_reqs.extend(self._resolve_one(requirement_set, req))
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/
legacy_resolve.py", line 333, in _resolve_one
abstract_dist = self._get_abstract_dist_for(req_to_install)
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/
legacy_resolve.py", line 265, in _get_abstract_dist_for
return self.preparer.prepare_editable_requirement(req)
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/operations/
prepare.py", line 554, in prepare_editable_requirement
abstract_dist = _get_prepared_distribution(
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/operations/
prepare.py", line 95, in _get_prepared_distribution
abstract_dist.prepare_distribution_metadata(finder, build_isolation)
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/distributions/
sdist.py", line 38, in prepare_distribution_metadata
self._setup_isolation(finder)
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/distributions/
sdist.py", line 96, in _setup_isolation
reqs = backend.get_requires_for_build_wheel()
File "/tmp/venv/share/python-wheels/pep517-0.7.0-py2.py3-none-any.whl/
pep517/wrappers.py", line 151, in get_requires_for_build_wheel
return self._call_hook('get_requires_for_build_wheel', {
File "/tmp/venv/share/python-wheels/pep517-0.7.0-py2.py3-none-any.whl/
pep517/wrappers.py", line 245, in _call_hook
self._subprocess_runner(
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/utils/
subprocess.py", line 271, in runner
call_subprocess(
File "/tmp/venv/lib/python3.8/site-packages/pip/_internal/utils/
subprocess.py", line 242, in call_subprocess
raise InstallationError(exc_msg)
pip._internal.exceptions.InstallationError: Command errored out with exit
status 1: /tmp/venv/bin/python3 /tmp/venv/share/python-wheels/pep517-0.7.0-
py2.py3-none-any.whl/pep517/_in_process.py get_requires_for_build_wheel /tmp/
tmpqmbnti16 Check the logs for full command output.
signature.asc
Description: This is a digitally signed message part.
Bug#955005: Relax requirements to copy copyright notices into d/copyright
On Thursday, March 26, 2020 1:31:31 PM EDT Scott Kitterman wrote: > 4. License requires copyright notice but doesn't specify anything about > source or binary (didn't look for an example, but I can totally see this > happening): I think this case is unclear with your revised wording. With > the current policy wording copyright notices would be required in > debian/copyright and I think that's correct. The current wording does seem > harsh, so it could probably be better while not leaving an ambiguity. Here's a specific example I am looking at in New: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. Scott K signature.asc Description: This is a digitally signed message part.
Bug#955005: Relax requirements to copy copyright notices into d/copyright
On March 26, 2020 4:57:12 PM UTC, Sean Whitton wrote: >Package: debian-policy >Version: 4.5.0.0 >User: debian-pol...@packages.debian.org >Usertags: normative discussion >X-debbugs-cc: debian-de...@lists.debian.org, ftpmas...@debian.org > >Scott has provided a useful summary of what the FTP Team require when >it >comes to copyright information, and as another FTP Team member, I >concur >with his assessment of the consensus within the team: > >On Thu 26 Mar 2020 at 10:32AM -04, Scott Kitterman wrote: > >> I think you assume we're looking for more than we are. We aren't >asking >> anyone to research and document undocumented but technically legally >> assertable copyright claims. From an FTP perspective we're after >license >> compliance. >> >> If debian/copyright includes all the copyright notices that upstream >does (or >> an equivalent), then that's all that's needed (there are exceptions, >I have >> reviewed packages where upstream literally wrote that they had copied >a bunch >> of code from some other location, changed the copyright owner to >themselves, >> and changed the license - that we had a problem with, but it wasn't >like we >> went looking for it). >> >> To pick one example, the Expat (MIT) license includes: >> >> The above copyright notice and this permission notice shall be >> included in all copies or substantial portions of the Software. >> >> When we ask for listing copyright holders in debian/copyright, that's >what >> we're after. I don't think complying with license requirements is an >> unreasonable thing to ask. >> >> That said, if we can make it easier for everyone, then we should >investigate >> that. As mentioned, policy does have a higher bar. It says they all >have to >> be listed regardless of license requirements. >> >> To pick another example, Apache-2.0 includes: >> >> (c) You must retain, in the Source form of any Derivative Works >> that You distribute, all copyright, patent, trademark, and >> attribution notices from the Source form of the Work, >> excluding those notices that do not pertain to any part of >> the Derivative Works; and >> >> For something that we distribute based on our rights in the >Apache-2.0 license >> and requirement to document all the copyright holders is strictly >Debian >> specific based on policy. Personally, I think the policy should be >changed so >> we don't require everyone to go beyond the license requirements. >Currently I >> think there is consensus within the FTP Team not to reject packages >for this. > >Policy currently says: > >Every package must be accompanied by a verbatim copy of its >copyright information, unless its distribution license explicitly >permits this information to be excluded from distributions of >binaries built from the source. In such cases, a verbatim copy of >its copyright information should normally still be included, but >need not be if creating and maintaining a copy of that information >involves significant time and effort. > >We wrote this based on [1], but I now believe it is too conservative, >and does not reflect what the FTP Team require, nor the project's >consensus on what should be in d/copyright. I think we want something >like this: > >The copyright information for files in a package must be copied >verbatim into d/copyright when (i) the distribution license for >those files requires that copyright information be included in all >binary distributions; (ii) the files are shipped in the binary >package, either in source or compiled form; and (iii) the form in > which the files are present in the binary package does not include a >plain text version of their copyright notices. > >Thus, the copyright information for files in the source package >which are only part of its build process, such as autotools files, >need not be included in d/copyright, because those files do not get >installed into the binary package. Similarly, plain text files > which include their own copyright information and are installed into >the binary package unmodified need not have that copyright >information copied into d/copyright. > > However, the copyright notices for any files which are complied into >the object code shipped in the binary package must all be included >in d/copyright when the license requires that copyright information >be included in all binary distributions, as most do. > >The point of separating (ii) and (iii) is because the sour
Bug#955000: azure-cli: Autopkgtest failure in unstable
Package: azure-cli
Version: 2.0.81+ds-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Note: Using the FTBFS tag because it is the closest one we have.
Now that humanfriendly is fixed to provide the missing files, azure-cli
has what looks like a real test failure [1]. Here's the relevant log
extract:
=== FAILURES ===
__ TestProgress.test_progress_indicator_indet_stdview __
self =
def test_progress_indicator_indet_stdview(self):
# tests the indeterminate progress standardout view
outstream = MockOutstream()
view = progress.IndeterminateStandardOut(out=outstream)
view.write({})
self.assertEqual(view.spinner.label, 'In Progress')
before = view.spinner.total
view.write({})
after = view.spinner.total
> self.assertTrue(after >= before)
E TypeError: '>=' not supported between instances of 'NoneType' and
'NoneType'
../autopkgtest-lxc.r8vnoncs/downtmp/autopkgtest_tmp/tests_core/test_progress.py:63:
TypeError
Scott K
[1]
https://ci.debian.net/data/autopkgtest/testing/amd64/a/azure-cli/4686987/log.gz
Bug#954910: dateparser: Incomplete test coverage due to missing requirements
Source: dateparser Version: 0.7.2-1 Severity: normal The current pip based install for the test includes two module not in Debian: jdatetime==3.1.0 umalqurra==0.2 As a result, 7 tests are skipped. Presumably this means that related functionality isn't available to users of the Debian package. These modules should be packaged and then included in Recommends or Suggests.
Bug#954909: python3-dateparser: Missing Recommends on python3-convertdate
Package: python3-dateparser Version: 0.7.2-1 Severity: important While investigating what the minimal package set that python3-dateparser needs to run its tests, I learned that adding python3-convertdate to the test environment causes 107 additional test cases to run. This seems like it's an indication that python3-convertdate should generally be installed with python3-dateparser. Recommends seems reasonable, but if there's some reason to avoid that, it should definitely be in Suggests. Scott K
Bug#954908: python3-convertdate: Syntax warning during installation with python3.8
Package: python3-convertdate Version: 2.1.3-2 Severity: normal When installing python3-convertdate in Unstable, where python3.8 is the default python3, the following warning is emitted: Setting up python3-convertdate (2.1.3-2) ... /usr/lib/python3/dist-packages/convertdate/utils.py:27: SyntaxWarning: "is" with a literal. Did you mean "=="? return b if modded is 0 else modded Scott K
Bug#954907: python3-dateparser: Warning with autopkgtest when python3.8 is default
Package: python3-dateparser Version: 0.7.2-1 Severity: normal While investigatin a resolution for #954147, I noticed the following warning being emitted. Presumably this will turn to an error in the future and should, at some point, be addressed: tmp/autopkgtest.ced6Wo/build.9qW/real-tree/dateparser/date.py:142: FutureWarning: Date formats should be list, tuple or set of strings warn(_DateLocaleParser.DATE_FORMATS_ERROR_MESSAGE, FutureWarning) Scott K
Bug#953863: python3-stem: "RuntimeError: dictionary keys changed during iteration" with python 3.8
On Sat, 14 Mar 2020 09:23:49 +0100 intrig...@debian.org wrote:
> Package: python3-stem
> Version: 1.7.1-1.1
> Severity: serious
>
> Hi,
>
> onioncircuits fails to start on current sid:
>
> Traceback (most recent call last):
> File "/bin/onioncircuits", line 657, in
> app = OnionCircuitsApplication()
> File "/bin/onioncircuits", line 633, in __init__
> self.connect_controller()
> File "/bin/onioncircuits", line 647, in connect_controller
> self.controller = stem.connection.connect(**connect_args)
> File "/usr/lib/python3/dist-packages/stem/connection.py", line 291, in
connect
> return _connect_auth(control_connection, password, password_prompt,
chroot_path, controller)
> File "/usr/lib/python3/dist-packages/stem/connection.py", line 375, in
_connect_auth
> return controller(control_socket, is_authenticated = True)
> File "/usr/lib/python3/dist-packages/stem/control.py", line 1057, in
__init__
> super(Controller, self).__init__(control_socket, is_authenticated)
> File "/usr/lib/python3/dist-packages/stem/control.py", line 585, in
__init__
> self._post_authentication()
> File "/usr/lib/python3/dist-packages/stem/control.py", line 3902, in
_post_authentication
> owning_pid = self.get_conf('__OwningControllerProcess', None)
> File "/usr/lib/python3/dist-packages/stem/control.py", line 2170, in
get_conf
> entries = self.get_conf_map(param, default, multiple)
> File "/usr/lib/python3/dist-packages/stem/control.py", line 2273, in
get_conf_map
> for key in reply:
> RuntimeError: dictionary keys changed during iteration
>
>
> onionshare-gui fails to start with the same error since I upgraded to
> python 3.8.
>
> I think that's https://trac.torproject.org/projects/tor/ticket/30882,
> which was fixed upstream with this commit:
> https://gitweb.torproject.org/stem.git/commit/stem/control.py?
id=b5aecb743d33db1a6378d59792d8e57305b6c6f2
>
> I confirm that this commit fixes the problem I'm experiencing with
> onioncircuits and onionshare.
>
> Until you, or someone else, finds time to package the 1.8.0 upstream
> release, could you please import that fix as a Debian patch?
> Alternatively, would you mind if someone else did that as an NMU?
I'm going to NMU this since it's one of the python3.8 transition blockers. NMU
diff attached.
Scott Kdiff -Nru python-stem-1.7.1/debian/changelog python-stem-1.7.1/debian/changelog
--- python-stem-1.7.1/debian/changelog 2019-10-05 21:50:32.0 -0400
+++ python-stem-1.7.1/debian/changelog 2020-03-24 16:47:02.0 -0400
@@ -1,3 +1,10 @@
+python-stem (1.7.1-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add fix from upstream to fix dictionary key error (Closes: #953863
+
+ -- Scott Kitterman Tue, 24 Mar 2020 16:47:02 -0400
+
python-stem (1.7.1-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru python-stem-1.7.1/debian/patches/key_order.patch python-stem-1.7.1/debian/patches/key_order.patch
--- python-stem-1.7.1/debian/patches/key_order.patch 1969-12-31 19:00:00.0 -0500
+++ python-stem-1.7.1/debian/patches/key_order.patch 2020-03-24 16:47:02.0 -0400
@@ -0,0 +1,18 @@
+Description: Fix from upstream to fix dictionary key error
+Author: Scott Kitterman
+Bug-Debian: https://bugs.debian.org/953863
+Origin: https://gitweb.torproject.org/stem.git/commit/?id=b5aecb7
+Forwarded: not-needed
+Last-Update: 2020-03-24
+
+--- python-stem-1.7.1.orig/stem/control.py
python-stem-1.7.1/stem/control.py
+@@ -2270,7 +2270,7 @@ class Controller(BaseController):
+ # entries since the user didn't request those by their key, so we can't
+ # be sure what they wanted.
+
+- for key in reply:
++ for key in list(reply):
+ if not key.lower() in MAPPED_CONFIG_KEYS.values():
+ user_expected_key = _case_insensitive_lookup(params, key, key)
+
diff -Nru python-stem-1.7.1/debian/patches/series python-stem-1.7.1/debian/patches/series
--- python-stem-1.7.1/debian/patches/series 1969-12-31 19:00:00.0 -0500
+++ python-stem-1.7.1/debian/patches/series 2020-03-24 16:47:02.0 -0400
@@ -0,0 +1 @@
+key_order.patch
signature.asc
Description: This is a digitally signed message part.
Bug#951944: src:ariba: Autopkgtest failure
It turns out my guess was wrong. Ariba is only built to support the default python3 version which makes reliability tough during transitions. The attached patch builds for all version, which should solve any remaining test issues. Since this has been sitting around for quite some time and it is a transition blocker I intend to NMU shortly. Scott Kdiff -Nru ariba-2.14.4+ds/debian/changelog ariba-2.14.4+ds/debian/changelog --- ariba-2.14.4+ds/debian/changelog 2020-01-24 01:40:24.0 -0500 +++ ariba-2.14.4+ds/debian/changelog 2020-03-24 11:14:59.0 -0400 @@ -1,3 +1,11 @@ +ariba (2.14.4+ds-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Build for all supported python3 versions to fix test failures in complex +Python environments and ease python3 transitions (Closes: #951944) + + -- Scott Kitterman Tue, 24 Mar 2020 11:14:59 -0400 + ariba (2.14.4+ds-2) unstable; urgency=medium * Add B-D on dh-python to fix FTBFS. diff -Nru ariba-2.14.4+ds/debian/control ariba-2.14.4+ds/debian/control --- ariba-2.14.4+ds/debian/control 2020-01-24 01:40:24.0 -0500 +++ ariba-2.14.4+ds/debian/control 2020-03-24 11:13:11.0 -0400 @@ -6,7 +6,7 @@ Build-Depends: debhelper-compat (= 12), dh-python, python3-biopython, - python3-dev, + python3-all-dev, python3-dendropy, python3-setuptools, python3-pymummer (>= 0.10.2), signature.asc Description: This is a digitally signed message part.
Bug#954854: kopanocore: Please build python3-mapi for all supported python3 versions
Source: kopanocore Version: 8.7.0-7 Severity: important Currently kopanocore is failing tests with python3-defaults that has python3.8 as default + Testing to test python3-defaults migration. Additionally, kopanocore can't migrate from Unstable to Testing before python3-defualts. The reason for both of these issues is that python3-mapi is only compiled to support the default python3 version (3.7 in Testing and 3.8 in Unstable as of this writing). As a result, the python3-mapi from Testing isn't installable with the python3-defaults from Unstable (thus the test failure) and the python3-mapi from Sid is't installable in Testing (and thus the migration block). This kind of situation is exactly why it is preferable to build compiled binary Python extensions for all supported versions. While it's probably non-trivial to figure out how to do it, once it's done it will avoid kopanocore getting tangled up in these transitions in the future, so there will be a real pay off. I'm filing this as important because it complicates the transition, but there's no clear RC/policy issue to warrant something higher. We don't have a severity 'really important', but if we did, I think this would be one. Thanks for considering, Scott K
Bug#954819: lintian: Please update the old and ancient python-versions tags to warn about py3versions -r
Package: lintian Version: 2.59.0 Severity: normal Tags: patch Recently we've been seeing a number of autopkgtest failures related to the python3.8 as default python3 transition due to use of py3versions -r with no related X-Python3-Version field falling back to all supported versions. This is the correct behavior, but it has unfortunate consequences. I think it would be good to help mitigate future instances of these problems if we addeed information to the tags to also check for py3verions -r and see if it still gives what's needed for the package. Please see the attached patch. I'm not set on the wording, but I believe it's in the ball park. Scott K diff -Nru lintian-2.59.0/debian/changelog lintian-2.59.0+/debian/changelog --- lintian-2.59.0/debian/changelog 2020-03-22 16:22:08.0 -0400 +++ lintian-2.59.0+/debian/changelog2020-03-23 20:55:28.0 -0400 @@ -1,3 +1,10 @@ +lintian (2.59.0+) UNRELEASED; urgency=medium + + * Update old and ancient python-version-field tag text to suggest also +checking for incorrect use of py3verions -r + + -- Scott Kitterman Mon, 23 Mar 2020 20:55:28 -0400 + lintian (2.59.0) unstable; urgency=medium [ Chris Lamb ] diff -Nru lintian-2.59.0/tags/a/ancient-python-version-field.desc lintian-2.59.0+/tags/a/ancient-python-version-field.desc --- lintian-2.59.0/tags/a/ancient-python-version-field.desc 2020-03-22 16:22:08.0 -0400 +++ lintian-2.59.0+/tags/a/ancient-python-version-field.desc2020-03-23 20:55:28.0 -0400 @@ -7,4 +7,7 @@ associated Python version is satisfied by the current "oldstable" distribution of Debian and is therefore unnecessary. . - Please remove or update the reference. + Please remove or update the reference. If removing, please also check + for the use of py3versions -r in debian/control, debian/rules, and debian/ + tests/. Without an operative Python3-Version field py3versions will fall + back to all supported versions, which may not be appropriate. diff -Nru lintian-2.59.0/tags/o/old-python-version-field.desc lintian-2.59.0+/tags/o/old-python-version-field.desc --- lintian-2.59.0/tags/o/old-python-version-field.desc 2020-03-22 16:22:08.0 -0400 +++ lintian-2.59.0+/tags/o/old-python-version-field.desc2020-03-23 20:55:28.0 -0400 @@ -8,4 +8,7 @@ distribution of Debian and may be unnecessary. . Please remove or update the reference. This warning should be ignored - if you wish to support "sloppy" backports. + if you wish to support "sloppy" backports.If removing, please also check + for the use of py3versions -r in debian/control, debian/rules, and debian/ + tests/. Without an operative Python3-Version field py3versions will fall + back to all supported versions, which may not be appropriate.
Bug#954812: [Python-modules-team] Bug#954812: pythonmagick: autopkgtest regression: cannot import name '_PythonMagick'
The problem here is that py3versions -r falls back to supported versions when no X-Python3-Versions header field is present in debian/control and pythonmagic is only built for the current version: https://packages.debian.org/sid/amd64/python3-pythonmagick/filelist (shows only python3.8 objects) This is hidden behind redirecting stderr to /Dev/null. Solutions: Preferred: build for all supported python3 versions, change the -r to -s and ditch the redirect. Less preferred:. Change the -r to -d (default) and ditch the redirect. You may also need to allow stderr in debian/tests/control. Scott K On March 23, 2020 8:43:19 PM UTC, Paul Gevers wrote: >Source: pythonmagick >Version: 0.9.19-6 >X-Debbugs-CC: debian...@lists.debian.org >Severity: serious >User: debian...@lists.debian.org >Usertags: regression > >Dear maintainer(s), > >With a recent upload of pythonmagick the autopkgtest of pythonmagick >fails in testing when that autopkgtest is run with the binary packages >of pythonmagick from unstable. It passes when run with only packages >from testing. In tabular form: > > passfail >pythonmagick from testing0.9.19-6 >versioned deps [0] from testingfrom unstable >all others from testingfrom testing > >I copied some of the output at the bottom of this report. > >Currently this regression is blocking the migration to testing [1]. Can >you please investigate the situation and fix it? > >More information about this bug and the reason for filing it can be >found on >https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > >Paul > >[0] You can see what packages were added from the second line of the >log >file quoted below. The migration software adds source package from >unstable to the list if they are needed to install packages from >pythonmagick/0.9.19-6. I.e. due to versioned dependencies or >breaks/conflicts. >[1] https://qa.debian.org/excuses.php?package=pythonmagick > >https://ci.debian.net/data/autopkgtest/testing/amd64/p/pythonmagick/4632912/log.gz >autopkgtest [18:24:16]: test python3: [--- >+ py3versions -r >+ cd /tmp/autopkgtest-lxc.eflqupv1/downtmp/autopkgtest_tmp >+ echo Testing with python3.7: >Testing with python3.7: >+ python3.7 >Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3/dist-packages/PythonMagick/__init__.py", line >1, in >from . import _PythonMagick >ImportError: cannot import name '_PythonMagick' from 'PythonMagick' >(/usr/lib/python3/dist-packages/PythonMagick/__init__.py) >autopkgtest [18:24:17]: test python3: ---]
Bug#954805: src:xapers: Fails autopkgtest due to test assumptions about paths
Package: src:xapers
Version: 0.8.2-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
The following autopkgtest log extracted from [1] should be enough to
show the problem. It is currently showing up as a regression for
python3.8 as default, but this doesn't seem related at all.
Scott K
Note: Using FTBFS as a tag because it is the closest we have for
autopkgtest failures.
FAIL search --output=bibtex single
--- all.48.expected 2020-03-23 13:11:53.768226199 +
+++ all.48.output 2020-03-23 13:11:53.768226199 +
@@ -3,6 +3,6 @@
title = "Creation of the γ-verses",
year = "2011",
eprint = "1235",
-file = ":XAPERS_ROOT/01/1.pdf:pdf"
+file =
":/tmp/autopkgtest-lxc.cg\_m28kl/downtmp/build.i4p/src/test/tmp.all/docs/01/1.pdf:pdf"
}
FAIL bibtex multiple
--- all.49.expected 2020-03-23 13:11:53.940223633 +
+++ all.49.output 2020-03-23 13:11:53.936223692 +
@@ -10,7 +10,7 @@
year = "2012",
month = "Sep",
pages = "2092",
-file = ":XAPERS_ROOT/02/2 file.pdf:pdf"
+file =
":/tmp/autopkgtest-lxc.cg\_m28kl/downtmp/build.i4p/src/test/tmp.all/docs/02/2
file.pdf:pdf"
}
@article{arxiv:1235,
@@ -18,7 +18,7 @@
title = "Creation of the γ-verses",
year = "2011",
eprint = "1235",
-file = ":XAPERS_ROOT/01/1.pdf:pdf"
+file =
":/tmp/autopkgtest-lxc.cg\_m28kl/downtmp/build.i4p/src/test/tmp.all/docs/01/1.pdf:pdf"
}
@article{30929234,
No bibtex for doc id:5.
[1] https://ci.debian.net/data/autopkgtest/testing/amd64/x/xapers/4639691/log.gz
Bug#954804: release.debian.org: Need release team intervention to disentagle python-pip from python3.8 as default
Package: release.debian.org Severity: normal Python-pip is actually ready to migrate, but there are problems that will take manual intervention to address: 1. Autopkgtest regressions marked against doit and logbook: Both tests are RC buggy (and bugs filed). It's true that updating pip unmasked the bugs, but they were RC buggy before due to using packages downloaded from the internet to run tests. Also, logbook can't be fixed in Testing until after the python3.8 as default (python3-defaults) transition is complete. 2. Python-pip needs python-msgpack to migrate: Python-msgpack is trapped behind waiting for borgbackup to migrate and it's stuck behind python3.8 as default. The Unstable python-msgpack will break the borgbackup in Testing, so merely force updating python-msgpack may not be a great idea. This could be unblocked either by forcing python-msgpack or a temporary removal of borgbackup from Testing. This will also enable python-virtualenv to migrate in a few days after the updated Tox is in testing. Thanks, Scott K
Bug#954763: lintian: Lintian should warn about use of py3versions -i in autopkgtests
Package: lintian Version: 2.59.0 Severity: normal Is recently discussed in a thread on debian-devel [1] there is a common error in python related auotpkgtests where py3verions -i is used to loop over 'installed' python3 versions. This is currently causing a substantial number of failures since the debci systems testing for the python3.8 as default transition have python3.7-minimal installed. This provides enough of an interpreter to count as being installed (/usr/bin/ python3.7 is present) and to run autopkgtest, but not enough for the tests themselves to succeed in most cases. Eventually, this will stop being an immediate problem, so it would be useful to have lintian detect and warn against it so that these latent bugs don't accumulate. Preferably these packages should run their tests with all supported python3 versions. This is ensured by including python3-all in the test dependencies and using py3versions -s (instead of -i). Tests should run deterministically, not just based on whatever happens to be installed. If for some reason a package can't run tests against all supported versions, then py3versions -d should be used (test against the default version). Thanks, Scott K [1] https://lists.debian.org/debian-devel/2020/03/msg00280.html
Bug#954482: src:pyx3: Autopkgtest failure due to use of py3versions -i
Package: src:pyx3 Version: 0.15-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag because it's the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954483: src:wand: Autopkgtest failure due to use of py3versions -i
Package: src:wand Version: 0.5.9-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag because it's the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954481: src:python3-proselint: Autopkgtest failure due to use of py3versions -i
Package: src:python3-proselint Version: 0.10.2-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag because it's the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954480: src:python-tinyrpc: Autopkgtest failure due to use of py3versions -i
Package: src:python-tinyrpc Version: 0.6-3 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag because it's the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954477: src:python-jsonext: Autopkgtest failure due to use of py3versions -i
Package: src:python-jsonext Version: 0.4.2-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag because it's the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954479: src:python-pynvim: Autopkgtest failure due to use of py3versions -i
Package: src:python-pynvim Version: 0.4.1-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag because it's the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954478: src:python-pbkdf2: Autopkgtest failure due to use of py3versions -i
Package: src:python-pbkdf2 Version: 1.3+20110613.git2a0fb15~ds0-3.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag because it's the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954476: src:python-jsbeautifier: Autopkgtest failure due to use of py3versions -i
Package: src:python-jsbeautifier Version: 1.10.3-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag because it's the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954471: src:pystemd: Autopkgtest failure due to use of py3versions -iwq
Package: src:pystemd Version: 0.7.0-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag because it's the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954474: src:python-h2: Autopkgtest failure due to use of py3versions -i
Package: src:python-h2 Version: 3.2.0-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag because it's the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954473: src:python-daemon: Autopkgtest failure due to use of py3versions -i
Package: src:python-daemon Version: 2.2.4-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag because it's the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954470: src:pysha3: Autopkgtest failure due to use of py3versions -i
Package: src:pysha3 Version: 1.0.2-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag since that's the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954468: src:pyethash: Autopkgtest failure due to use of py3versions -i
Package: src:pyethash Version: 0.1.27-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag since that's the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954469: src:pyrlp: Autopkgtest failure due to use of py3versions -i
Package: src:pyrlp Version: 0.5.1-1.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag since it's the closes we have This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954467: src:pydbus: Autopkgtest failure due to use of py3versions -i
Package: src:pydbus Version: 0.6.0-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using the FTBFS tag because it's the closest one we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954461: src:editorconfig-core-py: Autopkgtest failure due to use of py3versions -i
Package: src:editorconfig-core-py Version: 0.12.2-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Used FTBFS as a tag, since it's the closes we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954462: src:m2crypto: Autopkgtest failure due to use of py3versions -i
Package: src:m2crypto Version: 0.31.0-9 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using FTBFS as a tag since it is the closest we have. This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#951944: src:ariba: Autopkgtest failure aused by use of py3versions -i
Package: src:ariba Version: 2.14.4+ds-2 Followup-For: Bug #951944 This package failed a recent autopkgtest and this is one of the blockers for python3-defaults migration. It failed because python3.7 was installed in the chroot and the current autopkgtest doesn't handle that. Autopkgtests should be run for all supported versions. The package attempts to do that, but in a way that is unreliable. Based on a review of the failure log (I have not looked at the package, so there's a small chance the root cause is different), the autopkgtest uses the output of py3versions -i to iterate over available python3 versions. The -i flag indicates all installed versions. In many cases python3.7 is still partially installed, so it is included in the tests, but fails. The reliable way to do this is add python3-all to your tests depends in debian/tests/control and change the py3versions call to py3versions -s. These two steps will ensure all supported python3 interpreters are fully installed and that the tests are run against them. As this is a blocker for getting python3.8 as default python3 into bullseye, please address this soon. I'm open to doing NMUs if anyone would like the support. Please let me know if you would like for me to do that. Scott K
Bug#954451: PAPT Team upload, not NMU
Now that I see PAPT is the maintainer, I guess it would be a team upload, not an NMU. In any case if someone has a plan other than dropping the tests, please say so in the bug. Scott K signature.asc Description: This is a digitally signed message part.
Bug#954451: src:tox: Please remove python2 autopkgtests that use virtualenv
Package: src:tox Version: 3.13.2-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Note: Using FTBFS to cover autopkgtest failure as it is a rough equivalent (package can't migrate to testing). The python-virtualenv package can no longer support creation of python2 virtualenvs without external downloads, which are not allowed for packages in Main. The ipaddr module is no longer in Testing and is required for this. As a result, tox python2 autopkgtests now fail: py2 create: /tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2 ERROR: invocation failed (exit code 1), logfile: /tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/log/py2-1.log == log start === Traceback (most recent call last): File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/lib/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/__main__.py", line 16, in from pip._internal.cli.main import main as _main # isort:skip # noqa File "/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/_internal/cli/main.py", line 10, in from pip._internal.cli.autocompletion import autocomplete File "/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/_internal/cli/autocompletion.py", line 9, in from pip._internal.cli.main_parser import create_main_parser File "/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/_internal/cli/main_parser.py", line 7, in from pip._internal.cli import cmdoptions File "/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/_internal/cli/cmdoptions.py", line 25, in from pip._internal.locations import USER_CACHE_DIR, get_src_prefix File "/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/_internal/locations.py", line 20, in from pip._internal.utils.compat import WINDOWS File "/tmp/autopkgtest-lxc.zhf4r5q1/downtmp/autopkgtest_tmp/.tox/py2/lib/python2.7/site-packages/pip/_internal/utils/compat.py", line 29, in import ipaddr as ipaddress # type: ignore ImportError: No module named ipaddr I'm happy to do an NMU to simply drop the tests if you would like. Please let me know if you plan to take care of it. I will probably NMU in a week (including the NMU diff in this bug once I have it ready) if I don't. Thanks, Scott K
Bug#937166: Python2 is not really depended on
On Sat, 22 Feb 2020 10:54:23 +0100 Kay Hayen wrote:
> Hello,
>
> this is not explained in the FAQ, but the way I have done it is like this
> (in build-depends, removed irrelevant parts):
>
>python (>= 2.6.6-2) | base-files (>= 11),
>python-all-dbg (>= 2.6.6-2) | base-files (>= 11),
>python-all-dev (>= 2.6.6-2) | base-files (>= 11),
>python-setuptools | base.files (>= 11),
>scons,
>python3-all-dev (>= 3.3),
>python3-all-dbg (>= 3.3),
>python3-setuptools,
>python-appdirs | base-files (>= 11),
>python3-appdirs | base-files (<< 7.2),
>python-pil | python-imaging | base-files (>= 11),
>python3-pil | base-files (<< 11),
>
> The reason being, that Nuitka is built for older Debian and Ubuntu
> distributions in Neurodebian as well. This is not pretty, but has been a
> strategy used for a long time now, although more reduced, see the Python3
> appdirs dependency.
>
> In dependencies there is then this:
>
> python3-appdirs | base-files (<< 7.2),
> python-dev (>= 2.6.6-2) | base-files (>= 11),
> python3-dev,
> ${misc:Depends},
> ${python:Depends},
> ${python3:Depends}
>
> That should not cause an issue. I have a bullseye based builder, where my
> package doesn't build, but the next one will (some rules check to discover
> Debian 11 fails on "testing", but not for "unstable"), and I had to make
> actual fixes with e.g. the tests not using "
Actual uploads to the Debian archive always take the first build-depend if
there are alternatives, so it doesn't work as you have it now. It'll pull in
Python.
If you want to use this kind of approach, put base-files first for the python
ones that aren't needed for the archive.
Scott K
signature.asc
Description: This is a digitally signed message part.
Bug#954236: Proposed Buster Fix (pyhon3-bleach: New secuirty issue: mutation XSS (again))
On Thursday, March 19, 2020 6:24:22 PM EDT Salvatore Bonaccorso wrote: > Hi Scott, > > On Thu, Mar 19, 2020 at 12:20:25AM -0400, Scott Kitterman wrote: > > Upstream's 3.1.2 release had just the security fix in it. I propose > > updating buster with it (I put 3.1.3 in unstable, but it had non-security > > fixes in it. > > > > I'm not 100% sure about if we need to modify the import path for the new > > test since we don't use the vendored html5lib, but other than that (which > > I will investigate), this should be good. > > Given we did release a DSA for the similar issue CVE-2020-6802 for > buster we can do the same as well now for this issue (it got assigned > CVE-2020-6816). > > Your plan to rebase to 3.1.2 looks good to me. > > Once you have the update ready please just come back to us, if > possible add the CVE id reference as it was assigned now, but more > importantly please adjust the debian/changelog (the target > distribution needs to be buster-security). > > many thanks for your work! I've uploaded it to security-master (didn't get the accept yet, so you should see it shortly. I added the CVE reference and changed the target distribution. In addition to test building, I ran the autopkgtests locally and it all passed, so it should be good to go. Scott K signature.asc Description: This is a digitally signed message part.
Bug#942910: automake-1.15: Python2 removal in sid/bullseye
On Tue, 17 Mar 2020 17:34:06 -0400 Scott Kitterman wrote: ... > As I mentioned in the automake-1.16 bug, these are the last two packages that > use python-virutalenv, so I'd really like to see them updated to unblock other > work. > > Thanks. > > Scott K It's now become clear that due to other changes in the python ecosystem in Debian, python-virtualenv has to go sooner rather than later (once the cruft python-pip is removed it will stop working). It's tests are already failing. As a result, I'm bumping this to serious because it needs to be resolved ~now. Please let me know if you don't want an NMU. Scott K
Bug#942928: automake-1.16: Python2 removal in sid/bullseye
On Tue, 17 Mar 2020 17:24:25 -0400 Scott Kitterman wrote: ...> Automake-1.15 and automake-1.16 are the last two packages using python- > virtualenv in Debian Testing. We would like to move forward with the removal > soon as it blocks other work. As a result, I'm going to bump this bug to > important. > > Please see the attached patch. I've run the autopkgtest using the attached > and it passes. If you would prefer me to NMU to save you the near-term effort, > please let me know. > > Scott K It's now become clear that due to other changes in the python ecosystem in Debian, python-virtualenv has to go sooner rather than later (once the cruft python-pip is removed it will stop working). It's tests are already failing. As a result, I'm bumping this to serious because it needs to be resolved ~now. Please let me know if you don't want an NMU. Scott K
Bug#938249: python-virtualenv: Python2 removal in sid/bullseye
I know this is marked py2keep, but I don't think we can. Our virtualenv is 5 years old and really needs updated. The brings in a requirement for pip in the base virtualenv which then needs a wheel for ipaddr (which is already out of testing) and python-pip, which has already been dropped. I think it needs to go. Scott K signature.asc Description: This is a digitally signed message part.
