Hello,

As discussed during the DebConf24 Python BoF, I'm submitting this change
to the policy to require the use of the upstream test suite, both during
the build process and as an autopkgtest.

You can find the MR here:

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

People present at the BoF seemed to think this was a good idea. If you
don't please reply to this message and make yourself heard :)

Cheers,

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I have one concerne when using pybuild autopkgtest.

It install by default the build dependencies. which is not what peoples are doing when they install the packages.
It should be possible to define the autopkgtest dependencies. This way we could catch missing dependencies in python-<modules> dependencies.

Is it possible ?


Cheers

Frederic

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On July 29, 2024 8:53:11 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

Hello,

As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest.

You can find the MR here:

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

People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :)

I understand the theory and why it's a good idea to run the test suite. I don't think it ought to be a hard requirement. I have several packages where there's a test suite, but I don't run it:

1. The largest set is packages that need test only dependencies which are not packaged. When I am packaging something new which has a test suite, then I generally package any needed test depends. If those test depends also need test depends packaged, I
generally stop and don't enable tests for things that are only in the archives to support tests. Noseofyeti is an example of this.

2. There's at least one case where Debian has customizations that cause the test suite to fail, but the failures don't seem to cause any real problems. If anyone wants to make it so the weasyprint test suite works on Debian, please knock yourself out.

3. I also maintain multiple packages which require network access to run their test suite, so they can't run tests during build, only autopkgtests.

While I agree that running tests is good, it's not a universally reasonable requirement.

If we add this as a hard requirement for team packages, what do people think will happen? Will people invest more volunteer time that they otherwise wouldn't have to add running tests? Will they leave it for someone else on the team to address? Will
they remove packages from team maintenance?

Python policy is only enforceable within the team. For the rest of the archive, it's a statement of best practices for people to consider. Making this a hard requirement for team packages is a statement that we would rather such packages not be team
maintained. I don't think that's a good idea.

Scott K

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr>:

It install by default the build dependencies. which is not what
peoples are doing when they install the packages.
It should be possible to define the autopkgtest dependencies. This
way we could catch missing dependencies in python-<modules>
dependencies.

Is it possible ?

I believe (didn't check so many packages), in most cases
installing the build dependencies is the better option:

1. There might be testing frameworks to install as b-d, but
not as Depend.

2. Many unit test suites check various variants and optional
behaviour, that might be separated in different binary
packages (think of myapp-postgres and myapp-mariadb, etc.)

Maybe as an option for some packages?

Or a different kind of test, running on top of piuparts?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 29, 2024 at 03:30:39PM +0200, PICCA Frederic-Emmanuel wrote:

My use case, is to check that all the Dependencies computer by dh_python3 from the build tools are indeed listed in the Depends of the binary package.

Maybe we indeed want a "minimal" autopkgtest environment, but many
upstream tests will fail in those and I don't see an automatic way to test
a random package in this way.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmann0EtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh TA4QAKYeofVZQiHhu0Py9sJreefek4mSpMQkc0ySIi0p4kGlhf2MghDduckeZFSk zsi9KuNWnC7lEe39dM3+lveOs/gyDggc1bhxxWjIYHmmGbRNTAdEkL+EjAof2HE1 D5SswwF03qVhGsbDM5kgDlNAUPyLWCMQ22tkkMVL9xF+U4focdsvkco6zIOjUO2u K4ooof7pT+iSeyKOmwYfGq9mFuKyHMIIuD3FNQ2F9KwgMfYG0xLTOi0STBXW8Uyt ZltAB7YKi4/tPycpn/7R7T2SJp2XwF0LstlPrKYiqnMCIT/YaUIvPdPiHfefbO5J jofx+zWi+DuI3qwm8buyTOAOO4A+aIMzLTRuWYVJ6HxBtWj9FR3th2vAZn+wzs0b 1DjiqW/vPGq911aXk3sphDURdGu3CMRcwXVUIqvDdgXUQNSHLPrxLeiMYuk7Lcgu v5wbmOA1VBnn1AVl+hLwkkNHggE0DbT5/cfzoRv8CJq+8OE8X61EOr0SW3ivfLxh Vcer4Z0CF8+eVLPLKUvqnb6BOMUmJ5cZ3m0fYc6gug/xrmqZIa8dP1+1kZLBHdhD g8q/JpUrl5V8gvW/1h+pkibvDZKfsmHecu4LlK7tnG72HTgpX+RHZIESpCUg1Gg6 zXo+p1NU5msJmSB2uXAL6Q2n1qMoQ8D2yI2hI/XdT97u+Teo
=+qVJ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

My use case, is to check that all the Dependencies computer by dh_python3 from the build tools are indeed listed in the Depends of the binary package.

I think about package whcih provide oiptional dependencies via the extra. In that case the extra should be declare when calling dh_python3.

So I must install only the python3-<module> and the test framework to be sure that it is fonctionnal as installed.

It seems to me that the autopkgtest-pybuild plugin is not well suited for this purpose. (as it is now).

Cheers

Frederic

For piupart, I alsao have some test that should be perfore with one of my package

the upgrade of a database.

I should install the package, upgrade it and check that the new version has the right database upgraded.

Is it possible to test upgrade scenario with autopkgtests ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hey,

Louis-Philippe Véronneau <pollo@debian.org> wrote on 29/07/2024 at 10:53:11+0200:

Hello,

As discussed during the DebConf24 Python BoF, I'm submitting this
change to the policy to require the use of the upstream test suite,
both during the build process and as an autopkgtest.

You can find the MR here:

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

People present at the BoF seemed to think this was a good idea. If you
don't please reply to this message and make yourself heard :)

Cheers,

I spend a lot of time trying to make the upstream tests working in
package building, but I'm against enforcing this.

There are a lot of packages with good code but crappy tests, and we
don't want to force ourselves maintaining these, and dropping the
packages seem a bit too much.

--
PEB

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEE5CQeth7uIW7ehIz87iFbn7jEWwsFAmanok4PHHBlYkBkZWJp YW4ub3JnAAoJEO4hW5+4xFsLdZ0P/RgW6WkDvHRVqIgr+7p7i8fSOqaA2P6nZvNq DNSR3Wu2zdgra+VFwcr0Ace599YkkI6kJIslHzkWEBBL9GpL6S0pkRvGA5scsDQs YR4npAk2xjQ2sKWtr5h64K5bpEgVDtLE2WwZMrEKm5W9YyuxyoEuL5K3Ey9rrH59 svNTD3jom777cy1W5qyyCZ/1ZpcCY2uT6jCKPhrBaO+gxQACE3O0hHRLQo9Rr8r5 t11Tgf47PWaafRj2mZalaWoKa1MOTpttZV0CXEH7XfqCQ1LIFt0KRNsRbYpvaeCS AVdRSIpObMJyOLXdaFawZRZYhf5l+Hqb4nZN2O5oVFjqodnh3OX3N/WG26X51+Ml K4rM9V/MIC2yF/IV+ky6IFYjZhgvpZJnAoKcG7CeR+5Vda8Tg8GNAZoQkpFeHcX3 05AFfqpRkYypgHYR/CtUPc8E8Enq3SnURMi9R4b3KRsamYF0+ib1PaemTQGeXzGf dvCqYvkNP1f8mSNEtErpMXd8VBfIOvhFeYSzQ1FJB/7310NB2juxRdoyfuH/7Sje ZEI2+Smxp7pZzLAnbDhZZDvSjvkskC4He0j2wbuqBBA/94F5duZx1w9DogTRN6bi yX7K9EgqhQVVIfJq1HiaJR7is3NNCVTJxIpQsNcDPApiCwlmaoPMTbaMEL/BwECC
zOeGs/PB
=EQZy
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 29 Jul 2024 at 12:07:27 +0000, Scott Kitterman wrote:

While I agree that running tests is good, it's not a universally
reasonable requirement.

I agree. In a project as large as Debian, most requirements similar to
this one at least need the qualifier "... unless there is a reason why
we can't".

2. There's at least one case where Debian has customizations that
cause the test suite to fail, but the failures don't seem to cause any
real problems. If anyone wants to make it so the weasyprint test suite
works on Debian, please knock yourself out.

This seems like the situation is:

- a build-time test or autopkgtest test failure would be a
release-critical bug

- upstream tests failing always indicate a bug, but that bug might not
be RC:
- the tests might be broken, flaky or make assumptions that aren't
true in Debian (the tests have a bug, the package under test does not)
- or the tests might be showing us a genuine bug in the package
under test, but its severity might be anywhere between wishlist
and critical

- in the case of this specific package, Scott has assessed the severity of
the bug that is implied by the tests failing, and has decided that it's
Severity: normal or less

and that seems fine.

Ideally there would be a bug open in the BTS to document this limitation, possibly only wishlist, possibly tagged help.

If part of the test suite is fine but a different part of the test suite
is problematic, I'd personally prefer to flag the problematic parts as skipped/ignored, and run the rest (for example src:python3-mpd skips some
of its tests like this); but it's reasonable for opinions on this to vary,
and I don't know whether there would be anything left in this particular package's test suite after skipping the problematic parts.

3. I also maintain multiple packages which require network access
to run their test suite, so they can't run tests during build, only autopkgtests.

Running the test suite for these would be a Debian Policy violation
(usually a RC bug), and if Python team policy conflicts with Debian Policy, it's Debian Policy that wins.

If we add this as a hard requirement for team packages, what do people
think will happen? Will people invest more volunteer time that they otherwise wouldn't have to add running tests? Will they leave it for
someone else on the team to address? Will they remove packages from
team maintenance?

These are all valid questions. It's very easy to create new QA
requirements that are simple to achieve for simple packages, but for the packages where they are not so simple, someone who feels that a particular level of QA coverage is valuable will need to step up to do that work,
and threatening contributors with sanctions if they don't do particular
work ("we'll throw you out of the team" or "we'll delete the package
you've invested time in from Debian" or similar) should be rare and a
last resort.

We often say that Debian Policy is (and should be) a tool for getting
a better distribution, and not a stick to beat contributors with. I
think the same should be equally true for individual teams' self-imposed policies.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On July 29, 2024 3:14:33 PM UTC, PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> wrote:

Maybe we indeed want a "minimal" autopkgtest environment, but many
upstream tests will fail in those and I don't see an automatic way to test >> a random package in this way.

Even if not minimal, at least correspond to the upstream declares dependencies.

by 'declare' I am not even sure of the meaning.

dependencies of the test can be different from the required installed ones.

Maybe we should install only the python binaries and the dependencies marked <!nocheck>.

Is there a standard in the Python community for the test dependencies ?

As usual, there are several.

Scott K

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Maybe we indeed want a "minimal" autopkgtest environment, but many
upstream tests will fail in those and I don't see an automatic way to test
a random package in this way.

Even if not minimal, at least correspond to the upstream declares dependencies.

by 'declare' I am not even sure of the meaning.

dependencies of the test can be different from the required installed ones.

Maybe we should install only the python binaries and the dependencies marked <!nocheck>.

Is there a standard in the Python community for the test dependencies ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 29, 2024 at 12:07:27PM +0000, Scott Kitterman wrote:

I understand the theory and why it's a good idea to run the test suite. I don't think it ought to be a hard requirement. I have several packages where there's a test suite, but I don't run it:
[...]

Here's another case: the package has to be fully installed for the
test suite to work. So the tests can't be run at build time, only at autopkgtest time.

Best wishes,

Julian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-29 21:07, Scott Kitterman wrote:

On July 29, 2024 8:53:11 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

Hello,

As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest.

You can find the MR here:

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

People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :)

I understand the theory and why it's a good idea to run the test suite. I don't think it ought to be a hard requirement. I have several packages where there's a test suite, but I don't run it:

1. The largest set is packages that need test only dependencies which are not packaged. When I am packaging something new which has a test suite, then I generally package any needed test depends. If those test depends also need test depends packaged,

I generally stop and don't enable tests for things that are only in the archives to support tests. Noseofyeti is an example of this.

That sounds like a valid technical reason not to run the tests to me :)

2. There's at least one case where Debian has customizations that cause the test suite to fail, but the failures don't seem to cause any real problems. If anyone wants to make it so the weasyprint test suite works on Debian, please knock yourself out.

Again, as long as you document that, I don't think it would go against
the proposed policy change.

3. I also maintain multiple packages which require network access to run their test suite, so they can't run tests during build, only autopkgtests.

Same.


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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-29 23:08, Pierre-Elliott Bécue wrote:

Hey,

Louis-Philippe Véronneau <pollo@debian.org> wrote on 29/07/2024 at 10:53:11+0200:

Hello,

As discussed during the DebConf24 Python BoF, I'm submitting this
change to the policy to require the use of the upstream test suite,
both during the build process and as an autopkgtest.

You can find the MR here:

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

People present at the BoF seemed to think this was a good idea. If you
don't please reply to this message and make yourself heard :)

Cheers,

I spend a lot of time trying to make the upstream tests working in
package building, but I'm against enforcing this.

There are a lot of packages with good code but crappy tests, and we
don't want to force ourselves maintaining these, and dropping the
packages seem a bit too much.

I'd file that under "a technical issue [that] prevents you from running
the test suite and you believe the reason to be valid".

:)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-30 11:09, Scott Kitterman wrote:

On July 30, 2024 12:49:50 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

On 2024-07-29 21:07, Scott Kitterman wrote:

On July 29, 2024 8:53:11 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

Hello,

As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest.

You can find the MR here:

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

People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :)

I understand the theory and why it's a good idea to run the test suite. I don't think it ought to be a hard requirement. I have several packages where there's a test suite, but I don't run it:

1. The largest set is packages that need test only dependencies which are not packaged. When I am packaging something new which has a test suite, then I generally package any needed test depends. If those test depends also need test depends

packaged, I generally stop and don't enable tests for things that are only in the archives to support tests. Noseofyeti is an example of this.

That sounds like a valid technical reason not to run the tests to me :)

2. There's at least one case where Debian has customizations that cause the test suite to fail, but the failures don't seem to cause any real problems. If anyone wants to make it so the weasyprint test suite works on Debian, please knock yourself

out.

Again, as long as you document that, I don't think it would go against the proposed policy change.

3. I also maintain multiple packages which require network access to run their test suite, so they can't run tests during build, only autopkgtests.

Same.

Except for #3, I don't get that from the wording in the MR. I don't think not worth the trouble is a technical reason. I think the real rule that's being proposed is that packages must run the test suit or document why not. I don't have a problem

with that, but I don't think that's what it actually says now. I think if you were to change must to should and strike the word technical before reason, it would accomplish the same thing and be clearer. I could support that.

Language is hard and I'm not a native English speaker :)

What I want to prevent is people not running tests because they don't
feel like it, even though it would not take them a large amount of
efforts to do so.

I'll strike "technical", as it seems others also interpreted this word
they way you have.

As for "MUST" vs "SHOULD", I believe the exception clause provides
enough leeway to justify a reasonable way out in case of $VALID_REASON.

"SHOULD" is not particularly strong and again, I fear it would let
people get away with not running tests although it wouldn't be much work
to do so...

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On July 30, 2024 12:49:50 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

On 2024-07-29 21:07, Scott Kitterman wrote:

On July 29, 2024 8:53:11 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

Hello,

As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest.

You can find the MR here:

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

People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :)

I understand the theory and why it's a good idea to run the test suite. I don't think it ought to be a hard requirement. I have several packages where there's a test suite, but I don't run it:

1. The largest set is packages that need test only dependencies which are not packaged. When I am packaging something new which has a test suite, then I generally package any needed test depends. If those test depends also need test depends packaged,

I generally stop and don't enable tests for things that are only in the archives to support tests. Noseofyeti is an example of this.

That sounds like a valid technical reason not to run the tests to me :)

2. There's at least one case where Debian has customizations that cause the test suite to fail, but the failures don't seem to cause any real problems. If anyone wants to make it so the weasyprint test suite works on Debian, please knock yourself

out.

Again, as long as you document that, I don't think it would go against the proposed policy change.

3. I also maintain multiple packages which require network access to run their test suite, so they can't run tests during build, only autopkgtests.

Same.

Except for #3, I don't get that from the wording in the MR. I don't think not worth the trouble is a technical reason. I think the real rule that's being proposed is that packages must run the test suit or document why not. I don't have a problem with
that, but I don't think that's what it actually says now. I think if you were to change must to should and strike the word technical before reason, it would accomplish the same thing and be clearer. I could support that.

Scott K

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On July 30, 2024 2:47:08 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

On 2024-07-30 11:09, Scott Kitterman wrote:

On July 30, 2024 12:49:50 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

On 2024-07-29 21:07, Scott Kitterman wrote:

On July 29, 2024 8:53:11 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

Hello,

As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest.

You can find the MR here:

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

People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :)

I understand the theory and why it's a good idea to run the test suite. I don't think it ought to be a hard requirement. I have several packages where there's a test suite, but I don't run it:

1. The largest set is packages that need test only dependencies which are not packaged. When I am packaging something new which has a test suite, then I generally package any needed test depends. If those test depends also need test depends

packaged, I generally stop and don't enable tests for things that are only in the archives to support tests. Noseofyeti is an example of this.

That sounds like a valid technical reason not to run the tests to me :)

2. There's at least one case where Debian has customizations that cause the test suite to fail, but the failures don't seem to cause any real problems. If anyone wants to make it so the weasyprint test suite works on Debian, please knock yourself

out.

Again, as long as you document that, I don't think it would go against the proposed policy change.

3. I also maintain multiple packages which require network access to run their test suite, so they can't run tests during build, only autopkgtests.

Same.

Except for #3, I don't get that from the wording in the MR. I don't think not worth the trouble is a technical reason. I think the real rule that's being proposed is that packages must run the test suit or document why not. I don't have a problem

with that, but I don't think that's what it actually says now. I think if you were to change must to should and strike the word technical before reason, it would accomplish the same thing and be clearer. I could support that.

Language is hard and I'm not a native English speaker :)

What I want to prevent is people not running tests because they don't feel like it, even though it would not take them a large amount of efforts to do so.

I'll strike "technical", as it seems others also interpreted this word they way you have.

As for "MUST" vs "SHOULD", I believe the exception clause provides enough leeway to justify a reasonable way out in case of $VALID_REASON.

"SHOULD" is not particularly strong and again, I fear it would let people get away with not running tests although it wouldn't be much work to do so...

I guess it depends on how you look at the word. In the context of technical specifications, I tend to think of terms as defined in RFC 2119 [1]. I think that's pretty close to what you are suggesting:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

The way RFC 2119 defines MUST doesn't leave much room for exceptions. If you want to be clear, I suggest SHOULD with a reference to RFC 2119. While not universal, it is a widely used reference for definitions of these terms in technical specifications.

Scott K

[1] https://datatracker.ietf.org/doc/html/rfc2119#section-3

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-30 12:58, Scott Kitterman wrote:

On July 30, 2024 2:47:08 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

On 2024-07-30 11:09, Scott Kitterman wrote:

On July 30, 2024 12:49:50 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

On 2024-07-29 21:07, Scott Kitterman wrote:

On July 29, 2024 8:53:11 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

Hello,

As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest.

You can find the MR here:

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

People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :)

I understand the theory and why it's a good idea to run the test suite. I don't think it ought to be a hard requirement. I have several packages where there's a test suite, but I don't run it:

1. The largest set is packages that need test only dependencies which are not packaged. When I am packaging something new which has a test suite, then I generally package any needed test depends. If those test depends also need test depends

packaged, I generally stop and don't enable tests for things that are only in the archives to support tests. Noseofyeti is an example of this.

That sounds like a valid technical reason not to run the tests to me :) >>>>

2. There's at least one case where Debian has customizations that cause the test suite to fail, but the failures don't seem to cause any real problems. If anyone wants to make it so the weasyprint test suite works on Debian, please knock yourself

out.

Again, as long as you document that, I don't think it would go against the proposed policy change.

3. I also maintain multiple packages which require network access to run their test suite, so they can't run tests during build, only autopkgtests.

Same.

Except for #3, I don't get that from the wording in the MR. I don't think not worth the trouble is a technical reason. I think the real rule that's being proposed is that packages must run the test suit or document why not. I don't have a problem

with that, but I don't think that's what it actually says now. I think if you were to change must to should and strike the word technical before reason, it would accomplish the same thing and be clearer. I could support that.

Language is hard and I'm not a native English speaker :)

What I want to prevent is people not running tests because they don't feel like it, even though it would not take them a large amount of efforts to do so.

I'll strike "technical", as it seems others also interpreted this word they way you have.

As for "MUST" vs "SHOULD", I believe the exception clause provides enough leeway to justify a reasonable way out in case of $VALID_REASON.

"SHOULD" is not particularly strong and again, I fear it would let people get away with not running tests although it wouldn't be much work to do so...

I guess it depends on how you look at the word. In the context of technical specifications, I tend to think of terms as defined in RFC 2119 [1]. I think that's pretty close to what you are suggesting:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

The way RFC 2119 defines MUST doesn't leave much room for exceptions. If you want to be clear, I suggest SHOULD with a reference to RFC 2119. While not universal, it is a widely used reference for definitions of these terms in technical

specifications.

Scott K

[1] https://datatracker.ietf.org/doc/html/rfc2119#section-3

Fair enough. I also made that change.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On July 30, 2024 4:27:48 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

On 2024-07-30 12:58, Scott Kitterman wrote:

On July 30, 2024 2:47:08 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

On 2024-07-30 11:09, Scott Kitterman wrote:

On July 30, 2024 12:49:50 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

On 2024-07-29 21:07, Scott Kitterman wrote:

On July 29, 2024 8:53:11 AM UTC, "Louis-Philippe Véronneau" <pollo@debian.org> wrote:

Hello,

As discussed during the DebConf24 Python BoF, I'm submitting this change to the policy to require the use of the upstream test suite, both during the build process and as an autopkgtest.

You can find the MR here:

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

People present at the BoF seemed to think this was a good idea. If you don't please reply to this message and make yourself heard :)

I understand the theory and why it's a good idea to run the test suite. I don't think it ought to be a hard requirement. I have several packages where there's a test suite, but I don't run it:

1. The largest set is packages that need test only dependencies which are not packaged. When I am packaging something new which has a test suite, then I generally package any needed test depends. If those test depends also need test depends

packaged, I generally stop and don't enable tests for things that are only in the archives to support tests. Noseofyeti is an example of this.

That sounds like a valid technical reason not to run the tests to me :) >>>>>

2. There's at least one case where Debian has customizations that cause the test suite to fail, but the failures don't seem to cause any real problems. If anyone wants to make it so the weasyprint test suite works on Debian, please knock

yourself out.

Again, as long as you document that, I don't think it would go against the proposed policy change.

3. I also maintain multiple packages which require network access to run their test suite, so they can't run tests during build, only autopkgtests.

Same.

Except for #3, I don't get that from the wording in the MR. I don't think not worth the trouble is a technical reason. I think the real rule that's being proposed is that packages must run the test suit or document why not. I don't have a problem

with that, but I don't think that's what it actually says now. I think if you were to change must to should and strike the word technical before reason, it would accomplish the same thing and be clearer. I could support that.

Language is hard and I'm not a native English speaker :)

What I want to prevent is people not running tests because they don't feel like it, even though it would not take them a large amount of efforts to do so.

I'll strike "technical", as it seems others also interpreted this word they way you have.

As for "MUST" vs "SHOULD", I believe the exception clause provides enough leeway to justify a reasonable way out in case of $VALID_REASON.

"SHOULD" is not particularly strong and again, I fear it would let people get away with not running tests although it wouldn't be much work to do so...

I guess it depends on how you look at the word. In the context of technical specifications, I tend to think of terms as defined in RFC 2119 [1]. I think that's pretty close to what you are suggesting:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

The way RFC 2119 defines MUST doesn't leave much room for exceptions. If you want to be clear, I suggest SHOULD with a reference to RFC 2119. While not universal, it is a widely used reference for definitions of these terms in technical

specifications.

Scott K

[1] https://datatracker.ietf.org/doc/html/rfc2119#section-3

Fair enough. I also made that change.

Thanks,

Scott K

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Cgo+ID5GYWlyIGVub3VnaC4gSSBhbHNvIG1hZGUgdGhhdCBjaGFuZ2UuIAoKPgoKPiBUaGFua3Ms IAoKPgoKPiBTY290dCBLIAoKCllvdSBoYXZlIG15ICsxIHdpdGggdGhlIGN1cnJlbnQgd29yZGlu Zy4KCgpDaGVlcnMsCgoKVGhvbWFzIEdvaXJhbmQgKHppZ28pCgoK PGh0bWw+PGJvZHk+PGJyPjxkaXYgZGlyPSJsdHIiPiZndDsgJmd0O0ZhaXIgZW5vdWdoLiBJIGFs c28gbWFkZSB0aGF0IGNoYW5nZS4gPC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDs8L2Rpdj4KPGRp diBkaXI9Imx0ciI+Jmd0OyBUaGFua3MsIDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7PC9kaXY+ CjxkaXYgZGlyPSJsdHIiPiZndDsgU2NvdHQgSyA8L2Rpdj4KPGJyPjxkaXYgZGlyPSJsdHIiPllv dSBoYXZlIG15ICsxIHdpdGggdGhlIGN1cnJlbnQgd29yZGluZy48L2Rpdj4KPGJyPjxkaXYgZGly PSJsdHIiPkNoZWVycyw8L2Rpdj4KPGJyPjxkaXYgZGlyPSJsdHIiPlRob21hcyBHb2lyYW5kICh6 aWdvKTwvZGl2Pgo8YnI+PC9ib2R5PjwvaHRtbD4=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Those will correspond to build dependencies in a typical simple case, as
the upstream tests need all those optional deps, assuming you mean the
tests dependencies (and not the runtime dependencies which should already
be in Depends).

Yes the runtime dependencies should be listed in the python3-<module> Depends:

Maybe we should install only the python binaries and the dependencies marked
<!nocheck>.

In a typical simple case all B-Ds except sphinx stuff will be <!nocheck>
as you don't need anything beyond the build system to "build" a pure
Python module.

So this is exactly what you wanted to avoid.

Yes, I want to be sure that all the runtime dependencies are rightfully declared in the Depends of the python module package.

sometimes the upstream forgot about dependencies, or mark them as optional, but they are not when running the tests...

Is it possible to achieve this automatically ? lintian ? dh-python ? python3-stdeb ?

Fred.

PS: In haskell we have a cabal-debian package which compute automatically the list of the Dependencies, from the cabal file, then it update the control file to reflect the new status of the package.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 29, 2024 at 05:14:33PM +0200, PICCA Frederic-Emmanuel wrote:

Maybe we indeed want a "minimal" autopkgtest environment, but many
upstream tests will fail in those and I don't see an automatic way to test a random package in this way.

Even if not minimal, at least correspond to the upstream declares dependencies.

Those will correspond to build dependencies in a typical simple case, as
the upstream tests need all those optional deps, assuming you mean the
tests dependencies (and not the runtime dependencies which should already
be in Depends).

Maybe we should install only the python binaries and the dependencies marked <!nocheck>.

In a typical simple case all B-Ds except sphinx stuff will be <!nocheck>
as you don't need anything beyond the build system to "build" a pure
Python module.

So this is exactly what you wanted to avoid.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmaopMEtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh GjsP/i7y6egwe8t52C3ZtbVsa9cQlyICqMStbnWmKRDxPOfWXdG5jT/ndutmCZFX +6O7tJmicM0+zI9R5Fdf90OiVCkez+Edvk5l2MWvIZsWq9c4BHm7IOdpVHyfHo1A HTifYfMcPEPNok1tN43jyAESQ1fI5VA+kbBo1wMeNPf9ZEGVeqNTrbGc4gCeze2s JdhxHZiGbzoYTbQD5MF9/a8F0NPX+7KsDWQ6+EKZSivx58Hm15T1QIRjRD5tZkdf jizB+d8NODOgGCOpHwX5ImiK5T8q06ORJlc0bDbKrE0Iqrh9WzrIADiSLmfcDJUp vDJ9v8fmhMnkn/JiWLcP/Rx2kqwaJTrYRexwv4rwIDlj9BwJbH0LcUzakrHm8I8D GqZpe5zbBTUGCyhi9sR2/0Bq5LEsY5/63ttr/lAO4/rl8iNjxxAb2POmObvLV2pT gUpNGEMZRCGnTT0fxm4vvAxswoCAbanv4Pran8bKFaIN1RCIvlrr4Z3lYpA++An/ LyQkYmrWUFvf62F1M1sOpCj6y06qaa///oRV29ngcpTL5flo4bRhJ5OqN8dABvOP VaaePuXjNVsoINw7ndLpl2HagDM5ftNVFf/LD9kKvziyXfwKCMqBJErStZpmJ6Q0 BKLHLrf6qFuogU1j1RaWORd9N0FF+V8skLhUSMlt30vKEQyd
=pMBF
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jul 30, 2024 at 01:30:57PM +0500, Andrey Rakhmatullin wrote:

Maybe we should install only the python binaries and the dependencies marked <!nocheck>.

In a typical simple case all B-Ds except sphinx stuff will be <!nocheck>
as you don't need anything beyond the build system to "build" a pure
Python module.

Erm, no, you need to B-D on all runtime dependencies so they are
correctly included in the computed python3:Depends substvar, unless
you list these runtime dependencies explictly by hand.

Best wishes,

Julian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 29 Jul 2024 at 18:55:26 +0500, Andrey Rakhmatullin wrote:

On Mon, Jul 29, 2024 at 03:30:39PM +0200, PICCA Frederic-Emmanuel wrote:

My use case, is to check that all the Dependencies computer by dh_python3 from the build tools are indeed listed in the Depends of the binary package.

Maybe we indeed want a "minimal" autopkgtest environment

For a simple smoke-test that the Python packages import succesfully, isn't
this exactly autopkgtest-pkg-python?

For thorough test coverage, I don't think this is possible: in general,
the test suite will legitimately require installation of packages that are
only needed during testing (pytest or similar), or packages that are
optional for basic use of the code but mandatory for full test coverage
(those might be Recommends or Suggests).

but many
upstream tests will fail in those and I don't see an automatic way to test
a random package in this way

If we want to run upstream test-suites as autopkgtests, then I think
ideally we want the same test coverage as autopkgtest-pkg-python,
*and* the same test coverage as autopkgtest-pkg-pybuild, as separate autopkgtest test-cases with different dependencies.

But I don't think we can easily have that, because the Testsuite field
only takes one value.

Would it be possible to make autopkgtest-pkg-pybuild absorb
the functionality of autopkgtest-pkg-python, so that it
generates a debian/control that does some simple smoke-tests (like autopkgtest-pkg-python does), *and* runs the upstream test suite (like autopkgtest-pkg-pybuild currently does)?

If not, then the proposed policy change would result in us gaining
coverage but also losing coverage.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 31, 2024 at 09:46:27AM +0100, Simon McVittie wrote:

My use case, is to check that all the Dependencies computer by dh_python3 from the build tools are indeed listed in the Depends of the binary package.

Maybe we indeed want a "minimal" autopkgtest environment

For a simple smoke-test that the Python packages import succesfully, isn't this exactly autopkgtest-pkg-python?

Yes.

For thorough test coverage, I don't think this is possible: in general,
the test suite will legitimately require installation of packages that are only needed during testing (pytest or similar), or packages that are
optional for basic use of the code but mandatory for full test coverage (those might be Recommends or Suggests).

I was thinking about "running a subset of the test suite that doesn't need those optional deps" (I didn't consider that this needs pytest and likely various pytest plugins and their deps so it isn't strictly minimal) and automatically identifying this subset is what I later said I think isn't possible.

but many
upstream tests will fail in those and I don't see an automatic way to test a random package in this way

If we want to run upstream test-suites as autopkgtests, then I think
ideally we want the same test coverage as autopkgtest-pkg-python,
*and* the same test coverage as autopkgtest-pkg-pybuild, as separate autopkgtest test-cases with different dependencies.

I always thought the smoke test is redundant if there is the upstream
tests one.
What do you think?

But I don't think we can easily have that, because the Testsuite field
only takes one value.

It was easy (and achieved by accident) before autopkgtest-pkg-pybuild: you could have upstream tests in debian/tests and the smoke test via Testsuite
or automatic discovery (I could never remember which combination gives you both). But, again, I never thought this is desirable and was removing the
smoke test.


--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmaqQ5stFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh W0AQAICm2gU2jst3PqDc/R2U61Qd68z77AAPPhZkstgWLgmj39tzJwSncs+JCjP7 izsm6Fgzdynb5W2yMRNtw+MfE5W/De58zNvO9GZeeAHZOFCEGy0SgVjxkhyyusW+ 0xJZN2DTiTSk2Rl6vOEJxT0jF9JacXPbpd+4I12D0RM1T+HPlHTy5f72YASs4X8i Vzz+6uQsF833+Ki7uCu7CICU3P6R1LDrFjgqdi1H2QC+62g2sXuVA+J613GatHPV CEb1AvdqYPonygP3j6eB4WOpjuztAi5zKEmUDiQw0OpRFnWZ7YzHQGDz7r/6gyXq RaRmVCyZQ6H7rlSelm3ly4yCI928aBsclMT+utgnyxb/kuS7iWiaTMNr8c6kzbaS 0OeMF9bcQQpihcKPjv8+uQdLUEMKhMu4cx5odcv6ImsLTaI+QrCZaisT8mvxEhd4 R/BryogpbU+BGvPGXv8qlyfWJk2T5tuOydtfEw8oyBy/KyWouVkQFknfUoX9vg70 DORoTydowfqDYvl62NHXOSlimD665kKfRZ8KxZvYA7CR/GQls1ROHpcEh865x2Tu gZwJGiuQA6D1rFZGbiR9ntY5JOH6rKpgh6fVpI0NgOZ5XYWgj+kLrUMkNoote+OR W92+ieVRT1T/JHDgGnEQWPcQ2pNX+f/pg9DHu+HcwaTRIcA/
=cCgq
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jul 30, 2024 at 03:59:04PM +0100, Julian Gilbey wrote:

Maybe we should install only the python binaries and the dependencies marked <!nocheck>.

In a typical simple case all B-Ds except sphinx stuff will be <!nocheck>
as you don't need anything beyond the build system to "build" a pure
Python module.

Erm, no, you need to B-D on all runtime dependencies so they are
correctly included in the computed python3:Depends substvar, unless
you list these runtime dependencies explictly by hand.

Those will be installed anyway via Depends, by definition, but also in my experience you don't always need to do one of these two things. Maybe I'm
doing it wrong and my python3:Depends are not 100% correct though.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmaqRG8tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh /ZQP/2iGeF+a4Y0F+uuEAJ/Q6ib9LmExAVM0BIh3Oe69EtiFANxltEVXkC5eordT aZnULHooU/LBbPbyro77yVzl9iAivOWX6ItjSBzN1EweF7t6DDb+NFkEdhMMILcL FtogsCR4GyRJ79wONwOYGagC1rmNgqWeVhkLQm44ypaWkIwf0AvPjukYNOCy0a+E 59yRum346mUHXnJnOxZ34vadstHQXE5sKNRfHn96s594jS4hKmbYhS9Kpi7RsBHo WC4WpWKbvnWC/4gMwZGisoj2X02jpwrAPDWvLZDlPhYTKW584WaplpCTMg0fam+r 00WhvRsJrp4wyWtlMQr3tTIoE2UkzqjC0JqT0lmb4CsRvgJPRvM184dXn1gc3VxY N54EkHBXuiwwQNCJM5GESJWDhomSzI4JkMmBa8OsGV6uHT5Qk024991Bc6a5/m1I E6bDD9LgcLjGIa239vz2s77PjayRV5jdG7w6uzyT5pQqtJt1KPVCmuA95kbC6wPW CDV0H2Q3MbOYsNEXHy1gNgv0sqZ92EQYuPp/vQgtt3qN2aLMWQcbwnY734rMaqdh hIsDPReZxTq1u6jvT2/Y15KTfWqT3rxu4oMj7TEaeja2dnxztypcmlS1tNWX9FQG fOb3yjTFA/ubBrfGYkIpWS3qjYyth5UsEFF82Rv15WWRQej3
=jPDy
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jul 30, 2024 at 10:47:59AM +0200, PICCA Frederic-Emmanuel wrote:

Yes, I want to be sure that all the runtime dependencies are rightfully declared in the Depends of the python module package.

Depending on what do you mean by "all" this is not always what we want. We often don't put all modules imported by all parts of the shipped code into Depends, instead using Recommends, Suggests or nothing.

sometimes the upstream forgot about dependencies, or mark them as optional, but they are not when running the tests...

Similarly, all modules installed for tests shouldn't always go into
Depends ("all modules installed for tests" is ideally the same as "all
modules imported by all parts of the shipped code", plus test system
deps, and minus deps for e.g. Windows code that we ship but don't run or
test).

Is it possible to achieve this automatically ? lintian ? dh-python ? python3-stdeb ?

Well our tools can look at the deps declared by the upstream, and normally
do that as a part of the build process. But that won't help when those
deps are not what we want.


--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmaqRjEtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh YUEQAJeRAO0wU0HmQLLxVfRG/XUmhJaET0qSZ8Qj5xmoYUkHnAv/6oNZsxdFiuUX 8vu086lyNeeZWQEOYzfsXzGd97HyDJJAzbUiGqnP/5uQjK/+LTIrwPIBzc1Oeqg8 X0SDw6qnY57dhhb17xU2AYQCddPi9WlRdkCAlfNprBfPzuv/JZH1RRIR45Aq/DOk A8qVDb0e3wrRnsl58s4rHii618wq07vYtHOyzUPORHuW0esoGsrcp7Z4X9GWByTO lDw73n3eIbxQ5xgv15nwl6EPN9BSvtWqIyKEQxkB0FBaY/5oZss8xpVEiYZyMi/O hlof8XxoRJB0A5iCSyofrAFVOQPQVAwee3UjJRFv6Nt5I7ATC+t+1yA2uAIsKQkp s0E9rYB59xIDlJRKzOEqcD7lky9/ysJIVeN789/+Xnat/i0WutkUDlNDJyRP8x0i npz1MIpnND3pHJXX5FNVqcs5DvwIPKn4bonFe655G90Om/ke9PhUpOOZioNgIhOC DNtzGZLKZkvMpR2ys0H6Q44Fy3dL746M4fsXH74U2iS1WTb2uQ9Af2MPfN8kAkSk 6Pt16ol44KWEuu43uycSYql4sS8O3QkxJQh/JWAH/YTJPLmNCtuEBjkKiAxI3pvt lgZvPWxTYgobucQ6lxcF1GvNjSzB9HsJCaNOO+BhXiXrWtyB
=GybF
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 31 Jul 2024 at 19:01:05 +0500, Andrey Rakhmatullin wrote:

On Wed, Jul 31, 2024 at 09:46:27AM +0100, Simon McVittie wrote:

If we want to run upstream test-suites as autopkgtests, then I think ideally we want the same test coverage as autopkgtest-pkg-python,
*and* the same test coverage as autopkgtest-pkg-pybuild, as separate autopkgtest test-cases with different dependencies.

I always thought the smoke test is redundant if there is the upstream
tests one.
What do you think?

I think it is not redundant, because it's a quick way to catch packaging
errors where the python3-foo binary package is missing a mandatory
dependency - which seems to be a somewhat common failure mode, because
the maintainer (who presumably has the Build-Depends installed) will
never notice it by testing on their own system.

For instance in this (hypothetical) package:

Source: python-foo
Build-Depends: dh-python, python3-all, python3-bar, ...

Package: python3-foo
Depends: ${misc:Depends}, ${python3:Depends}

Suppose python3-foo does an "import bar", therefore there should have
been a "Depends: python3-bar" which is missing here. The smoke test
would detect that.

(I know that ideally python3-bar would be part of the ${python3:Depends},
and with some upstream build systems under some phases of the moon,
it is; but I'm thinking here about the packages where that information
doesn't work or isn't propagated.)

I'm a fan of putting a small amount of effort into automated tests, and
then having running the tests before uploading save you from a class of Severity: grave bugs forever :-)

But I don't think we can easily have that, because the Testsuite field
only takes one value.

Actually it seems it's meant to be able to take more than one value, and
the fact that autodep8 doesn't support that appears to be considered a bug. (#1042717, #1061620, #1077645)

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------scUDGCCeFo1UX85REpMSRdfy
Content-Type: multipart/mixed; boundary="------------E8CFZc7buBbVr49MfaVoivx7"

--------------E8CFZc7buBbVr49MfaVoivx7
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMjAyNC0wNy0yOSA0IGggNTMgYS5tLiwgTG91aXMtUGhpbGlwcGUgVsOpcm9ubmVhdSB3 cm90ZToNCj4gSGVsbG8sDQo+IA0KPiBBcyBkaXNjdXNzZWQgZHVyaW5nIHRoZSBEZWJDb25m MjQgUHl0aG9uIEJvRiwgSSdtIHN1Ym1pdHRpbmcgdGhpcyBjaGFuZ2UgDQo+IHRvIHRoZSBw b2xpY3kgdG8gcmVxdWlyZSB0aGUgdXNlIG9mIHRoZSB1cHN0cmVhbSB0ZXN0IHN1aXRlLCBi b3RoIGR1cmluZyANCj4gdGhlIGJ1aWxkIHByb2Nlc3MgYW5kIGFzIGFuIGF1dG9wa2d0ZXN0 Lg0KPiANCj4gWW91IGNhbiBmaW5kIHRoZSBNUiBoZXJlOg0KPiANCj4gaHR0cHM6Ly9zYWxz YS5kZWJpYW4ub3JnL3B5dGhvbi10ZWFtL3Rvb2xzL3B5dGhvbi1tb2R1bGVzLy0vIA0KPiBt ZXJnZV9yZXF1ZXN0cy8yNA0KPiANCj4gUGVvcGxlIHByZXNlbnQgYXQgdGhlIEJvRiBzZWVt ZWQgdG8gdGhpbmsgdGhpcyB3YXMgYSBnb29kIGlkZWEuIElmIHlvdSANCj4gZG9uJ3QgcGxl YXNlIHJlcGx5IHRvIHRoaXMgbWVzc2FnZSBhbmQgbWFrZSB5b3Vyc2VsZiBoZWFyZCA6KQ0K PiANCj4gQ2hlZXJzLA0KPiANCg0KSGksDQoNCkl0J3MgYmVlbiBhYm91dCAyIHdlZWtzIHNp bmNlIHRoZSBwb2xpY3kgY2hhbmdlIGhhcyBiZWVuIHByb3Bvc2VkLiBJIA0KYmVsaWV2ZSBJ IGhhdmUgdGFrZW4gaW4gYWNjb3VudCB0aGUgZmVlZGJhY2sgYW5kIHRoZSBkaXNjdXNzaW9u IHNlZW1zIHRvIA0KaGF2ZSBkaWVkIGRvd24uDQoNCkFzIHRoZSByZXNwb25zZSBmcm9tIHRo ZSB0ZWFtIG1lbWJlciB3YXMgbGFyZ2VseSBwb3NpdGl2ZSwgSSBwcm9wb3NlIHRoZSANCmNo YW5nZSBiZSBtZXJnZWQuDQoNCkNoZWVycywNCg0KLS0gDQogICDiooDio7TioL7ioLviorbi o6bioIANCiAgIOKjvuKggeKioOKgkuKggOKjv+KhgSAgTG91aXMtUGhpbGlwcGUgVsOpcm9u bmVhdQ0KICAg4qK/4qGE4qCY4qC34qCa4qCLICAgcG9sbG9AZGViaWFuLm9yZyAvIHZlcm9u bmVhdS5vcmcNCiAgIOKgiOKgs+KjhA0KDQo=
--------------E8CFZc7buBbVr49MfaVoivx7
Content-Type: application/pgp-keys; name="OpenPGP_0xE1E5457C8BAD4113.asc" Content-Disposition: attachment; filename="OpenPGP_0xE1E5457C8BAD4113.asc" Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEYEPdjBYJKwYBBAHaRw8BAQdA5yh8SOHhcvKeX/A4rv0/JTCL8Kgnnwy4/okK h1Htbs3NOExvdWlzLVBoaWxpcHBlIFbDqXJvbm5lYXUgPGxvdWlzLXBoaWxpcHBl QHZlcm9ubmVhdS5vcmc+wpkEExYKAEECGwMFCQHhM4AFCwkIBwMFFQoJCAsFFgID AQACHgECF4AWIQT2TWHTIfPLSJFWdT3h5UV8i61BEwUCYEPeHgIZAQAKCRDh5UV8 i61BE0xKAP4oRsMaA2T/Zjge126dwHbnxBsjI/Q3ky8QkGlOffUKJAEA9dWm0hE4 0URSXM8Ndtf+GeHxvNeryVMCtVDUfjHMBA/CmQQTFgoAQQIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAIZARYhBPZNYdMh88tIkVZ1PeHlRXyLrUETBQJiEWgLBQkD rr3/AAoJEOHlRXyLrUETOK0BAM9I6BMMiqhsORsRcDVcM4VTm8G67YHapBW5zdl/ llfxAPwLAsi32TCPWjuwD3UdKig+6syvKFsiIfjiNBweNIQED8KZBBMWCgBBAhsD BQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAhkBFiEE9k1h0yHzy0iRVnU94eVFfIut QRMFAmPExgwFCQWDEYAACgkQ4eVFfIutQRNr2AD+L1MzuP25AZMyDYNUNmxbTOEg TP6PV/QrLnwhklD4pIcBAL3Zi/VynLJIvCxRUcvzCalWVJ3F/GAL0PqwTOuRda0N wpkEExYKAEECGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4ACGQEWIQT2TWHTIfPL SJFWdT3h5UV8i61BEwUCZb/fiAUJDuIDfAAKCRDh5UV8i61BE004AQCHEbsPWc/N IGpUErFr4mBtStwhYRZr+FmfoW9IylhVbAD/fOeZfkf/IciaFQPb0eorhWqA2KMo Xay7G1vVTM7DiQfNLExvdWlzLVBoaWxpcHBlIFbDqXJvbm5lYXUgPHBvbGxvQGRl Ymlhbi5vcmc+wpYEExYKAD4WIQT2TWHTIfPLSJFWdT3h5UV8i61BEwUCYEPd6wIb AwUJAeEzgAULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRDh5UV8i61BE3izAQCQ AM5ypBaNwptKQFupJR7+o5w3jC0v+vbQGyUEQzRAIQEAxkE63ACWQHABSqGHodlJ UaJJtcRty3PhQ6WRjiiQWgXClgQTFgoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBPZNYdMh88tIkVZ1PeHlRXyLrUETBQJiEWgLBQkDrr3/AAoJEOHlRXyL rUETCLcA/jnHuZdEAUSbGsdQuTF3t+yZOXCDFdnjh9IuIXenNsKmAP99Vp9KreW7 +4tcvtibAnirb9DCLGENy1NVxvJPYaW/AcKWBBMWCgA+AhsDBQsJCAcDBRUKCQgL BRYCAwEAAh4BAheAFiEE9k1h0yHzy0iRVnU94eVFfIutQRMFAmPExgwFCQWDEYAA CgkQ4eVFfIutQRO9JAEAkEhUgwuGUbdWhKnakB4DHcl/27WAb/Ig10C98nKKRSYA /j5y02CKj5Ydd3iMi/Y+Vt15W2N4mMw0bc0XHOrJx+sKwpYEExYKAD4CGwMFCwkI BwMFFQoJCAsFFgIDAQACHgECF4AWIQT2TWHTIfPLSJFWdT3h5UV8i61BEwUCZb/f iAUJDuIDfAAKCRDh5UV8i61BEzdaAP0cGJp8CpkywzefhdaJjfK5/uAQLRg5Bk6y CWnyR8B4wQEAxA4C39PJPsosgOVBMdfkzCPhGVynYBnujOyEcksX1w/OMwRgQ+DR FgkrBgEEAdpHDwEBB0BJt6Q0DfEmfFSEx6cry21+bw5N6meJcckQ3RKbX/OaJ8LA NQQYFgoAJhYhBPZNYdMh88tIkVZ1PeHlRXyLrUETBQJgQ+DRAhsCBQkB4TOAAIEJ EOHlRXyLrUETdiAEGRYKAB0WIQTKp0AHB6gWsCAvw830JXpQshz6hQUCYEPg0QAK CRD0JXpQshz6hazDAQChFPOW6RzpKzg9oKGiCa51PMx17MXUVDNPkcfQLgRVrAD/ Ul9rKwr6x4v/N0RApQcPdwx2Dw28y05d9wyDgSIVFgTVJAEA8qJQKpIwuqXtC1aI H/GYMVRiW01rf40uNFhGw0p970kA/1kRpdjqg77ejDCnFs2mEGmFKQf72URqDQN3 cESjA4oMwsA1BBgWCgAmAhsCFiEE9k1h0yHzy0iRVnU94eVFfIutQRMFAmISe8MF CQOvznIAgXYgBBkWCgAdFiEEyqdABweoFrAgL8PN9CV6ULIc+oUFAmBD4NEACgkQ 9CV6ULIc+oWswwEAoRTzlukc6Ss4PaChogmudTzMdezF1FQzT5HH0C4EVawA/1Jf aysK+seL/zdEQKUHD3cMdg8NvMtOXfcMg4EiFRYECRDh5UV8i61BE9joAQCf1i+t POWIC+fI95/eRdcK/If3vd0+f/nf2y5eKt4GewD+Kq3CI57jvnz7bx+CxdpVSnIV wSGKuy7T8iHNKelVdQ3CwDUEGBYKACYCGwIWIQT2TWHTIfPLSJFWdT3h5UV8i61B EwUCY8TGFgUJBYMORQCBdiAEGRYKAB0WIQTKp0AHB6gWsCAvw830JXpQshz6hQUC YEPg0QAKCRD0JXpQshz6hazDAQChFPOW6RzpKzg9oKGiCa51PMx17MXUVDNPkcfQ LgRVrAD/Ul9rKwr6x4v/N0RApQcPdwx2Dw28y05d9wyDgSIVFgQJEOHlRXyLrUET /dEA/AgqUnNa1JZr9Tle8LWPq8QYkBUCxqnoVOR+f+blHlXFAQDToU8ZL2N22j2U yHMNz8p2L2MNeMCs3mj8HjMAm98LBsLANQQYFgoAJgIbAhYhBPZNYdMh88tIkVZ1 PeHlRXyLrUETBQJlv9+vBQkO4gBeAIF2IAQZFgoAHRYhBMqnQAcHqBawIC/DzfQl elCyHPqFBQJgQ+DRAAoJEPQlelCyHPqFrMMBAKEU85bpHOkrOD2goaIJrnU8zHXs xdRUM0+Rx9AuBFWsAP9SX2srCvrHi/83REClBw93DHYPDbzLTl33DIOBIhUWBAkQ 4eVFfIutQRNGFwD5AVYQfZSNgQ8OfCX2UVgYFeku22XO0ufqng2gzJHXiTMBAKMJ UmRsYhd7KfPx5LEv+B2bIhl+cVZUJDuzLnEFWFYPzjgEYEPg5RIKKwYBBAGXVQEF AQEHQIES2w30v+hi13deaiPcx7KPVMCUIA25nu6by9Wfa5BuAwEIB8J+BBgWCgAm FiEE9k1h0yHzy0iRVnU94eVFfIutQRMFAmBD4OUCGwwFCQHhM4AACgkQ4eVFfIut QRMNhgD9HkVqB+Vy+F9EAzjHilHnSPft2xfLdhTrqzh6O0jEhqsA/2dd/AMSsZNA H8FYQKq3Th+Hikj+jXXs+P9HYlULp1UHwn4EGBYKACYCGwwWIQT2TWHTIfPLSJFW dT3h5UV8i61BEwUCYhJ72AUJA6/OcwAKCRDh5UV8i61BE2CVAP9+JHidrPFWE7Ww NskxdVY1YzHxGihO20Zt65AagSMVgAD9FlBCTPfQKpvC5jBax89pLAg07QsLq1wJ 5U5v1zV5JQTCfgQYFgoAJgIbDBYhBPZNYdMh88tIkVZ1PeHlRXyLrUETBQJjxMYf BQkFgw46AAoJEOHlRXyLrUETqTUBAI8cz/gDORn8lcDQ/tzvXYiyZBeelktw++Si mxhIlUmMAQC9ZISRQeqa52/EUErTMrg3e3hgZ7SiYNXaRCuj4vTrBMJ+BBgWCgAm AhsMFiEE9k1h0yHzy0iRVnU94eVFfIutQRMFAmW/37AFCQ7iAEoACgkQ4eVFfIut QRMGGgEA4b20EKpkwxf33aHc34mOOSFmHJG/awrymlZ3z+gzmPUBAP3nmhFpjqtj aTmKQXrFYwWQi3vIyr9VjzHyy2DnwyAHzjMEYhFqKxYJKwYBBAHaRw8BAQdAZIVA ArBgjmmj0WOB9pSYnoI6fIRa3bhpJbeKsTMoCfPCeAQoFgoAIBYhBPZNYdMh88tI kVZ1PeHlRXyLrUETBQJi6C3mAh0DAAoJEOHlRXyLrUETlWQA/RNjQxvcQamu4GY2 Ka0JGOBM1IFJGWOYOZdOOoyNFrzfAQDytAG+Eo8e3pDyQw2uIAfzK9YbQsqGaz8r Cge7ZLgkA8LANQQYFgoAJhYhBPZNYdMh88tIkVZ1PeHlRXyLrUETBQJiEWorAhsC BQkB4TOAAIEJEOHlRXyLrUETdiAEGRYKAB0WIQSQXfPjkatdPeFHEpNmts1qvsDb lgUCYhFqKwAKCRBmts1qvsDbljr/AQCn3i6trKCXohwwHaFdLKUMaFSQ5nthc4Jg Qsa9CsUX0AD/c2h8CPfjY4q5gvBqLyBr3me8MVyf7/I2BZ2WnVYSEQapPgEA1ypU 5j7Fiw+kpzL1vpBdUmx1Kumj6gC125xGov4U06wA/j7ezWTtSqiUIiCfpoj9SyJT 6omSjD7fLjXcPCiqh1cGzjgEYhFxEhIKKwYBBAGXVQEFAQEHQGUjAsbDR5A4iNrZ 6fRV9V5ft/fyp63vY3e3sbWtCxgBAwEIB8J4BCgWCgAgFiEE9k1h0yHzy0iRVnU9 4eVFfIutQRMFAmLoLhcCHQMACgkQ4eVFfIutQRNw9wD7B/YAwKzq2Ov3dvy3n6cp o/skeQxwxFqRL0Phk55wPXsBAOi4Bxsdw0Tfyn5FtXqF8ZZ2hXkD16oICzhY/JM2 JA4Awn0EGBYKACYWIQT2TWHTIfPLSJFWdT3h5UV8i61BEwUCYhFxEgIbDAUJAeEz gAAKCRDh5UV8i61BE4p2APd4nRcoabtOeBFUWxc/8m1QJaRqpHbevfi2Ldwq9ESJ AQDQETDGHeO5Vf9fwtX1rHpkbmQwnfgcx/6O28om5FGuDg==
=78EK
-----END PGP PUBLIC KEY BLOCK-----

--------------E8CFZc7buBbVr49MfaVoivx7--

--------------scUDGCCeFo1UX85REpMSRdfy--

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQTKp0AHB6gWsCAvw830JXpQshz6hQUCZr0rCwAKCRD0JXpQshz6 hXm8AQDKrBssam2zouPr4GesrQUO3DjSnBh72mePeSgkkr9vTwEA/y9FFv/ekW3S CNAbOu+682qGyH1/sfSnDh5vlQ6Newc=
=PM2t
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, Aug 14, 2024 at 06:09:15PM -0400 schrieb Louis-Philippe V�ronneau:

It's been about 2 weeks since the policy change has been proposed. I believe I have taken in account the feedback and the discussion seems to have died down.

As the response from the team member was largely positive, I propose the change be merged.

Thank you for driving this forward
Andreas.

--
https://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Louis-Philippe Véronneau <pollo@debian.org> wrote on 15/08/2024 at 00:09:15+0200:

On 2024-07-29 4 h 53 a.m., Louis-Philippe Véronneau wrote:

Hello,
As discussed during the DebConf24 Python BoF, I'm submitting this
change to the policy to require the use of the upstream test suite,
both during the build process and as an autopkgtest.
You can find the MR here:
https://salsa.debian.org/python-team/tools/python-modules/-/
merge_requests/24
People present at the BoF seemed to think this was a good idea. If
you don't please reply to this message and make yourself heard :)
Cheers,

Hi,

