Re: Request to join Python Modules Team
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: Request to join Python Modules Team
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
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: Offer to help with packaging
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: [Python-apps-team] Bug#937009: mercurial: Python2 removal in sid/bullseye
> > > 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
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