Hello,I prepared lists of packages which currently depends on "python (<< 2.6)".
http://lintian.debian.org/~jwilk/python2.6/conflictors-binary.txt http://lintian.debian.org/~jwilk/python2.6/conflictors-binary.ddlist http://lintian.debian.org/~jwilk/python2.6/conflictors-source.txt http://lintian.debian.org/~jwilk/python2.6/conflictors-source.ddlistThe lists are regenerated daily. "ALL" is a shortcut for all release architectures; "all" denotes an architecture-independent packages. Only release architectures are considered here.
These packages will prevent new python-defaults from migrating into testing, and as such all will have be fixed: either by a binNMU, or by a sourceful upload, or by kicking out of testing.
How to help ===========0. If your package currently FTBFS (on at least one architecture), go and fix it *now*!
1. If your package is architecture-independent:- It's possible that a simple no-change rebuild will loosen dependencies. If that's the case and you are lazy, rebuild your package and upload it. - Investigate why python-central/-support generate "python (<< 2.X)" dependencies and, if possible, fix your package.
2. If your package is architecture-dependent:- It's possible that your package builds modules for all supported Python versions but we somehow missed that fact and it hasn't been binNMUed so far. Please notify us or the release team if that's the case. - We've seen packages which builds extensions for all supported Python versions but then fail to install those for >= 2.6 into binary packages. If that's the case, fix your package *now*. - Many packages build Python extensions only for the current Python version. That's suboptimal but we can live with it. If your are lazy, your package will be just binNMUed at some point. Otherwise, please fix it to build extensions for all supported Python versions.
-- Jakub Wilk
Attachment:
signature.asc
Description: Digital signature