Re: Future of Trac in Debian

2019-11-29 Thread Martin
On 2019-11-29 18:13, Nicholas D Steeves wrote: > IMHO one of the Debian Trac uploaders should post to the #12130 Trac > ticket informing them of our plan. I linked to the email of 2019-10-14: https://trac.edgewall.org/ticket/12130#comment:63

Re: Future of Trac in Debian

2019-11-29 Thread Martin
On 2019-11-29 16:24, Sandro Tosi wrote: > I know it may sound hard, but is it now time to remove trac from > Debian, and ideally re-introduce it back when it's being ported to > py3k? See also: https://groups.google.com/forum/#!topic/trac-users/5VMI83sbqFs What would be the alternative? It would

Re: Future of Trac in Debian

2019-11-29 Thread Nicholas D Steeves
Hi, Sandro Tosi writes: > Hello everyone, > i'd like to discuss the future of Trac in Debian. as we all know, Trac > is still python2, and while there are plans to port it to python3 > (https://trac.edgewall.org/ticket/12130) that port is not there yet, > and it may take quite some time to reach

Future of Trac in Debian

2019-11-29 Thread Sandro Tosi
Hello everyone, i'd like to discuss the future of Trac in Debian. as we all know, Trac is still python2, and while there are plans to port it to python3 (https://trac.edgewall.org/ticket/12130) that port is not there yet, and it may take quite some time to reach a state it can be tested, let alone

Re: Bug#945775: python-sponge: should this package be removed.

2019-11-29 Thread Mattia Rizzolo
Control: reassign -1 ftp.debian.org Control: severity -1 normal Control: retitle -1 RM: python-sponge -- RoQA; RC buggy, unmaintained, low popcon On Thu, Nov 28, 2019 at 01:33:25PM +, peter green wrote: > To me this adds up to a package that is not in a fit state to remain > in Debian, if no

Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

2019-11-29 Thread Andreas Tille
On Fri, Nov 29, 2019 at 10:42:45AM +, Simon McVittie wrote: > > I've opened > https://salsa.debian.org/cpython-team/python3-defaults/merge_requests/2 > to clarify this. Comments welcome, particularly if you don't think my > proposed change reflects consensus. Thanks. This is more clear. I j

Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

2019-11-29 Thread Simon McVittie
On Thu, 28 Nov 2019 at 17:27:53 +, Simon McVittie wrote: > On Thu, 28 Nov 2019 at 11:15:31 -0500, Sandro Tosi wrote: > > if you install `pubsub` as top-level module, your package must be > > named pythonN-pubsub, if not it violates the policy and it's RC buggy. > > That's what I had thought, b

Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

2019-11-29 Thread Simon McVittie
On Fri, 29 Nov 2019 at 08:30:16 +0800, Yao Wei (魏銘廷) wrote: > The binary package for module foo should preferably be named > python3-foo, if the module name allows > > If the module name has upper case in it, it would actually break Policy §5.6.1 I'd assumed the "foo" here was shorthand f