(sorry if this is long winded, but I feel the need to explain the situation
so-far, the important bit of this mail is the last few paragraphs)
python-gevent cannot currently be built in testing because it has a build-dependency on
python-greenlet (>= 0.4.13) but testing only has 0.4.12-2. This is technically a RC bug
(violates "Packages must be buildable within the same release." but AIUI in such
cases it is generally considered more productive to investigate why there is a delta between
testing and unstable than file a bug against the victim of the delta.
After digging into the britney update output it seems that the new
python-gevent is not migrating to testing because the python-greenlet no longer
builds -dbg packages but the old -dbg packages are still in unstable.
trying: python-greenlet
skipped: python-greenlet (3538, 0, 13)
got: 29+0: a-4:i-24:a-0:a-0:a-0:m-0:m-0:m-0:p-0:s-1
* amd64: python-greenlet-dbg, python3-greenlet-dbg
The old debug packages are still in unstable because python-gevent failed to
build on hurd (and for some reason hurd is still on ftp-master).
* source package python-greenlet version 0.4.13-2 no longer builds
binary package(s): python-greenlet-dbg python3-greenlet-dbg
on
amd64,arm64,armel,armhf,hurd-i386,i386,kfreebsd-amd64,kfreebsd-i386,mips,mips64el,mipsel,ppc64el,s390x
- suggested command:
dak rm -m "[auto-cruft] NBS (no longer built by python-greenlet)" -s
unstable -a
amd64,arm64,armel,armhf,hurd-i386,i386,kfreebsd-amd64,kfreebsd-i386,mips,mips64el,mipsel,ppc64el,s390x
-p -R -b python-greenlet-dbg python3-greenlet-dbg
- broken Depends:
python-gevent: python-gevent-dbg [hurd-i386]
python3-gevent-dbg [hurd-i386]
Following the general principle that issues affecting release architectures in testing
(python-gevent being unbuildable in testing) are more important than issues that only
affect non-release architectures in unstable (some uninstallable -dbg packages on hurd) I
filed a removal request asking for the old -dbg packages to be removed so that
python-greenlet could migrate to testing. I cc'd the removal request to the
"python-green...@packages.debian.org" maintainer alias in case the maintainer
had any concerns.
A couple of hours after I filed the removal request Laszlo uploaded a new
version of python-gevent which fixed the hurd FTBFS. I have no idea if these
two events were related.
Anyway Scott Kitterman (a ftp assistant) replied to my removal request with the
following.
It appears these are not being removed automatically because they are
depended on by out of date binaries on hurd. Can you clean them up
manually?
This is certainly possible, but is deleting the -dbg packages really the best
solution?
For python debug packages to work, they need to run with the debug version of
the python
interpreter, which -dbgsym packages make no provision for.
Generally, for python packages, it's desirable to keep the traditional -dbg
packages.
I am far from a python expert, I am just a random dd pushing on an issue that I
noticed as
a result of running a downstream distribution.
So I am passing Scott's comment on to the package maintainer and to Debian's
python
experts so that hopefully a descision can be taken to either tell the
ftpmasters to
go ahead with the removal of the old dbg packages or to reintroduce the -dbg
packages
to the python-gevent and python-greenlet source packages.
More generally I find it surprising that given that python apparently has
special
requirements regarding dbg packages this does not seem to be addressed in the
python
policy.
