Re: Joining the Debian Python Team

[Pierre-Elliott Bécue]

Hey,

Alexandru Mihail  wrote on 22/07/2024 at 
21:33:37+0200:

> Hey,
>
> I would like to join the debian-python packaging team.
> I am already the package maintainer for
> https://salsa.debian.org/debian/mini-httpd and have also been
> contributing to the wiki for some years:
> https://wiki.debian.org/AlexandruMihail
>
>
> Why you want to join the team: e.g. maintain your current packages
> within the team, help maintain some specific packages, etc:
>
>
> I intend to package https://github.com/astrofrog/psrecord and possibly
> more useful python related things in the future.
> ITP:https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075810
>
> Your Salsa login:
> https://salsa.debian.org/alexandru_mihail
>
> A statement that you have read
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> and that you accept it. 
>
> I read it, understood it and accepted it.
>
> Thanks and have a great day !

Access granted with Developer level.

Please don't hesitate to reach out if you need some help with anything
regarding setting up your repo.

-- 
PEB


signature.asc
Description: PGP signature

Re: Request to join

[Pierre-Elliott Bécue]

Hi,

Henri  wrote on 16/07/2024 at 16:34:50+0200:

> Hi DPT,
>
> I'm requesting to join the Debian Python Team in order to maintain some
> new packages under the team, such as "wgconfig" [1].
>
> My Salsa username is "towalink".
>
> I have read
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> and accept it.
>
> Thanks,

Developer access granted.

Please poke us if you need a hand to setup something.

Bests,
-- 
PEB


signature.asc
Description: PGP signature

Re: requesting salsa access

[Pierre-Elliott Bécue]

Hi,

Salvo Tomaselli  wrote on 26/06/2024 at 19:07:58+0200:

> In data mercoledì 26 giugno 2024 16:55:19 CEST, Stefano Rivera ha scritto:
>> Hi Salvo (2024.06.17_16:18:02_+)
>> 
>> > Can someone check and give me access? My username is ltworf.
>> 
>> Have you read and agreed to the team policy?
>> 
>> Stefano
>
> yes

Access granted.

-- 
PEB


signature.asc
Description: PGP signature

Re: Request for Python Team assistance in Debian Mentors

[Pierre-Elliott Bécue]

Andrey Rakhmatullin  wrote on 13/06/2024 at 12:48:36+0200:

> On Thu, Jun 13, 2024 at 07:28:32AM +0100, Phil Wyett wrote:
>> Dear Python Team Members,
>> 
>> At present we have a number of Python related packages[1] within Debian
>> Mentors[2]. Would it be possible for team members/DD's to offer their expert
>> assistance to these submitters and their packages with a goal of upload to
>> Debian where appropriate.
>> 
>> Your time and assistance would be greatly appreciated.
>> 
>> [1] Package list, not exhaustive...
>> 
>> https://mentors.debian.net/package/python-keep/
>> https://mentors.debian.net/package/python-autodocsumm/
>> https://mentors.debian.net/package/python-radexreader/
>> https://mentors.debian.net/package/anytree/
>> https://mentors.debian.net/package/browser-cookie3/
> I'm always hesitant to look at Python module RFSes because on one hand I
> would like all of them to be in the team but on the other hand I'm not
> sure if it makes sense to write "please move this to DPT" or "please
> consider moving this to DPT", especially for people who are first time
> packages without a team membership.
> Perhaps we should discuss this and find a single recommended practice for
> such packages.

I really think we should encourage newcomers to apply joining the team
and put their packages there.

What we could do if the idea of giving broad commit rights to newcomers
poses issues is to create a specific namespace in python-team for
newcomers. (then we'd need to have some migration plan and then oh dear)

-- 
PEB

Re: Request for Python Team assistance in Debian Mentors

[Pierre-Elliott Bécue]

Hey,

Phil Wyett  wrote on 13/06/2024 at 08:28:32+0200:

> Dear Python Team Members,
>
> At present we have a number of Python related packages[1] within Debian
> Mentors[2]. Would it be possible for team members/DD's to offer their expert
> assistance to these submitters and their packages with a goal of upload to
> Debian where appropriate.
>
> Your time and assistance would be greatly appreciated.
>
> [1] Package list, not exhaustive...
>
> https://mentors.debian.net/package/python-keep/
> https://mentors.debian.net/package/python-autodocsumm/
> https://mentors.debian.net/package/python-radexreader/
> https://mentors.debian.net/package/anytree/
> https://mentors.debian.net/package/browser-cookie3/
>
> [2] https://mentors.debian.net/packages/

Thanks for poking us.

I can't promise that it will be fast but I'll try to give it some time.

Bests,

-- 
PEB


signature.asc
Description: PGP signature

Re: Request to join the DPT

[Pierre-Elliott Bécue]

Hey,

Simon Chopin  wrote on 30/05/2024 at 16:56:39+0200:

> On jeu. 30 mai 2024 13:57:58, Simon Chopin wrote:
>> Hi folks,
>>
>> Could I please join the DPT Salsa team? My Salsa login is `schopin`.
>>
>> My rationale for joining isn't because of specific packages, but rather
>> that as part of my work in Ubuntu I tend to touch a lot of Python
>> packages, and being a member of the DPT would reduce the friction in
>> submitting those changes back to Debian (my eventual goal being becoming
>> a DD so that friction gets reduced even further).
>
> Forgot to add:
>
> I have read the policy at
> https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst
> and I accept it.

Maintainr access granted. :)
-- 
PEB


signature.asc
Description: PGP signature

Re: Request to join Debian Python Team

[Pierre-Elliott Bécue]

Hi,

Maytham Alsudany  wrote on 15/05/2024 at 11:37:19+0200:

> Hi DPT,
>
> I'm requesting to join the Debian Python Team in order to maintain some
> new packages under the team, such "nwg-clipman"[1], as well as moving
> "nwg-hello"[2] to team maintenance. (I also may look into packaging
> "plots"[3] in the long term.)
>
> My Salsa username is "Maytha8".
>
> I have read
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> and I accept it.
>
> Thanks,

Developer access granted to the group.

Welcome!
-- 
PEB


signature.asc
Description: PGP signature

Re: Request to join the Debian Python Team

[Pierre-Elliott Bécue]

Paul Boddie  wrote on 04/04/2024 at 17:22:35+0200:

> On Wednesday, 3 April 2024 19:03:44 CEST Pierre-Elliott Bécue wrote:
>> Paul Boddie  wrote on 03/04/2024 at 16:21:05+0200:
>> > 
>> > Many thanks for giving me access! Would it make sense to move the existing
>> > project into the Python Team's packages collection on Salsa, or is that
>> > only permitted for packages that are actually adopted by the team?
>> 
>> On the contrary, please do!
>
> It seems that the "transfer project" function would be the most appropriate 
> way of moving the project, but I don't think I am allowed to perform the 
> transfer. In the settings for my project, the pull-down menu only offers 
> transfer to the "moin" group where I have some other projects.
>
> I reviewed the documentation...
>
> https://salsa.debian.org/help/user/project/settings/migrate_projects#transfer-a-project-to-another-namespace
>
> ...and I think that the only obstacle is that I am a developer as opposed to 
> a 
> maintainer. I suppose that I could re-create the project in the group 
> instead, 
> if that is more appropriate.
>
> Thanks in advance for any assistance that can be offered, and sorry to bring 
> up such tedious administrative issues!

I've bumped your access to maintainer, let's try, and I'll downgrade
when you're done.

-- 
PEB


signature.asc
Description: PGP signature

Re: Membership request

[Pierre-Elliott Bécue]

Hi Nicolas,

Nicolas Couture  wrote on 04/04/2024 at 10:32:05+0200:

> Hello Pierre-Elliott,
>
> Thank you for your response.
>
> I believe that a contribution track is a way to contribute to the Python team 
> without being a full member. I am interested in learning
> more about the contribution track and how I can get involved.
>
> Please let me know if there is any additional information or resources that 
> you can provide.
>
> Thank you for your time and consideration.
>
> Best regards,

What I was meaning is that before granting full access, it would be good
to build trust.

To do so, I was offering to create the specific repositories you want to
work on in the group and grant you access on these very repositories.

After some time we could consider expanding your access to the whole
group packages.

Would that be fine?
-- 
PEB


signature.asc
Description: PGP signature

Re: Request to join the Debian Python Team

[Pierre-Elliott Bécue]

Paul Boddie  wrote on 03/04/2024 at 16:21:05+0200:

> On Wednesday, 3 April 2024 15:56:48 CEST Pierre-Elliott Bécue wrote:
>> 
>> I've granted you developer access to the package subgroup. You can
>> create a shedskin project here if you want.
>
> Many thanks for giving me access! Would it make sense to move the existing 
> project into the Python Team's packages collection on Salsa, or is that only 
> permitted for packages that are actually adopted by the team?

On the contrary, please do!

>> If you lack some access, don't hesitate to reach out for help (we are on
>> #debian-python on OFTC IRC network).
>> 
>> Don't hesitate after some time and contributions to ask for maintainer
>> access if you need to create new repos.
>
> One step at a time, I think!
>
> Thanks once again,

You're welcome.
-- 
PEB

Re: Request to join the Debian Python Team

[Pierre-Elliott Bécue]

Hi Paul,

Paul Boddie  wrote on 16/01/2024 at 02:10:14+0200:

> Hello,
>
> I would like to request membership of the Debian Python Team. For a while, I 
> have been working on a package for Shed Skin (shedskin) which is a compiler 
> for a dialect of Python.
>
> I previously maintained a package for this software in the Python 2 era, and 
> since it has been made compatible with Python 3, I feel that it would be 
> beneficial to Debian users to have convenient access to it once again. To 
> this 
> end, I filed an "intent to package" report a while back:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051352
>
> The principal developer of Shed Skin is very encouraging of packaging efforts 
> and has been responsive to feedback about issues that might otherwise incur 
> distribution-level patches. Personally, I think that the software deserves 
> more exposure, especially when considering some of the transformative effects 
> it has on some kinds of Python code:
>
> http://shed-skin.blogspot.com/2024/01/fast-doom-wad-renderer-in-999-lines-of.html
>
> I have sought to follow advice provided in the team policy, making a Salsa 
> project available here:
>
> https://salsa.debian.org/pboddie/shedskin
>
> Building on experience with a previous repository (noted in the ITP report), 
> I 
> have hopefully managed to follow the branching and pristine-tar guidelines, 
> also introducing test running using Salsa CI.
>
> I have read and accept the policy published here:
>
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/
> policy.rst
>
> My Salsa login is pboddie.
>
> Thanks in advance for any guidance that might be offered!

I've granted you developer access to the package subgroup. You can
create a shedskin project here if you want.

If you lack some access, don't hesitate to reach out for help (we are on
#debian-python on OFTC IRC network).

Don't hesitate after some time and contributions to ask for maintainer
access if you need to create new repos.

-- 
PEB


signature.asc
Description: PGP signature

Re: Request to join debian-python team

[Pierre-Elliott Bécue]

Hi,

eevelweezel  wrote on 21/01/2024 at 22:53:06+0200:

> Hello,
>
> I am working on packaging pdm, and I would like to join Debian Python Team. 
> My username on salsa is eevelweezel. 
>
> I have read and accept the Debian Python Team policy. 
>
> Best,
> ./wzl

I'd be happy to create a repository or give you a specific access on a
repository you'd like to maintain.

On the other hand giving you full group access while you seem to have no
contributions to Debian so far seems a bit far-fetched at this time.

In the meantime, you can submit Merge Requests to the projects you want
to contribute to, this would help us creating this track record I
mentioned above.

I hope you'll understand our position.

Bests,
-- 
PEB


signature.asc
Description: PGP signature

Re: Application to be a member

[Pierre-Elliott Bécue]

Hi Patrick,

Patrick ZAJDA  wrote on 29/01/2024 at 19:18:19+0200:
> Hello,
>
> I write this message to be a member of the Python Team.
>
> Firstly because I wish to package Aresponse, RFS will be mailed to the list.
> I would also be happy to help for other modules in the maximum of my skills.
>
> As a Python programmer, I actually maintain PySMSBoxNet [1], a library
> to use smsbox.net API
> [1]: https://github.com/Nardol/pysmsboxnet
> I plan to also package PySMSBoxNet if it can be of interest for Debian.
> I have made some little contributions to Home Assistant core and have
> implemented auto-completion using Argcomplete in ESPHome.
>
> My name on Salsa is Nardol
>
> Best regards,

Sorry for the delay in replying.

I've granted you developer access based on your current track of
contributions.

Feel free to ask when you need a repository created.

And on the long term, I'll be happy to evaluate the opportunity to give
you Maintainer access.

-- 
PEB


signature.asc
Description: PGP signature

Re: Request to join the team

[Pierre-Elliott Bécue]

Hi Ricardo,

"Ricardo B. Marliere"  wrote on 29/01/2024 at 
23:07:59+0200:

> Hi,
>
> My name is Ricardo and I've been trying to get involved with Debian to
> give back to the community. I'm "rbmarliere" in Salsa [1] and I have
> made a few contributions to the Go team. However, I have more experience
> with Python and would like to help in fixing bugs for the team and
> other general QA work. I have read and accept the Debian Python Team
> Policy [2].

Considering your past contributions, I've granted you a Developer access.

Feel free to reach out when you need new repos created.

On the long-term if you contribute, I'll be happy to extend your ACLs.

Thanks, and sorry for the delay.
-- 
PEB


signature.asc
Description: PGP signature

Re: Membership request

[Pierre-Elliott Bécue]

Nicolas Couture  wrote on 27/02/2024 at 21:00:58+0200:

> Good day,
>
> As I met "pollo" this morning on OFTC after inquiring about helping out with 
> the adoption of virtualenvwrapper or researching more into
> the state of packaging pyenv in Debian, he suggested a good starting point 
> would be to read  https://deb.li/PyPolicy which I had not until
> now and then join the team to help out on any team-maintained packages.
>
> I understand the gist of it but I'm starting to think that "pollo" might 
> actually be a chicken, because he's excellent at laying out
> eggs-amples of policy, but when it comes to packaging, he believes in 
> free-range.
>
> On with the serious phase of this request:
>
> Why you want to join the team:
>
>  * Help maintain specific packages though my interest might be broader than 
> that and I'm willing to help out on team-maintained
>  packages to become familiar with the workflows
>  * Salsa login: ncouture
>  * I have read and accept 
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
>
> Best regards,

Hello Nicolas,

Sorry for not replying to your request earlier.

And nice of you roasting pollo. :-)

I'd be glad to give you access to specific repositories (and create
those which you need to have created), but before granting you a full
access to the group, I guess I'd like to see a bit of your contributions
track.

Would that be a fine compromise for you?

-- 
PEB


signature.asc
Description: PGP signature

Re: Request to join Debian Python team

[Pierre-Elliott Bécue]

Hi,

Xuanteng Huang  wrote on 05/03/2024 at 
10:25:03+0200:
> Hi all,
>
> I’m a newcomer to Debian community and interested in participating in Debian 
> package maintainances.
> I’m willing to maintain jupyter-cache[1], the execution cache system of 
> Jupyter Notebook under DPT, as other jupyer related package do.
>
> My Salsa login is xuantengh [2] and I’ve read the DPT policy [3] and accept 
> it.
>
> Best,
> Xuanteng Huang
>
> [1] https://github.com/executablebooks/jupyter-cache
> [2] https://salsa.debian.org/xuantengh
> [3] 
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

As Christian is sponsoring your application I gave you Developer access
to the package subgroup.

This means some ACLs will be missing, but you can ask Christian to do
privileged operations you can't.

If you contribute on the long-term I'll be glad to increase your access
level.

Thanks!
-- 
PEB


signature.asc
Description: PGP signature

Re: Request to join Debian Python team

[Pierre-Elliott Bécue]

Hi Daniel,

Daniel Echeverri  wrote on 15/03/2024 at 18:20:32+0200:

> Hello Team!
>
> El sáb, 9 mar 2024 a la(s) 11:33 a.m., Daniel Echeverri (epsi...@debian.org) 
> escribió:
>
>  Hi Team,
>
>  I am interested in joining the team, because, actually I am working in 
> adopting some python apps [1][2][3]
>
>  My Salsa login is epsilon[4].
>
>  Thanks!
>
>  Regards
>
>  [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065239
>  [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065241
>  [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065237
>  [4]: https://salsa.debian.org/epsilon
>
>  --
>  Daniel Echeverri
>  Debian Developer
>  Linux user: #477840
>  GPG Fingerprint:
>  D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB
>
> I forgot to say, that I accept the policy team mentioned in 
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
>
> Thanks in advance.
>
> Kind Regards.

It'd have been best to sign your request, but giving access to a DD to
the group without such a sig is not really something problematic to me.

Access granted. :)
-- 
PEB


signature.asc
Description: PGP signature

Re: Request to Join Debian Python Team

[Pierre-Elliott Bécue]

Dear Marcos,

Marcos Rodrigues de Carvalho (aka oday)  wrote on 
19/03/2024 at 06:28:23+0200:

> Dear Debian Python Team,
>
> I hope this email finds you well. My name is 
> Marcos Rodrigues de Carvalho (aka oday),
> and I am a Debian contributor interested in joining the Debian Python
> Team.
>
> I am reaching out to express my interest in becoming a member of the team and
> contributing to Python-related package maintenance within the Debian 
> ecosystem.
> I  believe that collaborating with the Debian Python Team will allow me to
> contribute more effectively and efficiently to the Debian project.
>
> My Salsa login is: marcos.rcarvalho.
>
> I have thoroughly reviewed the team's policies outlined in the following
> document:
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team.
> I fully understand and accept the responsibilities and guidelines set forth in
> the policy document.
>
> I am eager to join the team to help maintain existing packages, contribute to
> specific packages, and collaborate with other members of the Debian Python
> community.
>
> Thank you for considering my request to join the Debian Python Team. I look
> forward to the opportunity to contribute and collaborate with fellow team
> members.

First, I'd like to apologize for the long delay for you to get a reply.

Second, as you're quite new to Debian in terms of contributions, I'd
like to ask you first to point to specific repositories you'd like to
contribute to, and second, to start doing so by submitting merge
requests (which are open for anyone).

Once you'll have built sufficient trust, we'll consider a wide-range
inclusion in DPT.

I hope that you'll understand our position on this matter.

-- 
PEB


signature.asc
Description: PGP signature

Re: Request to join DPT

[Pierre-Elliott Bécue]

Hi Jakob,

Jakob Haufe  wrote on 27/03/2024 at 11:43:55+0200:
> Hi all,
>
> I recently adopted intelhex[1] and would like to continue maintaining
> it in the repo under the DPT group.
>
> My salsa username is sur5r[2].
>
> I have read the policy[3] and accept it.
>
> Cheers,
> sur5r
>
> [1] https://bugs.debian.org/976074
> [2] https://salsa.debian.org/sur5r
> [3] 
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

Sorry for the delay, invitation sent!

-- 
PEB


signature.asc
Description: PGP signature

Re: Team join request

[Pierre-Elliott Bécue]

Hi Vivek,

Vivek K J  wrote on 31/03/2024 at 10:38:20+0200:

> [[PGP Signed Part:Good signature from A5FF4BB3EA53C5DF Vivek K J 
>  (trust undefined) created at 2024-03-31T10:38:20+0200 
> using RSA]]
> Hey,
>
> I would like to join debian-python team for helping in maintaining some
> python packages. I've got experience in maintaining packages in ruby and
> JS teams. For now, I would like to update pmbootstrap package for fixing
> #1065637.
>
> My salsa login: vivekkj
>
> I've read python-team policy, and I'm ready to follow all the guidelines.

Invitation sent.
--
PEB


signature.asc
Description: PGP signature

Re: SALSA_CI_LINTIAN_FAIL_WARNING / SALSA_CI_LINTIAN_ARGS in salsa-ci.yml

[Pierre-Elliott Bécue]

Carles Pina i Estany  wrote on 06/11/2023 at 00:39:42+0100:

> [[PGP Signed Part:No public key for A802884F60A55F81 created at 
> 2023-11-06T00:39:42+0100 using RSA]]
>
> Hi,
>
> I created python-ping3 package a month ago.
>
> At some point I didn't see some lintian warnings from salsa. To avoid
> missing warnings again I added in salsa-ci.yml:
>
> variables:
>   SALSA_CI_LINTIAN_FAIL_WARNING: 1
>
> https://salsa.debian.org/python-team/packages/python-ping3/-/blob/debian/unstable/debian/salsa-ci.yml#L7
>
> Is there any convention on doing this for python-team maintained
> packages?
>
> Also, I would be happy to have:
>   SALSA_CI_LINTIAN_ARGS: --pedantic --fail-on pedantic
>
> (added there as well)
>
> IIRC, lintian pedantic's reports are shown in mentors.debian.net and I
> thought that would be good to have them in salsa - with the fail-on
> pedantic to avoid missing them.
>
> Any +1 / -1 of these options for python-team packages? Like "do not do
> this" or "if it works for you, feel free to do it".
>
> Thanks!

The team policy doesn't mention anything on this regard, and I guess
it's partially because originally this feature did not exist and the
policy has not been updated significantly in the past years.

In general, if something is not in the team policy, it's up to you to
chose how you deal with it.

In this very case, you really should feel fine about enabling CI
features that improve your packages' quality.
-- 
PEB


signature.asc
Description: PGP signature

Re: Sponsorship request: python-ping3

[Pierre-Elliott Bécue]

Carles Pina i Estany  wrote on 18/10/2023 at 01:56:46+0200:

> [[PGP Signed Part:No public key for A802884F60A55F81 created at 
> 2023-10-18T01:56:46+0200 using RSA]]
>
> Hi,
>
> On 17 Oct 2023 at 22:42:27, Carles Pina i Estany wrote:
>
> [...]
>
>> >  2. Regarding testing, this package is a bit a mess. First you probably
>> > realized that you can't run tests at buildtime because a raw socket
>> > requires root privilege. I see you designed custom autopkgtest to
>> 
>> yep...
>> 
>> [...]
>> 
>> > From there you have two options: the first one is to drop the
>> > Testsuite: field and keep the two tests you designed and call it a
>> > day, or you drop it and write a third test stanza in
>> > debian/tests/control with a shell script you'd also have to write
>> > that moves the tests to the tmp dir autopkgtest creates, puts
>> > localhost in /etc/hosts and then run tests. In that case you need
>> > to add pytest to the dependencies of this test stanza.
>> 
>> Sounds doable no problem, I'll try it this evening and see how it goes.
>
> From doable to "I'm 99% sure that not possible". I cannot send pings
> from autopkgtest in salsa with any software.
>
> Side note: I remembered that when using "needs-internet": HTTP GET
> requests (even using hostnames) works. This is my first package for
> Debian, but I've used autopkgtest with needs-internet to run a sphinx
> "linkcheck" and it was working correctly.
>
> I've checked that no ICMP replies even using the standard ping binary
> from iputils-ping:
> -
> Test-Command: set +e ; ping -c 4 8.8.8.8 ; ping -c 4 example.com ; curl -s -I 
> https://en.wikipedia.org ; curl -s -L https://en.wikipedia.org | head -5
> Depends: python3-ping3, iputils-ping, curl
> Restrictions: needs-root, needs-internet
> Features: test-name=test-real-ping
> -
> That's in:
> https://salsa.debian.org/carlespina/python-ping3/-/blob/autopkgtest-connectivity/debian/tests/control
>
> The output:
> https://salsa.debian.org/carlespina/python-ping3/-/jobs/4822521#L213
>
> 4 packets transmitted, 0 received, 100% packet loss, time 3059ms
> 4 packets transmitted, 0 received, 100% packet loss, time 3079ms
>
> Even more: I think that curl -I (--head) (HTTP HEAD) might not work? but
> curl HTTP GET works. I'm not sure about the curl -I but I don't think it
> is relevant for this discussion. Somewhere, I think, I had read
> something that it implied that autopkgtest needs-internet was using a
> proxy? I cannot find it anyway and ICMP seems that cannot be used.
>
> So, for now, I've:
> -Used wrap-and-soft (excellent!).
> -Removed "set -e" in one of my Test-Commands: it's the default in
>  autopkgtest (I discovered with the "pings..." and then documenation)
> -Fixed a cosmetic line in d/tests/control (s/features/Features)
> -Removed "Testsuite: autopkgtest-pkg-pybuild" from d/control because
>  ICMP is not available anyway
> -Ran dch -r to update the date
> -"dput --force mentors python-ping3_4.0.4-1_amd64.changes"
>
> I've also discovered that there are a few unit tests in upstream that do
> not work. Some have an easy fix, I will do a MR of the fixes that I've
> done for some of them (separately, in GitHub, not tonight).
>
>> Your call.
>> 
>> Tell me when you're fine with your work and I'll upload.
>
> To me, it can be uploaded :-)
>
> Let me know if I need or can do anything else.

Uploaded, remember to put a tag on the latest commit. :)
-- 
PEB


signature.asc
Description: PGP signature

Re: Sponsorship request: python-ping3

[Pierre-Elliott Bécue]

Carles Pina i Estany  wrote on 17/10/2023 at 23:42:27+0200:

> [[PGP Signed Part:No public key for A802884F60A55F81 created at 
> 2023-10-17T23:42:27+0200 using RSA]]
>
> Hi,
>
> On 17 Oct 2023 at 22:13:05, Pierre-Elliott Bécue wrote:
>> Hi,
>> 
>> Carles Pina i Estany  wrote on 16/10/2023 at 21:27:33+0200:
>> 
>> > [[PGP Signed Part:No public key for A802884F60A55F81 created at 
>> > 2023-10-16T21:27:33+0200 using RSA]]
>> >
>> > Hi,
>> >
>> > I ITP simplemonitor (#1016113), so I started with one of its
>> > dependencies (actually is a "soft" dependency, optional but better to
>> > have) (two more to come).
>> >
>> > So, I RFS for ping3:
>> > https://mentors.debian.net/package/python-ping3/
>> > https://mentors.debian.net/debian/pool/main/p/python-ping3/python-ping3_4.0.4-1.dsc
>> >
>> > Also in:
>> > https://salsa.debian.org/python-team/packages/python-ping3
>> >
>> > This is my first package for Debian. Reviewing only, or reviewing +
>> > sponsorship, are very appreciated. I'd like to get this one as right as
>> > possible to do the next Python3 packages as good as possible.
>> >
>> > If it suits anyone better: I'm cpina on freenode (#debian-python for
>> > example).
>> >
>> > Thank you very much for any advise!
>> 
>> LGTM. Just for DEP-14, you should have the main branch named
>> debian/unstable and not debian/master.
>
> Oops! I actually followed
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#branch-names
> in the section "Branch names" and mentions "debian/master". Perhaps that
> should be updated?
>
> Anyway, thanks for changing it!

I could be wrong, but ISTR that the branch name was debian/master for a
long time in the policy (dates back to 2016 at least?)

I'm not sure that DEP-14 was providing a recommendation for sid branches
at that time.

Anyway, I think that indeed we should offer in the policy a choice
between debian/unstable, debian/latest or debian/master although I'd not
recommend the latest, because it makes less sense logically, so I'd
deprecate it.

