Re: DebConf22 -- Python Team BoF + Sprint?

2022-03-28 Thread Louis-Philippe Véronneau
On 2022-03-26 18 h 02, Stefano Rivera wrote:
> Hi Louis-Philippe (2022.03.20_21:51:45_+)
>> I think it would also be neat to have a team sprint during DebCamp. Here
>> are a few ideas of things we could work on:
>>
>> * pybuild improvements (getting the autopkgtest MR in would be great)
>> * general team QA (maybe based on [2]?)
>> * lintian tags used for the team
> 
> +1 to a sprint, as usual.
> 
> I think upstream cpython would also appreciate it if we did a pass
> through all of our cpython patches and ensured they were forwarded. Ping
> bugs, etc. Same goes for any core libraries / big packages.
> I've attempted to document them all, this year, which is a start. But
> only a start. In many cases forwarding the patch would require clearly
> defining the bug, writing reproducer scripts, etc.
> 
> I'd happily mentor people in working on this.

I've just submitted the sprint too, the description links to:

https://wiki.debian.org/DebConf/22/Sprints

Which links to:

https://pad.riseup.net/p/dc22pythonsprint-keep

Please add relevant goals there :)


-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



DebConf22 -- Python Team BoF + Sprint?

2022-03-20 Thread Louis-Philippe Véronneau
Hello team!

The DebConf22 content team has issued a call for papers [1]. As I'm
planning to be there this year, I'd be happy to send a proposal for our
annual BoF :)

I think it would also be neat to have a team sprint during DebCamp. Here
are a few ideas of things we could work on:

* pybuild improvements (getting the autopkgtest MR in would be great)
* general team QA (maybe based on [2]?)
* lintian tags used for the team

I don't think any of this is controversial, but I'll give y'all a few
days to reply before submitting the talks :)

[1]: https://debconf22.debconf.org/cfp/
[2]: https://github.com/sandrotosi/dpt-repos-check/blob/main/violations.txt

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



Re: Should we allow Janitor to commit directly to all DPT packages?

2022-02-17 Thread Louis-Philippe Véronneau
On 2022-02-17 12 h 39, Sandro Tosi wrote:
> Hello all,
> the question is essentially all in the subject line, and my answer is yes.
> 
> I receive notifications for all MRs opened against DPT packages, and
> Janitor's are always pretty much ready to merge as is, and so i think
> we should let Janitor commit directly to the team packages.
> 
> Jelmer is in CC (not sure if he's subscribed), in case he wants to
> chime in on the implication of this discussion.
> 
> Regards,

You sent a mail on the list on 2020-07-27 about this and the general
consensus (3-4 replies) was that it was a good idea.

Anyway, I also vote yes!

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



Re: Moving deepdiff to the Python Team? (and maybe taking over)

2022-01-29 Thread Louis-Philippe Véronneau
CleverCSV and ordered-set went through NEW 2 days ago, so I tweaked what
Andreas had done and uploaded the latest upstream version of deepdiff to
unstable.

I had a look at the upstream docs, but it seems nothing builds a clean
man page. Clearly something that could be improved :)

Note that I also moved the default branch from `master` to
`debian/master` on Salsa, per the team's policy.

Cheers,

PS: I'm not planning on maintaining this package btw, this really was a
one-off. New versions should be easy to update, since all the deps are
now in Sid :)

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Re: Cleaning up the Salsa DPT landing page

2022-01-17 Thread Louis-Philippe Véronneau
On 2022-01-17 12 h 31, Scott Kitterman wrote:
> On Monday, January 17, 2022 12:20:59 PM EST Louis-Philippe Véronneau wrote:
>> Hey folks,
>>
>> The merger between the DPMT and the PAPT into a single entity has been
>> pretty successful IMO and I think it's time to cleanup the Salsa DPT
>> landing page.
>>
>> Looking at https://salsa.debian.org/python-team, I would propose the
>> following:
>>
>> 1. Delete the empty DPMT sub-group at
>> https://salsa.debian.org/python-team/modules
>>
>> 2. Delete the empty PAPT sub-group at
>> https://salsa.debian.org/python-team/applications
> 
> I don't have an opinion on #3 and #4.

I mostly care about #3 in #4 :P

> Might it be better to leave these with a description that explains where they 
> went?  There's lots of things that refer to DPMT/PAPT and I don't think all 
> the packages have been uploaded with the correct Vcs-* data yet.  It doesn't 
> hurt to leave them there and if they explain where to look instead, I think 
> the chances of someone being confused later are reduced.

The following lintian tags flag packages using the old Vcs-* data:

https://lintian.debian.org/tags/old-papt-vcs (11 packages)
https://lintian.debian.org/tags/old-dpmt-vcs (431 packages)

Those packages have been fixed in git though, as Ondřej ran a script to
fix all of them a while ago already.

Someone correct me if I'm wrong, but I don't think keeping empty dirs
does anything to the Salsa redirects though.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian

2022-01-17 Thread Louis-Philippe Véronneau
Hey folks,

I'm following up on bug #1001677 [1] on the DPT's list to try to reach
consensus, as I think the Lintian tags that were created to fix this bug
are not recommending the proper thing.

As a TL;DR for those of you who don't want to read the whole BTS thread,
jdg saw that a bunch of packages were using `py3versions -r` in
autopkgtests, and this fails when there's no X-Python3-Version variable
in d/control.

The fix that Lintian now proposes for packages that use `py3versions -r`
in autopkgtests is to set X-Python3-Version.

I think the proper fix would be to ask people to move away from
`py3versions -r` if there is no X-Python3-Version, and use`py3versions
-s` instead.

As such, I think we should ask the Lintian maintainers to:

1. Change the desc for tag declare-requested-python-versions-for-test to

The specified test attempts to query the Python versions
requested by your sources with the command py3versions
--requested but your sources do not actually declare those
versions with the field X-Python3-Version.
.
Please query all supported Python versions with the command
py3versions --supported in your test instead.

2. Change the desc for tag query-requested-python-versions-in-test to

The specified test queries all supported Python versions with
the command py3versions --supported but your sources
request a specific set of versions via the field
X-Python3-Version.
.
Please delete the field X-Python3-Version, as it is not needed.


These changes would push maintainers to use `py3versions -s`, but
wouldn't ask people using `py3versions -r` and X-Python3-Version to make
any changes.

AFAIU, the only valid use of X-Python3-Version would be a package that
fails to build on an older but currently supported version of Python
(let's say 3.9) but builds on the newer version (say 3.10). I think such
use cases are pretty rare though.

Cheers,

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001677

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Cleaning up the Salsa DPT landing page

2022-01-17 Thread Louis-Philippe Véronneau
Hey folks,

The merger between the DPMT and the PAPT into a single entity has been
pretty successful IMO and I think it's time to cleanup the Salsa DPT
landing page.

Looking at https://salsa.debian.org/python-team, I would propose the
following:

1. Delete the empty DPMT sub-group at
https://salsa.debian.org/python-team/modules

2. Delete the empty PAPT sub-group at
https://salsa.debian.org/python-team/applications

3. In the 'tools' sub-group, rename the 'python-modules' sub-sub-group
to 'policy' and delete everything that is not the 'policy.rst' file, as
people now use the 'packages' sub-sub-group for tracking purposes
https://salsa.debian.org/python-team/tools/python-modules

4. Delete the legacy 'python-apps' sub-sub-group
https://salsa.debian.org/python-team/tools/python-apps

Happy to hear what others think of this. I don't have the permissions to
enact this anyway, so if we reach consensus, and admin will have to make
the actual changes :)

Cheers,

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


ponyorm v0.7.15rc1, python3.10 and github releases

2022-01-10 Thread Louis-Philippe Véronneau
Hello!

Upstream ponyorm released v0.7.15rc1, which adds python3.10 support and
thus fixes #1000716. I ran a quick sbuild and the testsuite passes and
everything seems good.

Since it is team maintained, I'd have updated the package in unstable,
but the latest pypi tarball changes the default carriage return, and
creates a huge diff on the upstream branch. This causes some patches to
fail to apply, etc.

Would you mind if I migrated ponyorm to the github releases, using
uscan's git mode? I've made a quick test and it does solves this issue :)

Asking, since I'd be pretty upset if someone were to do the opposite on
a package I team maintain :P

Cheers,

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Re: DPT repositories checks/"violations" report

2022-01-03 Thread Louis-Philippe Véronneau
On 2022-01-03 01 h 30, Scott Kitterman wrote:
> Since this is all about team Git repositories, someone should just fix them 
> (modulo the one about using pypi, which I think we mostly agree isn't 
> something someone unfamiliar with the package can 'fix').
But that doesn't prevent future errors from popping up and doesn't make
maintainers aware of their errors (so they can learn from it).

I think the "perfect" solution would be to have an automated tool (aka
janitor) fixing these automatically, but this would require more work.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Re: DPT repositories checks/"violations" report

2022-01-02 Thread Louis-Philippe Véronneau
On 2021-12-12 01 h 23, Sandro Tosi wrote:
>> I think there's still one point we need to figure out: how to make
>> these remarks known to the packages maintainers, instead of all of
>> them just being in a text file.
> 
> This is still an open point, and i welcome ideas

Is there a reason why we shouldn't just file bugs in the BTS? I get it's
not the perfect tool for that, but it would certainly help reach the
maintainers.

Using a common usertag would also make it easier to find and fix these
issues en masse ;)

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Re: Moving deepdiff to the Python Team? (and maybe taking over)

2021-12-27 Thread Louis-Philippe Véronneau
On 2021-12-25 08 h 01, Andreas Tille wrote:
> Am Fri, Dec 24, 2021 at 11:49:49PM +0100 schrieb Michael Banck:
>> AFAICT, the newer deepdiff requires the following unpackaged modules:
>>
>> https://github.com/rspeer/ordered-set

I've just uploaded this one to NEW, it's packaged at:

https://salsa.debian.org/python-team/packages/python-ordered-set

>> https://github.com/alan-turing-institute/CleverCSV

Were you planning to work on this one? I _could_ package it myself, but
it depends on pandas and so far I've successfully avoided maintaining
packages that touch it :)

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Re: Moving deepdiff to the Python Team? (and maybe taking over)

2021-12-23 Thread Louis-Philippe Véronneau
On 2021-12-23 06 h 16, Michael Banck wrote:
> I'm not in
> https://salsa.debian.org/groups/python-team/packages/-/group_members
> AFAICT so either you will have to remove me as maintainer or add me to
> that group I guess.

Here's how you can join the team:

https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst#joining-the-team

If you do not wish to join the team, I can also remove you as uploader
and add myself instead.

Cheers, and thanks a lot Andreas!

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Moving deepdiff to the Python Team? (and maybe taking over)

2021-12-22 Thread Louis-Philippe Véronneau
Hi!

One of the packages I maintain is currently broken by BTS 1001292 [1]
and it seems deepdiff is in need of some love.

Would you be open to moving it to the Python Team? I'd be more than
happy to update it to the latest upstream version (seems like it would
fix the bug in question). It doesn't seem like there's a VCS though, so
that might require some work on your side.

