Re: Merging the PAPT and the DMPT

[Nicholas D Steeves]

Ondrej Novy  writes:

> Hi,
>
> po 21. 9. 2020 v 13:04 odesílatel Ondrej Novy  napsal:
>
>> Todo:
>>
>>- send debian-devel-announce (i will)
>>- mass-commit vcs+maintainer change
>>
>>
> done.
>
> Thanks to all who helped me with these.
>

Yes, thank you!  And I'm sure maintainers with lots of packages are even
more appreciative than myself :-)

Best,
Nicholas


signature.asc
Description: PGP signature

Re: Merging the PAPT and the DMPT

[Nicholas D Steeves]

Hi,

Dmitry Shachnev  writes:

> Hi Ondrej!
>
> On Mon, Sep 14, 2020 at 09:59:00AM +0200, Ondrej Novy wrote:
>> Hi,
>>
>> I prepared scripts for:
>>
>>- cloning ACLs from modules+applications subgroups to newly created
>>packages subgroup
>>- transferring all project from modules+applications to packages subgroup
>>- tested on one project:
>>https://salsa.debian.org/python-team/packages/alembic
>>
>> It looks like old web URLs works just fine:
>> https://salsa.debian.org/python-team/modules/alembic
>
> I think it's better to update Vcs fields in all packages to point to the
> new location, not one that redirects.
>
> Probably also update Maintainer/Uploader fields with the new team name/email.
>

Are there plans to do this team-wide (for team email in Maintainer) in
one fell swoop, or will this be a per-maintainer task?

Thanks,
Nicholas


signature.asc
Description: PGP signature

Re: Joining PAPT

[Nicholas D Steeves]

Hi Taowa,

Taowa Munene-Tardif  writes:

> Hello,
>
> I am taking over membernator, currently maintained by pollo. To this
> end, I'd like to be granted access to the team to allow me to
> effectively do so. I am taowa on Salsa.
>
> I have read and agree to the Python Applications Packaging Team
> Policy [1],
>

Sorry for the belated reply.  Just wanted to send to a note to say it's
cool to hear you're working on packages now, and also this: Welcome to
the team!

Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Bug#962574: ITP: dephell -- project management for Python

[Nicholas D Steeves]

Hi Scott, devel, and Python team,

Nicholas D Steeves  writes:

> Control: block -1 by 962574
>
> Tomlkit seems to be required for self-tests.
>

Thank you for taking care of tomlkit so quickly!  I wish I had more time
and energy to make faster progress with DepHell.  Today I discovered it
appears to require packaging 14 dephell-.* modules, listed here:

  https://pypi.org/search/?q=dephell

so it's going to be a while (months) before I complete this ITP (which
blocks my solution for converting pyproject.toml to setup.py for fissix
and thus Bowler).  If anyone would like to help out with the dephell-.*
dependencies to speed this process along, please go ahead, and let me
know if you'd like a comaintainer/second Uploader.  Failing that, I'll
get to it as soon as I can :-)

Best,
Nicholas


signature.asc
Description: PGP signature

Re: Offer to help with packaging

[Nicholas D Steeves]

Hi Pablo,

Pablo Mestre  writes:

> El 7/1/20 a las 10:58 PM, Nicholas D Steeves escribió:
>> Awesome, thank you :-) I expect it will be a popular package too! 
> [.]
>> If you're committed to packaging python lsp, then set yourself as the
>> owner of #96360[5], and retitle it, replacing "RFP" with "ITP".
> Yes, I committed to packaging
>> If the absence of a python-jsonrpc-server package is a blocker for
>> #963605, and you want to work on it, then file an ITP for
>> python-jsonrpc-server, set yourself as owner, and also set up a blocks
>> relationship between the two bugs.
>
> You mean
>
> Control: block 946035 by -1

This blocks the spyder bug with the new bug, and is generally used
from the email that creates a new bug.  Hint: #963605 contains an example


Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Offer to help with packaging

[Nicholas D Steeves]

Hi Pablo,

Pablo Mestre  writes:

> Im working on python-language-server

Awesome, thank you :-)  I expect it will be a popular package too!

> but looks like also depends on python-jsonrpc-server and I dont find
> any solution on Debian repositories.
>
> Any suggestion?
>

If you're committed to packaging python lsp, then set yourself as the
owner of #96360, and retitle it, replacing "RFP" with "ITP".

If the absence of a python-jsonrpc-server package is a blocker for
#963605, and you want to work on it, then file an ITP for
python-jsonrpc-server, set yourself as owner, and also set up a blocks
relationship between the two bugs.

Tools for doing this more conveniently are "bts" from devscripts, and
"reportbug" for filing the ITP.  IIRC bts requires an MTA (mail
transport agent) and for this I'd recommend msmtp-mta, because most
people find it easier to configure authentication with it than with
Postfix, Exim, etc.

If you'd like to do it manually for now, see:
  https://www.debian.org/Bugs/server-control

If you use cont...@bugs.debian.org, please CC the bug's email.

It's also possible to reply to a bug with this magic control server
header:

  Control: command -1 arguments

"-1" is a convenient alias for the bug number.  For more info, see the
man bts(1), the server-control documentation, and Developer's Reference:

  https://www.debian.org/doc/manuals/developers-reference/


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#962574: ITP: dephell -- project management for Python

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 

Package name: dephell
Version : 0.8.3
Upstream Author : Gram 
URL : http://www.example.org/
License : MIT (declared, but probably Expat)
Programming Lang: Python
Description : project management for Python

 DepHell Project management for Python
   * Format agnostic: supports setup.py, requirements.txt, Pipfile, poetry.
 DepHell converts between them at any time.
   * All-in-one-solution: manage dependencies, virtual environments, tests,
 CLI tools, packages; generate configs; show licenses for dependencies;
 assist with security audits; get download statistics from PyPI; search
 packages, and much more.
   * Smart dependency resolution: manages dependencies, resolves, and enables
 locking of dependencies that pip missed.
   * Asyncio based: optimised network and filesystem requests.
   * Multiple environments: facilitates the use of multiple environments per
 project.
   * Release tools: provides build, test, version upgrade, and upload helpers.

When I imported the latest version of Fissix, I discovered that it had
migrated to pyproject.toml.  I asked #debian-python about what the
status of Debian tooling is for this format, and had a good discussion
with ScottK.  My immediate motivation for packaging DepHell is to
convert Fissix's pyproject.toml to setup.py to expedite the completion
of its ITP.  I also wonder if it might be useful within a dh_python
context.

It's highly likely this software will be useful to the general Python
developer community, and I plan to maintain it in either the DPMT or
PAPT, as appropriate.  Please comment on this!

If anyone on the DPMT or PAPT would like to comaintain this package,
please let me know, and I'll add you to Uploaders without delay.

I will require a sponsor for the initial upload.

Regards,
Nicholas

Re: PEP-517/PEP-518 Support In Debian

[Nicholas D Steeves]

Hi Scott,

Thank you for the quick reply!

Scott Kitterman  writes:

> On Thursday, June 4, 2020 7:39:59 PM EDT Nicholas D Steeves wrote:
>> Scott Kitterman  writes:
>> > On Monday, April 13, 2020 5:18:53 AM EDT Dmitry Shachnev wrote:
>> >> Hi Scott!
>> >> 
>> >> On Sun, Apr 12, 2020 at 06:31:57PM -0400, Scott Kitterman wrote:
>> >> > This being roughly the mid-point in the development cycle, I thought it
>> >> > might be good to see where we are in terms of future Python packaging
>> >> > developments.
>> >> > 
>> >> > As I understand it, PEP-517 and PEP-518 are 'the future'.
>> 
>> While importing the latest release of Fissix (a grammar parser used by
>> Bowler) I found that it had a pyproject.toml but no setup.py.
>> 
>> >> > I took a look at the presence of pyproject.toml files in the Debian
>> >> > archive. There are currently 99 packages.  Of those, only 28 specify a
>> >> > 'build-backend', which is required by 517/518 to be useful for building
>> >> > a
>> >> > package.
>> >> > 
>> >> > 25 specify: build-backend = "setuptools.build_meta" (including
>> >> > setuptools)
>> >> > 3 specify: build-backend = "flit_core.buildapi" (including flit)
>> >> 
>> >> pyqt5 and pyqt5webengine specify: build-backend = "sipbuild.api".
>> 
>> Is there existing documentation around if/how build-backend can be used
>> to work around the absence of setup.py?
>> 
>> > So they do.  They didn't show up in my codesearch.d.n results, that makes
>> > me wonder what else I missed.  If anyone has an idea of a better way to
>> > track this, please speak up.
>> > 
>> >> > If build-backend is not specified, the build system has to fall back to
>> >> > setup.py.
>> >> > 
>> >> > I've recently package flit (just arrived in Testing) and written a flit
>> >> > plugin for pybuild that's pending review for merging[1].  I also
>> >> > packaged
>> >> > pep517 for our pip package, so that's available to support future
>> >> > Debian
>> >> > tool development in this area.
>> > 
>> > P1otr merged the flit plugin a little while ago, so it'll be in the next
>> > dh- python upload.
>> 
>> I think this is probably what is needed to unblock work on fissix (and
>> thus Bowler), because its Makefile has:
>> 
>> python -m pip install -r requirements.txt
>> python -m pip install -r requirements-dev.txt
>> python -m flit install --symlink
>> 
>> [snip]
>> 
>> Any advise for existing workarounds would be appreciated.  So far the
>> only idea I've had is writing or generating a setup.py, and then adding
>> it as a quilt patch.
>
> That is probably the best approach for now.
>

