Re: py2removal RC severity updates - 2019-12-22 17:36:38.269399+00:00
> src:dbus-python cannot drop its Python 2 support until all of the reverse > dependencies of python-dbus have done so (or been removed from testing, but > that's unlikely to happen while they include key packages like avahi, > jackd2 and pyqt5). this is now the case: bin:python-dbus has no more reverse dependencies (that are not RC and/or being removed from testing), see dak output: Checking reverse dependencies... # Broken Depends: dbus-python: python-dbus-dbg **Internal deps python-dbus-tests ladish: ladish ** removed from testing in May 2020 neard: neard-tools ** removed from testing in Dec 2019 wicd: wicd-daemon ** removed from testing in Oct 2019 So please proceed with drooping python-dbus as soon as possible. Currently python-dbus is the sole rdep of python-gi, which then could be dropped when python-dbus is gone. Let me know if you need help with this activity: i'm available to NMU or team upload src:dbus-python if that's preferred Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: py2removal RC severity updates - 2019-12-22 17:36:38.269399+00:00
Control: severity 942941 normal Control: user debian-python@lists.debian.org Control: usertags 942941 + py2keep On Sun, 22 Dec 2019 at 12:36:38 -0500, Sandro Tosi wrote: > # python-dbus-tests is a module and has 0 external rdeps or not in testing > severity 942941 serious I do not consider this to justify a release-critical bug at this stage. src:dbus-python cannot drop its Python 2 support until all of the reverse dependencies of python-dbus have done so (or been removed from testing, but that's unlikely to happen while they include key packages like avahi, jackd2 and pyqt5). As long as python-dbus exists, there is little or no cost to having python-dbus-tests continue to be built by the same source package, and I would be reluctant to have python-dbus exist in the archive without its automated tests also being present. I also don't think it's appropriate to escalate the severity of the Python 2 removal bug for an entire source package just because *one* of its binary packages is a leaf: the criterion should probably be *all* of its Python 2 binary packages being leaf packages. (See also libpython2.7-testsuite in #937569, which seems to have a similar issue.) Thanks, smcv
