On 9/14/26 08:10, Lyndon Brown wrote:
On Mon, 2026-09-14 at 04:03 +0200, Matthias Klose wrote:
Control: reassign -1 src:deluge
I'm concerned about this simply being reassigned to deluge, rather than
deluge getting marked as affected or a duplicate being made for it. If
deluge were depending on python3-pkg-resources, that might have
prevented me from installing the upgrade and ending up with a broken
application, but unfortunately deluge doesn't currently have such a
dependency. Others could find themselves in the same situation. With
the bug solely on deluge, there's nothing to stop python3-setuptools
from migrating to testing, and if it migrates to testing, then people
won't have an older testing version to downgrade to as a temporary
solution (the traditional solution for such breakage). (There is always
the stable version to downgrade to, but I've never had to downgrade to
a stable package version before and I've no idea if that version would
work).
I've done a little research and found some open MRs on deluge upstream
dating back to last year, so they seem to be very much aware of the
problem and have been working on it, though unfortunately that work
seems to have stalled. There's no knowing how long it may take before
they fix the problem.
I've scanned through the changelog of python3-setuptools and there seem
to be no security bugfixes to put pressure on getting anyone on Sid or
testing upgraded from v80 to v84.
If deluge is made to depend upon python3-pkg-resources, then that might
help mitigate the problem, but is it not sensible to block the python3-
setuptools testing migration for the time being to leave people with
with the option of downgrading to v80.9?
sure, you can let it depend on python3-pkg-resources. but this is one
out of more than 820 packages being affected by this, with around 780
packages already fixed. What do you gain by delaying? As you said,
upstream work has been stalled, so it's better to keep that package in
unstable for now.
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pkg-resources-deprecation;[email protected]