Thank you for the ACK :-)

> Ultimately we have two choices:
>
> 1.  Add per-backend capability into pybuild as I have done with flit.  
> Depending on how many of them there are, this may or may not be a reasonable 
> approach.
>
> 2.  Use the pep517 module with pip in our package build system.  I think 
> Fedora has gone this direction.
>
> I prefer #1 because we want to produce a traditional bdist, not wheels, but 
> we'll have to do the work.  I don't think we want an impenetrable morass of 
> zip files in /usr/lib/python3/dist-packages.
>

I also prefer #1.  Here's an idea for reducing the work, and more
importantly reducing the Debian-specific investment in time:

Dephell (from the author of Poetry?) claims to support: egginfo, sdist,
wheel, pip, piplock, pipfile, pipfilelock, poetry, poetrylock, already
installed system-wide packages, plus setup.py, flit, conda, and
pyproject.

More interestingly it claims to be able to convert between formats, eg:

  dephell deps convert --from=pyproject.toml --to=setup.py

Within a Debian packaging context this seems like it would be useful,
because packages whose upstreams change formats could continue to use
their existing rules file with the addition of a 'dephell deps convert'
step.

It seems like it might fit well with DPMT Policy, in that we could
recommend conversion to a particular format, for use with a particular
buildsystem, for uniformity of packaging.  Finally, if that conversion
capability works well then an effect is that Debian packaging is
effectively decoupled from upstream buildsystem changes, and this seems
like a good thing.

Downside: Their installation instructions (curl -L dephell.org/install |
python3) make me wonder if there is a fundamental cultural difference
that would make this a no-go.

tldr: Could integrating Dephell into dh_python solve these challenges
once and for all?


Regards,
Nicholas


signature.asc
Description: PGP signature

Re: PEP-517/PEP-518 Support In Debian

[Nicholas D Steeves]

Hi,

Scott Kitterman  writes:

> On Monday, April 13, 2020 5:18:53 AM EDT Dmitry Shachnev wrote:
>> Hi Scott!
>> 
>> On Sun, Apr 12, 2020 at 06:31:57PM -0400, Scott Kitterman wrote:
>> > This being roughly the mid-point in the development cycle, I thought it
>> > might be good to see where we are in terms of future Python packaging
>> > developments.
>> > 
>> > As I understand it, PEP-517 and PEP-518 are 'the future'.
>> >

While importing the latest release of Fissix (a grammar parser used by
Bowler) I found that it had a pyproject.toml but no setup.py.

>> > I took a look at the presence of pyproject.toml files in the Debian
>> > archive. There are currently 99 packages.  Of those, only 28 specify a
>> > 'build-backend', which is required by 517/518 to be useful for building a
>> > package.
>> > 
>> > 25 specify: build-backend = "setuptools.build_meta" (including setuptools)
>> > 3 specify: build-backend = "flit_core.buildapi" (including flit)
>> 
>> pyqt5 and pyqt5webengine specify: build-backend = "sipbuild.api".
>

Is there existing documentation around if/how build-backend can be used
to work around the absence of setup.py?

> So they do.  They didn't show up in my codesearch.d.n results, that makes me 
> wonder what else I missed.  If anyone has an idea of a better way to track 
> this, please speak up.
>
>> > If build-backend is not specified, the build system has to fall back to
>> > setup.py.
>> > 
>> > I've recently package flit (just arrived in Testing) and written a flit
>> > plugin for pybuild that's pending review for merging[1].  I also packaged
>> > pep517 for our pip package, so that's available to support future Debian
>> > tool development in this area.
>
> P1otr merged the flit plugin a little while ago, so it'll be in the next dh-
> python upload.
>