If you want, I'd also be happy to take over and maintain it in the
Python Team myself.

Happy holidays!

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001292

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Review of python-bonsai

2021-12-13 Thread Louis-Philippe Véronneau
Hi!

Here's my review of python-bonsai:

1. d/control:

* You don't need the "(>= 3.6)" restriction for python3-all-dev, as that
version isn't even in oldstable.

* sphinx-common isn't needed for the source package, as python3-sphinx
depends on it

* "python3 (>= 3.6)" is not required for python3-bonsai,
${python3:Depends} should take care of that for you.

* IMO, python3-bonsai should recommend or suggest python3-bonsai-doc,
but that's up to you.

-

2. d/copyright:

* you forgot to add a debian/* section. AFAIU, noirello isn't the one
who wrote d/rules :)

* .appveyor/run_with_env.cmd is licensed CC0. You probably don't need
those files, so you can exclude them from the source package using
Files-Excluded in d/copyright

* the MIT license in Debian is named "Expat", for historical reasons.

-

4. d/rules:

* You left "export DH_VERBOSE = 1" uncommented.

* I'm curious to why you need to set "export LC_ALL = C.UTF-8".

-

5. d/tests:

I don't have an autopkgtests setup that has machine-level isolation. You
ran that code and it works?

-

6. d/watch:

You left "" in there instead of replacing it by the actual
project's name (have a look at Lintian) :) Note you can use the "git
tag" mode to simplify this file (not that it's required, your file works
as-is): [1]

-

7. Upstream code

Have you read the upstream code? It's something you should do (and you
should read all the changes for each new update). Not that you have to
do a proper security audit, but you should go through the code to be
sure there's no obvious or dangerous things in there.

Otherwise, good job! Fix those, ping me and if it's OK, I'll read the
upstream code myself and sponsor it.

Cheers,

[1]:
https://salsa.debian.org/python-team/packages/python-mediafile/-/blob/debian/master/debian/watch


-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



Re: grammalecte sponsorship (was: Re: Fwd: grammalecte_2.1.2+ds-1_amd64.changes REJECTED)

2021-12-02 Thread Louis-Philippe Véronneau
On 2021-12-01 15 h 19, Romain Porte wrote:
> Hi,
> 
> 27/11/2021 19:32, Louis-Philippe Véronneau :
>> Sorry for being so slow to sponsor.
>>
>> While trying to build, I get this error:
>>
>> mv: will not overwrite just-created
>> 'debian/tmp/usr/share/doc/python3-grammalecte/README.txt' with
>> 'debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt'
>>
>> This happens because you are trying to move multiple files to the same
>> path:
>>
>> debian/tmp/usr/lib/python3.10/dist-packages/grammalecte/README.txt
>> debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt
>>
>> -> debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt
>>
>> I'd suggest singling out one python interpreter with `py3versions -d`?
> 
> Fixed by this commit:
> https://salsa.debian.org/python-team/packages/grammalecte/-/commit/20e2d458b360c81d929d3d8cab7db64ca21e0d0a
> 
> 
> New version available on salsa or on sponsors at your convenience:
> 
> https://mentors.debian.net/debian/pool/main/g/grammalecte/grammalecte_2.1.2+ds-1.dsc
> 
> 
> Bests
> 

Uploaded to NEW!

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Re: Installing data files with pybuild

2021-12-01 Thread Louis-Philippe Véronneau
On 2021-12-01 12 h 28, Andrey Rahmatullin wrote:
> 
>> Only the .py files are currently included in the build; what is the
>> best way to include all of the data files after the build step and
>> before the test step, and then to ensure they are included in the
>> final package?
> Apart from fixing setup.py? execute_after_dh_auto_install I guess.

Or you can use debian/foobar.install to install the missing files in the
right location, and keep your d/rules file cleaner :)

ex. (man dh_install):

https://sources.debian.org/src/sublime-music/0.11.16-1/debian/sublime-music.install/

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Re: Fwd: grammalecte_2.1.2+ds-1_amd64.changes REJECTED

2021-11-27 Thread Louis-Philippe Véronneau
On 2021-11-08 14 h 00, Romain Porte wrote:
> Hello,
> 
> 06/11/2021 18:18, Louis-Philippe Véronneau :
>> Hello!
>>
>> Grammalecte was rejected. It would be nice if you could fix the issue
>> mentioned below :)
> 
> Please have a look at https://mentors.debian.net/package/grammalecte/
> 
> DSC file:
> https://mentors.debian.net/debian/pool/main/g/grammalecte/grammalecte_2.1.2+ds-1.dsc
> 
> 
> Commits since last upload:
> 
> * 534d918 (HEAD -> debian/latest, origin/debian/latest) d/changelog: update
> * a9a6817 fix missing autopkgtest dep
> * 3f684d0 fix d/copyright REJECT
> * 1f38706 fix d/watch
> * e6d7849 introduce d/salsa-ci.yml
> 
> Salsa repo: https://salsa.debian.org/python-team/packages/grammalecte
> 
> Thanks.
> 

Sorry for being so slow to sponsor.

While trying to build, I get this error:

mv: will not overwrite just-created
'debian/tmp/usr/share/doc/python3-grammalecte/README.txt' with
'debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt'

This happens because you are trying to move multiple files to the same path:

debian/tmp/usr/lib/python3.10/dist-packages/grammalecte/README.txt
debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt

-> debian/tmp/usr/lib/python3.9/dist-packages/grammalecte/README.txt

I'd suggest singling out one python interpreter with `py3versions -d`?

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Re: DPT repositories checks/"violations" report

2021-11-27 Thread Louis-Philippe Véronneau
On 2021-11-27 08 h 54, Stefano Rivera wrote:
> Hi Sandro (2021.11.27_06:01:08_+)
> 
>> Hello,
>> while working on something else[1], i noticed how many of the
>> repositories in the DPT salsa group are in poor shape:
>>
>> * missing branches
>> * changes not pushed to salsa
>> * general misalignment in configuration/setup/organization
>> * many other small nuances
>>
>> [1] https://github.com/sandrotosi/debian-python-team-tracker
> 
> +1 this is great!

\0/

I've been wanting something for QA like that for a while, but never had
the time / energy to look into it further. All in all, it's too easy to
forget to push something to Salsa and never realise it.

>> please take the content with caution, as it's still an early, raw
>> draft (i spot-checked some of the reported issues, but there could be
>> bugs/issues) and it contains data that can be outdated (see below re
>> caching); the fact that the report indicates only 43 repos are without
>> violations is a bit disarming, but i think the tool tries to err on
>> the side of verbosity and pedantry, with 2 level of violations (ERROR
>> and WARNING) to mark which ones are the most important that require
>> immediate attention vs the nice-to-have ones.
> 
> When we did the migration to git, there weren't good tools for managing
> the setup of the salsa repos (hooks, etc.) yet.  I'd assume those exist
> now, we should check in with what other teams are doing. That stuff can
> all be fixed in one run of a tool, I'd assume.

Could this become part of the Debian Janitor at some point?

I could see teams adding a per-team config file to check things like
what branch names should be expected, etc. and the Janitor fixing all
this if it has commit access.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Fwd: grammalecte_2.1.2+ds-1_amd64.changes REJECTED

2021-11-06 Thread Louis-Philippe Véronneau
Hello!

Grammalecte was rejected. It would be nice if you could fix the issue
mentioned below :)

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

 Forwarded Message 
Subject: grammalecte_2.1.2+ds-1_amd64.changes REJECTED
Date: Sat, 06 Nov 2021 12:00:09 +
From: Thorsten Alteholz 
To: Debian Python Team , Louis-Philippe
Véronneau 


Hi,

different README.md state that the license of parts of this package is
GPL-3 only.
Please remove the term "or (at your option) any later version" from your
GPL-3+ license block and rename it to GPL-3.

Thanks!
 Thorsten



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.



OpenPGP_signature
Description: OpenPGP digital signature


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

2021-10-25 Thread Louis-Philippe Véronneau
On 2021-10-25 14 h 04, Mathias Behrle wrote:
> * Mathias Behrle: " PEP-517/PEP-518 Support In Debian: current state" (Mon, 25
>   Oct 2021 19:45:39 +0200):
> 
>> Hi all,
>>
>> before doing something nasty I would like to hear if
>> https://lists.debian.org/debian-python/2020/06/msg2.html
>> is still valid?
> 
> JFTR I forgot to mention the background of my question:
> 
> Package simpleeval has moved to a setup.py-less build using pypa/build.
> 

Stuart Prescott has done some work to get this in dh-python:

* https://salsa.debian.org/python-team/packages/python-installer

* https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/20

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature


Re: Python BoF at DebConf2021

2021-08-14 Thread Louis-Philippe Véronneau
On 2021-06-15 14 h 32, Louis-Philippe Véronneau wrote:
> On 2021-06-12 16 h 20, Louis-Philippe Véronneau wrote:
>> Hey folks,
>>
>> The deadline to submit talks for DebConf21 is June 20th and I was
>> thinking it would be a good idea to have a Python BoF, as we always do.
>>
>> Anyone opposed to the idea?
>>
> 
> I've submitted the BoF. Chances are it will be approved :P
> 

The Python BoF will be on Aug 27, from 21:00 to 21:45 UTC [1].

Sadly, I have prior engagements and I won't be able to make it. Could
someone else take on the task of coming up with an agenda and chairing
the BoF?

[1]: https://debconf21.debconf.org/talks/20-python-team-bof/

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: Plan to upload all packages still using Alioth in Maintainer/Uploaders

2021-08-14 Thread Louis-Philippe Véronneau
On 2021-08-14 09 h 30, Stefano Rivera wrote:
> Hi Sandro (2021.08.14_02:25:21_+)
>> [1] https://lintian.debian.org/tags/python-teams-merged
> 
> There are more than those, some other variants made it into use too:
> 
> udd=> SELECT COUNT(*), maintainer_email FROM sources WHERE release='sid' AND 
> maintainer_email LIKE '%python%' GROUP BY maintainer_email;
>  count |maintainer_email 
> ---+-
>  1 | gst-python...@packages.debian.org
>  1 | pkg-python-debian-ma...@lists.alioth.debian.org
>  1 | python-apps-t...@alioth-lists.debian.net
>  1 | python-apps-t...@lists.alioth.debian.net
> 62 | python-apps-t...@lists.alioth.debian.org
> 15 | python-modules-t...@alioth-lists.debian.net
>713 | python-modules-t...@lists.alioth.debian.org
>  9 | team+python-modu...@tracker.debian.org
>670 | team+pyt...@tracker.debian.org
> (9 rows)

Good catch. FWIW, I've opened a feature request on Lintian to try to
catch those kind of errors [1].

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991955

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: mathlibtools_1.0.0-1_amd64.changes is NEW

2021-08-06 Thread Louis-Philippe Véronneau
On 2021-08-06 03 h 18, Debian FTP Masters wrote:
> binary:mathlibtools is NEW.
> binary:mathlibtools is NEW.
> source:mathlibtools is NEW.
> 
> Your package has been put into the NEW queue, which requires manual action
> from the ftpteam to process. The upload was otherwise valid (it had a good
> OpenPGP signature and file hashes are valid), so please be patient.
> 
> Packages are routinely processed through to the archive, and do feel
> free to browse the NEW queue[1].
> 
> If there is an issue with the upload, you will receive an email from a
> member of the ftpteam.
> 
> If you have any questions, you may reply to this email.
> 
> [1]: https://ftp-master.debian.org/new.html
>  or https://ftp-master.debian.org/backports-new.html for *-backports
> 

Dear Christopher,

It looks like you made a mistake in the d/control file of this package.
The "Maintainer" field currently reads

Maintainer: Debian Python Team 

It should be

Maintainer: Debian Python Team 

I thought there was a lintian tag for that, but there is none. I'll put
that on my TODO.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: Request for review for Poetry(Was: Re: Asking for help Poetry)

2021-07-02 Thread Louis-Philippe Véronneau
On 2021-07-02 18 h 25, Louis-Philippe Véronneau wrote:
> 2. d/control:
> 
> If you require specific dependencies, you should make it clear in
> d/control. It's the kind of thing that helps a lot if people decide to
> backport it.

Specific _versions_ of dependencies. Sorry, Friday afternoon :)

-- 
Louis-Philippe Véronneau



OpenPGP_signature
Description: OpenPGP digital signature


Re: Request for review for Poetry(Was: Re: Asking for help Poetry)

2021-07-02 Thread Louis-Philippe Véronneau
On 2021-06-19 18 h 21, Emmanuel Arias wrote:
> Hello everybody,
> 
> I want to tell you that I push to salsa an advances of poetry packaging.
> 
> Now, we have a complete package of poetry, so I'm requesting some more
> experienced reviewers.

Sorry, I said I would do this but it took me some time to actually do it :)

Thanks for working on poetry, it's 100% going to make our lives easier.

I have not read the upstream code, so I might be missing things...
That's the kind of thing I only do when a package is ready to be sponsored.

Here are my comments:

1. d/control:

You haven't set the Python Team either in Maintainer or Uploaders.

-

2. d/control:

If you require specific dependencies, you should make it clear in
d/control. It's the kind of thing that helps a lot if people decide to
backport it.

-

3. tests/repositories/fixtures

This directory contains a bunch of tarballs from other projects. I'm not
sure what should be done with this, as I guess they are used in the
testsuite

My first reflex would be to exclude them from the imported tarball and
disable the tests that require them, but I don't know how much of the
testsuite depends on those tarballs.

Maybe someone else from the team can chime-in?

-

4. d/tests

There are no autopkgtests. This being a large project that's kinda hard
to package, I don't really mind for now.

I think it's fair to wait to have at least 1 version in unstable before
working on that.

-

5. d/rules

Isn't the step in execute_after_dh_auto_install better suited in
execute_after_dh_clean instead? At least, it seems to me you're cleaning
the ./foo dir you patched in.

-

6. Lintian: W: python3-poetry: no-manual-page usr/bin/poetry

Again, not something that needs to be fixed, but each subcommand of
poetry should probably get a man page:

https://python-poetry.org/docs/cli/

I looked at the code and I have no idea how this website is built (they
don't use sphinx). It seems like they do something manual?

https://github.com/python-poetry/poetry/issues/3382

Anyway, here's an example of how I added man pages to a program with
multiple commands:

https://github.com/spl0k/supysonic/tree/master/docs/man

-

Overall it's very good! The trickiest part to fix will likely be #3 :S

> I need to skip some tests because use a non versioned python, so that
> give me some troubles like "python don't exist".
> 
> Also, there're some package (or package version) that aren't in Debian
> yet. So, to save your time looking which are them I tell you that I run
> the buildpackage in this way:
> 
> ```
> 
> gbp buildpackage --git-ignore-new
> --extra-package=/home/eamanu/Debian/DEPENDENCIES/python3-cleo_0.8.1-1_all.deb
> --extra-package=/home/eamanu/Debian/DEPENDENCIES/python3-httpretty_1.0.5-0.1_all.deb
> --extra-package=/home/eamanu/Debian/DEPENDENCIES/python3-pkginfo_1.7.0-1_all.deb

This package has not been updated on Salsa, or at least, I couldn't find
version 1.7.0-1 anywhere. Maybe you forgot to push?

I'm getting test failures on tests/inspection/test_info.py, but I'm
taking for granted it's because I don't have the right version.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs

2021-06-26 Thread Louis-Philippe Véronneau
On 2021-06-25 16 h 42, Nicholas D Steeves wrote:
> Hi Team!
> 
> I feel like there is probably consensus against the use of PyPi-provided
> upstream source tarballs in preference for what will usually be a GitHub
> release tarball, so I made an MR to this effect (moderate recommendation
> rather than a "must" directive):
> 
>   
> https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/16

I don't often use PyPi releases because of the issues mentioned in the
MR, but I think Jeremy's point is valid. IMO, rewording the text so that
it clearly says "should" and not "must" would fix the issues at hand, as
long as people justify their usage of PyPi when it's "The Right Thing"
in a file somewhere.

To me, the most important thing is that all packages must at least run
the upstream testsuite when it exists (I'm planning on writing a policy
proposal saying this after the freeze). If PyPi releases include them, I
think it's fine (but they often don't).

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: Python BoF at DebConf2021

2021-06-15 Thread Louis-Philippe Véronneau
On 2021-06-12 16 h 20, Louis-Philippe Véronneau wrote:
> Hey folks,
> 
> The deadline to submit talks for DebConf21 is June 20th and I was
> thinking it would be a good idea to have a Python BoF, as we always do.
> 
> Anyone opposed to the idea?
> 

I've submitted the BoF. Chances are it will be approved :P

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Python BoF at DebConf2021

2021-06-12 Thread Louis-Philippe Véronneau
Hey folks,

The deadline to submit talks for DebConf21 is June 20th and I was
thinking it would be a good idea to have a Python BoF, as we always do.

Anyone opposed to the idea?

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: Code review for grammalecte

2021-05-25 Thread Louis-Philippe Véronneau
Hello!

This is quite a large package, so instead of continuing to spam the IRC
channel, here are my comments.

1. These files are licensed under the MPL2

* darg.py
* gc_core/py/oxt/Grammalecte.py
* gc_core/py/oxt/Options.py
* gc_lang/fr/build_data.py
* gc_lang/fr/dictionnaire/genfrdic.py
* gc_lang/fr/dictionnaire/_templates/ooo/DictionarySwitcher.py
* gc_lang/fr/oxt/AppLauncher.py
* gc_lang/fr/oxt/Graphspell.py
* gc_lang/fr/oxt/About/About.py
* gc_lang/fr/oxt/ChangeAuthor/Author.py
* gc_lang/fr/oxt/ContextMenu/ContextMenu.py
* gc_lang/fr/oxt/DictOptions/DictOptions.py
* gc_lang/fr/oxt/DictOptions/LexiconEditor.py
* gc_lang/fr/oxt/DictOptions/SearchWords.py
* gc_lang/fr/oxt/DictOptions/TagsInfo.py
* gc_lang/fr/oxt/GraphicOptions/GraphicOptions.py
* gc_lang/fr/oxt/Lexicographer/Enumerator.py
* gc_lang/fr/oxt/TextFormatter/TextFormatterEditor.py
* gc_lang/fr/oxt/TextFormatter/TextFormatter.py
* graphspell/dawg.py
* graphspell/progressbar.py
* graphspell-js/dawg.js

To me, this is a sign you haven't read the code

Although it can be long and tiresome (and trust me, I know, I've just
read the entire codebase :P), it's an important step in packaging
something in Debian. When updating a package, you should also go through
the diff.

2. There should be an entry in d/copyright for
gc_lang/fr/dictionnaire/metaphone2.py

3. gc_lang/fr/nodejs/cli/lib/minimist.js seems to be a vendored copy of
a version of node-minimist. If you need it, you should use the debian
package. If not, it should be excluded.

That's pretty much it! Fix those issues and I'll be happy to upload to
experimental.

Cheers,

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: Salsa access

2021-03-03 Thread Louis-Philippe Véronneau
On 2021-03-03 07 h 44, Stephan Lachnit wrote:
> Dear team members,
> 
> boolean.py is a python package that just landed in Unstable.
> I would like to transfer the repo from my namespace to the team namespace,
> since the team is also named as maintainer.
> 
> Can someone give me maintainer access so I can move it?

Hi!

If you intend to maintain the package in the Team, you need to follow this 
procedure:

https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst#joining-the-team

Cheers,

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: Joining the team

2021-01-31 Thread Louis-Philippe Véronneau
On 2021-01-31 15 h 25, nicoo wrote:
> In particular the CI setup (the usual pipeline?)

Nothing on that, since the Salsa Team has asked us not to use CI
systematically because Salsa CI apparently cannot take the load.

> whether it's fine to enable branch/tag protection

Nothing on that either.

> working through MRs

You're free to ask for MRs, no team policy on this.

> adding webhooks to tag BTS bugs as pending when a fix is merged

AFAIK, you don't need to add webhooks for that to work, something (I
don't know what) scans through all new commits on Salsa and checks for
relevant BTS info.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: python-mongoengine 0.21.0-1 review

2020-12-24 Thread Louis-Philippe Véronneau
On 2020-12-24 09 h 45, Håvard Flaget Aasen wrote:
> Hi,
> 
> Thanks for the review!
> 
> tor. 24. des. 2020 kl. 05:31 skrev Louis-Philippe Véronneau 
> :
>>
>> Hi,
>>
>> I've just finished reviewing your RFS for python-mongoengine 0.21.0-1
>> and it all looks good!
>>
>> I can't help but notice you are using the tarballs from pypi though,
>> which means you don't have access to the upstream testsuite :(
>>
>> Do you think it would be possible to migrate to the github one and have
>> your package run the tests?
> 
> I tested with the tarball from GitHub today, and almost all of the
> tests is testing against a MongoDB server, which we don't have. This
> of course means that almost all test fails. I'm not sure how much
> value it is to run the remaining tests during build.
> 
> As for the autopkgtest, there might be possible to download, install,
> and run MongoDB during the test, that's what upstream is doing when
> they test the package, but that must be stretching what we can and
> should do when running autopkgtest in Debian.
> 
> I'm open for suggestion here, but since we don't have the necessary
> package in the repository I believe it will be difficult to test this
> package properly.

This all makes a lot of sense, thanks for looking into it. I've
sponsored the package as-is.

Thanks for you contribution to Debian.

PS: as per policy, I renamed the "master" branch to "debian/master".

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


python-mongoengine 0.21.0-1 review

2020-12-23 Thread Louis-Philippe Véronneau
Hi,

I've just finished reviewing your RFS for python-mongoengine 0.21.0-1
and it all looks good!

I can't help but notice you are using the tarballs from pypi though,
which means you don't have access to the upstream testsuite :(

Do you think it would be possible to migrate to the github one and have
your package run the tests?

I would also suggest running them as an autopkgtests (here's an example
[1]). That would give you a non superficial one :)

If you don't have time to do that right now, I'd be happy to sponsor
your package as-is if you commit to trying that out for the next release.

Keep me posted!

NB: I've removed your package from the sponsor queue on IRC so that
others don't inadvertently review it a second time :)

[1]:
https://salsa.debian.org/python-team/packages/python-itemloaders/-/blob/debian/master/debian/tests/unittests

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: Please upload the latest version of python-flask-cors ready in git

2020-12-18 Thread Louis-Philippe Véronneau
On 2020-12-18 06 h 33, Nicolas Dandrimont wrote:
> On Thu, Dec 17, 2020, at 04:28, Louis-Philippe Véronneau wrote:
>> Hello!
>>
>> Bastian Germann asked a month ago for the package python-flask-cors [1]
>> to be sponsored by someone from the Python Team.
>>
>> Since you put the Team in "Uploaders", I'm writing to you to know if it
>> would be possible to make an upload from the latest git commit in Salsa.
>>
>> Bastian fixed a CVE and a FTBFS bug (as well as updated the package) and
>> I did a few tweaks left and right.
> 
> Hey,
> 
> I think you're being overly conservative here; That package has had a RC bug 
> open for almost a year. It's a security-sensitive package with open security 
> issues; I think it's more than ripe for a team-upload.
> 
> [rant about team in Uploaders deleted]

Uploaded! (twice, I forgot to git pull and Bastian added an extra commit...)

Thank you for the input and thanks to Bastian for the work on this package.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: Please upload the latest version of python-flask-cors ready in git

2020-12-17 Thread Louis-Philippe Véronneau
On 2020-12-17 16 h 19, Bastian Germann wrote:
> Am 17.12.20 um 21:37 schrieb Louis-Philippe Véronneau:>> Just checked
> the RFS queue again and the package is gone from there. I
>>> would appreciate you sponsoring the package so it can migrate to
>>> bullseye.
>>
>> I removed it since it cannot be sponsored by a member of the team at the
>> moment, as a consequence of Stewart putting the team in "Uploaders" and
>> not in "Maintainers".
>>
>> As stated in the Team's policy [1], this means Stewart should be the one
>> making the upload, thus the email I sent him.
>>
>> Otherwise, I would've gladly uploaded it myself.
> 
> I see. The RC bug is open for 11 months, so a NMU might be justified.

Let's give Stewart some time (at least a week) to reply to my mail.

Considering this fixes a CVE and a FTBFS, I'll make an upload if we
don't hear from them. I guess I could make a team upload to DELAYED/7,
but that seems like extra work ;P

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: Please upload the latest version of python-flask-cors ready in git

2020-12-17 Thread Louis-Philippe Véronneau
On 2020-12-17 15 h 28, Bastian Germann wrote:
> Am 17.12.20 um 04:28 schrieb Louis-Philippe Véronneau:
>> Hello!
>>
>> Bastian Germann asked a month ago for the package python-flask-cors [1]
>> to be sponsored by someone from the Python Team.
>>
>> Since you put the Team in "Uploaders", I'm writing to you to know if it
>> would be possible to make an upload from the latest git commit in Salsa.
>>
>> Bastian fixed a CVE and a FTBFS bug (as well as updated the package) and
>> I did a few tweaks left and right.
>>
>> I believe the package should thus be ready to upload as is, as the only
>> thing missing is "dch -r" :)
>>
>> If you don't have the time to do so, I would be happy to make the upload
>> for you.
> 
> Just checked the RFS queue again and the package is gone from there. I
> would appreciate you sponsoring the package so it can migrate to bullseye.

I removed it since it cannot be sponsored by a member of the team at the
moment, as a consequence of Stewart putting the team in "Uploaders" and
not in "Maintainers".

As stated in the Team's policy [1], this means Stewart should be the one
making the upload, thus the email I sent him.

Otherwise, I would've gladly uploaded it myself.

Cheers,

[1]:
https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst#maintainership

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Please upload the latest version of python-flask-cors ready in git

2020-12-16 Thread Louis-Philippe Véronneau
Hello!

Bastian Germann asked a month ago for the package python-flask-cors [1]
to be sponsored by someone from the Python Team.

Since you put the Team in "Uploaders", I'm writing to you to know if it
would be possible to make an upload from the latest git commit in Salsa.

Bastian fixed a CVE and a FTBFS bug (as well as updated the package) and
I did a few tweaks left and right.

I believe the package should thus be ready to upload as is, as the only
thing missing is "dch -r" :)

If you don't have the time to do so, I would be happy to make the upload
for you.

Cheers,

[1]: https://salsa.debian.org/python-team/packages/python-flask-cors

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: Looking for information about the Python Team

2020-10-27 Thread Louis-Philippe Véronneau
On 2020-10-28 00 h 30, Pablo Mestre wrote:
> Hello

Hi!

> 
> I'm looking for information about the work done by the Python Team for a
> talk to encourage the Cuban python community to collaborate in Debian.
> Where can I find information about:

> - When the Python Team was created

No idea, but the answer is surely in the mailing list archives somewhere :)

https://lists.debian.org/debian-python/

Someone else here might know.

> - Number of active members (approximately)

358

https://salsa.debian.org/groups/python-team/packages/-/group_members

> - Number of packages under the responsibility of Python Team (approximately)

2270 source packages

https://salsa.debian.org/python-team/packages

> - Requirements to be a member of the Python Team

Listed here:

https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team

> - Any other information of interest

https://wiki.debian.org/Teams/PythonTeam

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Newcomers project: DPMT/PAPT pristine-tar verification

2020-10-06 Thread Louis-Philippe Véronneau
On 2020-10-06 12 h 07, Louis-Philippe Véronneau wrote:
> On 2020-10-03 15 h 35, Sandro Tosi wrote:
>> attached the dd-list of the packages missing the pristine-tar branch (some
>> may have been moved/removed, but these are actual repos in DPT)
>>
>> On Fri, Jul 10, 2020 at 12:38 AM Sandro Tosi  wrote:
>>
>>> Hello,
>>> i would like to propose a project to make sure our teams (DPMT/PAPT)
>>> repos are using pristine-tar properly.
>>>
>>> The checks i have in mind for now, are:
>>>
>>> * pristine-tar branch must exist, if not -> it's a bug
>>> * pristine-tar + upstream branch must produce the same tarball as
>>> downloaded from the archive, if not -> it's a bug
>>> * bonus point: fix the repo if it doesn't generate the right tarball
>>> and or the branch is missing.
>>> * bonus point: make this into a service that runs regularly (not
>>> strictly necessary to be limited to us)
>>>
>>> i guess we should have a brief discussion about additional checks
>>> and/or procedures before "assigning" it to a volunteer. let's say up
>>> to 2 weeks of discussion, and during the same period volunteers can
>>> nominate themselves.
>>>
>>> I marked this project as newcomers as it doesn't require to be a DD/DM
>>> to work on it, you just need a salsa account and access to our teams.
>>> a handy tool to retrieve all our repos is at
>>>
>>> https://salsa.debian.org/python-team/tools/python-modules
>>> https://salsa.debian.org/python-team/tools/python-apps
>>>
>>> that contains a config file for `mr` and a `checkout` script to fetch
>>> the repos registered in that config file.
>>>
>>> Please feel free to discuss this project now :)
> 
> I had a chat with folks in #debian-qa last night, as I agree such checks
> would be nice to have.
> 
> 1. Lintian is not suited for that kind of checks, as it does not have
> network access. Frankensteining lintian to do that kind of stuff would
> surely be met with fierce opposition.
> 
> 2. The vcswatch script [1] from the QA team already does something akin
> to what we would want. It's written in Perl [2], but doesn't look
> terribly complicated. When a check doesn't pass, it issues an
> action-item like this one [3].
> 
> I think the first step would be modifying vcswatcher to issue warnings for:
> 
> * the absence of pristine-tar branches
> * missing git tags
> * repositories using 'master' instead of 'debian/master' as the main branch
> 
> Once these are flagged, we can easily script a way to fix them, maybe
> even using lintian-brush?

I meant Debian Janitor here.

I don't know the codebase enough, but in my mind, having the thing that
fixes problems and the thing that flags them be separate is valuable. I
don't know if Janitor follows that philosophy though.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄





signature.asc
Description: OpenPGP digital signature


Re: Newcomers project: DPMT/PAPT pristine-tar verification

2020-10-06 Thread Louis-Philippe Véronneau
On 2020-10-03 15 h 35, Sandro Tosi wrote:
> attached the dd-list of the packages missing the pristine-tar branch (some
> may have been moved/removed, but these are actual repos in DPT)
> 
> On Fri, Jul 10, 2020 at 12:38 AM Sandro Tosi  wrote:
> 
>> Hello,
>> i would like to propose a project to make sure our teams (DPMT/PAPT)
>> repos are using pristine-tar properly.
>>
>> The checks i have in mind for now, are:
>>
>> * pristine-tar branch must exist, if not -> it's a bug
>> * pristine-tar + upstream branch must produce the same tarball as
>> downloaded from the archive, if not -> it's a bug
>> * bonus point: fix the repo if it doesn't generate the right tarball
>> and or the branch is missing.
>> * bonus point: make this into a service that runs regularly (not
>> strictly necessary to be limited to us)
>>
>> i guess we should have a brief discussion about additional checks
>> and/or procedures before "assigning" it to a volunteer. let's say up
>> to 2 weeks of discussion, and during the same period volunteers can
>> nominate themselves.
>>
>> I marked this project as newcomers as it doesn't require to be a DD/DM
>> to work on it, you just need a salsa account and access to our teams.
>> a handy tool to retrieve all our repos is at
>>
>> https://salsa.debian.org/python-team/tools/python-modules
>> https://salsa.debian.org/python-team/tools/python-apps
>>
>> that contains a config file for `mr` and a `checkout` script to fetch
>> the repos registered in that config file.
>>
>> Please feel free to discuss this project now :)

I had a chat with folks in #debian-qa last night, as I agree such checks
would be nice to have.

1. Lintian is not suited for that kind of checks, as it does not have
network access. Frankensteining lintian to do that kind of stuff would
surely be met with fierce opposition.

2. The vcswatch script [1] from the QA team already does something akin
to what we would want. It's written in Perl [2], but doesn't look
terribly complicated. When a check doesn't pass, it issues an
action-item like this one [3].

I think the first step would be modifying vcswatcher to issue warnings for:

* the absence of pristine-tar branches
* missing git tags
* repositories using 'master' instead of 'debian/master' as the main branch

Once these are flagged, we can easily script a way to fix them, maybe
even using lintian-brush?

As for the problem of pristine-tar and the upstream branch not producing
the same tarballs, I think it would be best to have that done in another
script altogether.

Cheers,

[1]: https://qa.debian.org/cgi-bin/vcswatch
[2]: https://salsa.debian.org/qa/qa/-/blob/master/cgi-bin/vcswatch
[3]: https://tracker.debian.org/action-items/1469895


-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Policy proposal: Consistent use of UNRELEASED in debian/changelog

2020-10-06 Thread Louis-Philippe Véronneau
On 2020-09-28 08 h 40, Ondrej Novy wrote:
> Hi,
> 
> po 28. 9. 2020 v 2:08 odesílatel Louis-Philippe Véronneau 
> napsal:
> 
>> Hi!
>>
>> I am proposing a minor addition to the DPT policy to try to make the use
>> of UNRELEASED in debian/changelog more consistent. The full diff can be
>> found here [1].
>>
> 
> I agree with this proposal but please change the wording a bit as
> per rfc2119 :)
> 
Thanks for all the comments and improvements people proposed.

Ondřej merged my MR last night, so it's now part of policy.

Cheers,

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: dh_auto_test failure with pybuild due to missing PYTHONPATH

2020-10-04 Thread Louis-Philippe Véronneau
packages/pkg_resources/__init__.py:480: in 
> get_distribution
> dist = get_provider(dist)
> /usr/lib/python3/dist-packages/pkg_resources/__init__.py:356: in get_provider
> return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
> /usr/lib/python3/dist-packages/pkg_resources/__init__.py:899: in require
> needed = self.resolve(parse_requirements(requirements))
> /usr/lib/python3/dist-packages/pkg_resources/__init__.py:785: in resolve
> raise DistributionNotFound(req, requirers)
> E   pkg_resources.DistributionNotFound: The 'git-pw' distribution was not 
> found and is required by the application
> ! Interrupted: 5 errors during collection 
> !
> = 5 error in 0.40 seconds 
> =
> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=2: cd 
> /build/git-pw-2.0.0/.pybuild/cpython3_3.8_git-pw/build; python3.8 -m pytest 
> tests
> dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 
> returned exit code 13
> 
> Apparently, the test suite expects PYTHONPATH to be set.  Is there a
> way to achieve this in a clean way?

You could use "export PYBUILD_BEFORE_TEST=PYTHONPATH=" to tell pybuild
to run a command before the testsuite is ran.

I'd consider that "cleaner" than overriding dh_auto_test.

> Adding this to debian/rules works:
> 
> override_dh_auto_test:
>   PYTHONPATH=. pytest-3 tests
> 
> But it won't run the tests against the installed binaries.

Not sure I understand what you mean by "against the installed binaries".
The testsuite ran during build isn't ran against installed binaries,
that's why we use autopkgtests.

Here is an example of an autopkgtest running the testsuite and exporting
a python path:

https://sources.debian.org/src/supysonic/0.6.0+ds-1/debian/tests/unittests/?hl=4#L4


-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Policy proposal: Consistent use of UNRELEASED in debian/changelog

2020-09-27 Thread Louis-Philippe Véronneau
Hi!

I am proposing a minor addition to the DPT policy to try to make the use
of UNRELEASED in debian/changelog more consistent. The full diff can be
found here [1].

The problem this tries to solves is inconsistent use of UNRELEASED in
debian/changelog. Some people do not use it at all, and it can make
working on team packages harder.

Indeed, if you try to modify a package, if people don't use UNRELEASED,
you first need to check if the current VCS version has been uploaded to
the archive or not. This complicates the life of people doing mass
updates, as they can't rely on packages with `unstable` having been
uploaded.

This be can seen for example in the latest batch of updates by onovy,
where new versions of a package were made instead of marking changes as
addition to a yet to be released version, because some packages were
marked `unstable` but hadn't been uploaded.

I don't think it's a lot to ask and will surely make team contributions
more pleasant :)

Cheers,

[1]:
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/15

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Merging the PAPT and the DMPT

2020-09-18 Thread Louis-Philippe Véronneau
On 2020-09-14 17 h 54, Christian Kastner wrote:
> On 2020-09-14 09:59, Ondrej Novy wrote:
>>   * transferring all project from modules+applications to packages subgroup
> 
> Has getting rid of the subgroups entirely been considered, IOW: moving
> the packages directory to python-team/?
> 
> The only remaining subgroup seems to be "tooling", and that could live
> on as a subgroup unless I'm misunderstanding GitLab.
> 

At this point, I'm not sure it makes a huge difference. I like the
division, as it keeps the tools and the packages separated in a clear way.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: [DRAFT] DPMT and PAPT is DPT now

2020-09-18 Thread Louis-Philippe Véronneau
On 2020-09-14 17 h 42, Christian Kastner wrote:
> Hi Ondřej,
> 
> On 2020-09-14 10:39, Ondrej Novy wrote:
>> for simplification we merged two subteams - Debian Python Modules Team
>> and Python Applications Packaging Team into just one: Debian Python
>> Team, DPT.
>>
>> All Salsa repositories are in "packages" subgroup [1] now.
>>
>> We have only one team policy [2] now.
>>
>> And as always, new contributors are welcomed :)
>>
>> [1] https://salsa.debian.org/python-team/packages
>> [2] 
>> https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst
> 
> I'm prone to be much too verbose, but seeing as -devel-announce has an
> audience that might lack context and details that are well-known to
> -python, I'd like to suggest the following amended version just in case:
> 
> 
> PAPT and DPMT become DPT
> 
> 
> Historically, the Debian Python ecosystem was maintained by two separate
> teams: the Debian Python Applications Packaging Team (PAPT) for
> applications, and the Debian Python Modules Team (DPMT) for modules used
> by applications.
> 
> As there was substantial overlap between the members of these teams, their
> work,  and their tooling, these teams have been merged into one: the
> Debian Python Team (DPT).
> 
> [Or whatever the actual history and motivations were; as I said in an
> earlier mail, it was never quite clear to me why two teams were needed
> in the first place]
> 
> 
> Changes
> ---
> 
> This merge mainly affects package maintainers. End users should not see
> a change beyond the Maintainer field of packages.
> 
> For maintainers, the following has changed:
>   * The respective PAPT and DPMT policies are superseded by the new,
> more compact DPT policy [1]. Please take a few minutes to familiarize
> yourself with this new policy.
>   * All Salsa repositories are in "packages" subgroup [2] now. Please
> set Vcs-* fields of new packages accordingly.
>   * The Maintainer field of new packages should now be set to
> "Debian Python Team ".
> 
> 
> Migration
> -
> 
> On Salsa, redirects have been implemented from the old "applications"
> and "modules" subgroups to the new "packages" subgroup. Vcs-* URLs
> should continue working for now.
> 
> [... and the other migration steps are still being planned, right?]
> 
> 
> [1] 
> https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst
> [2] https://salsa.debian.org/python-team/packages
> 

I like those changes! Sounds good to send as is to me.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: What is the new maintainer address for Python team?

2020-09-07 Thread Louis-Philippe Véronneau
On 2020-09-07 10 h 12, Sandro Tosi wrote:
>> New/correct address is:
>> Maintainer: Debian Python Team 
> 
> Was this discussed somewhere? i cant find references in the ml -- thanks
> 

This was part of the recent DPMT-PAPT merger:

https://lists.debian.org/debian-python/2020/09/msg7.html

https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/10

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Merging the PAPT and the DMPT

2020-08-28 Thread Louis-Philippe Véronneau
On 2020-08-28 10 h 53, Emmanuel Arias wrote:
> oops, I forgot, I think we must update the line
> 
> ```
> Copyright (c) 2005-2019 Debian Python Team. All rights reserved.
> ```
> 
> to 2020, isn't?

Fixed.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Merging the PAPT and the DMPT

2020-08-28 Thread Louis-Philippe Véronneau
On 2020-08-28 05 h 28, Andrey Rahmatullin wrote:
> Can you please also describe the current plans for changing/not changing
> the Git paths after the merge?
> 

During the BoF, most people were against changing the git paths after
the merge and this differs from the discussion we had in the Merge Request.

In the MR, people proposed we move everything to a "/packages" path to
simplify things. The rationale is Gitlab should be taking care of
redirecting the old URLs to the new ones for us seamlessly.

I think changing the path would be a good idea, as I don't see the point
between the libraries and applications divide. Then again, if people
prefer we don't move things around, I don't really mind either.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Merging the PAPT and the DMPT

2020-08-27 Thread Louis-Philippe Véronneau
Hello folks!

Yesterday during the Python BoF at DebConf20 I brought up the question
of merging the PAPT and the DMPT into a single, coherent Python Team.

Most of the people present at the BoF agreed the merge would be a good
idea to:

* improve documentation
* have a consistent workflow between the PAPT and the DMPT
* reduce the bureaucracy of needing to ask membership twice when you
work on python packages

In October 2019, following a short discussion on the ML [1], I opened a
merge request on the policy [2] for this. Most if not all issues in that
MR have since been resolved and the only blocker is getting the admins
approval.

Can we make this happen? If people are against that merge, could you
please speak up and tell us why you think it's a bad idea? At the moment
I feel like I'm fighting the void...

Cheers,

[1]: https://lists.debian.org/debian-python/2019/09/msg00128.html
[2]:
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/10

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: DebCond20 @ Home -- Python Team Bof & Sprint ?

2020-08-23 Thread Louis-Philippe Véronneau
Hello folks,

1. To simplify the videoteam's life, the BoF and Sprint notes/agenda has
been moved to the DebConf etherpad instance.

  - https://pad.online.debconf.org/p/60-python-team-bof
  - https://pad.online.debconf.org/p/python-team-sprint

2. If you want to attend the BoF, please reach out to me, either by
email or on IRC (pollo). I'll send you the link to the Jitsi room (it
should stay private).

Cheers!

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄
On 2020-08-12 17 h 26, Louis-Philippe Véronneau wrote:
> Hi,
> 
> The DebConf20 schedule is now up! Here are two Python events you might
> want to attend:
> 
> = BoF =
> 
> The Python Team BoF will take place on *Wednesday August 26th from 16:00
>   to 16:45 UTC* [1]. We'll be using gobby to take notes and prepare the
> agenda for the meeting:
> 
> gobby infinote://gobby.debian.org/debconf20/bof/python
> 
> Although I tried to extrapolate, I am clearly not in the best position
> to prepare a thorough agenda for this meeting.
> 
> If you want something to be discussed, please modify the aforementioned
> agenda.
> 
> You can find instructions on how to use gobby here [2].
> 
> = Sprint =
> 
> The Python Sprint will take place on *Thursday August 27th, from 11:00
> to 20:45 UTC*.
> 
> More information on the sprint on the Debian Wiki [3]. Please add your
> name in advance if you are planning to participate!
> 
> 
> [1]: https://debconf20.debconf.org/talks/60-python-team-bof/
> [2]: https://wiki.debian.org/gobby.debian.org
> 
> [3]: https://wiki.debian.org/Sprints/2020/PythonTeamDebConf20
> 



signature.asc
Description: OpenPGP digital signature


Re: DebCond20 @ Home -- Python Team Bof & Sprint ?

2020-08-12 Thread Louis-Philippe Véronneau
Hi,

The DebConf20 schedule is now up! Here are two Python events you might
want to attend:

= BoF =

The Python Team BoF will take place on *Wednesday August 26th from 16:00
  to 16:45 UTC* [1]. We'll be using gobby to take notes and prepare the
agenda for the meeting:

gobby infinote://gobby.debian.org/debconf20/bof/python

Although I tried to extrapolate, I am clearly not in the best position
to prepare a thorough agenda for this meeting.

If you want something to be discussed, please modify the aforementioned
agenda.

You can find instructions on how to use gobby here [2].

= Sprint =

The Python Sprint will take place on *Thursday August 27th, from 11:00
to 20:45 UTC*.

More information on the sprint on the Debian Wiki [3]. Please add your
name in advance if you are planning to participate!


[1]: https://debconf20.debconf.org/talks/60-python-team-bof/
[2]: https://wiki.debian.org/gobby.debian.org

[3]: https://wiki.debian.org/Sprints/2020/PythonTeamDebConf20

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Granting `Janitor` direct access to our teams repos

2020-07-27 Thread Louis-Philippe Véronneau
On 2020-07-27 20 h 18, Sandro Tosi wrote:
> Hello,
> I don't know the technicalities required to do that (nor i have
> permissions to do it myself anyway), but I'm wondering if we should
> grant direct access to our repos to the Janitor user.
> 
> I don't think any of us checks those PRs in depth, and most of the
> time Jelmer comes in and bulk-merges them straight away (no complaints
> on that).
> 
> So: let's just make that automatic? Thoughts?
> 
> Regards,
> 

I'm all for it, people should check if the changes made to a repository
are sane before uploading to the archive anyway :)

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: DebConf20 @ Home -- Python Team Bof & Sprint ?

2020-07-06 Thread Louis-Philippe Véronneau
On 2020-07-01 09 h 59, Louis-Philippe Véronneau wrote:
> On 2020-06-24 21 h 13, Louis-Philippe Véronneau wrote:
>> Hello folks!
>>
>> As some of you might have seen, DebConf20 @ Home will be happening end
>> of August.
>>
>> I was wondering if others would be interested in having a Python Team
>> BoF to talk about ongoing work/issues (the Python 2 removals comes to my
>> mind but I'm sure there are other discussion-worthy topics).
>>
>> If there is interest, I'd be happy to submit something to the DebConf
>> Content team.
>>
>> Maybe it would also be good to set aside half a day during the conf
>> (preferably after the BoF) for a sprint to try and fix things?
>>
>> Cheers,
>>
> 
> FWIW, I haven't sent a BoF proposal to the DebConf Content team yet, as
> I don't feel 3 people (including me) is enough to interest.
> 
> If you'd like to see a Python BoF + Sprint happen during DebConf20@Home,
> please show your support.
> 


Thanks for all of those who showed interest, and to Stefano for the
extra poke.

I submitted a BoF + Sprint proposal to the DebConf20 Content Team.



-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: DebConf20 @ Home -- Python Team Bof & Sprint ?

2020-07-01 Thread Louis-Philippe Véronneau
On 2020-06-24 21 h 13, Louis-Philippe Véronneau wrote:
> Hello folks!
> 
> As some of you might have seen, DebConf20 @ Home will be happening end
> of August.
> 
> I was wondering if others would be interested in having a Python Team
> BoF to talk about ongoing work/issues (the Python 2 removals comes to my
> mind but I'm sure there are other discussion-worthy topics).
> 
> If there is interest, I'd be happy to submit something to the DebConf
> Content team.
> 
> Maybe it would also be good to set aside half a day during the conf
> (preferably after the BoF) for a sprint to try and fix things?
> 
> Cheers,
> 

FWIW, I haven't sent a BoF proposal to the DebConf Content team yet, as
I don't feel 3 people (including me) is enough to interest.

If you'd like to see a Python BoF + Sprint happen during DebConf20@Home,
please show your support.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


DebCond20 @ Home -- Python Team Bof & Sprint ?

2020-06-24 Thread Louis-Philippe Véronneau
Hello folks!

As some of you might have seen, DebConf20 @ Home will be happening end
of August.

I was wondering if others would be interested in having a Python Team
BoF to talk about ongoing work/issues (the Python 2 removals comes to my
mind but I'm sure there are other discussion-worthy topics).

If there is interest, I'd be happy to submit something to the DebConf
Content team.

Maybe it would also be good to set aside half a day during the conf
(preferably after the BoF) for a sprint to try and fix things?

Cheers,

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: joining the PAPT

2020-05-11 Thread Louis-Philippe Véronneau
On 20-05-11 17 h 02, Louis-Philippe Véronneau wrote:
> On 20-05-11 16 h 48, Utkarsh Gupta wrote:
>> Hi Hans,
>>
>> On Tue, May 12, 2020 at 2:03 AM Hans-Christoph Steiner  wrote:
>>> Ok, this has become a bit more urgent since someone has moved my package
>>> fdroidserver into PAPT without asking me.  Now I cannot push commits to
>>> it.  So either someone needs to grant me PAPT access or put my package
>>> back where it was in salsa.  I'm fine with fdroidserver being in PAPT,
>>> I'm not fine with being locked out of my package.
>>
>> I am sorry this happened (though I've no idea who did it).
>> Whilst I don't have the right permissions/access to add you to PAPT
>> officially, I have given you maintainer access to fdroidserver so this
>> won't be a blocker to you.
> 
> Hi,
> 
> That was I, and I documented the process in bug #946105 [1]. As stated
> on the BTS, the package was already in the PAPT but wasn't respecting
> the policy, thus making team work harder.
> 
> Looking at the package, it seems I forgot to push a patch to d/control
> to change the VCS. Sorry for overlooking that, I did a bunch in a row
> and must have skipped fdroidserver by mistake.
> 
> I'll do that in a few minutes.
> 
> Sorry if the changes to the repository path I made caused you problems.
> 
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946105
> 

Hmm, re-reading the BTS entry, it seems I went a little fast and didn't
take in account you put the PAPT in the "Uploaders" field instead of the
"Maintainer" one. I shouldn't have touched the package.

I guess that's why I didn't originally push a patch. Somehow
fdroidserver ended up in the list I gave to the Salsa team when I asked
them to migrate a bunch of repositories for us.

Again, sorry for the screw up :(

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: joining the PAPT

2020-05-11 Thread Louis-Philippe Véronneau
On 20-05-11 16 h 48, Utkarsh Gupta wrote:
> Hi Hans,
> 
> On Tue, May 12, 2020 at 2:03 AM Hans-Christoph Steiner  wrote:
>> Ok, this has become a bit more urgent since someone has moved my package
>> fdroidserver into PAPT without asking me.  Now I cannot push commits to
>> it.  So either someone needs to grant me PAPT access or put my package
>> back where it was in salsa.  I'm fine with fdroidserver being in PAPT,
>> I'm not fine with being locked out of my package.
> 
> I am sorry this happened (though I've no idea who did it).
> Whilst I don't have the right permissions/access to add you to PAPT
> officially, I have given you maintainer access to fdroidserver so this
> won't be a blocker to you.

Hi,

That was I, and I documented the process in bug #946105 [1]. As stated
on the BTS, the package was already in the PAPT but wasn't respecting
the policy, thus making team work harder.

Looking at the package, it seems I forgot to push a patch to d/control
to change the VCS. Sorry for overlooking that, I did a bunch in a row
and must have skipped fdroidserver by mistake.

I'll do that in a few minutes.

Sorry if the changes to the repository path I made caused you problems.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946105

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: mailing-list-obsolete-in-debian-infrastructure warning

2020-04-23 Thread Louis-Philippe Véronneau
On 20-04-23 20 h 52, Scott Kitterman wrote:
> 
> 
> On April 24, 2020 12:26:27 AM UTC, "Louis-Philippe Véronneau" 
>  wrote:
>> On 20-04-23 17 h 54, Scott Kitterman wrote:
>>> On Thursday, April 23, 2020 5:21:49 PM EDT Rebecca N. Palmer wrote:
>>>> This warning was added to Lintian today, after being requested in
>>>> #958182.  It appears on thousands of packages:
>>>>
>> https://lintian.debian.org/tags/mailing-list-obsolete-in-debian-infrastructu
>>>> re.html
>>>
>>> Thanks.  I mailed the bug to point out this tag is currently
>> problematic.
>>
>> FWIW, I proposed we merge the DPMT and the PAPT a few months ago [1]
>> and
>> migrate to team+pyt...@tracker.debian.org.
>>
>> That would also solve the current issue with lintian :)
>>
>> [1]:
>> https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/10
> 
> And I don't think the response was particularly positive.  My recollection 
> was that there's a preference for two teams because packages and modules have 
> different needs.

Hmm, from the discussions we had on the mailing list and on Salsa the
feedback was mainly positive actually.

Happy to talk some more about it either on Salsa or on the ML:

https://lists.debian.org/debian-python/2019/10/msg00021.html

> 
> I don't think we should let an artificial sense of urgency because lintian 
> push us in to anything (apologies if I'm remembering the wrong instance of 
> this being suggested - it's happened before).

Agreed :)

Sorry for disrupting this thread.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: mailing-list-obsolete-in-debian-infrastructure warning

2020-04-23 Thread Louis-Philippe Véronneau
On 20-04-23 17 h 54, Scott Kitterman wrote:
> On Thursday, April 23, 2020 5:21:49 PM EDT Rebecca N. Palmer wrote:
>> This warning was added to Lintian today, after being requested in
>> #958182.  It appears on thousands of packages:
>> https://lintian.debian.org/tags/mailing-list-obsolete-in-debian-infrastructu
>> re.html
> 
> Thanks.  I mailed the bug to point out this tag is currently problematic.

FWIW, I proposed we merge the DPMT and the PAPT a few months ago [1] and
migrate to team+pyt...@tracker.debian.org.

That would also solve the current issue with lintian :)

[1]:
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/10

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Force pushing on salsa?

2020-02-11 Thread Louis-Philippe Véronneau
Hey folks,

Looking at a package recently, I saw some important mistakes and I was
wondering: would it be ok to force push to fix them?

More explicitly, the import of the new upstream version with
pristine-tar contains a bunch of errors due to a wrong manipulation. It
seems to me it would be "more clean" to start again and force push.

I know force pushing is normally frowned upon when working in a team
environment, but I haven't seen any mention of it in the Python Team's
policy.

Happy to know what folks think of this. If there is a strong consensus,
maybe we should add something to the policy.

Cheers,

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Merge Requests

2019-12-06 Thread Louis-Philippe Véronneau
On 19-12-06 04 h 34, Jonathan Carter wrote:
> For other MRs, I noticed that many small changes in the packaging didn't
> have an associated changelog entry with it, so I had to dch to add a
> changelog entry. I think for small changes I'd prefer the person who
> submits the MR to add them. For larger ones it probably makes sense not
> to do that since it might take longer.

I rarely add a changelog entry when creating MRs, as I feel it often is
a burden for the maintainers if the MR isn't immediately merged and new
releases are made (creates merge conflicts, etc.).

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Prefered way to RFS

2019-12-05 Thread Louis-Philippe Véronneau
On 19-12-05 01 h 50, Håvard Flaget Aasen wrote:
> Thanks!
> 
> Is this something that could be added here?
> https://wiki.debian.org/Python/GitPackaging#Sponsoring.2C_mentoring.2C_reviewing

Sure. This is also documented on this page, although it might not be the
best place for it:

https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)

2019-11-08 Thread Louis-Philippe Véronneau
On 19-11-08 16 h 01, Thomas Goirand wrote:
> Hi intri!
> 
> I'm very glad to count you as a member of the team! Welcome. [1]
> I'd be glad if more perl team members join, it's so much always a
> pleasure to meet you at each debconf.
> 
> On 11/8/19 8:54 AM, intrigeri wrote:
>>  - In https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin,
>>the "Policy About Maintainer and Uploaders Fields" section
>>mentions an "unwritten policy". Said policy seems to have been
>>written since:
>>
>> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> 
> It's probably time to revisit this policy. I've heard many voices
> telling that a package should either be in the team, or just not, and I
> very much agree with this. This middle-ground makes no sense.

We now have a proper way to propose updates to the policy [1]!

Once the DPMT and the PAPT teams have been merged (see [2]), we will
have to clean up the Python Team's wikis. I guess it would also be a
good time to revisit things like that "unwritten" policy :)

[1]:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#L154

[2]:
https://salsa.debian.org/python-team/tools/python-modules/merge_requests/10

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Streamlining the use of Salsa CI on team packages

2019-10-11 Thread Louis-Philippe Véronneau
On 19-09-15 20 h 31, Louis-Philippe Véronneau wrote:
> On 19-09-05 01 h 40, Louis-Philippe Véronneau wrote:
>> Hello folks!
>>
>> I'd like to propose we start using Salsa CI for all the team packages. I
>> think using a good CI for all our packages will help us find packaging
>> bugs and fix errors before uploads :)
>>
>> I also think that when possible, we should be using the same CI jobs for
>> our packages. The Salsa CI Team's default pipeline [1] is a good common
>> ground, as currently it:
>>
>> * builds the package
>> * runs piuparts
>> * runs autopkgtest
>> * runs lintian
>> * runs reprotest
>> * and does more!
>>
>> I don't think a failing CI should be a blocker for an upload, but I
>> think it's a good red flag and should be taken in account.
>>
>> I know the Ruby team also decided to use debian/salsa-ci.yml instead of
>> debian/gitlab-ci.yml [2]. I guess we should also do the same.
>>
>> Thoughts? If we decide to go ahead with this, I guess we should modify
>> the policy accordingly and contact the Salsa Team to see if adding this
>> additional load is OK with them.
>>
>> [1] https://salsa.debian.org/salsa-ci-team/pipeline#basic-use
>> [2] https://salsa.debian.org/salsa-ci-team/pipeline/issues/86#note_106245
> These are the steps I see going forward with this:
> 
> --
> 1. Agree on a default pipeline we should be using on the DPMT & PAPT
> packages.
> 
> 2. Draft a proposed modification to the DPMT and the PAPT policies
> 
> 3. Adopt that proposed modification once we reach consensus
> 
> 4. Wait for the "All Clear" from the Salsa Team
> 
> 5. Commit the previously agreed upon CI pipeline to all the DPMT & PAPT
> packages, while making sure the CI isn't ran on that push ("-o ci.skip")
> --
> 
> For step 1, I proposed we use the "Salsa Pipeline" [1], as I feel it is
> the most mature solution, has more contributors and has more features
> (including reprotest and piuparts). This option seems to have had the
> most support so far.
> 
> Hans-Christoph Steiner proposed we use "ci-image-git-buidpackage"
> instead [2]. The code behind it is simpler and the way it's built makes
> it possible for maintainers to modify the CI for their packages.
> 
> For step 2, so far people seemed to agree that:
> 
> * having a standardised CI pipeline is a good idea
> * the CI should be used as a tool to help us improve our packages, and
> not be required to pass
> 
> Please contribute to this discussion if you care about this issue! I'll
> try to draft something more concrete in the next few days.
> 
> [1] https://salsa.debian.org/salsa-ci-team/pipeline
> [2] https://salsa.debian.org/salsa-ci-team/ci-image-git-buildpackage
> 

As promised, here's a draft proposal on CI usage for the team:

https://salsa.debian.org/python-team/tools/python-modules/merge_requests/12/

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: What is the process to update the DPMT and PAPT policies?

2019-10-11 Thread Louis-Philippe Véronneau
On 19-09-16 08 h 00, Ondrej Novy wrote:
> Hi,
> 
> po 16. 9. 2019 v 1:59 odesílatel Louis-Philippe Véronneau 
> napsal:
> 
>> What is the process to update the DPMT and PAPT policies?
> 
> 
> we don't have process/policy to update policy.
> 
> So I will propose one and let's add this process to policy itself:
> 
>- anyone can submit merge request
>- with MR created, send email to ML
>- give seven? days grace period to discuss proposal
>- to accept MR we needed at least one? ack from DPMT admins
> 
> Comments? :)
> 

This made a lot of sense to me, so I made an MR to implement this:

https://salsa.debian.org/python-team/tools/python-modules/merge_requests/11

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Merging the PAPT and the DPMT

2019-10-11 Thread Louis-Philippe Véronneau
On 19-09-16 08 h 00, Ondrej Novy wrote:
> Hi,
> 
> po 16. 9. 2019 v 9:55 odesílatel Mattia Rizzolo  napsal:
> 
>> I wonder, I think the historical reasons for papt and dpmt to be separated
>> don't quite stand anymore.  Perhaps the only difference left is the actual
>> technical difference between an application and a module as described in
>> the python policy (rather in the team one).
>>
> 
> I don't know historical reason but I agree we could/should merge DPMT and
> PAPT policies together.
> 

For those interested in having a look at it, I created a MR on Salsa [1]
to try to merge the two policies into one.

[1]
https://salsa.debian.org/python-team/tools/python-modules/merge_requests/10

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: What is the process to update the DPMT and PAPT policies?

2019-09-16 Thread Louis-Philippe Véronneau
On 19-09-16 08 h 00, Ondrej Novy wrote:
> Hi,
> 
> po 16. 9. 2019 v 9:55 odesílatel Mattia Rizzolo  napsal:
> 
>> I wonder, I think the historical reasons for papt and dpmt to be separated
>> don't quite stand anymore.  Perhaps the only difference left is the actual
>> technical difference between an application and a module as described in
>> the python policy (rather in the team one).
>>
> 
> I don't know historical reason but I agree we could/should merge DPMT and
> PAPT policies together.

Yes! I too agree this would make a lot of sense.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Streamlining the use of Salsa CI on team packages

2019-09-15 Thread Louis-Philippe Véronneau
On 19-09-05 01 h 40, Louis-Philippe Véronneau wrote:
> Hello folks!
> 
> I'd like to propose we start using Salsa CI for all the team packages. I
> think using a good CI for all our packages will help us find packaging
> bugs and fix errors before uploads :)
> 
> I also think that when possible, we should be using the same CI jobs for
> our packages. The Salsa CI Team's default pipeline [1] is a good common
> ground, as currently it:
> 
> * builds the package
> * runs piuparts
> * runs autopkgtest
> * runs lintian
> * runs reprotest
> * and does more!
> 
> I don't think a failing CI should be a blocker for an upload, but I
> think it's a good red flag and should be taken in account.
> 
> I know the Ruby team also decided to use debian/salsa-ci.yml instead of
> debian/gitlab-ci.yml [2]. I guess we should also do the same.
> 
> Thoughts? If we decide to go ahead with this, I guess we should modify
> the policy accordingly and contact the Salsa Team to see if adding this
> additional load is OK with them.
> 
> [1] https://salsa.debian.org/salsa-ci-team/pipeline#basic-use
> [2] https://salsa.debian.org/salsa-ci-team/pipeline/issues/86#note_106245
These are the steps I see going forward with this:

--
1. Agree on a default pipeline we should be using on the DPMT & PAPT
packages.

2. Draft a proposed modification to the DPMT and the PAPT policies

3. Adopt that proposed modification once we reach consensus

4. Wait for the "All Clear" from the Salsa Team

5. Commit the previously agreed upon CI pipeline to all the DPMT & PAPT
packages, while making sure the CI isn't ran on that push ("-o ci.skip")
--

For step 1, I proposed we use the "Salsa Pipeline" [1], as I feel it is
the most mature solution, has more contributors and has more features
(including reprotest and piuparts). This option seems to have had the
most support so far.

Hans-Christoph Steiner proposed we use "ci-image-git-buidpackage"
instead [2]. The code behind it is simpler and the way it's built makes
it possible for maintainers to modify the CI for their packages.

For step 2, so far people seemed to agree that:

* having a standardised CI pipeline is a good idea
* the CI should be used as a tool to help us improve our packages, and
not be required to pass

Please contribute to this discussion if you care about this issue! I'll
try to draft something more concrete in the next few days.

[1] https://salsa.debian.org/salsa-ci-team/pipeline
[2] https://salsa.debian.org/salsa-ci-team/ci-image-git-buildpackage

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Streamlining the use of Salsa CI on team packages

2019-09-15 Thread Louis-Philippe Véronneau
On 19-09-15 18 h 01, Thomas Goirand wrote:
> On 9/15/19 4:10 AM, Louis-Philippe Véronneau wrote:
>> On 19-09-14 17 h 35, Thomas Goirand wrote:
>>> On 9/13/19 11:08 PM, Louis-Philippe Véronneau wrote:
>>>> On 19-09-13 05 h 57, Thomas Goirand wrote:
>>>>> On 9/5/19 7:40 AM, Louis-Philippe Véronneau wrote:
>>>>>> Hello folks!
>>>>>>
>>>>>> I'd like to propose we start using Salsa CI for all the team packages. I
>>>>>> think using a good CI for all our packages will help us find packaging
>>>>>> bugs and fix errors before uploads :)
>>>>>
>>>>> I would agree *IF* and only *IF* we find better runners than the one
>>>>> currently default in Salsa. The GCE runners are horribly slow (they are
>>>>> the smallest to avoid cost). As a result, some tests may just fail
>>>>> because of that, and it becomes just frustrating / annoying noise.
>>>>
>>>> I never experienced such timeouts, but I guess I don't work on very
>>>> large packages or things that take more than a few minutes to build.
>>>
>>> The issue isn't build time. But when you have unit tests sensitive to
>>> timing. See for example openvswitch:
>>>
>>> https://salsa.debian.org/openstack-team/third-party/openvswitch/pipelines/61713
>>
>> Do you have similar issues running those CI tasks in a private runner?
>> (I'm really curious since I haven't had problems and the Salsa runners
>> don't seem slow compared to the private runners I run on my machines).
> 
> For this particular package, I even had issues with some buildd on some
> slow architectures like older MIPS. Just, with the Salsa default
> runners, it's a complete disaster where most of the tests fails, not
> just a few, because the runner is too slow.
> 
> What this shows is that we should *not* just blindly add the CI to all
> of the team's package. Potentially, this will be a disaster. You may add
> the CI script here and there, but I am warning you: adding it to all
> packages at once is a recipe for a big disaster.
> 
>> Maybe one solution to your problem would be to provide a fast/responsive
>> shared runners to the Salsa Team and tag your CI pipelines to use that
>> runner exclusively [1]?
>>
>> [1] https://docs.gitlab.com/ee/ci/yaml/#tags
> 
> Yes, that's what I've been telling to begin with. We should try
> providing other runners for the team if possible.
> 
>> [1]
>> https://salsa.debian.org/salsa/salsa-terraform/blob/master/environments/prod/runner.tf
> 
> This tells "instance_type: g1-small", which doesn't match any name at:
> https://cloud.google.com/compute/vm-instance-pricing
> 
> Am I right that this is n1-standard-1, which is 1 VCPU and 3.75 GB?
> 
>> It's possible to push to Salsa without triggering a CI run with "git
>> push -o ci.skip" or by including "[ci-skip]" in the HEAD commit message.
>>
>> IIUC, the problem isn't the overall amount of repositories using the CI,
>> but adding a 1000 ones at the same time and overloading the runners.
> 
> Ah, nice, good to know.
> 
>>> 1/ Take a super big care when adding jobs.
>>
>> I feel this is easily resolved by the "-o ci.skip" thing.
> 
> Good!
> 
>> I'm not 100% sure that's a good idea. The Salsa Team has pretty strict
>> requirements about shared runners (they require root on those machines
>> to make sure the .debs created by the runners can be trusted) and I'm
>> happy they do.
> 
> I didn't know, and this makes me question the overall way it works, and
> worries me a lot. ie we should be running on throwaway VMs, rather than
> having a VM we should be able to trust. The way you describe things, I
> wonder how easy it should be to get root on these VMs by running a
> crafted CI job...

Well, runners aren't running the CI jobs directly: everything is ran in
Docker, as that's the only available executor on the Salsa shared
runners. Even then, it uses a Gitlab special sauce, so it's not even
strait up Docker.

>> I really wonder how common the issues you've experienced with the Salsa
>> CI runners are. Has anyone here had similar problems?
> 
> Since we're talking about the smallest type of instance possible at
> google, then other people may have experience the lack of RAM for sure.
> 
>> I'd be fine with 95% of our package using the same default pipeline and
>> the last 5% using something else or disabling it and adding a few
>> comments in d/gitlab-ci.yml explaining why.
> 
> The question is: how do you know who's the 5% tha

What is the process to update the DPMT and PAPT policies?

2019-09-15 Thread Louis-Philippe Véronneau
Hi!

What is the process to update the DPMT and PAPT policies? I feel the
DPMT policy is pretty good and I feel the PAPT policy could copy a bunch
of stuff from there.

For example, the PAPT policy doesn't include a "Git Procedures" section.

I'm guessing the way to go is to clearly propose a draft modification on
the mailing list and see if it reaches consensus. Would that be acceptable?

Cheers!

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Streamlining the use of Salsa CI on team packages

2019-09-13 Thread Louis-Philippe Véronneau
On 19-09-13 05 h 57, Thomas Goirand wrote:
> On 9/5/19 7:40 AM, Louis-Philippe Véronneau wrote:
>> Hello folks!
>>
>> I'd like to propose we start using Salsa CI for all the team packages. I
>> think using a good CI for all our packages will help us find packaging
>> bugs and fix errors before uploads :)
> 
> I would agree *IF* and only *IF* we find better runners than the one
> currently default in Salsa. The GCE runners are horribly slow (they are
> the smallest to avoid cost). As a result, some tests may just fail
> because of that, and it becomes just frustrating / annoying noise.

I never experienced such timeouts, but I guess I don't work on very
large packages or things that take more than a few minutes to build.

If what you describe really is caused by the default runners not being
fast enough, why couldn't we ask the Salsa team for more powerful ones?
Have you talked to them about this?

It seems to me that spending money in QA like CI runners is very
profitable for the project, as it saves everyone a lot of time dealing
with unnecessary failure caused by lack of tests. It's not like Debian
is a very poor organisation...

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Getting rid of debian-python.readthedocs.io ?

2019-09-12 Thread Louis-Philippe Véronneau
Hi!

Often I stumble on this readthedocs.io [1] website and it's badly outdated.

Since we already have the Debian Wiki, I'm not sure it's worth keeping
up to date, or at least no one has cared to do so in the last 4 years.
If we really want a sphinx website, we should just build one on Salsa [2].

Is there anyone here with access to that page? I think we should remove
it, but if people want to keep it, at least we should update it :)

[1]: https://debian-python.readthedocs.io/en/latest/debian-policy.html
[2]: https://wiki.debian.org/Salsa/Doc#Web_page_hosting

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Streamlining the use of Salsa CI on team packages

2019-09-12 Thread Louis-Philippe Véronneau
On 19-09-10 14 h 09, Hans-Christoph Steiner wrote:
> 
> 
> Gregor Riepl:
>>
>>> I am not a fan of pointing to a moving target with the "include" statement:
>>>
>>> include:
>>>   - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
>>>   -
>>> https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
>>>
>>> "master" will change, and that can break CI jobs where nothing in the
>>> local repo has changed.
>>
>> It does have pros and cons.
>>
>> The good: Additional build/verification steps or even automatic deployment 
>> can
>> be added by the Salsa team at some point without requiring changes to each
>> repository.
>>
>> The bad: As you mentioned, a moving target can be bad and cause inadvertent
>> build failures and other issues that are out of the hands of maintainers.
>>
>> The ugly: Pulling in external scripts always bears a certain risk. They may 
>> go
>> away at some point or cause potentially dangerous side effects.
>>
>> However, I do think that a standardised CI pipeline is very useful. Consider
>> that the buildd infrastructure also uses a standardised build process that
>> packages cannot simply get away from. If this process is replicated on Salsa,
>> with an external script or not, people will quickly get a "glimpse" of what
>> would happen on buildd. The need to manually adapt the CI script every time
>> something changes in the buildd process is a heavy burden to bear and will
>> easily lead to people "forgetting" to update their scripts. That kind of
>> defeats the purpose.
>>
>> Also, consider that the Salsa CI pipeline is not an absolute source of truth,
>> but a tool for developers and maintainers to quickly spot issues with their
>> packages. If an autobuild fails, it's not the end of the world. It just means
>> you have to go check what's going on.
>>
> 
> I totally agree about having a standardized build process and CI
> pipeline.  And I agree that the CI builds are a tool, not the final
> release build process.

I think we all agree on that :)

I'd like to start working on a draft modification to the DPMT and PAPT
to add a part about using Gitlab CI, but I'm not sure what the process
to change those files is...

How were previous modifications dealt with?

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Streamlining the use of Salsa CI on team packages

2019-09-04 Thread Louis-Philippe Véronneau
Hello folks!

I'd like to propose we start using Salsa CI for all the team packages. I
think using a good CI for all our packages will help us find packaging
bugs and fix errors before uploads :)

I also think that when possible, we should be using the same CI jobs for
our packages. The Salsa CI Team's default pipeline [1] is a good common
ground, as currently it:

* builds the package
* runs piuparts
* runs autopkgtest
* runs lintian
* runs reprotest
* and does more!

I don't think a failing CI should be a blocker for an upload, but I
think it's a good red flag and should be taken in account.

I know the Ruby team also decided to use debian/salsa-ci.yml instead of
debian/gitlab-ci.yml [2]. I guess we should also do the same.

Thoughts? If we decide to go ahead with this, I guess we should modify
the policy accordingly and contact the Salsa Team to see if adding this
additional load is OK with them.

[1] https://salsa.debian.org/salsa-ci-team/pipeline#basic-use
[2] https://salsa.debian.org/salsa-ci-team/pipeline/issues/86#note_106245
-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Mass bug filing for Python2 removal in sid/bullseye

2019-08-30 Thread Louis-Philippe Véronneau
On 19-08-30 11 h 40, Emmanuel Arias wrote:
> El vie., 30 de ago. de 2019 a la(s) 12:25, Steve Cotton (
> st...@s.cotton.clara.co.uk) escribió:
> 
>> On Fri, Aug 30, 2019 at 07:10:36AM +, Matthias Klose wrote:
>>> User: debian-python@lists.debian.org
>>> Usertags: py2removal
>>>
>>> Python2 becomes end-of-live upstream, and Debian aims to remove
>>> Python2 from the distribution, as discussed in
>>> https://lists.debian.org/debian-python/2019/07/msg00080.html
>>
>> Hi Matthias,
>>
>> There's been a previous MBF for games depending on python2-pygame:
>>> User: python-modules-t...@lists.alioth.debian.org
>>> Usertags: python3-migration
>>>
>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-modules-t...@lists.alioth.debian.org=python3-migration
>>
>> BTW, I get a 403 Forbidden when trying to view
>> https://wiki.debian.org/Python/2Removal without logging in to the Wiki.

That's likely because your IP has been blocked. It tends to happen when
using public VPNs and IPs prone to abuse.


-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Joining the DPMT team!

2019-07-02 Thread Louis-Philippe Véronneau
Hi!

I would like to join the DPMT team.

My current goal is to package ponyorm [1] to be able to package
supysonic [2] with the PAPT team (which I'm already part of).

I'm currently am  a non-uploading DD, but I've started packaging stuff
[3] [4] [5].

My Salsa login is: pollo

I have read the DPMT policy [6] and agree to it.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926459
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926457

[3]: https://salsa.debian.org/debian/firmware-tomu
[4]: https://salsa.debian.org/python-team/applications/rename-flac
[5]: https://salsa.debian.org/python-team/applications/membernator

[6]:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: Joining the PAPT team

2019-06-13 Thread Louis-Philippe Véronneau
On 2019-06-01 5:03 p.m., Louis-Philippe Véronneau wrote:
> Hi!
> 
> I would like to join the PAPT team to package various python
> applications I maintain upstream, such as:
> 
> * Imap Spam Begone (isbg) [1]
> * rename-flac [2]
> * genfo [3]
> 
> I'm currently am non-uploading DD, but I've started packaging stuff [4]
> (currently in NEW).
> 
> My Salsa login is: pollo
> 
> I have read the PAPT policy [5] and agree to it.
> 
> [1]: https://github.com/isbg/isbg
> [2]: https://gitlab.com/baldurmen/rename-flac
> [3]: https://gitlab.com/baldurmen/genfo
> [4]: https://salsa.debian.org/debian/firmware-tomu
> [5]:
> https://salsa.debian.org/python-team/tools/python-apps/blob/master/policy.rst
> 

Ping. I haven't heard back from anyone on the list :( I also asked about
this on IRC and no one replied.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Joining the PAPT team

2019-06-01 Thread Louis-Philippe Véronneau
Hi!

I would like to join the PAPT team to package various python
applications I maintain upstream, such as:

* Imap Spam Begone (isbg) [1]
* rename-flac [2]
* genfo [3]

I'm currently am non-uploading DD, but I've started packaging stuff [4]
(currently in NEW).

My Salsa login is: pollo

I have read the PAPT policy [5] and agree to it.

[1]: https://github.com/isbg/isbg
[2]: https://gitlab.com/baldurmen/rename-flac
[3]: https://gitlab.com/baldurmen/genfo
[4]: https://salsa.debian.org/debian/firmware-tomu
[5]:
https://salsa.debian.org/python-team/tools/python-apps/blob/master/policy.rst

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature