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