I think this is probably what is needed to unblock work on fissix (and
thus Bowler), because its Makefile has:

python -m pip install -r requirements.txt
python -m pip install -r requirements-dev.txt
python -m flit install --symlink

[snip]

Any advise for existing workarounds would be appreciated.  So far the
only idea I've had is writing or generating a setup.py, and then adding
it as a quilt patch.

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#960767: RFP: python-pressagio -- Pressagio text prediction system

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Control: block 721192 by -1

Package name: python-pressagio
Version : 0.1.6
Upstream Author : Peter Bouda 
URL : https://github.com/Poio-NLP/pressagio
  https://pressagio.readthedocs.io
License : Apache-2.0
Programming Lang: Python
Description : Pressagio text prediction system

 Pressagio is a library that predicts text based on n-gram models. For
 example, you can send a string and the library will return the most
 likely word completions for the last token in the string.
 .
 Pressagio is a pure Python port of the presage library:
 https://presage.sourceforge.io
 .
 Pressagio is part of the Poio project: https://www.poio.eu
 .
 [very quickly skimming the source suggests that it requires sqlite, and also
  that it could benefit from some enhance-user-friendliness work for the
  initial per-user setup...unless that would fall under the domain of
  applications that use this library]

--

Uberwriter/Apostrophe appears to require this library, and that is the
reason for this RFP (or weak ITP).  I'm willing to do the packaging
work if someone would like to comaintain, and I'd prefer not to be the
only person responsible.  DPMT is an option, but it's better to [also]
have someone who is interested in seeing a specific piece of software
succeed :-)


Regards,
Nicholas

Re: Python Wheel Related Policy Change

[Nicholas D Steeves]

Hi,

Scott Kitterman  writes:

> On Thursday, April 30, 2020 5:49:20 PM EDT Stefano Rivera wrote:
>> Hi Scott (2020.04.30_20:33:59_+)
>> 
>> > > That seems reasonable, although if we're going down that road, it
>> > > probably makes no sense for any of them to be universal.
>> > 
>> > If we were talking about maintaining this for multiple release cycles with
>> > lots of version divergence, I would agree.  Let's not do more than we have
>> > to until python2 is gone (whether it is before bullseye or after).
>> 
>> I suspect pypy (2.7) will probably be around post-bullseye, unless
>> somebody funds pypy to migrate rpython to python 3.
>> 
>> But yeah, we can change strategy later, if appropriate.
>
> Well, we have also talked about pypy vendoring as much of the python2.7 
> package as it needs to build itself so we don't have to support it in the 
> archive as an active interpreter, but that's a different discussion.
>

I think that discussion must have been before I joined the team :-) It's
only recently that I became aware of pypy, and I assumed it had been
discounted because it weakened the argument (and/or was bad for morale)
for the py2 removal initiative we saw in 2019.

I can't remember if it was on reddit or stackoverflow, but apparently
people are considering pypy 2.7 as a solution to their py2 technical
debt.

It makes sense that a vendoring/bootstrapping/dfsg-compliance issue was
the reason the avenue wasn't explored in Debian, and I'm happy to hear
that this was the reason pypy wasn't explored as an alternative--and not
my assumption.

Thanks,
Nicholas


signature.asc
Description: PGP signature

Re: Request to join the PAPT (already a member of DPMT)

[Nicholas D Steeves]

Stefano Rivera  writes:

> Hi Nicholas (2020.01.28_00:03:37_+)
>> I'd like to join the PAPT, since the PAPT is the best place for an RFP
>> that I've chosen to work on.  I am already a member of the DPMT, so have
>> already accepted Team Policy, and of course have accepted remaining in
>> compliance with its changes.
>
> Added, welcome to the other side of the team.
>

Thank you Stefano! :-)

Regards,
Nicholas 


signature.asc
Description: PGP signature

Request to join the PAPT (already a member of DPMT)

[Nicholas D Steeves]

Hi,

I'd like to join the PAPT, since the PAPT is the best place for an RFP
that I've chosen to work on.  I am already a member of the DPMT, so have
already accepted Team Policy, and of course have accepted remaining in
compliance with its changes.