>> I pushed a debian/unstable branch and modified gbp.conf.
>> 
>>  1. Regarding packaging, lintian is happy and the files look good to
>> me. You can install devscripts and use wrap-and-sort to make some
>> things a bit more readable (IMHO). (have a look at devscripts in
>> general, it's resourceful)
>
> Thanks for showing wrap-and-sort! Note taken and I will look at other
> interesting things in devscripts.
>
>>  2. Regarding testing, this package is a bit a mess. First you probably
>> realized that you can't run tests at buildtime because a raw socket
>> requires root privilege. I see you designed custom autopkgtest to
>
> yep...
>
> [...]
>
>> From there you have two options: the first one is to drop the
>> Testsuite: field and keep the two tests you designed and call it a
>> day, or you drop it and write a third test stanza in
>> debian/tests/control with a shell script you'd also have to write
>> that moves the tests to the tmp dir autopkgtest creates, puts
>> localhost in /etc/hosts and then run tests. In that case you need
>> to add pytest to the dependencies of this test stanza.
>
> Sounds doable no problem, I'll try it this evening and see how it goes.
>
>> Tell me when you're fine with your work and I'll upload.
>
> thanks very much for the information, will let you know something.

You're very welcome!

-- 
PEB


signature.asc
Description: PGP signature

Re: Sponsorship request: python-ping3

[Pierre-Elliott Bécue]

Hi,

Carles Pina i Estany  wrote on 16/10/2023 at 21:27:33+0200:

> [[PGP Signed Part:No public key for A802884F60A55F81 created at 
> 2023-10-16T21:27:33+0200 using RSA]]
>
> Hi,
>
> I ITP simplemonitor (#1016113), so I started with one of its
> dependencies (actually is a "soft" dependency, optional but better to
> have) (two more to come).
>
> So, I RFS for ping3:
> https://mentors.debian.net/package/python-ping3/
> https://mentors.debian.net/debian/pool/main/p/python-ping3/python-ping3_4.0.4-1.dsc
>
> Also in:
> https://salsa.debian.org/python-team/packages/python-ping3
>
> This is my first package for Debian. Reviewing only, or reviewing +
> sponsorship, are very appreciated. I'd like to get this one as right as
> possible to do the next Python3 packages as good as possible.
>
> If it suits anyone better: I'm cpina on freenode (#debian-python for
> example).
>
> Thank you very much for any advise!

LGTM. Just for DEP-14, you should have the main branch named
debian/unstable and not debian/master.

I pushed a debian/unstable branch and modified gbp.conf.

 1. Regarding packaging, lintian is happy and the files look good to
me. You can install devscripts and use wrap-and-sort to make some
things a bit more readable (IMHO). (have a look at devscripts in
general, it's resourceful)

 2. Regarding testing, this package is a bit a mess. First you probably
realized that you can't run tests at buildtime because a raw socket
requires root privilege. I see you designed custom autopkgtest to
still have some proper testing. That being said, the Testsuite:
field is not useful as by default pybuild uses unittest which
doesn't work on this package.

I was hoping to provide you with a way to run upstream tests anyway
which is possible (add python3-pytest as a build dep, disable tests
in d/rules, and then configure autopkgtest-pkg-pybuild to use root
privilege) but upstream made tests that actually require dns
resolution (you won't have any) for the value in /etc/hostname which
won't work on a buildd. We'd require to force change the value in
this file and it'd make it a bit tedious.

From there you have two options: the first one is to drop the
Testsuite: field and keep the two tests you designed and call it a
day, or you drop it and write a third test stanza in
debian/tests/control with a shell script you'd also have to write
that moves the tests to the tmp dir autopkgtest creates, puts
localhost in /etc/hosts and then run tests. In that case you need to
add pytest to the dependencies of this test stanza.

Your call.

Tell me when you're fine with your work and I'll upload.

Cheers!

-- 
PEB


signature.asc
Description: PGP signature

Re: uploading paramiko 3.0.0

[Pierre-Elliott Bécue]

Hans-Christoph Steiner  wrote on 06/02/2023 at 22:35:44+0100:

> paramiko 3.0.0 was released two weeks ago.  Any reason to not upload
> it now?  It would be nice to get into bookworm.

paramiko is a key package. The hard freeze is in a month. Uploading a
new major release right now could break a lot of things that depend
on it and create a mess right before the freeze.

In particular, ganeti, which is used a lot by DSA, and ansible which is
used by a lot of people.

I'd advise against such an upload except if someone makes sure that it
wouldn't break anything sensitive.

-- 
PEB


signature.asc
Description: PGP signature

Re: Please make a separate package for mistune 2.x

[Pierre-Elliott Bécue]

Nilesh Patra  wrote on 05/02/2022 at 20:23:44+0100:

> [[PGP Signed Part:No public key for 00BAE74B343369F1 created at 
> 2022-02-05T20:23:44+0100 using RSA]]
> On 2/6/22 12:20 AM, Julian Gilbey wrote:
>> On Fri, Feb 04, 2022 at 09:27:59PM +0530, Nilesh Patra wrote:
>>> On 2/4/22 9:18 PM, Julian Gilbey wrote:
 [...]
 _mistune.py within the Debian package,
 and have nbconvert do "import nbconvert.filters._mistune as mistune"
 (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
 That seems like an eminently sensible solution to this problem.
>>>
>>> But that'd lead to a number of mistune's embedded copies in a huge number 
>>> of packages; since majority of
>>> the rev-deps (when I last checked) haven't adapted to this new version. 
>>> When they do,
>>> and it becomes a overhead to fix each one later.
>>> Even worse, if we discover a security problem sometime later, then all such 
>>> packages would be
>>> effected, and that honestly does not look like a good idea to me.
>> I have just had another idea, which might solve all of the problems:
>> create a new Debian package called mistune0 (or mistune1), which
>> contains the legacy version of mistune, but with the Python module
>> called "mistune0" instead of "mistune".  Then it will be
>> co-installable with mistune 2.x, and the packages which still depend
>> on mistune 0.8.4 could be patched to say "import mistune0 as mistune"
>> until they are updated upstream.  This will also avoid having multiple
>> copies of the legacy code in the archive, which addresses the security
>> issue, and allow those packages which have migrated to mistune 2.x to
>> still say "import mistune".
>
> Ah, looks like we just had to think in the reverse direction from the initial 
> proposal (mistune-{0,1} instead of mistune-{1,2}).
> Indeed, that sounds like a much better plan.
> I hope PEB agrees with this as well, would like to hear from them :)
>
> Thanks for the discussion, Julian :)
>
> Regards,
> Nilesh

I'd like other python team member's opinion on this, and I'm not eager
to maintain that legacy package, as I tend to not want to maintain
obsolete software. Still, I can do the initial work of creating it.

-- 
PEB


signature.asc
Description: PGP signature

Re: Please make a separate package for mistune 2.x

[Pierre-Elliott Bécue]

Le 4 février 2022 16:57:59 GMT+01:00, Nilesh Patra  a écrit :
>On 2/4/22 9:18 PM, Julian Gilbey wrote:
>> Basically, the mistune upstream author has completely messed up on
>> this by making what is essentially a completely different package with
>> superficially similar functionality but the same name.
>
>True.
>  
>> [...]
>> _mistune.py within the Debian package,
>> and have nbconvert do "import nbconvert.filters._mistune as mistune"
>> (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
>> That seems like an eminently sensible solution to this problem.
>
>But that'd lead to a number of mistune's embedded copies in a huge number of 
>packages; since majority of
>the rev-deps (when I last checked) haven't adapted to this new version. When 
>they do,
>and it becomes a overhead to fix each one later.
>Even worse, if we discover a security problem sometime later, then all such 
>packages would be
>effected, and that honestly does not look like a good idea to me.
>
>I somehow do not understand the urgency of uploading this newer version, as 
>the maintainer said:
>
>| I intend to upload src:mistune 2.0.0 to unstable between March the
>| 15th and April the 15th (depending on the progress of its
>| reverse-dependencies).
>
>We could simply wait a little more for the dust to settle, IMHO.
>
>Regards,
>Nilesh
>

Because some packages I maintain depend on mistune 2.x and mistune 0.8.4 is, 
whether we like it or not, obsolete.

I can't really afford to wait for a year to try having mailman3 in testing 
again...
--
Pierre-Elliott Bécue
From my phone

Re: Please make a separate package for mistune 2.x

[Pierre-Elliott Bécue]

Hi Michael,

"Michael R. Crusoe"  wrote on 24/01/2022 at 11:39:23+0100:

> [[PGP Signed Part:No public key for 3C26763F6C67E6E2 created at 
> 2022-01-24T11:39:23+0100 using RSA]]
> On Tue, 11 Jan 2022 22:38:44 +0100 p...@debian.org wrote:
>> Package: python3-schema-salad
>> Severity: wishlist
>>
>> Dear maintainer,
>>
>> Your package python3-schema-salad depends on python3-mistune 0.8.4
>> which is no longer maintained and deprecated in favour of version
>> 2.0.0.
>>
>> As python3-mistune 2.0.0 is not backward compatible, I reverted the
>> upload of it that I did in unstable and python3-mistune 0.8.4 will
>> stay around a bit longer.
>>
>> In the meantime, please try to see if upstream of
>> python3-schema-salad either released a version that is compatible
>> with python3-mistune 2.0.0 or if python3-schema-salad can easily be
>> fixed to support such a version. As soon as you're ready to upload
>> your package please update this bug report and we'll try to
>> coordinate so that I release python3-mistune at a time that is fit
>> for you to also release python3-schema-salad.
>
> Dear Pierre-Elliott Bécue,
>
> Thank you for trying to find a way forward in this mess. I am also the
> upstream maintainer for schema-salad. We have yet to find a way to 
> support mistune 2.x
>
> Here is our attempt so far:
>
> https://github.com/common-workflow-language/schema_salad/pull/496/files?short_path=5c6a130#diff-5c6a1301c6b59b30a040d747d065e861d3dd98bde0e5a4356d92d594e9835986
>
> And an issue I opened with mistune directly about a regression in
> multi-line list handling that goes against multiple markdown specs: 
> https://github.com/lepture/mistune/issues/296
>
> We have not decided if we will switch to another library, wait for a
> fixed mistune 2.x release, or keep with the older version.
>
>> I intend to upload src:mistune 2.0.0 to unstable between March the
>
>> 15th and April the 15th (depending on the progress of its
>> reverse-dependencies). I'll raise the severity of this bug
>> approximately a month before making such an upload.
>
> Since Mistune 2.0.0 regresses its support for standard markdown, I ask
> that a separate package be made for mistune 2.x to give more time for 
> mistune 0.8.x users to migrate to mistune 2.x or another library entirely.
>
> Cheers,

I'm not formally against it, but it's not really standard in my
opinion. It'd lead to maintenance of two packages, probably on some long
term (as it'd relieve the pressure to migrate for maintainers of
reverse-deps of mistune).

Besides, having a source package named "mistune2" while upstream's
package is named "mistune" adds also another layer of complexity.

I'd like to have some python team members' opinion on this, and I am not
sure to be eager to do it as of now.

Cheers!
-- 
PEB


signature.asc
Description: PGP signature

Re: Please enable me transfering python-bioblend to Debian Med team

[Pierre-Elliott Bécue]

Nilesh Patra  wrote on 22/12/2021 at 20:45:53+0100:

> [[PGP Signed Part:No public key for 00BAE74B343369F1 created at 
> 2021-12-22T20:45:49+0100 using RSA]]
> Hi Pierre-Elliot,
>
> On Wed, Dec 22, 2021 at 08:06:01PM +0100, Pierre-Elliott Bécue wrote:
>> >> I'm sorry but pressuring to take over a package is not really fine. If
>> >> you're not happy with the time it takes for an answer, you can try to
>> >> fill an ITS and if the procedure goes to its end then you may take over.
>> >
>> > Please note:  The people involved are the same.  We are members of
>> > both teams but consider the Debian Med team more appropriate.  We
>> > are simply missing the permissions to do the move properly.
>> 
>> I am aware of that.
>> 
>> Yet, the fact that you are members of both teams doesn't entitle you to
>> decide such a transfer, even if you had the technical rights to do so.
>
> Hmm, I am not sure what the problem in such a case would be (permission in 
> both teams)
> Steffen is the maintainer (uploader if you might prefer it that way) and he 
> has
> agreed already[1] -- so what's the problem?
>
> [1]: https://lists.debian.org/debian-med/2021/12/msg00119.html

I guess the problem is that the python-team doesn't seem to have been
Cc-ed in your exchange, which was not quoted in the initial mail of this
thread.

As I'm not subscribed to the list, it really looked like you were
intending to take over a package without any maintainer of it having
been asked for it before.

As it seems not to be the case, it's not the same at all.

>> I therefore stand my point: the way Debian is made has not changed
>> recently, and taking over still requires a formal approval from the
>> maintainer, which you are not.
>> 
>> The only alternatives are either an ITS or MIA team orphaning their
>> packages, but as the maintainer is an active team, the latter will not
>> happen.
>
> I do not think it is sensible to take consensus from an entire team to
> move a single package.

I did not suggest to wait for a consensus, but rather that an admin asks
if someone is against and waits for a reasonable delay (72 hours?) and
then makes the transfer if they're happy with it.

> Honestly speaking, we really do not need to make team transfer debian
> processes such a high friction ones -- it just stalls the work for no
> good reason.  The package has not seen uploads since more than two
> years, I really doubt anyone in the team feels strong ly about not
> moving it.

There is no real difference between teams and individual developers on
that part: a take over has to be approved or to follow due procedures,
whether we like it or not.

Here, as Steffen gave his approval, the topic is a bit moot.

> If you are talking about Ondřej doing the uploads apart from the
> initial uploads, then you probably are also aware that Ondřej does a
> number of team-maintained package uploads to fix bugs, does updates
> and so on (a lot of us do so, for that matter albeit in other teams) I
> really don't think that he has a personal interest in every single one
> of those packages (including this one) but we should hear from him.

I was under the (false) impression that Steffen was not currently
available to reply to your query. Ondřej being an admin of the team and
having done all the uploads apart from those done by Steffen, he clearly
seemed the best second contact point to ask this transfer.

>> >> and they could be willing to check that no one in the team objects.
>
> Sure but how are you making a "check" here? I do have admin access in
> a few teams, and speaking for myself: I would send out an email to the
> list, wait for a time frame (maximum 1 week) and check if someone has
> any comments If not, I would make a move.  So we already have a mail
> in the debian-python mailing list, and no objections so far, so 
>
> I would have probably done more to ask for consensus better (asking on
> IRC channels etc) but admittedly, we only have 24 hours in the day,
> and several dozens of packages to do.

Asking globally on the list and waiting a reasonable amount of time for
a potential grunt is fine with me.

>> I think you missed the second part of my sentence you're quoting.
>
> I recetified this above.
>
>> >> Steffen only did the first upload. I'd suggest to contact Ondrej (Cc-ed).
>> >> 
>> >> In the meantime, Nilesh is member of the Python team and therefore can
>> >> do an update of the package (but not change the maintainer).
>> >
>> > I'm a member myself - but the upload should happen in the Debian
>> > Med team.  This is the point of my mail.
>> 
>> I disagree.
>> 
>>

Re: Please enable me transfering python-bioblend to Debian Med team

[Pierre-Elliott Bécue]

Andreas Tille  wrote on 22/12/2021 at 19:42:26+0100:

> Am Wed, Dec 22, 2021 at 06:13:32PM +0100 schrieb Pierre-Elliott Bécue:
>> 
>> Andreas Tille  wrote on 21/12/2021 at 15:43:11+0100:
>> 
>> > Ping?  Could any admin of Debian Python Team help out?  We can simply
>> > recreate the repository in Debian Med and move on ... but that might
>> > be confusing for users who will find two clones in differen teams.
>> > Thank you, Andreas.
>> 
>> I'm sorry but pressuring to take over a package is not really fine. If
>> you're not happy with the time it takes for an answer, you can try to
>> fill an ITS and if the procedure goes to its end then you may take over.
>
> Please note:  The people involved are the same.  We are members of
> both teams but consider the Debian Med team more appropriate.  We
> are simply missing the permissions to do the move properly.

I am aware of that.

Yet, the fact that you are members of both teams doesn't entitle you to
decide such a transfer, even if you had the technical rights to do so.

I therefore stand my point: the way Debian is made has not changed
recently, and taking over still requires a formal approval from the
maintainer, which you are not.

The only alternatives are either an ITS or MIA team orphaning their
packages, but as the maintainer is an active team, the latter will not
happen.

>> Apart from that, you'll need for an admin of the team to do the transfer,
>> and they could be willing to check that no one in the team objects.
>
> Yes, we need an admin and that was I'm asking for.

I think you missed the second part of my sentence you're quoting.

>> Steffen only did the first upload. I'd suggest to contact Ondrej (Cc-ed).
>> 
>> In the meantime, Nilesh is member of the Python team and therefore can
>> do an update of the package (but not change the maintainer).
>
> I'm a member myself - but the upload should happen in the Debian
> Med team.  This is the point of my mail.

I disagree.

Either the python team accepts the package to be transferred and it
indeed should happen there. Or you're in a hurry and you should not
change the maintainer field and still do your upload.

This probably means we should have a stanza in the DPT policy about
transfer of maintainership.

-- 
Pierre-Elliott Bécue


signature.asc
Description: PGP signature

Re: Please enable me transfering python-bioblend to Debian Med team

[Pierre-Elliott Bécue]

Andreas Tille  wrote on 21/12/2021 at 15:43:11+0100:

> Ping?  Could any admin of Debian Python Team help out?  We can simply
> recreate the repository in Debian Med and move on ... but that might
> be confusing for users who will find two clones in differen teams.
> Thank you, Andreas.

I'm sorry but pressuring to take over a package is not really fine. If
you're not happy with the time it takes for an answer, you can try to
fill an ITS and if the procedure goes to its end then you may take over.

Apart from that, you'll need for an admin of the team to do the transfer,
and they could be willing to check that no one in the team objects.

Steffen only did the first upload. I'd suggest to contact Ondrej (Cc-ed).

In the meantime, Nilesh is member of the Python team and therefore can
do an update of the package (but not change the maintainer).

With best regards,

-- 
PEB


signature.asc
Description: PGP signature

Re: Status of poetry

[Pierre-Elliott Bécue]

Emmanuel Arias  wrote on 12/11/2021 at 23:51:12+0100:

> Hello everybody,
>
> I write to let you know that poetry (1.1.11) is already in NEW [0].
>
> Thanks everybody for helping me to package it. Thanks pollo for
> the first reviews. And a lot of thanks to morph to push me to finish
> this work and for the sponsorship.
>
> [0] https://ftp-master.debian.org/new/poetry_1.1.11+dfsg-1.html

Thanks a lot for your work!!

--
PEB


signature.asc
Description: PGP signature

python-coverage 5.1

[Pierre-Elliott Bécue]

Dear Ben,

Coverage 5.1 is out and is needed, eg by zope.interface version 5 which
requires coverage 5.0.3 or higher for testing. Currently, not having
coverage blocks any update for mailman3 that would help me having it
back into testing.

Would you agree to either have it in unstable, or me doing a release?

Thanks a lot!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: Mass commit: Rename d/tests/control.autodep8 to d/tests/control

[Pierre-Elliott Bécue]

Le 07/01/2019 à 21:42, Ondrej Novy a écrit :
> Hi,
> 
> because of:
> 
>   * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908272
>   * 
> https://salsa.debian.org/ci-team/autodep8/commit/8b355f6128bffe58d2246e9d52435a81816dda5c
>   * 
> https://salsa.debian.org/lintian/lintian/commit/b9a7ca6d2701dc01e4745774597a5860a7b605e5
> 
> 
> I would like to mass commit that change in our Salsa repositories.
> 
> Example:
> https://salsa.debian.org/python-team/modules/python-flake8/commit/9fc14c64a56a2e90bf6d4a35764fdd803e0e4285
> 
> Any thoughts?
> 
> Thanks.

Hi,

Fine with me!

I'm just curious, could you provide me with the tools you use for such a
mass commit? For the sake of knowledge.

Thanks!

-- 
PEB

Re: Request to update the gnukhata-core new version

[Pierre-Elliott Bécue]

Hi Manas,

Le 05/01/2019 à 16:28, Manas Kashyap a écrit :
> Hola , 
> I have updated the Gnukhata-core
>  version to
> 5.50 and it has passed lintian and sbuild and is ready to be uploaded. 
> I would request mentors to please look into this and test it and update
> as needed. 
> Thank you so much 
> Manas Kashyap 

I'll take care of this this evening.

Cheers,

-- 
PEB

Re: RFS: mu-editor and yotta dependencies

[Pierre-Elliott Bécue]

Le dimanche 30 décembre 2018 à 23:15:10+, Nick Morrott a écrit :
> On Sun, 30 Dec 2018 at 18:42, Pierre-Elliott Bécue  wrote:
> >
> > Re,
> >
> > Actually, nudatus is a dependency of uflash.
> 
> See below for my reasoning for adding python3-nudatus as a Recommends
> for python-uflash, rather than a hard Depends.
> 
> > ## python-nudatus
> >
> > Uploaded.
> 
> Awesome
> 
> > ## python-uflash
> >
> > Uploaded, though installing it will be hard, as
> > firmware-microbit-micropython is missing and apt tries to fetch the
> > recommends too.
> 
> nudatus is really an optional dependency of uflash, as minification is
> not essential. The uflash code checks to see if nudatus is available
> at runtime, and will disable minify if it is not available.

It's a build-dep of uflash (or at least you declared it that way), I was
mentionning the dependency in that way: I needed to build nudatus first.

> > ## python-guizero
> >
> > Uploaded.
> 
> Awesome
> 
> > ## mu-editor
> >
> > Hmmm.
> >
> > In the dependencies of the project are mentionned and imported:
> >
> > gpiozero
> 
> Please see the request to provide the gpiozero package on non-armhf
> architectures at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856413
> 
> > pigpio
> 
> Please see the RFP discussion for packaging pigpio at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908787

Saw both. I was more interested in "are they mandatory for mu to work". It
seems that the answer is nope. :)

> > pynsist
> 
> pynsist is a tool to build Windows installers

Ack.

> > + some deps useful for testing.
> 
> i) pytest-cov measures test coverage, and I am not sure if that's a
> useful statistic for packing?

Nah, that's why I wrote "+ some deps useful for testing". :)

> ii) pytest-random-order would be useful, especially for reproducibility.

