Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
Hi Thomas, list, On 02 Oct 2023 at 14:11:54, Thomas Goirand wrote: > 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. Done: https://salsa.debian.org/python-team/packages/python-cloudscraper/ (including the CI/CD setup) > > 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 > > Uploader: Carles Pina i Estany > > 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... Changed. I didn't want to add the team in "Maintainer:" before double checking with the team. I will do it straight away on the next package (python-pyaarlo, the other missing dependency of simplemonitor) I will create a new version of the package and upload it into mentors.debian.net when I finish this email. For reference: it will be the version 1.2.69-3. > > So far I've done: > > Maintainer: Carles Pina i Estany > > 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. :-) didn't want to impose it on my first attempt before seeing the dynamic. > > * 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. In my first version (not published) I wrote a simple autopkgtest with an "import cloudscraper" (I know that this is not fully testing everything but at least something!). Then I realised that it's not needed... without debian/tests it's just doing it: https://salsa.debian.org/python-team/packages/python-cloudscraper/-/jobs/4762103#L180 """ autopkgtest [22:24:36]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import cloudscraper; print(cloudscraper)" ; done """ I don't see this mentioned in "man autodep8": https://manpages.debian.org/testing/autodep8/autodep8.1.en.html (should it be there?) But it's done this way: https://salsa.debian.org/ci-team/autodep8/-/blob/master/support/python/generate#L78 > > * 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. Very appreciated, I take note. -- Carles Pina i Estany https://carles.pina.cat || Wiktionary translations: https://kamus.pina.cat
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 Uploader: Carles Pina i Estany 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 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)
first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
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/ ? 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 Uploader: Carles Pina i Estany So far I've done: Maintainer: Carles Pina i Estany And no Uploader (will be the sponsor on the first time). Is that correct? * 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? * 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 Thank you, -- Carles Pina i Estany https://carles.pina.cat || Wiktionary translations: https://kamus.pina.cat
