Re: Request to join DPMT team
On Sun, Jul 5, 2015 at 3:56 PM, Piotr Ożarowski pi...@debian.org wrote: Hi, [Corey Bryant, 2015-07-02] For example I currently have some updates to python-cliff that I'd like to push. could you point us to these patches? I just submitted a patch via Debian bug 791586. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150705195626.gi9...@sar0.p1otr.com -- Regards, Corey
DPMT: server-side git hooks
hi all, while toying around with managing a few python packages in git, i noticed that the post-receive hook installed by the setup-repository script is not working as advertised. for one thing, it complains that dam.homelinux.net:9418 is unreachable (and indeed that name cannot be resolved via DNS). this is one of the KGB bot servers, configured for all repositories in /git/python-modules/kgb-client.conf. according to Gregor Herrmann of the KGB team¹, that host has changed quite some time ago, with the new name being kgb.ktnx.org, as documented on https://kgb.alioth.debian.org/alioth.html. maybe some of the admins can update the kgb-configuration. another problem is a spurious complaint about Invalid revision range 00..commitish. i haven't been able to track that down yet, but will report back if i find something. fgmar IOhannes ¹ here's transcript of my conversation with gregor: 21:56 umlaeute gregoa: the python-modules team uses dam.homelinux.net:9418 as one of the KGB-servers, which is non-responding 21:56 umlaeute actually it doesn't resolve 21:56 umlaeute i've been told that you might be in the know 21:57 umlaeute or should that server not be used at all? 21:58 gregoa umlaeute: the servername changed quite some time ago. the current one(s) are here: https://kgb.alioth.debian.org/alioth.html 21:58 gregoa umlaeute: dam.homelinux.net - kgb.ktnx.org 22:03 umlaeute gregoa: thx 22:04 gregoa np signature.asc Description: OpenPGP digital signature
Re: DPMT: server-side git hooks
On Mon, Jul 6, 2015 at 4:19 PM, IOhannes m zmölnig (Debian/GNU) umlae...@debian.org wrote: hi all, while toying around with managing a few python packages in git, i noticed that the post-receive hook installed by the setup-repository script is not working as advertised. for one thing, it complains that dam.homelinux.net:9418 is unreachable (and indeed that name cannot be resolved via DNS). this is one of the KGB bot servers, configured for all repositories in /git/python-modules/kgb-client.conf. according to Gregor Herrmann of the KGB team¹, that host has changed quite some time ago, with the new name being kgb.ktnx.org, as documented on https://kgb.alioth.debian.org/alioth.html. maybe some of the admins can update the kgb-configuration. done another problem is a spurious complaint about Invalid revision range 00..commitish. i haven't been able to track that down yet, but will report back if i find something. this is probably the first push you made, and it says it cant compare to a previous version (0) simply because there is none. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cab4xwxyhgbg29hq1tme7xd7knbvtzmbe-njehesscrr73gf...@mail.gmail.com
Re: Removing some python3-* packages
On July 2, 2015 3:55:30 PM EDT, Barry Warsaw ba...@debian.org wrote: As part of the 3.5 test rebuild I noticed an incompatibility with python3-enum, which I reported upstream. The response was: there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. Since that's all we have now, maybe it makes more sense to just remove the python3-enum package from Debian. There may be similar packages which are fairly straight backports of Python 3 packages. For those that are no longer necessary, what do you think about removing the python3-* version of the binary package? It seems like a bit of a regression given that we want Python 3 versions of our libraries, but in cases like this it probably makes sense. Thoughts? -Barry I think dropping these duplicates is the only thing that makes sense. For reference, I dropped python3-ipaddr once python3.2 was gone (because 3.3 has ipaddress, which does the same thing). Scott K