Bug#1025841: RM: lazr.smtptest -- ROM; broken with Python 3.10, superseded by python3-aiosmtpd, no rdeps
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org, Barry Warsaw As the last person to release a version of lazr.smtptest upstream, and a member of the Python team, I'd like to request its removal from Debian. I considered updating lazr.smtptest to fix https://bugs.debian.org/1018392. It also had a new upstream release made by me in 2019 adding support for Python 3.6 which nobody had yet packaged, and the fact that nobody's reported that as a bug rather suggests it isn't heavily used. When I tried packaging that, I found that the new version's tests fail with Python >= 3.10 (though this is a little non-obvious in the Debian packaging since the doctests aren't currently set up to run at build time), and I'm not sure I want to bother with the work required to figure that out and fix it. lazr.smtptest has no reverse dependencies in Debian. To my knowledge, even in upstream repositories, it was only ever used by Mailman and by the Mailman integration tests in Launchpad. I removed Launchpad's use of this module a while back as a consequence of some other rearrangements. Barry Warsaw, lazr.smtptest's original author, switched Mailman over to aiosmtpd in https://gitlab.com/mailman/mailman/-/issues/296, saying: Core uses lazr.smtptest for various things, which is based on the stdlib smtpd module, which itself is based on asyncore/asynchat. It also uses an LMTP server based on smtpd. Well, all that technology is old and cruft, and we have shiny new goodness in aiosmtpd. Rather than bringing it up to date, presumably as a wrapper around aiosmtpd, I think it's better to declare this package abandoned and remove it from Debian. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
review for pygubu/0.27-1
hi Bo,
my comments for the pygubu package up for sponsorship in the Python
team:
* changelog: only a single entry is needed for an initial debian
release.
* copyright:
+ please remove the copyright statement at the start of the MIT
license paragraph so that it contains only the license terms;
+ tests/support.py appears to be based on [1] (i.e. from upstream
python, license info at [2])?
* control:
+ do you need python3-tk for any other purpose than running tests?
If not, mark as !nocheck;
+ "Description: Debian packaging for pygubu": you want to describe
pygubu itself here, not that it's packaged for Debian - every
package in the distribution is, after all.
* rules: the script at development/runtests.sh simply calls "python3
-m unittest" on the tests dir for the default python3 only, which
is not what you want. Consider letting pybuild (+pytest?) handle
things directly, for example by changing the override to something
like PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="xvfb-run -a
{interpreter} -m pytest -v tests" dh_auto_test.
* tests: you don't want to hardcode dependencies on an autopkgtest
that should be pulled in by the binary package.
There's a debian/.gitlab-ci.yml file but the CI isn't enabled in the
repository settings on salsa.
The binary package seems to be missing dependencies on tk, pil
(conditional import at src/pygubu/stockimage.py:124), as well as a
large number of tk-related modules used by the plugins (tkcalendar,
awesometkinter, customtkinter, tkintertable, tkintermapview, tksheet;
most of these don't seem to be packaged yet).
Have you done any functional testing on a (reasonably clean) debian
testing or unstable install?
[1]https://hg.python.org/cpython/file/b5ac5e25d506/Lib/lib-tk/test/runtktests.py
[2]https://hg.python.org/cpython/file/b5ac5e25d506/LICENSE
pgpZArB6DiIph.pgp
Description: OpenPGP digital signature
Re: [MBF] pybuild: Stop calling setup.py test?
On Mon, Aug 15, 2022 at 06:27:22PM +, Stefano Rivera wrote: > Calling "setup.py test" has been deprecated since setuptools 28.5. > That's 6 years ago. > > pybuild calls currently setup.py test, when it can see that the package > supports it, and another test runner hasn't been selected. I looked at > dropping support for this (https://bugs.debian.org/982298) last year. > I did some test builds and decided that breaking 50 odd packages to stop > calling setup.py test wasn't worth it. I spent a bit of time this weekend converting some packages that I'm interested in to use the pytest runner, focusing first on ones that were using nose but also a few from this list (lazr.uri, python-wadllib, zope.interface). I needed a couple of workarounds, some due to packages using importlib.metadata to get their own version at import time (typified by the rather messy https://salsa.debian.org/python-team/packages/lazr.uri/-/commit/786825acc6) and some due to pre-PEP-420 namespace packages (typified by https://salsa.debian.org/python-team/packages/zope.interface/-/commit/a8c7881b1a). Fortunately pytest provides IMO rather convenient ways to hook in and gently tweak the import system just before it tries to import the modules under test, which I think is better in this context than bringing up a virtualenv or whatever. I'd be happy to do a bit more of this sort of thing. https://veronneau.org/debian-python-team-2022-sprint-report.html said that around 29 of 67 team-maintained packages were fixed during the sprint, which means I'm going to have a slightly annoying hit rate if I have to just go through this email to find targets. Is there somewhere else where the current list of target packages is being maintained, or would it be possible to do this mass bug-filing at sub-RC level so that there's a convenient list in the BTS? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Re: [MBF] pybuild: Stop calling setup.py test?
On 2022-12-10 17 h 09, Colin Watson wrote: On Mon, Aug 15, 2022 at 06:27:22PM +, Stefano Rivera wrote: Calling "setup.py test" has been deprecated since setuptools 28.5. That's 6 years ago. pybuild calls currently setup.py test, when it can see that the package supports it, and another test runner hasn't been selected. I looked at dropping support for this (https://bugs.debian.org/982298) last year. I did some test builds and decided that breaking 50 odd packages to stop calling setup.py test wasn't worth it. I spent a bit of time this weekend converting some packages that I'm interested in to use the pytest runner, focusing first on ones that were using nose but also a few from this list (lazr.uri, python-wadllib, zope.interface). I needed a couple of workarounds, some due to packages using importlib.metadata to get their own version at import time (typified by the rather messy https://salsa.debian.org/python-team/packages/lazr.uri/-/commit/786825acc6) and some due to pre-PEP-420 namespace packages (typified by https://salsa.debian.org/python-team/packages/zope.interface/-/commit/a8c7881b1a). Fortunately pytest provides IMO rather convenient ways to hook in and gently tweak the import system just before it tries to import the modules under test, which I think is better in this context than bringing up a virtualenv or whatever. I'd be happy to do a bit more of this sort of thing. https://veronneau.org/debian-python-team-2022-sprint-report.html said that around 29 of 67 team-maintained packages were fixed during the sprint, which means I'm going to have a slightly annoying hit rate if I have to just go through this email to find targets. Is there somewhere else where the current list of target packages is being maintained, or would it be possible to do this mass bug-filing at sub-RC level so that there's a convenient list in the BTS? This is the list we used during the sprint to coordinate: https://pad.riseup.net/p/FixSetupTest-keep It's probably outdated though and I feel a real MBF would be helpful to keep track at this point... -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