Ack, I'll look into it when you're done (saw your ITP).

> *However*, since upstream Mu added the dependency back in 2018/03,
> upstream pytest-random-order 1.0.0+ disabled its "random by default"
> behaviour (2018/10). As such, the mu-editor tests are not currently
> randomised. This is a testing regression and I will report it, so that
> the forthcoming 1.0.2 release of Mu contains it.
> 
> pytest-random-order is not actually packaged yet for Debian, so I could ITP 
> it.
> 
> > I don't see any of those three packages in debian right now. Is there a
> > reason you consider we don't need these?
> 
> I have added notes about gpiozero/pigpio to d/control. pynsist does
> not seem necessary.

So they don't seem mandatory to you to have a working release of mu-editor?

I've uploaded the package.

Thanks for your thoroughness, and your contribution to Debian!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: RFS: mu-editor and yotta dependencies

[Pierre-Elliott Bécue]

Re,

Actually, nudatus is a dependency of uflash.

## python-nudatus

Uploaded.

## python-uflash

Uploaded, though installing it will be hard, as
firmware-microbit-micropython is missing and apt tries to fetch the
recommends too.

## python-guizero

Uploaded.

## mu-editor

Hmmm.

In the dependencies of the project are mentionned and imported:

gpiozero
pigpio
pynsist

+ some deps useful for testing.

I don't see any of those three packages in debian right now. Is there a
reason you consider we don't need these?

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: RFS: mu-editor and yotta dependencies

[Pierre-Elliott Bécue]

Le dimanche 30 décembre 2018 à 05:14:34+, Nick Morrott a écrit :
> On Sun, 30 Dec 2018 at 02:12, Pierre-Elliott Bécue  wrote:
> >
> > Le dimanche 30 décembre 2018 à 02:01:28+0100, Pierre-Elliott Bécue a écrit :
> > > [snip]
> >
> > ## python-project-generator-definitions: uploaded
> >
> >  1) I uploaded a bit fast. It's not a big issue but could you consider
> > removing the explicit python3 dependencies from the binary package's
> > Depends field? Normally debhelper finds the appropriate list from
> > python3:depends meta-dependency, using install_requires field of
> > setup.py.
> 
> Updated
> 
> > ## python-project-generator:
> >
> >  1) I wonder why you removed the alternative entry point.
> 
> I dropped it to be consistent with
> python3-project-generator-definitions which only provides a single
> entrypoint in the same "namespace". I also thought the longer
> entrypoint name was somewhat cumbersome.
> 
> >  2) Please remove all specific entries for the binary package Depends,
> > except python3-project-generator-definitions (<< 0.3.0):
> > python3:depends drags the others properly.
> 
> Updated

Uploaded, thanks!

> > ## valinor:
> >
> >  1) You should ask upstream to provide a changelog, even though your
> > changelog.upstream.md is a perfectly fine temporary solution.
> 
> https://github.com/ARMmbed/valinor/issues/29
> 
> >  2) Same about the Depends field of this package, keep gdb of course, as
> > no :depends entry will drag it.
> 
> Updated
> 
> >  3) d/watch: could you use version=4 here or is there an issue?
> 
> Bumped to version 4 (I had cribbed from another d/watch file using pypi)
> 
> >  4) Is there a good reason for your export PYBUILD_AFTER_INSTALL=mv
> > {destdir}/usr/bin/valinor {destdir}/usr/share/valinor/run in d/rules
> > plus the link for /usr/bin?
> 
> The package build attempts to install the script "valinor" into
> /usr/share/valinor/valinor/, which it can't because of the naming
> conflict. This occurs in a few of the other packages too I think.

Ack, I'm surprised by the mentioned behaviour but in any case, this choice
you made isn't irrelevant so let's stick to it for now.

If you find some time to investigate what causes such behaviour, please give
me some feedback!

> > ## python-mbed-ls:
> >
> >  1) Same as the others regarding the Depends field of the binary package.
> 
> Updated
> 
> >  2) For the Doxygen patch, you removed the genlatex, I guess it's because
> > you don't want to drag texlive for the building part? I'm fine with
> > this.
> 
> Yes

I made a small mistake, you had to keep python3-pkg-resources and
python3-colorlog here, but I forgot to mention them. I made a fixing commit.

Uploaded.

> > ## python-mbed-host-tests:
> >
> >  1) Same as the others regarding the Depends field, prospectively keeping
> > the versioned dependencies
> 
> Updated

I restored python3-pkg-resources as a dependency. I missed that one.

Uploaded.

> > ## mbed-test-wrapper:
> >
> >  1) Still the same Depends question. :) keep binutils-arm-none-eabi, of
> > course.
> 
> In this instance, the source setup.py file does not declare anything
> in install_requires and so the dependencies must be added manually.
> 
> I've asked upstream to consider adding explicit dependencies for
> mbed-ls and mbed-host-tests:
> 
> https://github.com/autopulated/mbed-test-wrapper/issues/3

Ack, my bad, I must've been a little tired, I missed the setup.py emptyness.

Uploaded.

> > ## python-hgapi
> >
> >  1) You should suggest your patches to upstream.
> 
> The patches were take from upstream's repository and links to the PRs
> are in the patch headers.

Ah, good to know!

> > ## yotta
> >
> >  1) Same old Depends field. You must keep valinor and mbed-test-wrapper at
> > least for now (I think that they'll be matched by the dh magic when
> > they'll be in the archive).
> 
> Updated
> 
> >  2) I wonder why you added python3-openssl and python3-idna to the
> > dependencies, they seem not needed according to setup.py? If you need
> > them, please add them manualy to the Depends field as they won't be
> > dragged by the python3:depends variable. In that case maybe it would be
> > worth do att a README.source in the debian/ directory explaining why
> > these packages are needed. If upstream forgot to add these dependencies,
> > please notify them with a bug report.
> 
> I *think* I originally added them because the

Re: RFS: mu-editor and yotta dependencies

[Pierre-Elliott Bécue]

Le dimanche 30 décembre 2018 à 02:01:28+0100, Pierre-Elliott Bécue a écrit :
> [snip]

## python-project-generator-definitions: uploaded

 1) I uploaded a bit fast. It's not a big issue but could you consider
removing the explicit python3 dependencies from the binary package's
Depends field? Normally debhelper finds the appropriate list from
python3:depends meta-dependency, using install_requires field of
setup.py.

## python-project-generator:

 1) I wonder why you removed the alternative entry point.
 2) Please remove all specific entries for the binary package Depends,
except python3-project-generator-definitions (<< 0.3.0):
python3:depends drags the others properly.

I'll upload as soon as this is done, as the package builds properly and
raises no lintian issue.

## valinor:

 1) You should ask upstream to provide a changelog, even though your
changelog.upstream.md is a perfectly fine temporary solution.
 2) Same about the Depends field of this package, keep gdb of course, as
no :depends entry will drag it.
 3) d/watch: could you use version=4 here or is there an issue?
 4) Is there a good reason for your export PYBUILD_AFTER_INSTALL=mv
{destdir}/usr/bin/valinor {destdir}/usr/share/valinor/run in d/rules
plus the link for /usr/bin?

Same as -project-generator, I'll upload as soon as you've answered these
questions. It builds perfectly otherwise.

## python-mbed-ls:

 1) Same as the others regarding the Depends field of the binary package.
 2) For the Doxygen patch, you removed the genlatex, I guess it's because
you don't want to drag texlive for the building part? I'm fine with
this.

I'll upload as soon as you've answered these questions.

## python-mbed-host-tests:

 1) Same as the others regarding the Depends field, prospectively keeping
the versioned dependencies

I'll upload as soon as you've answered these questions.

## mbed-test-wrapper:

 1) Still the same Depends question. :) keep binutils-arm-none-eabi, of
course.

I'll upload as soon as you've answered these questions.

## python-hgapi

 1) You should suggest your patches to upstream.

Uploaded.

## yotta

 1) Same old Depends field. You must keep valinor and mbed-test-wrapper at
least for now (I think that they'll be matched by the dh magic when
they'll be in the archive).
 2) I wonder why you added python3-openssl and python3-idna to the
dependencies, they seem not needed according to setup.py? If you need
them, please add them manualy to the Depends field as they won't be
dragged by the python3:depends variable. In that case maybe it would be
worth do att a README.source in the debian/ directory explaining why
these packages are needed. If upstream forgot to add these dependencies,
please notify them with a bug report.

Summary:

> >   -> yotta: x
> > -> python-hgapi: ./
> > -> mbed-test-wrapper: x
> >   -> python-mbed-host-tests: x
> > -> python-mbed-ls: x
> > -> valinor: x
> >   -> python-project-generator: x
> > -> python-project-generator-definitions: ./ (!)

The other packages will have to wait, I'd rather finish this batch first.

As my remarks are more like nitpicking, I'd like to insist on the quality of
your work. Those packages are really neat.

Thanks for your great work!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: RFS: mu-editor and yotta dependencies

[Pierre-Elliott Bécue]

Le samedi 29 décembre 2018 à 20:33:37+, Nick Morrott a écrit :
>   -> yotta
> -> python-hgapi
> -> mbed-test-wrapper
>   -> python-mbed-host-tests
> -> python-mbed-ls
> -> valinor
>   -> python-project-generator
> -> python-project-generator-definitions

Hi Nick!

Thanks for your work!

I'll start with these.

Mail to follow soon.

P.S.: I see you are uploader of many packages. Did you consider applying to
become DM/DD? (this question may be totally stupid, maybe you answered
somewhere, but I'm not really into stalking, so I'd rather get the answer
from you)

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: Shifting of gnukhata-core to Salsa and Sponsoring it

[Pierre-Elliott Bécue]

Hi, Praveen, Balanskar.

Le mercredi 03 octobre 2018 à 20:20:34+0530, Manas Kashyap a écrit :
> Hola Guys,
> I am Manas Kashyap , an active Debian contributor and i have recently worked
> and packaged gnukhata-core (https://gitlab.com/pkg-gnukhata/gnukhata-core) , 
> as
> its a python package , i would like someone to shift it to salsa of python 
> team
> and i would really be thankful if some DD sponsor this package. 
> Thank you 
> Manas Kashyap 
> http://wiki.debian.org/ManasKashyap

I have reviewed the work of Manas which is now on salsa[1], but before 
uploading it, as you're the
co-maintainers of gnukhata-core-engine in Debian[2], and as this package is
supposed to replace it, I'd like your explicit agreement with the upload of
Manas work, and the future removal of your package from unstable.

Thanks in advance.

[1] https://salsa.debian.org/python-team/modules/gnukhata-core/
[2] https://tracker.debian.org/pkg/gnukhata-core-engine

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: Best way to handle circular build deps to make a pypy- package

[Pierre-Elliott Bécue]

Le lundi 20 août 2018 à 16:20:54+0200, Thomas Goirand a écrit :
> On 08/15/2018 03:11 PM, Pierre-Elliott Bécue wrote:
> > Le mercredi 15 août 2018 à 13:10:39+0200, Samuel Thibault a écrit :
> >> Pierre-Elliott Bécue, le mer. 15 août 2018 13:05:09 +0200, a ecrit:
> >>>  2. What's the proper way to handle such packages?
> >>
> >> Build profiles? You can annotate the build-dep needed for check with
> >>  so that one can easily (re)bootstrap the circle at any time
> >> by using DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -Pnocheck
> > 
> > Thanks, I'll dig the wiki pages and try this!
> > 
> > Cheers!
> 
> Hi!
> 
> I have uploaded PBR 4.2.0-2 with lots of  in debian/control,
> which includes removing mock if such build profile is activated.
> 
> I hope this helps,
> Cheers,

Hi,

Thanks!

Unfortunately I'll have to look into some deps of pbr that are not yet
pypy-packaged. But I'll find my way.

I'll start to work on this between mid and late September.

Thanks again and cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: Best way to handle circular build deps to make a pypy- package

[Pierre-Elliott Bécue]

Le mercredi 15 août 2018 à 15:11:25+0200, Pierre-Elliott Bécue a écrit :
> Le mercredi 15 août 2018 à 13:10:39+0200, Samuel Thibault a écrit :
> > Pierre-Elliott Bécue, le mer. 15 août 2018 13:05:09 +0200, a ecrit:
> > >  2. What's the proper way to handle such packages?
> > 
> > Build profiles? You can annotate the build-dep needed for check with
> >  so that one can easily (re)bootstrap the circle at any time
> > by using DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -Pnocheck
> 
> Thanks, I'll dig the wiki pages and try this!
> 
> Cheers!

Hi,

So I found a way to build locally, using your suggestions. In my case I
guess I could upload directly the output of the nocheck build as the bin
package isn't altered.

But how should I handle the upload in the archive in a general case? Let's
imagine my profile produces a different bin package, eg if foo -> bar (for
specific foo functionalities) -> foo, so with a stage1 foo, then a stage1
bar and then a stage2 foo, how should I proceed? Do all the builds locally
and upload the packages obtained from the last build?

On the other hand, let's assume one wants to do a sourceful upload, and not
upload the .deb files (I know this is not possible when one introduces a new
package in the archive), then the buildd farm couldn't succeed because the
nocheck wouldn't be taken into account. So this means profile builds
systematically require source + binary upload?

Maybe some of these questions may seem dumb, but I'd rather ask them than
upload shit to the archive. ^^

Thanks. :)

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: Best way to handle circular build deps to make a pypy- package

[Pierre-Elliott Bécue]

Le mercredi 15 août 2018 à 13:10:39+0200, Samuel Thibault a écrit :
> Pierre-Elliott Bécue, le mer. 15 août 2018 13:05:09 +0200, a ecrit:
> >  2. What's the proper way to handle such packages?
> 
> Build profiles? You can annotate the build-dep needed for check with
>  so that one can easily (re)bootstrap the circle at any time
> by using DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -Pnocheck

Thanks, I'll dig the wiki pages and try this!

Cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Best way to handle circular build deps to make a pypy- package

[Pierre-Elliott Bécue]

Hi,

I was asked a long time ago to make a pypy package for nose2[1]. I realized
while considering this bug that I'd require to have a pypy package for mock
first. mock build-depends on unittest2 and pbr that are not pypy-packaged
either.

pbr is maintained in the OpenStack Team, but zigo is eager to help me should
I provide a sustainable MR. The thing is, pbr build-depends (indep) on
mock[3].

The way I see it, a solution is to:

 1. Build the pypy-pbr package without the testing phase (which seems to be
the part where mock is required), and upload it.
 2. Build the pypy-mock package and upload it.
 3. Rebuild the pypy-pbr package with the testing phase and upload it.

But that doesn't satisfy me, because I guess sometimes I couldn't use this
subterfuge to build the packages.

So I have two questions :

 1. Are there other packages with the same circular build-dep thing, and if
so, can someone provide me with examples?
 2. What's the proper way to handle such packages?

Thanks a lot!

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887933
[2] https://tracker.debian.org/media/packages/p/python-mock/control-2.0.0-3
[3] https://tracker.debian.org/media/packages/p/python-pbr/control-3.1.1-4

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: git-dpm -> gbp conversion (mass-change) [phase 1 DONE]

[Pierre-Elliott Bécue]

Le mercredi 15 août 2018 à 08:43:28+0200, Ondrej Novy a écrit :
> Hi,
> 
> st 15. 8. 2018 v 4:12 odesílatel Lars Kruse  napsal:
> 
> > What's up with the page? https://wiki.debian.org/Python/GitPackagingPQ
> 
> thankfully it was merged by Ondrej into
> https://wiki.debian.org/Python/GitPackaging.
> 
> 
> yes I merged it "back" to original page. If you know how to redirect
> GitPackagingPQ to original page, please go ahead.
> 
> Thanks.

Hi, Ondřej,

It's as easy as creating a new page at
https://wiki.debian.org/Python/GitPackagingPQ, and to put on the first line
the following code: "#redirect Python/GitPackaging" without the quotes.

It's done, now. :)

Cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: Request to join the PAPT

[Pierre-Elliott Bécue]

Le lundi 26 mars 2018 à 23:37:06+0200, Piotr Ożarowski a écrit :
> [Pierre-Elliott Bécue, 2018-03-18]
> > After hanging around a lot in DPMT, I'm currently packaging an app that
> > henceforth would definitely find its place into PAPT namespace on salsa.
> > 
> > I'll commit myself to follow the PAPT policy. :)
> > 
> > My salsa login is peb-guest
> 
> you're in, welcome :)

Thanks a lot!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: packages that use dh_python{2,3} but don't depend on dh-python

[Pierre-Elliott Bécue]

Le lundi 26 mars 2018 à 13:32:10+0200, Piotr Ożarowski a écrit :
> Hi,
> 
> Here's a list of packages that will FTBFS soon if dh-python will not be
> added to Build-Depends (it's time to drop dh-python from python3's
> Depends and old version of dh_python2 from python package).
> 
> http://people.debian.org/~piotr/dh_python3_without_dh-python.list
> http://people.debian.org/~piotr/dh_python3_without_dh-python.ddlist
> http://people.debian.org/~piotr/dh_python2_without_dh-python.list
> http://people.debian.org/~piotr/dh_python2_without_dh-python.ddlist
> 
> The plan is to report bugs first and follow up with changes in -defaults
> packages in April or May.

Thanks for making me remark that we forgot to add it to two of our mailman3
packages!

Cheers,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: Request to join the PAPT

[Pierre-Elliott Bécue]

Le dimanche 18 mars 2018 à 18:58:55+0100, Pierre-Elliott Bécue a écrit :
> Hi,
> 
> After hanging around a lot in DPMT, I'm currently packaging an app that
> henceforth would definitely find its place into PAPT namespace on salsa.
> 
> I'll commit myself to follow the PAPT policy. :)
> 
> My salsa login is peb-guest
> 
> Thanks and cheers!

Hey,

Small bump regarding my query. :)

Thanks!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: apt.Cache.update with alternative sources.list

[Pierre-Elliott Bécue]

Le mercredi 21 mars 2018 à 23:12:18+0100, Ole Streicher a écrit :
> Hi,
> 
> I need some access (as normal user) to an apt cache with an alternative
> sources.list (those in /etc/blends/ installed by blends-dev), but I have
> problems to find out how to use it.
> 
> I first tried to just specify the alternative source file:
> 
> ```
> >>> import apt
> >>> c = apt.Cache()
> >>> c.update('sources_list='/etc/blends/sources.list.testing')
> LockFailedException: Failed to lock /var/lib/apt/lists/lock
> ```
> 
> Then I tried to use an alternative root directory:
> 
> ```
> >>> import apt
> >>> c = apt.Cache(rootdir='/tmp/myapttmp')
> >>> c.update('sources_list='/etc/blends/sources.list.testing')
> FetchFailedException: W:GPG error: http://ftp.debian.org/debian testing 
> InRelease: The following signatures couldn't be verified because the public 
> key is not available: NO_PUBKEY 7638D0442B90D010, E:The repository 
> 'http://ftp.debian.org/debian testing InRelease' is not signed.
> ```
> 
> To which place in the new root directory do I need to copy the keyring?
> I tried <>/usr/share/keyrings/ but this didn't work.
> 
> And/or how can I disable authentication (--allow-unauthenticated,
> resp. APT::Get::AllowUnauthenticated)?

AFAIK, the apt trusted keyring is normally in /etc/apt/trusted.gpg +
/etc/apt/trusted.gpg.d

So, as long as you're sure the rootdir behaves as you think this should help
you to chose the appropriate place.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Request to join the PAPT

[Pierre-Elliott Bécue]

Hi,

After hanging around a lot in DPMT, I'm currently packaging an app that
henceforth would definitely find its place into PAPT namespace on salsa.

I'll commit myself to follow the PAPT policy. :)

My salsa login is peb-guest

Thanks and cheers!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#893414: ITP: flatlatex -- A LaTeX math converter to unicode text

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 

* Package name: flatlatex
  Version : 0.6
  Upstream Author : Jean-Benoist Leger 
