Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #10722 > unrolled thread

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

Back to article view | Back to linux.debian.maint.python

Contents

  python-gevent, python-greenlet, debug packages, hurd, and testing. peter green <plugwash@p10link.net> - 2018-07-23 02:30 +0200
    Re: python-gevent, python-greenlet, debug packages, hurd, and testing. László Böszörményi (GCS) <gcs@debian.org> - 2018-07-24 06:40 +0200

#10722 — python-gevent, python-greenlet, debug packages, hurd, and testing.

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

[toc] | [next] | [standalone]

#10723

On Mon, Jul 23, 2018 at 2:35 AM peter green <plugwash@p10link.net> wrote:
> 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.
[...]
> 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.
 I plan to add back -dbg packages to python-greenlet.

> 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.
 He is right, I shouldn't remove the -dbg packages from a Python package.

> > 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.
 I didn't receive a reply from others, but I plan to re-add the -dbg
packages for reasons mentioned above.

> 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.
 It would be nice to add this to the Python policy.

Regards,
Laszlo/GCS

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web