It's been about 2 weeks since the policy change has been proposed. I
believe I have taken in account the feedback and the discussion seems
to have died down.

As the response from the team member was largely positive, I propose
the change be merged.

Cheers,

I'm still against this, and I'm not sure yet whether or not it'll drive
me to leave the team. The first sentence is ok, but the second is not
ok with me.

Regards,
--
PEB

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEE5CQeth7uIW7ehIz87iFbn7jEWwsFAma/1mcPHHBlYkBkZWJp YW4ub3JnAAoJEO4hW5+4xFsLJAoP/2QtHC8jA/o0TrctuwsBXXL59gpBnsubKnno FzD4ncLas6v6BBblPmKAV34n0RLS28tyC10+rteMcFpme7CwW8fUr9gghzqB9SfE gMWUs1oUpuWjDoWSAXcimjIZCaRdrv/OTeM6TRZfU4OiA/cEbKYjEjt8F35ZDi/u 9hxxdxZsbA6m1kFPJwgNXmMkIUz+C+A7jzbKvNXEu0RhlhQsMkbW5GLMr5ocHYec ZtCHWdF6h2d9DmVxjkKE5UNfVr+Z2INPI4gF1wu98ulaSwAjNdxwd7TLb14I/Gfl hLib0HRp1hzebKDmpzlA8XfETigd5sZy09uyB6QZPkqi1KVNHwigmiHBEPREv67F YSX5D3Xh5Z8vXhxWtUKCsZpQ7uJBTE0Hz2Gzh7OUoxUZmxBvys+dIk97jtW76YQR tGUlb5iAsLZOxWCQAedRZ7XFdn8P+GHOz8kCm5V99V33tY8Ve15BxzTapOyG3YEf 7h5jOz8WVnqap2rVdnNv9n82Y8m9RH2bix2imPQaes3RCds6UYKZAbKuv48Bcl+D kli0aFibAc3mkpbHJVwCFOV0aeDh1ovW1Jm/0zxtavWtBdzBMzOwxQLCs5ZmwQnw X/k3slSOTxvqMf5pfItMh+XeBo+kTJZFEHDsCGg/Qlf8ecqoJi51na2uJoN7y8jQ
KgjW5t0M
=w0Lm
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

T24gMjAyNC0wOC0xNiA2IGggNDQgcC5tLiwgUGllcnJlLUVsbGlvdHQgQsOpY3VlIHdyb3Rl Og0KPiBIaSwNCj4gDQo+IExvdWlzLVBoaWxpcHBlIFbDqXJvbm5lYXUgPHBvbGxvQGRlYmlh bi5vcmc+IHdyb3RlIG9uIDE1LzA4LzIwMjQgYXQgMDA6MDk6MTUrMDIwMDoNCj4gDQo+PiBP biAyMDI0LTA3LTI5IDQgaCA1MyBhLm0uLCBMb3Vpcy1QaGlsaXBwZSBWw6lyb25uZWF1IHdy b3RlOg0KPj4+IEhlbGxvLA0KPj4+IEFzIGRpc2N1c3NlZCBkdXJpbmcgdGhlIERlYkNvbmYy NCBQeXRob24gQm9GLCBJJ20gc3VibWl0dGluZyB0aGlzDQo+Pj4gY2hhbmdlIHRvIHRoZSBw b2xpY3kgdG8gcmVxdWlyZSB0aGUgdXNlIG9mIHRoZSB1cHN0cmVhbSB0ZXN0IHN1aXRlLA0K Pj4+IGJvdGggZHVyaW5nIHRoZSBidWlsZCBwcm9jZXNzIGFuZCBhcyBhbiBhdXRvcGtndGVz dC4NCj4+PiBZb3UgY2FuIGZpbmQgdGhlIE1SIGhlcmU6DQo+Pj4gaHR0cHM6Ly9zYWxzYS5k ZWJpYW4ub3JnL3B5dGhvbi10ZWFtL3Rvb2xzL3B5dGhvbi1tb2R1bGVzLy0vDQo+Pj4gbWVy Z2VfcmVxdWVzdHMvMjQNCj4+PiBQZW9wbGUgcHJlc2VudCBhdCB0aGUgQm9GIHNlZW1lZCB0 byB0aGluayB0aGlzIHdhcyBhIGdvb2QgaWRlYS4gSWYNCj4+PiB5b3UgZG9uJ3QgcGxlYXNl IHJlcGx5IHRvIHRoaXMgbWVzc2FnZSBhbmQgbWFrZSB5b3Vyc2VsZiBoZWFyZCA6KQ0KPj4+ IENoZWVycywNCj4+Pg0KPj4NCj4+IEhpLA0KPj4NCj4+IEl0J3MgYmVlbiBhYm91dCAyIHdl ZWtzIHNpbmNlIHRoZSBwb2xpY3kgY2hhbmdlIGhhcyBiZWVuIHByb3Bvc2VkLiBJDQo+PiBi ZWxpZXZlIEkgaGF2ZSB0YWtlbiBpbiBhY2NvdW50IHRoZSBmZWVkYmFjayBhbmQgdGhlIGRp c2N1c3Npb24gc2VlbXMNCj4+IHRvIGhhdmUgZGllZCBkb3duLg0KPj4NCj4+IEFzIHRoZSBy ZXNwb25zZSBmcm9tIHRoZSB0ZWFtIG1lbWJlciB3YXMgbGFyZ2VseSBwb3NpdGl2ZSwgSSBw cm9wb3NlDQo+PiB0aGUgY2hhbmdlIGJlIG1lcmdlZC4NCj4+DQo+PiBDaGVlcnMsDQo+IA0K PiBJJ20gc3RpbGwgYWdhaW5zdCB0aGlzLCBhbmQgSSdtIG5vdCBzdXJlIHlldCB3aGV0aGVy IG9yIG5vdCBpdCdsbCBkcml2ZQ0KPiBtZSB0byBsZWF2ZSB0aGUgdGVhbS4gVGhlIGZpcnN0 IHNlbnRlbmNlIGlzIG9rLCBidXQgdGhlIHNlY29uZCBpcyBub3QNCj4gb2sgd2l0aCBtZS4N Cg0KQ2FuIHlvdSBiZSBtb3JlIGV4cGxpY2l0IG9uIHRoZSByZWFzb25zIHdoeSB5b3UgZGlz bGlrZSB0aGUgc2Vjb25kIHNlbnRlbmNlPw0KDQpJdCBvbmx5IHNheXMgeW91IHNob3VsZCBk b2N1bWVudCB3aHkgdGVzdHMgYXJlbid0IHJhbiBpbiBhIHBhY2thZ2UgYW5kIA0KZW5jb3Vy YWdlcyB5b3UgdG8gb3BlbiBhIGJ1ZyByZXBvcnQuDQoNCllvdSBjZXJ0YWlubHkgZG9uJ3Qg aGF2ZSB0byB3cml0ZSB0ZW4gcGFyYWdyYXBocywgYSBzaW5nbGUgc2VudGVuY2UgDQpzdW1t YXJpemluZyB0aGUgaXNzdWUgKGFuZCB0aHVzIGxldHRpbmcgb3RoZXIgcGVvcGxlIGluIHRo ZSB0ZWFtIGhlbHApIA0KaXMgZW5vdWdoIElNTy4NCg0KLS0gDQogICDiooDio7TioL7ioLvi orbio6bioIANCiAgIOKjvuKggeKioOKgkuKggOKjv+KhgSAgTG91aXMtUGhpbGlwcGUgVsOp cm9ubmVhdQ0KICAg4qK/4qGE4qCY4qC34qCa4qCLICAgcG9sbG9AZGViaWFuLm9yZyAvIHZl cm9ubmVhdS5vcmcNCiAgIOKgiOKgs+KjhA0KDQo=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 18 Aug 2024 at 21:14, Louis-Philippe Véronneau <pollo@debian.org> wrote:

Can you be more explicit on the reasons why you dislike the second sentence?

It only says you should document why tests aren't ran in a package and encourages you to open a bug report.

I thought the second sentence was:
"As such, the use of `Testsuite: autopkgtest-pkg-pybuild` is highly recommended."

I would still like to add a note about adding <!nocheck> to
build-dependencies only needed for the tests.

It might be easier if I add that once this proposal is committed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)