Re: Offer to help with packaging

2020-07-04 Thread Emmanuel Arias
Hi,


On Thu, Jul 2, 2020 at 12:48 AM Pablo Mestre  wrote:

> Hi
>
> 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, 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
> Control: block #[newcode] by -1
>
> Something like this?
>

yes go ahead.

I don't see the ITP for python-jsonrpc-server. Do you need some help?

Cheers,
Emmanuel

>
> >
> > 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
>
> Ok
>
> Thanks for all
>
> P.
>
>
>


Re: Request to join Python Modules Team

2020-07-04 Thread Emmanuel Arias
Hi,

You just need to be patient. Some administrator from the team will join you.

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El sáb., 4 de jul. de 2020 a la(s) 04:17, Sao I Kuan
(saoik...@gmail.com) escribió:
>
> On Fri, Apr 10, 2020 at 6:22 PM Sao I Kuan  wrote:
> >
> > On Fri, Apr 10, 2020 at 6:16 PM Sao I Kuan  wrote:
> > >
> > > Hiya o/,
> > >
> > > I would like to join the Python Modules Team.
> > >
> > > I'm a newcomer into Debian from this March, and doing the packaging
> > > which is COVID-19 related, with COVID-19 Biohackathon[0].
> > >
> > > [0] https://lists.debian.org/debian-devel-announce/2020/03/msg00010.html
> > >
> > > Now I'm trying to packaging the new python application idseq-bench[1]
> > > (which will be team-maintained inside debian-med), which needs a
> > > module smart_open[2]. I think [2] could be team maintained inside
> > > DPMT.
> > >
> > > [1] https://github.com/chanzuckerberg/idseq-bench
> > > [2] https://github.com/RaRe-Technologies/smart_open
> > >
> > > I read the Debian Python Policy[3].
> > >
> > > [3] https://www.debian.org/doc/packaging-manuals/python-policy/
> >
> > I now found and accept the DPMT Policy[4]. My Salsa handle is @sikuan-guest.
> >
> > [4] 
> > https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst
>
> Ping o/ Or am I missing any necessary information?
>
> My Salsa handle was changed to @sikuan.
> Thank you!
>
> Sincerely,
>
> Sao I Kuan
> saoik...@gmail.com
>



Re: Offer to help with packaging

2020-07-04 Thread 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: Request to join Python Modules Team

2020-07-04 Thread Sao I Kuan
On Fri, Apr 10, 2020 at 6:22 PM Sao I Kuan  wrote:
>
> On Fri, Apr 10, 2020 at 6:16 PM Sao I Kuan  wrote:
> >
> > Hiya o/,
> >
> > I would like to join the Python Modules Team.
> >
> > I'm a newcomer into Debian from this March, and doing the packaging
> > which is COVID-19 related, with COVID-19 Biohackathon[0].
> >
> > [0] https://lists.debian.org/debian-devel-announce/2020/03/msg00010.html
> >
> > Now I'm trying to packaging the new python application idseq-bench[1]
> > (which will be team-maintained inside debian-med), which needs a
> > module smart_open[2]. I think [2] could be team maintained inside
> > DPMT.
> >
> > [1] https://github.com/chanzuckerberg/idseq-bench
> > [2] https://github.com/RaRe-Technologies/smart_open
> >
> > I read the Debian Python Policy[3].
> >
> > [3] https://www.debian.org/doc/packaging-manuals/python-policy/
>
> I now found and accept the DPMT Policy[4]. My Salsa handle is @sikuan-guest.
>
> [4] 
> https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst

Ping o/ Or am I missing any necessary information?

My Salsa handle was changed to @sikuan.
Thank you!

Sincerely,

Sao I Kuan
saoik...@gmail.com



Re: [Python-apps-team] Bug#937009: mercurial: Python2 removal in sid/bullseye

2020-07-04 Thread Sandro Tosi
> > > Do you need any help in coordinating with the packaged extensions,
> > > testing changes, preparing patches? a lot of time has passed since we
> > > started asking about mercurial and python3 and it is becoming the only
> > > reverse-dependency of several packages that could be removed if
> > > mercurial switched to py3k.
> > >
> > Getting an uptodate list of extensions and their status wrt porting both
> > upstream and in Debian would be useful.  I've spent some time looking at
> > hgsubversion a few weeks ago but there's a ton of work and I don't
> > actually use it so I've kind of given up on that; I forget what the
> > status is on others.
>
> will look into the rdeps of mercurial once 5.4.1-1+exp1 hits the archive

I've rebuilt all rdeps of mercurial against the python3 version
uploaded to unstable; results are:

2020/07/05 00:28:22 Build results:
2020/07/05 00:28:22 PASSED: salt
2020/07/05 00:28:22 PASSED: golang-github-masterminds-vcs-dev
2020/07/05 00:28:22 PASSED: pepper
2020/07/05 00:28:22 PASSED: python-hglib
2020/07/05 00:28:22 PASSED: git-remote-hg
2020/07/05 00:28:22 PASSED: haskell-filestore
2020/07/05 00:28:22 PASSED: composer
2020/07/05 00:28:22 PASSED: yotta
2020/07/05 00:28:22 PASSED: ros-rosinstall
2020/07/05 00:28:22 PASSED: check-manifest
2020/07/05 00:28:22 PASSED: jags
2020/07/05 00:28:22 PASSED: setuptools-scm
2020/07/05 00:28:22 PASSED: reposurgeon
2020/07/05 00:28:22 PASSED: devpi-common
2020/07/05 00:28:22 PASSED: firmware-microbit-micropython
2020/07/05 00:28:22 PASSED: python-hgapi
2020/07/05 00:28:22 PASSED: hgsubversion
2020/07/05 00:28:22 PASSED: ros-wstool
2020/07/05 00:28:22 PASSED: ros-vcstools
2020/07/05 00:28:22 FAILED: hg-git (see buildlogs/hg-git_0.8.12-1.2)
2020/07/05 00:28:22 FAILED: meson (see buildlogs/meson_0.54.3-1)

(build logs and artifacts are at
https://people.debian.org/~morph/mercurial_python3/ )

hg-git is RC and not in testing since mid-December, and meson is i
think a real error, since without mercurial depending on python2 now
the build fails to find that executable

Tbh, i think it's time to just rip the bandaid and upload mercurial
python3 to unstable, and deal with the consequences there (i volunteer
to do so); you mentioned hgsubversion as a potential blocker: that
package are popcon on 56, i dont believe such a minor package should
hold progress with the py2removal effort (I've added debian-python@ to
gather their input on this).

I do understand the rebuild results are not conclusive on the python3
migration (after all hgsubversion rebuilds fine with py3k mercurial,
which also raises the questions of why it b-d on it since it clearly
doesnt use it, but i'm digressing), but i think it's better to just go
ahead and upload the experimental version to unstable and see what's
the impact there

What do people think about this?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



py2removal - make all leaf applications RC

2020-07-04 Thread Sandro Tosi
Hello,
Currently only leaf applications (ie something that doesnt start with
`python-`) with popcon <= 1000 get their py2removal bug bumped to RC.

I propose to raise the severity of all leaf applications in 3 days, if
i dont hear any objections.

The current list of applications, and their popcon, impacted by this is:

gnumeric-plugins-extra, popcon = 1072
xchat, popcon = 1437
getmail, popcon = 1285
libapache2-mod-python, popcon = 3626
mysql-workbench, popcon = 1355

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi