Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
On 10/2/23 09:11, Carles Pina i Estany wrote:
Hi,
I've uploaded my first package (python-cloudscraper). I've filled a RFS
(#1053332). I have some questions (some specific to debian-python
organisation)
* Question 1: Git repo
I pushed the code to
https://salsa.debian.org/carlespina/python-cloudscraper/ . Should I,
instead, push it already to
https://salsa.debian.org/python-team/packages/python-cloudscraper/ ?
Yes please.
That might be related to Question 2.
* Question 2: debian/control, Maintainers and Uploaders
I've read
https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst#maintainership
and I think that my favourite, "long term" (does not need to be now),
would be:
Maintainer: Debian Python Team <team+python@tracker.debian.org>
Uploader: Carles Pina i Estany <carles@pina.cat>
Yes. Note that not everyone in the team agree with the Python team
policy of having the team as Uploader, some, including myself, think
that if you don't want other people from the team to upload, you
shouldn't push the package to the team at all. YMMV...
So far I've done:
Maintainer: Carles Pina i Estany <carles@pina.cat>
And no Uploader (will be the sponsor on the first time).
Is that correct?
It's probably preferable to directly put the team as Maintainer.
* Question 3: allow failing tests from upstream in dh_auto_test
Upstream has 4 failing unit tests. Besides working with upstream to fix
them what I've done is, in debian/rules:
-----
override_dh_auto_test:
# Disable tests failing from upstream
pytest -k "not (test_bad_interpreter_js_challenge1_16_05_2020 or test_bad_solve_js_challenge1_16_05_2020 or test_Captcha_challenge_12_12_2019 or test_reCaptcha_providers)"
-----
The reason is that I don't want to disable or even ignore failing unit
tests in the salsa-ci pipeline. If there is a new one failing I'd like
to know. The override_dh_auto_test is my way of having "allowed to fail"
for a specific list. Is there any other, better / recommended / standard
way?
That's very good, and that's exactly what you should do, indeed: have as
many tests running as possible, so that you avoid regression. I would
also strongly suggest to use autopkgtest, to avoid that someone breaks
your package when uploading some of your dependencies.
* Question 4
Any casual comments on the package would be welcomed (even in a
non-sponsor level). For sponsoring: the main reason of packaging this is
that it's an indirect dependency of "simplemonitor". Related bugs:
RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053134
ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053134
ITP of simplemonitor: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016113
Sorry, I wont have time for this right now, but if nobody does it, feel
free to ping me in a week or 2.
Cheers,
Thomas Goirand (zigo)
Reply to: