python-gevent, python-greenlet, debug packages, hurd, and testing.

[peter green <plugwash@p10link.net>]

(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-greenlet@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.