Re: python-gevent, python-greenlet, debug packages, hurd, and testing.
On Mon, Jul 23, 2018 at 2:35 AM peter green 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-green...@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
Re: [mm-deb] Bug#242740: Help needed on obscure mailman bug
Hi, Seems the user's last feedback on list_lists output was sent only to me, but not to the BTS. I think it's provide vital information, so I Cc it. On Tue, Apr 20, 2004 at 02:56:21PM +0200, Siggy Brentrup <[EMAIL PROTECTED]> wrote: > The bug submission (more exactly a followup) contains the following > unreproducible traceback: [...snip...] > File "/usr/lib/python2.3/email/Charset.py", line 13, in ? > lower_map = string.maketrans(string.ascii_uppercase, > string.ascii_lowercase) > AttributeError: 'module' object has no attribute 'ascii_uppercase' > > which smells like a broken python installation to me. When asked for > running and reporting results > > snip > python < import string > print string > print string.ascii_uppercase > import email.Charset > print email.Charset > EOF > snip > > It should read: > snip > > ABCDEFGHIJKLMNOPQRSTUVWXYZ > > snip > > the answer was: > > > It does. No Problem at all... But the mailman still does not > > run... :-( When I have asked for list_lists's output (this would list the Mailman lists from shell), I got this feedback: | Traceback (most recent call last): | File "./list_lists", line 47, in ? | from Mailman import MailList | File "/var/lib/mailman/Mailman/MailList.py", line 39, in ? | import email.Iterators | File "/usr/lib/python2.3/email/Iterators.py", line 10, in ? | from email._compat22 import body_line_iterator, | typed_subpart_iterator | File "/usr/lib/python2.3/email/_compat22.py", line 7, in ? | from __future__ import generators | ImportError: cannot import name generators | | i have removed/installed python2.2 and python2.3 incl. dependencies | and so | on.. All I could came up was these: - a similar problem and solution was archived at http://mail.python.org/pipermail/python-list/2002-June/111047.html Which said that $PYTHONPATH was incorrect. - a mailman installation fails with the same error online at http://lists.hanfmuseum.de/mailman/listinfo Judging from the dump of the environment variables dump, it's about the same problem: $PYTHONPATH is set to /var/lib/mailman . Is that made by Mailman, user or any other thing, I do not know; neither if the user's problem shares the same root. Cheers, Laszlo signature.asc Description: Digital signature
Re: Package adoptions
On Mon, 2013-02-18 at 19:34 +, Javi Merino wrote: > On Mon, Feb 18, 2013 at 05:24:34AM +0800, Thomas Goirand wrote: > > On 02/18/2013 04:43 AM, Vincent Bernat wrote: > > > I am currently too short on time to do anything but I have high interest > > > in both setproctitle and gevent and therefore if nobody steps in, I will > > > maintain them under the DPMPT. I could also take python-greenlet since > > > it seems in good shape. > > I may help as well with python-greenlet if needed. It's a dependency for > > ceilometer, cinder, heat, keystone and nova... > > Please note that python-greenlet is currently maintained by Laszlo > Boszormenyi[0] (cced) so if you guys are interested in it, you should > contact him. Sorry, I was away for some days. I'm a DD and as Javi notes, I maintain python-greenlet. I was taking steps to get over on the other, mentioned packages as well. I've half-ready/odobted packages and would like to maintain them. Regards, Laszlo/GCS signature.asc Description: This is a digitally signed message part