* URL : https://gitlab.crans.org/leger/flatlatex
* License : BSD-2
  Programming Lang: Python3
  Description : A LaTeX math converter to unicode text

flatlatex is a basic converter from LaTeX math to human readable text
math using unicode characters. Some people tend to require such tool to
inline small equations in emails or on instant messaging clients, thus
avoiding unreadable garbage or to send a pdf link.

Although there are online solutions (I'll not make any advertisement so
far, you're free to look for them), a command-line local solution would
potentially be useful to one.

I'll maintain the package inside Python Apps Packaging Team.

Cheers,

-- 
PEB

Request to join DPMT

[Pierre-Elliott Bécue]

Hey,

I'm currently working on packaging mailman3 suite. The work was halted until
3.1 got out. Now that mailman3.1 is out, I'm back into business! But there
is one missing dependency that requires to be packaged: aiosmtpd.

I offered Barry Warsaw to package it, and he suggested me that I should do
it into DPMT, and push the git repo on git.debian.org. For now, it's on
github: https://github.com/P-EB/python-aiosmtpd which is not the best
solution.

I tend to agree, and I hereby ask if you could consider adding me to the DPM
project on alioth. I'm currently neither developer nor maintainer, but I
intend to work on this issue asap. :)

My alioth login is peb-guest.

I'm eager to provide more intel and answer potential questions.

Cheers!

-- 
PEB

Re: Bug#848416: RFS: pyvtk/0.5.18-1 [ITA]

[Pierre-Elliott Bécue]

Le mardi 27 décembre 2016 à 22:11:38+, Sean Whitton a écrit :
> Hello Pierre,
> 
> On Tue, Dec 27, 2016 at 06:04:58PM +0100, Pierre-Elliott Bécue wrote:
> > Le lundi 26 décembre 2016 à 20:38:42+, Sean Whitton a écrit :
> > > control: tag -1 +moreinfo
> > > 
> > > Dear Pierre,
> > > 
> > > Thank you for your interest in adopting this package.
> > > 
> > > Unfortunately, your work has not been properly integrated with what is
> > > already in Debian:
> > > 
> > > - you marked version 0.4.74-4 as released but it was never uploaded
> > 
> > True. Yet, it is in the team repo.
> 
> The changelog tracks the Debian archive.  You should merge the existing
> 0.4.74-4 changelog entry with your changes.

0.4.74-4 is not in the debian archive, only in the team repo. How should I
merge exactly?

> > 
> > Actually, it is included. The commit is just hidden in the history of the
> > team git repository for an unknown reason. See commit
> > 53434cf161a64ab9ac1578fec3613cce20ed451b and merge commit
> > 6fd4d560cf1f1f25a581a28a3c0a93ebd3159386. I added manually the changelog
> > that has been truncated in the merge.
> 
> Sorry, my fault, thanks for fixing up the changelog in your upload.

No worries, you're welcome. :)

> > > - your work is not pushed to the team git repository
> > 
> > I have no permission to push.
> 
> Have you asked to join the team?

I don't feel that I've done enough to get permissions, maybe my
interpretation is wrong.

-- 
PEB


signature.asc
Description: PGP signature

Re: Bug#848416: RFS: pyvtk/0.5.18-1 [ITA]

[Pierre-Elliott Bécue]

Le lundi 26 décembre 2016 à 20:38:42+, Sean Whitton a écrit :
> control: tag -1 +moreinfo
> 
> Dear Pierre,
> 
> Thank you for your interest in adopting this package.
> 
> Unfortunately, your work has not been properly integrated with what is
> already in Debian:
> 
> - you marked version 0.4.74-4 as released but it was never uploaded

True. Yet, it is in the team repo.

> - you haven't included the NMU 0.4.74-3.1

Actually, it is included. The commit is just hidden in the history of the
team git repository for an unknown reason. See commit
53434cf161a64ab9ac1578fec3613cce20ed451b and merge commit
6fd4d560cf1f1f25a581a28a3c0a93ebd3159386. I added manually the changelog
that has been truncated in the merge.

> - your work is not pushed to the team git repository

I have no permission to push.

-- 
PEB


signature.asc
Description: PGP signature

RFS: pyvtk/0.5.18-1 [ITA]

[Pierre-Elliott Bécue]

Package: sponsorship-requests
Severity: normal

Dear mentors,

This RFS is linked to an ITA. See bug #795017
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795017) for more
information regarding this package.

I am looking for a sponsor for my package "pyvtk"

 * Package name: pyvtk
   Version : 0.5.18-1
   Upstream Author : Pearu Peterson <pearu.peter...@gmail.com>
 * URL : https://github.com/pearu/pyvtk
 * License : BSD-3-Clause
   Section : python

It builds those binary packages:

 * python-pyvtk - Module for manipulating VTK files
 * python3-pyvtk - Module for manipulating VTK files - Python3 library

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

https://mentors.debian.net/package/pyvtk

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

  dget -x https://mentors.debian.net/debian/pool/main/p/pyvtk/pyvtk_0.5.18-1.dsc

Changes since the last upload (extracted from NEWS.txt written by the author of
the library):

 * Added Python 3 support (thanks to Thomas Kluyver).
 * Maintain the package (thanks to Thomas Kluyver and David Froger).
 * Development is moved under Github.

Regards,

-- 
Pierre-Elliott Bécue

Re: Bug#799287: Packaging dependencies for mailman3-hyperkitty

[Pierre-Elliott Bécue]

Le 26 mars 2016 04:57:34 GMT+01:00, Paul Wise <p...@debian.org> a écrit :
>On Fri, 2016-03-25 at 19:35 +0100, Pierre-Elliott Bécue wrote:
>
>> That's in progress, the only goal of this detection is to deactivate
>> javascript dynamic load of threads. We're thinking about alternative
>> solutions.
>
>I don't understand why you would deactivate JavaScript dynamic load for
>bots? Typically they don't support JavaScript (except Google) and you
>should have a fallback for people who turn off JavaScript anyway.
>
>I hope mailman3/HyperKitty web interfaces use progressive enhancement:
>
>http://en.wikipedia.org/wiki/Progressive_enhancement
>
>> I understand your point, and I'll think about it, but my goal is to
>make
>> upstream remove obsolete dependencies. django-libravatar seems to be
>the
>> only project that bundles support for that, and it's not maintained,
>whereas
>> django-gravatar2 is still maintained.
>
>I guess you are talking about this project, it hasn't seen any issues
>filed so probably just works as-is without needing any changes?
>
>https://github.com/fnp/django-libravatar
>
>> So, for now, I think that I'd rather have a first mailman3 suite in
>debian,
>> and then, think about how to make things better. :)
>
>I see.
>
>-- 
>bye,
>pabs
>
>https://wiki.debian.org/PaulWise

Can't tell exactly regarding javascript question. Sorry.

But I'll forward your comments, thanks for taking the time to make them. :)
-- 
PEB

Re: Packaging dependencies for mailman3-hyperkitty

[Pierre-Elliott Bécue]

Le vendredi 25 mars 2016 à 13:02:55+0800, Paul Wise a écrit :
> On Thu, Mar 24, 2016 at 11:43 PM, Pierre-Elliott Bécue wrote:
> 
> > Packaging dependencies for mailman3-hyperkitty
> 
> Does HyperKitty depend on mailman3 or just enhance it by providing an
> archive web interface? If the latter, I would suggest calling it
> hyperkitty instead of mailman3-hyperkitty.
> 
> > robot-detection suffers the same illness, but it's tiny, it's possible to
> > integrate it in hyperkitty, or make it optionnal.
> 
> Embedded code copies are against Debian policy, please package it
> separately or get upstream to switch to something else.
> 
> https://wiki.debian.org/EmbeddedCodeCopies
> 
> Something like that sounds like it isn't possible to keep usefully
> up-to-date in Debian stable though, since the landscape of robots on
> the web will be changing continually and many will be aiming to
> emulate browsers.
> 
> https://pypi.python.org/pypi/robot-detection
> 
> In addition, it seems to be woefully inadequate for that since the API
> doesn't appear to take into account IP address ranges.
> 
> It also depends on the robotstxt.org database, which would need to be
> packaged separately and is also no longer kept up to date at this
> time:
> 
> http://www.robotstxt.org/db.html
> 
> "This robots database is currently undergoing re-engineering. Due to
> popular demand we have restored the existing data, but
> addition/modification are disabled."
> 
> As the page says, there is a better database of user-agents available
> 
> http://www.botsvsbrowsers.com/
> http://www.botsvsbrowsers.com/category/1/index.html
> 
> Unfortunately this is incompatible with the data format used by
> robotstxt.org/robot-detection:
> 
> http://www.robotstxt.org/db/all.txt
> 
> So you can see from the botsvsbrowsers.com data, the User-Agent field
> is often bogus or contains vulnerability attack patterns and is thus
> mostly not useful at all and should probably just be ignored by all
> web apps at this point.
> 
> So I would suggest convincing upstream to remove whatever use of
> robot-detection is present in mailman3 or hyperkitty.

That's in progress, the only goal of this detection is to deactivate
javascript dynamic load of threads. We're thinking about alternative
solutions.

> > That leaves me with django-gravatar2, that seems useful, and is still
> > developed. I heard there is some kind of "canonical" way of packaging django
> > apps. As I'm not used to that, I'm here to ask advice.
> 
> I would suggest upstream switch from Gravatar (a centralised
> proprietary service) to Libravatar (a federated Free Software service
> that falls back on Gravatar):
> 
> https://www.libravatar.org/

I understand your point, and I'll think about it, but my goal is to make
upstream remove obsolete dependencies. django-libravatar seems to be the
only project that bundles support for that, and it's not maintained, whereas
django-gravatar2 is still maintained.

So, for now, I think that I'd rather have a first mailman3 suite in debian,
and then, think about how to make things better. :)

> Re canonical django packaging, you may be talking about this:
> 
> https://wiki.debian.org/DjangoPackagingDraft
> 
> There are also lots of python-django-* packages in Debian that you
> could look at.

Thanks!

-- 
PEB

Re: Bug#819183: ITP: python-django-gravatar2 -- Essential Gravatar support for Django. Features helper methods and templatetags.

[Pierre-Elliott Bécue]

Le jeudi 24 mars 2016 à 12:09:00-0400, Pierre-Elliott Bécue a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: "Pierre-Elliott Bécue" <be...@crans.org>
> 
> * Package name: python-django-gravatar2
>   Version : 1.4.0
>   Upstream Author : Tristan Waddington
> * URL : https://github.com/twaddington/django-gravatar
> * License : MIT
>   Programming Lang: Python
>   Description : Essential Gravatar support for Django. Features helper 
> methods and templatetags.
> 
> A lightweight django-gravatar app. Includes helper methods for interacting 
> with gravatars
> outside of template code.
> .
> It features the following:
> .
>  * Helper methods for constructing a gravatar url and checking an email for 
> an existing
>gravatar
>  * Templatetags for generating a gravatar url or gravatar  tag.
> 
> This package provides gravatar features that are not yet present in django
> packages in Debian. It's also a dependency of HyperKitty, that I'm currently
> packaging.
> 
> I'd be happy to co maintain it with the DPMT, and I look for a sponsor who
> knows about django packaging.

Package VCS can be found here:

https://gitlab.pimeys.fr/PEB/python-django-gravatar2

Package results can be found there:

https://peb.pimeys.fr/packages/python-django-gravatar2/

-- 
PEB

Bug#819183: ITP: python-django-gravatar2 -- Essential Gravatar support for Django. Features helper methods and templatetags.

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: "Pierre-Elliott Bécue" <be...@crans.org>

* Package name: python-django-gravatar2
  Version : 1.4.0
  Upstream Author : Tristan Waddington
