On 04/06/2020 23:12, Thomas Goirand wrote:
On 6/4/20 10:33 PM, peter green wrote:
A few days ago Sandro Tosi uploaded the python-unittest2 and
python-funcsigs source packages. It seems that both of these were
effectively "team uploads" though they were not marked as such.
A few years ago, I've been flamed, them banned from the DPMT for less
than this... Though I don't think we should put the blame on Sandro. He
did a lot and we should be thankful for his work on Python 2 removal.
I'm not looking to place blame on anyone here, I am just looking to get broken
build-dependencies in testing dealt with.
The thing is, funcsigs is a backport of the PEP 362 function signature
features from Python 3.3's inspect module (as per the package
description), so it should in fact go away if possible.
I don't have any objection to it going away as long as the reverse-dependencies
are dealt with. It's now down to four rdeps, two of which (pagure and nipype)
are not in testing and one of which (kombu) is tagged pending with you on the
uploaders list.
I'm really not
sure what's going to be the faith of pypy-pytest, maybe it should be
replaced by pypy3-pytest? If I remember well the discussion, we wrote
that we would just disable the tests for things depending on python 2
test suites. Maybe this includes pypy-pytest?
Earlier in the discussion on bug 937769 the following was posted by Stefano
Rivera (pypy maintainer)
Stefano> pypy itself (the python 2.7 pypy) will continue to exist for the
Stefano> foreseeable future, to support building pypy3. But we don't need to
ship
Stefano> modules for it. I'd be pretty happy if we had working virtualenv, and
Stefano> nothing else.
And the following was posted by Ondřej Nový (pytest maintainer)
Ondřej> I'm perfectly fine with removing pypy-pytest binary package and all
other
Ondřej> dependencies in chain. It's painfull to maintain it.
Based on this it seemed that getting rid of pypy-pytest was the desired way
forward.
I went through the reverse (build-)depends of pypy-pytest and thier transitive
reverse (build-)depends, making the assumption that if the pypy-<module>
package was removed from a source package the build-dependencies on any pypy package
could also be removed. I concluded that in order for pypy-pytest to go away.
* The pypy-atomicwrites, pypy-pluggy, pypy-py pypy-setuptools-scm pypy-wcwidth
pypy-importlib-metadata and pypy-zipp binary packages need to go away (or alternatively
have their tests disabled). These packages are involved in build-dependency loops with
pytest, so they need to be dealt with at the same time as pypy-pytest. All of these have
the debian python maintainers team in the maintainer field which according to the team
policy indicates "Team in ``Maintainers`` is a strong statement that fully
collaborativemaintenance is preferred. Anyone can commit to the Git repository and
uploadas needed" so dealing with these as a block should not be an issue.
* vanguards needs to stop build-depending on pypy-pytest
According to the discussion over at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932820 vanguards uses pypy
for performance reasons, the long term goal would be to move to pypy3 but there
are (or at least were when that bug was last active) apparently some tooling
issues.
I filed bug 958848 on pytest ccing the vanguards maintainers, Chris Lamb (part
of the team that maintains vanguards but not directly involved in it's
maintenance) responded suggesting the possibility of running the vanguards
testsuite under python3. Obviously running the testsuite with a different
version of python from that which will be used on the running system is
sub-optimal, but it's probably better than not running the tests at all.
I took Chris's patch, tested that it builds the package succesfully, prepared a
debdiff and posted a rc bug report on vanguards. I am now waiting to see if the
maintainer responds.
