Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
Hi, I've investigated a bit more and found where I was confused. TL;DR: I'm deleting the non-needed workaround and found where things are happening. On 05 Oct 2023 at 16:36:17, Andrey Rakhmatullin wrote: > On Tue, Oct 03, 2023 at 11:52:58PM +0100, Carles Pina i Estany wrote: > > > upstream tests. Though I think it won't see your explicit `pytest -k` and > > > you should replace the override with a PYBUILD_TEST_ARGS var. > > > > Done this way: > > https://salsa.debian.org/python-team/packages/python-cloudscraper/-/commit/78a83fbb0fe5fdfba78136921b919a11c8c9bc43 > Now you don't need to override dh_auto_test, it should call pytest with > correct args automatically. > > > pytest, as run automatically when having "Testsuite: > > autopkgtest-pkg-pybuild": runs in the directory > > "/tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build" doing > > "python3.11 -m pytest -k ...". > > > > The contents of the directory via "ls -l" can be seen here: > > https://salsa.debian.org/carlespina/python-cloudscraper/-/jobs/4766353#L357) > This gives 404. > > > Because there is the sub-directory > > /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/cloudscraper > It shouldn't be there. They are not there if using all the automatic way. I was using at some point a manual invocation of pytest and then things are not as nice :-) So, using the automatic (generated via autodep8, etc.)...: autodep8 generates: Test-Command: pybuild-autopkgtest Depends: @, pybuild-plugin-autopkgtest, @builddeps@, Restrictions: allow-stderr, skippable, Features: test-name=pybuild-autopkgtest man pybuild-autopkgtest(1): pybuild-autopkgtest will run the tests in exactly the same way as pybuild will dur‐ ing the build, with the exception that the tests are not run in the build directory. The test files are copied to a temporary directory, so that the tests will run against the installed Python modules, and not against anything in the source tree. And yes, it happens in /usr/share/dh-python/dhpython/build/base.py So, all good as long as pybuild-autopkgtest is used (and not pytest invoked manually). I'm happy deleting the d/rules workaround. Cheers, -- Carles Pina i Estany https://carles.pina.cat signature.asc Description: PGP signature
Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
Hi,
On 05 Oct 2023 at 16:38:29, Andrey Rakhmatullin wrote:
> On Wed, Oct 04, 2023 at 07:58:11AM +0100, Carles Pina i Estany wrote:
> > Recap: pytest executed from "pybuild-autopkgtest", in the
> > python-cloudscraper package, would use the src cloudscrapper instead of
> > the installed one.
> >
> > So, to make sure that pytest uses the installed one, I added in
> > debian/rules:
> >
> > -
> > before-pybuild-autopkgtest:
> > mv cloudscraper $(AUTOPKGTEST_TMP)
> >
> > after-pybuild-autopkgtest:
> > mv $(AUTOPKGTEST_TMP) cloudscraper
> This looks very wrong, assuming it even runs.
Well, luckily $(AUTOPKGTEST_TMP) has no spaces :-) (I'll add " ")
Besides the lack of quotes: why does it look wrong? It's documented (or
this is how I understood it) in pybuild-autopkgtest(1), and it's
implemented in /usr/bin/pybuild-autopkgtest:
---
$ENV{PYBUILD_AUTOPKGTEST} = "1";
if (system("grep -q ^before-pybuild-autopkgtest: debian/rules") == 0) {
doit($run, "before-pybuild-autopkgtest");
}
doit($run, "pybuild-autopkgtest");
if (system("grep -q ^after-pybuild-autopkgtest: debian/rules") == 0) {
doit($run, "after-pybuild-autopkgtest");
}
---
Thanks!
--
Carles Pina i Estany
https://carles.pina.cat
Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
Hi, On 05 Oct 2023 at 16:36:17, Andrey Rakhmatullin wrote: > On Tue, Oct 03, 2023 at 11:52:58PM +0100, Carles Pina i Estany wrote: > > > upstream tests. Though I think it won't see your explicit `pytest -k` and > > > you should replace the override with a PYBUILD_TEST_ARGS var. > > > > Done this way: > > https://salsa.debian.org/python-team/packages/python-cloudscraper/-/commit/78a83fbb0fe5fdfba78136921b919a11c8c9bc43 > Now you don't need to override dh_auto_test, it should call pytest with > correct args automatically. Thanks, deleted and tested: all good. Doing something late night I thought that PYBUILD_TEST_ARGS was only for the autopkgtest step and not for the pytest run after the build. > > pytest, as run automatically when having "Testsuite: > > autopkgtest-pkg-pybuild": runs in the directory > > "/tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build" doing > > "python3.11 -m pytest -k ...". > > > > The contents of the directory via "ls -l" can be seen here: > > https://salsa.debian.org/carlespina/python-cloudscraper/-/jobs/4766353#L357) > This gives 404. Apologies, for some reason, the settings of the repo was in Private. The relevant URL for the "ls -l" that I mentiond is here: https://salsa.debian.org/carlespina/python-cloudscraper/-/jobs/4766353#L190 This is how I generated that output: https://salsa.debian.org/carlespina/python-cloudscraper/-/commit/c8a01fca7bb8748da4529c57f2248db9ddb45bc7 > > Because there is the sub-directory > > /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/cloudscraper > It shouldn't be there. I think (and I see with one more package) that it's there if upstream created a directory named PACKAGE_NAME in the root of the repository (instead of doing src/PACKAGE_NAME). Which I think it's quite common, or at least I've seen it other times. I thought that I did something wrong with python-cloudscraper so I got another random one (recently modified, and with the same layout). I added these autopkgtests: -- Test-Command: set -e ; pwd ; ls -l . airspeed; cd "$AUTOPKGTEST_TMP" ; python3 -c "import airspeed ; print(airspeed.__file__)" Depends: python3-airspeed Features: test-name=import-airspeed-system Test-Command: set -e ; python3 -c "import airspeed ; print(airspeed.__file__)" Depends: python3-airspeed Features: test-name=import-airspeed-build -- (seen here: https://salsa.debian.org/carlespina/python-airspeed/-/commit/6ff20a68595be56101b63fbd4db720dee7c90ac9 ) The test with the "cd" to TMP: it imports the system wide airspeed: "/usr/lib/python3/dist-packages/airspeed/__init__.py" (see the output of the ls -l, airspeed, etc. and the airspeed.__file__ in https://salsa.debian.org/carlespina/python-airspeed/-/jobs/4773820#L277 ) The test without the "cd" it imports the bundled one: "/tmp/autopkgtest-lxc.yn973old/downtmp/build.9NT/src/airspeed/__init__.py" (seen in https://salsa.debian.org/carlespina/python-airspeed/-/jobs/4773820#L330) That's why I did my work around of moving "cloudscraper" build directory temporary before running autopkgtest. That lines in debian/rules: before-pybuild-autopkgtest: mv cloudscraper $(AUTOPKGTEST_TMP) after-pybuild-autopkgtest: mv $(AUTOPKGTEST_TMP) cloudscraper > > : for what I can tell, pytest is running the tests with the code from > > /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/cloudscraper > > and not the installed package in > > /usr/lib/python3/dist-packages/cloudscraper/ . Generally speaking, I > > prefer to use the installed code (as done via the basic "import"). > Sure, autopkgtests need to use the installed code. I'm afraid that for some packages layout this is not happening. I am happy to discuss it in another thread (I can open it). I think that, meanwhile, the workaround using "before-pybuild-autopkgtest" in debian/rules makes sense? If I missed, or might have missed something let me know and I will dig more... Thanks for all the feedback! -- Carles Pina i Estany https://carles.pina.cat
Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
On Wed, Oct 04, 2023 at 07:58:11AM +0100, Carles Pina i Estany wrote: > Recap: pytest executed from "pybuild-autopkgtest", in the > python-cloudscraper package, would use the src cloudscrapper instead of > the installed one. > > So, to make sure that pytest uses the installed one, I added in > debian/rules: > > - > before-pybuild-autopkgtest: > mv cloudscraper $(AUTOPKGTEST_TMP) > > after-pybuild-autopkgtest: > mv $(AUTOPKGTEST_TMP) cloudscraper This looks very wrong, assuming it even runs.
Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
On Tue, Oct 03, 2023 at 11:52:58PM +0100, Carles Pina i Estany wrote: > > upstream tests. Though I think it won't see your explicit `pytest -k` and > > you should replace the override with a PYBUILD_TEST_ARGS var. > > Done this way: > https://salsa.debian.org/python-team/packages/python-cloudscraper/-/commit/78a83fbb0fe5fdfba78136921b919a11c8c9bc43 Now you don't need to override dh_auto_test, it should call pytest with correct args automatically. > pytest, as run automatically when having "Testsuite: > autopkgtest-pkg-pybuild": runs in the directory > "/tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build" doing > "python3.11 -m pytest -k ...". > > The contents of the directory via "ls -l" can be seen here: > https://salsa.debian.org/carlespina/python-cloudscraper/-/jobs/4766353#L357) This gives 404. > Because there is the sub-directory > /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/cloudscraper It shouldn't be there. > : for what I can tell, pytest is running the tests with the code from > /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/cloudscraper > and not the installed package in > /usr/lib/python3/dist-packages/cloudscraper/ . Generally speaking, I > prefer to use the installed code (as done via the basic "import"). Sure, autopkgtests need to use the installed code.
Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
Hi Andrey, list On 03 Oct 2023 at 23:52:58, Carles Pina i Estany wrote: > On 03 Oct 2023 at 12:25:27, Andrey Rakhmatullin wrote: > > On Mon, Oct 02, 2023 at 11:32:31PM +0100, Carles Pina i Estany wrote: > > > 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. > > Note that the usual practice is not bumping Debian versions for packages > > that were not uploaded yet and always uploading -1. > > Note taken, thanks! It will stay in -1 until uploaded. Makes it even > easier. > > > > 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... > > Yeah. > > And you should try "Testsuite: autopkgtest-pkg-pybuild" instead, to run > > Ha! I didn't know of autopkgtest-pkg-pybuild. Thanks for this! > > > upstream tests. Though I think it won't see your explicit `pytest -k` and > > you should replace the override with a PYBUILD_TEST_ARGS var. > > Done this way: > https://salsa.debian.org/python-team/packages/python-cloudscraper/-/commit/78a83fbb0fe5fdfba78136921b919a11c8c9bc43 > > When I added it, the automatic simple test from autodep8 (importing the > module) stopped being added. > > pytest, as run automatically when having "Testsuite: > autopkgtest-pkg-pybuild": runs in the directory > "/tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build" doing > "python3.11 -m pytest -k ...". > > The contents of the directory via "ls -l" can be seen here: > https://salsa.debian.org/carlespina/python-cloudscraper/-/jobs/4766353#L357) > > Because there is the sub-directory > /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/cloudscraper > : for what I can tell, pytest is running the tests with the code from > /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/cloudscraper > and not the installed package in > /usr/lib/python3/dist-packages/cloudscraper/ . Generally speaking, I > prefer to use the installed code (as done via the basic "import"). > > Once, in a similar situation, some files were shipped but not installed > and the tests were running but not for the user. > > So I still added this: > --- > Test-Command: set -e ; cd "$AUTOPKGTEST_TMP" ; python3 -c "import > cloudscraper" > Depends: python3-cloudscraper > Features: test-name=import-cloudscraper > --- > (simplified from the the original code done by autodep8) Recap: pytest executed from "pybuild-autopkgtest", in the python-cloudscraper package, would use the src cloudscrapper instead of the installed one. So, to make sure that pytest uses the installed one, I added in debian/rules: - before-pybuild-autopkgtest: mv cloudscraper $(AUTOPKGTEST_TMP) after-pybuild-autopkgtest: mv $(AUTOPKGTEST_TMP) cloudscraper - https://salsa.debian.org/carlespina/python-cloudscraper/-/commit/c4ad00d05f9a7cf95c1c62d9fc791bf2cf0f222d Then I could delete (seems redundant now) what I did last night (debian/tests/control): - Test-Command: set -e ; cd "$AUTOPKGTEST_TMP" ; python3 -c "import cloudscraper" Depends: python3-cloudscraper Features: test-name=import-cloudscraper - Which was testing the import from the installed package. Any thoughts? -- Carles Pina i Estany https://carles.pina.cat
Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
Hi Andrey, list, On 03 Oct 2023 at 12:25:27, Andrey Rakhmatullin wrote: > On Mon, Oct 02, 2023 at 11:32:31PM +0100, Carles Pina i Estany wrote: > > 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. > Note that the usual practice is not bumping Debian versions for packages > that were not uploaded yet and always uploading -1. Note taken, thanks! It will stay in -1 until uploaded. Makes it even easier. > > 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... > Yeah. > And you should try "Testsuite: autopkgtest-pkg-pybuild" instead, to run Ha! I didn't know of autopkgtest-pkg-pybuild. Thanks for this! > upstream tests. Though I think it won't see your explicit `pytest -k` and > you should replace the override with a PYBUILD_TEST_ARGS var. Done this way: https://salsa.debian.org/python-team/packages/python-cloudscraper/-/commit/78a83fbb0fe5fdfba78136921b919a11c8c9bc43 When I added it, the automatic simple test from autodep8 (importing the module) stopped being added. pytest, as run automatically when having "Testsuite: autopkgtest-pkg-pybuild": runs in the directory "/tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build" doing "python3.11 -m pytest -k ...". The contents of the directory via "ls -l" can be seen here: https://salsa.debian.org/carlespina/python-cloudscraper/-/jobs/4766353#L357) Because there is the sub-directory /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/cloudscraper : for what I can tell, pytest is running the tests with the code from /tmp/autopkgtest-lxc.u3g8w1m_/downtmp/autopkgtest_tmp/build/cloudscraper and not the installed package in /usr/lib/python3/dist-packages/cloudscraper/ . Generally speaking, I prefer to use the installed code (as done via the basic "import"). Once, in a similar situation, some files were shipped but not installed and the tests were running but not for the user. So I still added this: --- Test-Command: set -e ; cd "$AUTOPKGTEST_TMP" ; python3 -c "import cloudscraper" Depends: python3-cloudscraper Features: test-name=import-cloudscraper --- (simplified from the the original code done by autodep8) > > 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": > It says "each supported package type is tried against a set of heuristics, > based on packages names, build dependencies. specific files under debian/, > or a combination of those", or do you mean something else? I read it differently / expressed myself badly :-( TL;DR: I understood it now. I'm just explaining below what I had read and understood wrongly. In the section just above your text (AUTOMATIC USAGE BY AUTOPKGTEST) it says: "autodep8 can be automatically called by autopkgtest(1). To achieve that, you must set the Testsuite: field in the source package paragraph to autopkgtest-pkg-TYPE," Because debian/control didn't have the line "Testsuite: " I thought that the rest of the text didn't really apply and I didn't expect the automatic "import" to happen (which I liked, not complaining!). In the next section: "autodep8 will first look for Testsuite: autopkgtest-pkg-TYPE field in debian/control. if TYPE is a known package type, then that is used. If not, each supported package type is tried against a set of heuristics,"... I read (yesterday) "if TYPE is a known package type, then that is used. If is not a known package type, then the heuristics..." Basically I had understood that I needed "Testsuite: autopkgtest-pkg-SOMETHING" (where SOMETHING is a non-supported one) to enable the automatic heuristics. But that "Testsuite: " line was required to enable it. Anyway, all clear on this front! Thanks very much! -- Carles Pina i Estany https://carles.pina.cat
Re: first package questions (salsa repo in personal or team, debian/control maintainers, expected failing unit tests)
On Mon, Oct 02, 2023 at 11:32:31PM +0100, Carles Pina i Estany wrote: > 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. Note that the usual practice is not bumping Debian versions for packages that were not uploaded yet and always uploading -1. > 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... Yeah. And you should try "Testsuite: autopkgtest-pkg-pybuild" instead, to run upstream tests. Though I think it won't see your explicit `pytest -k` and you should replace the override with a PYBUILD_TEST_ARGS var. > 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": It says "each supported package type is tried against a set of heuristics, based on packages names, build dependencies. specific files under debian/, or a combination of those", or do you mean something else?
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