* URL : https://github.com/twaddington/django-gravatar
* License : MIT
  Programming Lang: Python
  Description : Essential Gravatar support for Django. Features helper 
methods and templatetags.

A lightweight django-gravatar app. Includes helper methods for interacting with 
gravatars
outside of template code.
.
It features the following:
.
 * Helper methods for constructing a gravatar url and checking an email for an 
existing
   gravatar
 * Templatetags for generating a gravatar url or gravatar  tag.

This package provides gravatar features that are not yet present in django
packages in Debian. It's also a dependency of HyperKitty, that I'm currently
packaging.

I'd be happy to co maintain it with the DPMT, and I look for a sponsor who
knows about django packaging.

Packaging dependencies for mailman3-hyperkitty

[Pierre-Elliott Bécue]

Hey,

I'm packaging mailman3 suite, and I'm currently working on HyperKitty (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799287 for the ITP).

The issue I met is that some dependencies are not yet packaged in Debian.

Here is a list :

 * robot-detection
 * django-paintstore
 * django-gravatar2
 * django-browserid

The latter relies on Mozilla Persona which is due to shutdown in Nov. 2016,
so I'll drop it out and suggest upstream to remove this (small) dependency.
django-paintstore is not developped nor supported anymore by upstream, I'll
try to look to alternatives and discuss with upstream regarding what to do.

robot-detection suffers the same illness, but it's tiny, it's possible to
integrate it in hyperkitty, or make it optionnal.

That leaves me with django-gravatar2, that seems useful, and is still
developed. I heard there is some kind of "canonical" way of packaging django
apps. As I'm not used to that, I'm here to ask advice.

I'll create an ITP, and I'm willing to hear any suggestion you could make.

Thanks, and cheers,

-- 
PEB

Re: I've been removed from the Python team

[Pierre-Elliott Bécue]

On jeu. 01 oct. 2015 à 18:48:08, Scott Kitterman wrote:
> On Thursday, October 01, 2015 02:11:29 PM Barry Warsaw wrote:
> > On Oct 01, 2015, at 07:47 PM, Vincent Bernat wrote:
> > >I am a bit worried that the team is handled behind closed walls.
> > 
> > I have no particular interest in either grabbing power nor in taking power
> > away from anybody, but I think there may be some value in making team
> > governance more transparent and democratic.  Two reasons come to mind:
> > 
> > No one person has to take the heat for uncomfortable decisions.  At some
> > point decisions have to be made for the good of the team, whether they're
> > technical or social.  What might be difficult for one person to decide can
> > be made easier when the burden of that decision can be shared among duly
> > elected representatives.
> > 
> > Team members can have more of a say --and more confidence in-- how the team
> > is run.  If you elect someone to a leadership role, you're giving your
> > support to them to make the tough decisions.  And you have the option of
> > voting them out at the next election.
> > 
> > I don't think any of that's controversial, given that the Debian project
> > itself is both transparent and democratic, and we always have those
> > governance rules to fall back on.  But that's a pretty heavyweight
> > bureaucracy.
> > 
> > Does it make sense to have some lightweight rules for the team?  Is there
> > precedence within other Debian teams?
> 
> I've been a team member since, I think, 2008.  This is the first time we've 
> had 
> anything like this come up that I recall.  I don't think we have a problem 
> with team members not having enough say as a general rule.
> 
> For the git migration, the people taking the time to do the work or pay 
> attention to the work and provide feedback are driving what happens when.  
> There's nothing that being a team administrator has to do with it.
> 
> With the exception of the DPL, Debian is not democratic.  It's doacratic.  
> Let's not mess with that.

I frankly disagree. GR is another example of democratic process in Debian.

Yes, do-it-o-craty is good, at some point, but this is exactly what brought
Thomas out. So nope, it's not enough.

I'm not a team member, but I think any team has to get some democratic
process inside it if you want it to be fair and efficient, even in hard
situations.

Cheers.

-- 
PEB


signature.asc
Description: Digital signature

Re: I've been removed from the Python team

[Pierre-Elliott Bécue]

On sam. 03 oct. 2015 à 16:15:53, Piotr Ożarowski wrote:
> [Pierre-Elliott Bécue, 2015-10-03]
> > Yes, do-it-o-craty is good, at some point, but this is exactly what brought
> > Thomas out. So nope, it's not enough.
> 
> and if I didn't do it, it would be better because...
> It's easy to point fingers if it's not you who cleans after each mess.

You didn't get my point. As previously said, I heard and understood your
answer, I'm not trying to going back on what I said. But this new argument
about doitocraty VS. democracy is something interesting to discuss about.

I was meaning that Thomas probably acted as a doitocraty recommends to, and
that's what led to this situation, with him out of the team.

I beleive there is a need to create some democratic processes in a team,
that's all.

> /me (AKA dictator who'd love to give all his powers to someone else) who
> still stands by his decision and would do it again.
> The only regret is that I didn't do it a year ago.

I'm not able to judge on this, as I'm not aware of all the stories, neither
do I have enough experience.

-- 
PEB

Re: I've been removed from the Python team

[Pierre-Elliott Bécue]

On jeu. 01 oct. 2015 à 08:09:51, Piotr Ożarowski wrote:
> [Pierre-Elliott Bécue, 2015-10-01]
> > Even if I'm not in the team and thus I do not decide of anything, I
> > wonder if that's an appropriate answer, regarding the initial trouble.
> > 
> > We are currently talking about preventing Thomas to maintain his
> > packages that has DPMT as maintainer, because he uploaded something in
> 
> which packages? All of them are in OpenStack team and few that list
> Thomas as co-maintainer have other maintainers who can commit changes.
> 
> > experimental, which is neither a release, nor a distro of any kind.
> 
> I would not remove someone due to technical mistake (or several made not
> on purpose) - that's not the case here. I did that because I see no hope
> in change of behaviour (and I was warned about it from day one and I *did*
> try to change it several times).
> 
> There's something good that comes out of it, though:
> I was afraid to accept new members after two that caused more harm than
> good and now I have solution to that problem: everyone who wants to be
> in the team, automatically is! Yes, from now on we will not (or at least
> I will not) stop you from contributing if you don't have write access.
> No more "you cannot contribute, stay away, do not send patches" policy!
> Every new member can now send commits to me and I will push them to the
> repo (both svn/git and unstable). If you want write access, just bombard
> me with commits to review (the same way my sponsorees force me to ask
> them to join NM queue - just send contribution and learn from problems I
> pointed out). Thomas is the first person I asked to do that.

Thanks for your answer, I hope all this will go well.

Ack for the last part, but I'll have to finish my packages and become
maint/dev before I can do all of this.

Cheers,

-- 
PEB


signature.asc
Description: Digital signature

Re: I've been removed from the Python team

[Pierre-Elliott Bécue]

On mer. 30 sept. 2015 à 23:13:26, Piotr Ożarowski wrote:
> [Thomas Goirand, 2015-09-30]
> > Piotr decided to remove me from the Python team.
> 
> DPMT and PAPT to be precise, yes
> 
> > is an over reaction and that it should be reverted.
> 
> I talked with you many times in private about your involvement in the
> teams over last ~3 years and since I kind of forced other admins into
> accepting you, I also take all the blame for removing you.
> As I said in the private mail earlier today, if you still want to work
> with me, I'm happy to review / sponsor your commits in DPMT or help with
> any problems you might have with tools I wrote.

Dear Piotr,

Even if I'm not in the team and thus I do not decide of anything, I
wonder if that's an appropriate answer, regarding the initial trouble.

We are currently talking about preventing Thomas to maintain his
packages that has DPMT as maintainer, because he uploaded something in
experimental, which is neither a release, nor a distro of any kind.

Considering the potential trouble it'll lead to (as for an example it'll
probably send my attempt to package mailman3 to nowhere), and the
potential bad consequences for python team (some packages no longer
maintained, etc), does it worth it?

-- 
PEB


signature.asc
Description: Digital signature

Re: I've been removed from the Python team

[Pierre-Elliott Bécue]

Le 1 octobre 2015 00:25:55 GMT+02:00, Ian Cordasco <graffatcolmin...@gmail.com> 
a écrit :
>On Wed, Sep 30, 2015 at 5:04 PM, Pierre-Elliott Bécue <be...@crans.org>
>wrote:
>> On mer. 30 sept. 2015 à 23:13:26, Piotr Ożarowski wrote:
>>> [Thomas Goirand, 2015-09-30]
>>> > Piotr decided to remove me from the Python team.
>>>
>>> DPMT and PAPT to be precise, yes
>>>
>>> > is an over reaction and that it should be reverted.
>>>
>>> I talked with you many times in private about your involvement in
>the
>>> teams over last ~3 years and since I kind of forced other admins
>into
>>> accepting you, I also take all the blame for removing you.
>>> As I said in the private mail earlier today, if you still want to
>work
>>> with me, I'm happy to review / sponsor your commits in DPMT or help
>with
>>> any problems you might have with tools I wrote.
>>
>> Dear Piotr,
>>
>> Even if I'm not in the team and thus I do not decide of anything, I
>> wonder if that's an appropriate answer, regarding the initial
>trouble.
>>
>> We are currently talking about preventing Thomas to maintain his
>> packages that has DPMT as maintainer, because he uploaded something
>in
>> experimental, which is neither a release, nor a distro of any kind.
>>
>> Considering the potential trouble it'll lead to (as for an example
>it'll
>> probably send my attempt to package mailman3 to nowhere), and the
>> potential bad consequences for python team (some packages no longer
>> maintained, etc), does it worth it?
>>
>> --
>> PEB
>
>Pierre,
>
>I'm new to the team, mailing list, etc. (honestly, I never had a
>chance to formally introduce myself to everyone) but it looks as if
>Piotr has had several instances in the past where he's had to
>discipline Thomas. I doubt this is an action that Piotr took lightly.
>Further, I doubt those packages will suddenly go unmaintained.
>
>Please continue working on mailman3, it will benefit the community far
>more than the outcome of this apparent disciplinary action.
>
>Cheers,
>Ian

Dear Ian,

I do not intend to stop working on it, but even if it is not the first time (I 
hope no one would take such an action for one isolated mistake), I strongly 
beleive that such removal from a team where mostly anyone is supposed to be at 
a same level should be calmly discussed and debated with mostly everybody of 
the team in order to reach a consensus.

This decision looks like something decided just after an aggressive discussion 
about something which does not look that bad from where I sit.

Wouldn't taking some time to think before this removal had been a better idea 
for everybody?

Peace, love and cheers.
-- 
PEB

About OpenStack, Mailman3 and python-falcon update

[Pierre-Elliott Bécue]

Good evening,

I was suggested to start a thread here, even having already filled a
bugreport.

I'm currently trying to package mailman3 suite, I started with mailman3 core
functionnalities, you can see the ITP here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799281

But, mailman3-core would depend on falcon version >= 0.3.0rc1 which is not
yet packaged in Debian.

I filled a bug report here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799321

Thomas Goirand (zigo) answered to me something I perfectly understand, that
for now, zaqar, which is part of the python stuff used in OpenStack, depends
on falcon < 0.2.0, and thus can no longer be packaged in debian if we update
python-falcon.

It seems he has contacted zaqar developers in hope to have them test zaqar
with falcon 0.3, and, if needed, patch it.

I'm opening this thread to discuss about this, and possible solutions to
this deadend, as I can no longer test anything nor continue packaging mm3. I
could try to package my own python-falcon in my custom repo to see if my
mailman3-core packaging works, but it could not go in Debian's repo anyway.

As I'm a beginner, I certainly need some wisdom from people on
debian-python@

Thanks for the time anyone will give to me, and apologies to bother.

-- 
PEB