I think the proper fix would be to ask people to move away from
`py3versions -r` if there is no X-Python3-Version, and use`py3versions
-s` instead.
As such, I think we should ask the Lintian maintainers to:
1. Change the desc for tag declare-requested-python-versions-for-test to
The specified test attempts to query the Python versions
<em>requested</em> by your sources with the command <code>py3versions --requested</code> but your sources do not actually declare those
versions with the field <code>X-Python3-Version</code>.
.
Please query all <em>supported</em> Python versions with the command <code>py3versions --supported</code> in your test instead.
2. Change the desc for tag query-requested-python-versions-in-test to
The specified test queries all <em>supported</em> Python versions with
the command <code>py3versions --supported</code> but your sources
request a specific set of versions via the field <code>X-Python3-Version</code>.
.
Please delete the field <code>X-Python3-Version</code>, as it is not needed.
AFAIU, the only valid use of X-Python3-Version would be a package that
fails to build on an older but currently supported version of Python
(let's say 3.9) but builds on the newer version (say 3.10). I think such
use cases are pretty rare though.
Hey folks,
I'm following up on bug #1001677 [1] on the DPT's list to try to reach consensus, as I think the Lintian tags that were created to fix this
bug are not recommending the proper thing.
As a TL;DR for those of you who don't want to read the whole BTS
thread, jdg saw that a bunch of packages were using `py3versions -r`
in autopkgtests, and this fails when there's no X-Python3-Version
variable in d/control.
The fix that Lintian now proposes for packages that use `py3versions
-r` in autopkgtests is to set X-Python3-Version.
I think the proper fix would be to ask people to move away from
`py3versions -r` if there is no X-Python3-Version, and use`py3versions
-s` instead.
On Mon, 17 Jan 2022 12:47:44 -0500
Louis-Philippe Véronneau <pollo@debian.org> wrote:
Hey folks,
I'm following up on bug #1001677 [1] on the DPT's list to try to reach consensus, as I think the Lintian tags that were created to fix this
bug are not recommending the proper thing.
As a TL;DR for those of you who don't want to read the whole BTS
thread, jdg saw that a bunch of packages were using `py3versions -r`
in autopkgtests, and this fails when there's no X-Python3-Version
variable in d/control.
The fix that Lintian now proposes for packages that use `py3versions
-r` in autopkgtests is to set X-Python3-Version.
I think the proper fix would be to ask people to move away from `py3versions -r` if there is no X-Python3-Version, and use`py3versions
-s` instead.
Just as a general point, can I ask that - especially in a TL;DR - that
long option names are used or the context of each option is included as
the difference between -r and -s is not obvious from this email & not everyone on the list uses py3versions routinely.
Hey folks,
I'm following up on bug #1001677 [1] on the DPT's list to try to reach consensus, as I think the Lintian tags that were created to fix this bug
are not recommending the proper thing.
As a TL;DR for those of you who don't want to read the whole BTS thread,
jdg saw that a bunch of packages were using `py3versions -r` in
autopkgtests, and this fails when there's no X-Python3-Version variable
in d/control.
The fix that Lintian now proposes for packages that use `py3versions -r`
in autopkgtests is to set X-Python3-Version.
I think the proper fix would be to ask people to move away from
`py3versions -r` if there is no X-Python3-Version, and use`py3versions
-s` instead.
As such, I think we should ask the Lintian maintainers to:
1. Change the desc for tag declare-requested-python-versions-for-test to
The specified test attempts to query the Python versions
<em>requested</em> by your sources with the command <code>py3versions --requested</code> but your sources do not actually declare those
versions with the field <code>X-Python3-Version</code>.
.
Please query all <em>supported</em> Python versions with the command <code>py3versions --supported</code> in your test instead.
2. Change the desc for tag query-requested-python-versions-in-test to
The specified test queries all <em>supported</em> Python versions with
the command <code>py3versions --supported</code> but your sources
request a specific set of versions via the field <code>X-Python3-Version</code>.
.
Please delete the field <code>X-Python3-Version</code>, as it is not needed.
These changes would push maintainers to use `py3versions -s`, but
wouldn't ask people using `py3versions -r` and X-Python3-Version to make
any changes.
AFAIU, the only valid use of X-Python3-Version would be a package that
fails to build on an older but currently supported version of Python
(let's say 3.9) but builds on the newer version (say 3.10). I think such
use cases are pretty rare though.
Cheers,
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001677
On 1/17/22 18:47, Louis-Philippe Véronneau wrote:
Hey folks,
I'm following up on bug #1001677 [1] on the DPT's list to try to reach consensus, as I think the Lintian tags that were created to fix this bug are not recommending the proper thing.
As a TL;DR for those of you who don't want to read the whole BTS thread, jdg saw that a bunch of packages were using `py3versions -r` in autopkgtests, and this fails when there's no X-Python3-Version variable
in d/control.
The fix that Lintian now proposes for packages that use `py3versions -r`
in autopkgtests is to set X-Python3-Version.
I think the proper fix would be to ask people to move away from `py3versions -r` if there is no X-Python3-Version, and use`py3versions
-s` instead.
[...]
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 349 |
Nodes: | 16 (2 / 14) |
Uptime: | 117:00:22 |
Calls: | 7,612 |
Files: | 12,786 |
Messages: | 5,683,861 |