My Salsa login is "sten-guest"

Regards,
Nicholas


signature.asc
Description: PGP signature

Re: dh_python3 sets shebang to Python 2 -- is this a bug?

[Nicholas D Steeves]

Hi,

Andreas Henriksson  writes:

> I've personally seen some upstream use 'python' in shebang with the
> intention of meaning 'works with either python2 or python3',

Yes, this has worked thus far, and it will definitely work in cases where
`which python` is a symlink to python3 within a virtual environment.

>  but in debian it seems people have always assumed unversioned
> (/usr/bin/)python always means python *2*.

I don't think this is an assumption.  Debian adheres to PEP 394, which
until recently said that /usr/bin/python is supposed to be Python 2, for
backwards compatibility.  When I discovered this I felt increased trust
in Debian and its developers for doing the sensible and standardised
thing, rather than what some other distributions have done.  To everyone
involved, thank you!  This also made me proud to be part of such a
community :-)

  https://www.python.org/dev/peps/pep-0394/

I believe that it was on 26-Jun-2019 of this year that PEP 394 was
modified to allow /usr/bin/python to be py3, because py2 EOL frees
up this path.  IMHO that change was premature and should have been
deferred until the actual EOL.

> I guess the tools are written in the latter sense here, rewriting the
> shebang from python -> python2 explicitly unless you override it
>

Yeah, this is a tricky point.  Per PEP 394 (until py2 EOL), this is the
correct approach, but now it may make more sense to change this to
"python -> python3", because if this breaks a package, tough luck, we're
in a python3-only world.  eg: packages in the archive should already
have the shebang override, and NEW py2 packages will be rejected by
ftpmasters.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: python-requests: adding a documentation package python-requests-doc

[Nicholas D Steeves]

Hi Fabrice,

Fabrice BAUZAC-STEHLY  writes:

> Hello Daniele,
>
> Daniele Tricoli writes:
>
>> Please next time can you assign it to me? I should reveive some sort of
>> notification I hope! :)
>
> Sure, will do.
>
> I have updated the merge request.
>
> For d/changelog, I used "debchange -i" which for some reason chose
> "2.22.0-2.1", I've changed it to "2.22.0-3" as it seems to better match
> the existing practice.
>

Debchange/dch chooses upstream_version-x.y (NMU Debian revision) when
one's email address is in neither the Maintainer nor the Uploaders
fields.  Dch --team will do the right thing for the Debian revision;
that said, the "* Team upload" line it generates shouldn't be used if
one of the Uploaders (or Maintainer for weak team attributed package)
will be finalising the changelog and uploading.  'no idea whether or not
that's the case here, btw.

I've filed #947961 against devscripts in the hopes that someone will
enhance dch's behaviour for team-maintained packages.

> Thanks a lot and a happy new year!
>

Thank you, happy New Year to you too! :-D

Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Future of Trac in Debian

[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 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

Bug#944989: ITP: python-fissix -- backport of lib2to3, supporting the latest Python3 grammars, with enhancements

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist

Package name: python-fissix
Version : 19.2b1
Upstream Author : John Reese 
URL : https://github.com/jreese/fissix
License : PSF
Programming Lang: Python
Description : backport of lib2to3, supporting the latest Python3 grammars, 
with enhancements

Fissix is a backport of lib2to3, a CST (concrete syntax tree)
implementation, that supports various features and grammars that are
more up-to-date than the latest upstream CPython version.  It is the
parser that Bowler uses to make safe, large scale code modifications
and smart refactoring.  It supports source written in both Python 2
and 3.

As noted Fissix is a dependency of Bowler, and I am packaging Bowler
because Rope isn't well maintained upstream, because Parso/Jedi do not
yet support refactoring, and because Elpy (the Emacs Python IDE) has
been hoping to move away from Rope for many years now.

I plan to maintain it on the DPMT, I will need a sponsor for the
initial upload, and I would very much appreciate a co-maintainer who
has advanced Python expertise!


Regards,
Nicholas

Re: Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

[Nicholas D Steeves]

Brian May  writes:

> Stéphane Blondon  writes:
>
>> Perhaps there is a doubt how to read it?
>> - do not (remove python-foo-doc or rename it to python3-foo-doc)
>> - (do not remove python-foo-doc) or (rename it to python3-foo-doc)
>>
>> Would it be better if we remove the indentation and use this sentence(?):
>> if documentation is in python-foo-doc, do not move it
>
> Myself, I read it as the first option.
>
> I would personally use:
>
> - Do not remove python-foo-doc and do not rename it to python3-foo-doc.
>
> Or maybe even expand as two bullet points:
>
> - Do not remove python-foo-doc.
> - Do not rename it to python3-foo-doc.
>
> I think this makes it very explicit what was intended.

+1.  I also read it as (do (not (remove python-foo-doc) or (not (rename
to python3-foo-doc.  In natural language that "or" should be a
"nor", but breaking it into two negated bullet points may be clearer to
those whose first language doesn't possess a negative list operator.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream

[Nicholas D Steeves]

Hi Thomas and Python Team,

Thomas Goirand  writes:

> For example, today I looked into removing Python 2 from python-cogent.
> Running sixer on all files lead to a huge log of problems to solve by
> hand. There's no upstream support for Python 3 on that one.
>
> For this kind of package, I see no way out except:
> - Upstream works on Python 3 support
> - Someone in Debian makes the effort
>
> But in both cases, it's going to take a very long time. Do we really
> want to get stuck on these packages for like forever, or would it feel
> ok to raise the severity to serious, so that the package gets
> auto-removed and then we can work on removing Python 2 from its
> dependencies?

It seems to me that a fair and conservative solution is to send an
announcement once a month that all Python 2 packages will have an RC bug
filed against them on 1 January 2020.  I work on the Calibre package,
and depend on it for my daily work.  I do not believe that its reverse
deps should be removed before 1 Jan 2020.

As far as the maximum number of announcements, how about: the first
announcement ASAP, the second one 1 Nov, then 1 Dec.  Lets CC this
announcement to devel, -python, -med, and any other teams with a
significant number of Python packages.

The issue is similar to global warming.  People will hide their head in
the sand singing "nah nah nah, it's not real, I don't have to deal with
it" until a tipping point occurs.

Honestly part of me wonders if RedHat/IBM is going to maintain Python 2,
like they did with Java.

  
https://developers.redhat.com/blog/2018/09/24/the-future-of-java-and-openjdk-updates-without-oracle-support

Barring that hypothetical possibility, I still think the right thing to
do is file RC bugs the 1 of January.  What happens then?  My guess is
upstreams start containerising their py2 software and someone will write
a helper script like py2-zombie-flatpack.


Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: pylint and pylint3

[Nicholas D Steeves]

Hi Fred,

On Tue, Aug 27, 2019 at 07:29:06PM +, PICCA Frederic-Emmanuel wrote:
> Hello it seems that  the pylint package does not provide pylint3 anymore 
> (since 21h ;)
> But the spyder package still require pylint3 and pylint when installint 
> spyder or spyder3.
> this is why the next taurus will FTBFS.
> 
> So is it something expected and the spyder package should be fixed, or a bug 
> in the pylint package ?
> 
> Cheers
> 
> Fred

ScottK and I discussed this type of case on #debian-python.

The Python 3 variant of the package should begin provide the
/usr/bin/foo wrapper script interface when the Python 2 package is
dropped.

This really ought to be codified somewhere, and I'm not sure that the
DPMT wiki page is visible enough or will be consulted by maintainers
when dropping the Python 2 variant of their packages.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#922938: RFS: python-css-parser/1.0.4-1~bpo9+1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal
Justification: necessary for to update the bpo for Calibre

Dear mentors,

I am looking for a sponsor for my package "python-css-parser"

Package name: python-css-parser
Version : 1.0.4-1~bpo9+1
Upstream Author : Christof Hoeke, Walter Doerwald,
  and Kovid Goyal 
URL : https://github.com/ebook-utils/css-parser
License : LGPL-3+
Section : python

It builds these binary packages:

  python-css-parser - CSS related utilities (parsing, serialization, etc) for 
Python 2
  python3-css-parser - CSS related utilities (parsing, serialization, etc) for 
Python 3

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/python-css-parser

Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-css-parser/python-css-parser_1.0.4-1~bpo9+1.dsc


Regards,
Nicholas

Re: Re add my account?

[Nicholas D Steeves]

Hi Andreas,

On Fri, Feb 08, 2019 at 11:52:55AM +0100, Andreas Noteng wrote:
>Hello, I am a DM who have not been active for a few years, but I can still
>se my name in the list of DMs. Now coming back I see that quite a few
>things have changed. Most noteably our packages has moved to GIT it seems.
>Looks like I don't have access to this new host. How would I proceed to
>gain access and update my long neglected packages?
>My alioth username was anoteng-guest
>--
>Andreas Noteng

I'm a *very* recent member to the team, but:

Off the topic of my head, you'll need to check that your unexpired gpg
key is still on the DM keyring, register for a salsa account
(presumably anoteng-guest), read and accept both
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
and also read & accept relevant pages on the wiki such as
https://wiki.debian.org/Python/LibraryStyleGuide#Style_Guide_for_Packaging_Python_Libraries.

Then send an email to this list with your salsa account name, the list
of your team-maintained packages, mention you confirmed your GPG key
is up-to-date on the DM keyring, and say that you read accepted those
articles on team standards.  Oh, that email is to request that
anoteng-guest be added to the salsa team.

P.S. Everyone is super busy right now, so I would anticipate a long
delay for a reply...but maybe not :-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Update of ipython3 to latest upstream

[Nicholas D Steeves]

Hi Christoph,

On Fri, Feb 01, 2019 at 06:49:15PM +0100, Jan Christoph Terasa wrote:
> Hi,
> 
> the soft freeze of buster is approaching fast, will there be a chance to get
> a more recent (latest?) version of upstream ipython3 (https://ipython.org/)
> into buster, or at least into sid? ipython3 is still on v5.8, which is the
> last one supporting python2. I guess this is since currently both versions
> are handled by the same source package, so the adoption of the newest
> upstream version needs a redesign of the way ipython2/3 is currently
> packaged for Debian? v5.8 is more than one year old by now, and there have
> been very useful additions since then. I currently install it via pip3 on my
> work systems, but I'd love to get it through the usual Debian packaging.
> 
> If any help is needed on this issue I might see what I can do about this,
> but I have never packaged anything for Debian, so I have no experience with
> that.
> 

I agree, that would be nice to have!  My suspicion is that it's too
late for this, because a NEW src:python3-ipython might be considered a
large/disruptive change post 12 Jan 2019, but I could be wrong. Here
is the output from apt-cache rdepends python3-ipython on sid:

Reverse Depends:
  ipython3
  python3-caffe-cuda
  python3-yt
  python3-sagenb-export
  python3-skbio
  python3-randomize
  python3-pweave
  python3-line-profiler
  python3-fluids
  python3-pyraf
  python3-pprofile
  python3-nbconvert
  python3-nb2plots
  python3-jupyter-console
  python3-itango
  python3-ipywidgets
  androguard
  python3-ipykernel
  python3-glue
  python3-caffe-cpu

Sorry, I don't have time to make sure the rdeps wouldn't break before
the soft freeze.  Worst case scenario is that the new ipython3 would
be a good candidate for buster-backports.


Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#920775: RFS: python-css-parser/1.0.4-1 [ITP]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal
Justification: new required dep for Calibre

Dear mentors,

I am looking for a sponsor for my package "python-css-parser".  It
will be maintained on the Debian Python Modules Team.  I hope that it
can clear NEW before 12 Feb, because the Christmas Kobo firmware
update requires a newer Calibre, and a newer Calibre requires
python-css-parser.

Package name: python-css-parser
Version : 1.0.4-1
Upstream Author : Kovid Goyal (maintainer of fork), Christof Hoeke (orig)
URL : https://github.com/ebook-utils/css-parser
License : LGPL-3.0 and Apache 2.0
Section : python

It builds these binary packages:

  python-css-parser - CSS related utilities (parsing, serialization, etc) for 
Python 2
  python3-css-parser - CSS related utilities (parsing, serialization, etc) for 
Python 3

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/python-css-parser

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-css-parser/python-css-parser_1.0.4-1.dsc

Alternatively, clone this repository:

  git clone https://salsa.debian.org/python-team/modules/python-css-parser.git


Thank you,
Nicholas

Re: P.S. Requesting to join team and for sponsorship of python-css-parser

[Nicholas D Steeves]

On Mon, Jan 28, 2019 at 10:33:09AM +0100, Ondrej Novy wrote:
>Hi,
>st 16. 1. 2019 v 7:35 odesÃlatel Nicholas D Steeves 
>napsal:
> 
>  > I'd like to finally join the DPMT
> 
>welcome :)

Thank you Ondřej!

Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: P.S. Requesting to join team and for sponsorship of python-css-parser

[Nicholas D Steeves]

On Tue, 15 Jan 2019 at 17:30, Nicholas D Steeves  wrote:
>
> Dear Python team,
>
> I'd like to finally join the DPMT, and am requesting sponsorship of a
> new package.  That package is python-css-parser.
>
> I've been collaborating with Norbert Preining for a year on Calibre,
> and Calibre's most recent release requires css-parser, a fork of
> css-utils.
>
>   g...@salsa.debian.org:sten-guest/python-css-parser.git
>   https://salsa.debian.org/sten-guest/python-css-parser
>
> Please let me know if there's anything I can do to improve it.
>
> Regards,
> Nicholas

P.S. I have read and accepted
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
and have also read relevant pages on the wiki such as 
https://wiki.debian.org/Python/LibraryStyleGuide#Style_Guide_for_Packaging_Python_Libraries

I also maintain elpy, an Emacs IDE for Python, and the package would
benefit from the insights of more experienced Python
developers--particularly with respect to what approach to virtualenvs
should be encouraged on Debian systems.


signature.asc
Description: PGP signature

Requesting to join team and for sponsorship of python-css-parser

[Nicholas D Steeves]

Dear Python team,

I'd like to finally join the DPMT, and am requesting sponsorship of a
new package.  That package is python-css-parser.

I've been collaborating with Norbert Preining for a year on Calibre,
and Calibre's most recent release requires css-parser, a fork of
css-utils.

  g...@salsa.debian.org:sten-guest/python-css-parser.git
  https://salsa.debian.org/sten-guest/python-css-parser

Please let me know if there's anything I can do to improve it.

Regards,
Nicholas


signature.asc
Description: PGP signature

Re: Bug#902629: missing required versioned dependency on python-lxml may cause FTBFS

[Nicholas D Steeves]

On Fri, Jun 29, 2018 at 06:08:52AM +0900, Norbert Preining wrote:
> Hi Nicholas,
> 
> > I've already fixed this in g...@salsa.debian.org:debian/html5-parser.git
> > 
> > If it's possible to fix the FTBR on i386 in sid, then that fix seems
> > like it ought to included into the proposed 0.4.4-2 upload.  Sadly I
> > don't know why it's occurring so can't fix it.
> 
> I am not sure what is the problem on i386, does the current 0.4.4-2 not
> build there?

It builds for i386, but fails to build reproducibly.  It might just be
a transient error.
  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/html5-parser.html
  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/html5-parser.html
  
However it currently FTBFS for arm64 (maybe transient error, or maybe
the cause is elsewhere):
  https://tests.reproducible-builds.org/debian/unstable/arm64/index_FTBFS.html

> Should I upload 0.4.4-2?

Upside: will allow the backport to build.

Downside: https://tracker.debian.org/pkg/html5-parser states "This
package is part of the ongoing testing transition known as
python3.7. Please avoid uploads unrelated to this transition, they
would likely delay it and require supplementary work from the release
managers."

Fixing the FTBFS on arm64 would definitely justify an upload, but I'm
not sure if my additions and updates are sufficient.  CCing the Python
Team to find out.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#872183: RFP: importmagic -- Python library for finding unresolved symbols and managing imports

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist

* Package name: importmagic
  Version : 0.1.7
  Upstream Author : Alec Thomas 
* URL : https://github.com/alecthomas/importmagic
* License : BSD-2-Clause
  Programming Lang: Python
  Description : Python library for finding unresolved symbols and 
corresponding imports

The goal of this package is to be able to automatically manage imports in 
Python. To that end it can:
.
 * Build an index of all known symbols in all packages.
 * Find unresolved references in source, and resolve them against the index, 
effectively automating imports.
 * Automatically arrange imports according to PEP8.
.
It was originally written for the Sublime Text 2 Python Import Magic plugin.

I became aware of importmagic while investigating the dependencies for 
Bug#861174.  I believe it would be a valuable addition to Debian because it 
facilitates migration from Sublime Text to a free software IDE.  Additionally 
it sounds like it would be very convenient for Python programmers!

Unfortunately I am not qualified to maintain it, and hope that someone on the 
Python Modules Team would be willing to care care of importmagic.

Importmagic should have an "Enhances: elpa-elpy" added at some point after 
elpa-elpy is uploaded.  If replying from debian-python@lists.debian.org please 
take care to insure this bug is in the recipients list.

Sincerely,
Nicholas