Re: Future of Trac in Debian
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
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 be nice to have newer versions (based on Python 2) as backports or sloppy backports for buster, but that will not be possible anymore, as soon as Trac is removed from unstable, right? Btw. Trac development is still active (1.4 released three months ago, but slow, maybe because of lack of developers: "Trac 1.4 is the first major release of Trac in almost 3 years." Trac 1.6 will probably use Python 3. But when? Nobody knows. Cheers
Re: Future of Trac in Debian
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 a state it can be tested, let > alone released. > > What should we do in the meantime? bin:trac has 30 reverse > dependencies (its plugins/addons) and all of them collectively are > likely forceing several other python2 packages to stay in Debian > because they depend on them. > > 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? At that upstream issue gwync writes that he might have to drop Trac in Fedora if there isn't a py3 test release "before Fedora 32 is GA". I'm not sure what "GA" means, but given their release schedule here: https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html and it looks like they'll be dropping py2 on 2020-01-01, and thus Trac. IMHO one of the Debian Trac uploaders should post to the #12130 Trac ticket informing them of our plan. Is there a concrete plan yet? eg: We intend to remove Python 2 from Debian by 31 January, and because we are a conservative and slow moving distribution we are slowly working are way through thousands of application dependency chains to remove applications that do not support Python 3, rather than breaking everything at once by simply removing the interpreter on New Year's Day. If we were not removing packages now we could not meet this objective. . We would like to continue distribute Software-X in Debian, so is there a Python 3 port we can package that is ready for testing today? -- Which is to say, I think the question of "remove now" is contingent on that question. If there is zero hope of a py3 port in a testable state by py2 EOL, then it's ok to drop now, but we need to do more to maintain good relationships with upstreams. Best, Nicholas signature.asc Description: PGP signature
Future of Trac in Debian
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 released. What should we do in the meantime? bin:trac has 30 reverse dependencies (its plugins/addons) and all of them collectively are likely forceing several other python2 packages to stay in Debian because they depend on them. 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? thanks, sandro
Re: Bug#945775: python-sponge: should this package be removed.
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 noone disagrees I will likely convert this bug to a > removal request in the not too distant future. Sure, let's do this already! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
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 just uploaded with python3-pubsub to new. (To bad that this will need another iteration for a source-only upload :-() Kind regards Andreas. -- http://fam-tille.de
Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
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, but I've also seen people asserting that the
> Debian package name ought to reflect the egg name in cases where it
> differs from the top-level Python module name.
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.
(I tried to open a wishlist bug in python3-defaults, but the BTS hasn't
responded so far.)
On Fri, 29 Nov 2019 at 08:29:34 +, Simon McVittie wrote:
> On Fri, 29 Nov 2019 at 08:30:16 +0800, Yao Wei (魏銘廷) wrote:
> > 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 for
> module_name.lower().replace('_', '-'), although maybe it would be better
> for this to be explicit in the policy.
Documenting this is also part of
https://salsa.debian.org/cpython-team/python3-defaults/merge_requests/2
> autopkgtest-pkg-python would ideally transform - back to _ to decide
> what to import, which would fix the more_itertools case?
In fact it already does.
https://salsa.debian.org/ci-team/autodep8/merge_requests/17 adds test
coverage.
> It would need
> an override mechanism for the Xlib case anyway
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884181 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929957 are requests
for such a mechanism.
https://salsa.debian.org/ci-team/autodep8/merge_requests/6 and
https://salsa.debian.org/ci-team/autodep8/merge_requests/17 are two
proposals for implementations of this.
smcv
Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
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 for
module_name.lower().replace('_', '-'), although maybe it would be better
for this to be explicit in the policy. For example, the modules with
which you can 'import Xlib' and 'import more_itertools' are packaged as
python3-xlib and python3-more-itertools.
autopkgtest-pkg-python would ideally transform - back to _ to decide
what to import, which would fix the more_itertools case? It would need
an override mechanism for the Xlib case anyway, because lower() isn't
a reversible transformation.
smcv
