• Re: Reaching team consensus on usage of py3versions -r and X-Python3-Ve

    From Sandro Tosi@21:1/5 to All on Mon Jan 17 21:00:02 2022
    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.

    +1

    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.

    maybe https://www.debian.org/doc/packaging-manuals/python-policy/#specifying-supported-versions
    would need to be updated to clarify that the optional field is meant
    to be used in exceptional circumstances (and state what they are
    explicitly) and we generally expect the field to be absent.

    Thanks,
    --
    Sandro "morph" Tosi
    My website: http://sandrotosi.me/
    Me at Debian: http://wiki.debian.org/SandroTosi
    Twitter: https://twitter.com/sandrotosi

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Neil Williams@21:1/5 to pollo@debian.org on Tue Jan 18 09:20:02 2022
    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.

    --
    Neil Williams
    =============
    https://linux.codehelp.co.uk/

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

    iQIzBAEBCgAdFiEEf3HB6ceOc10DYMbM8WfkPIFDtoIFAmHmd5sACgkQ8WfkPIFD toIpDRAAsnwPbvikNJwCR5dEShdyY/7EjlkGXyGuTevCbm4Xf9duM1FX6jYoRyKK jxczRNI5jdwklx3U+s0v0+P4tQbWnD/cGzSPT7mu3sypE1KHMbT+1rYvwo8i7zEt sB9BbvdaomM9gpcfSZkWY3dllSaqh7ctKFFwdZO5LYhCkHj9GozwuCExYeww2fXO hhugI3hdVrvzZ8wXfkqD/W3vEHakd1aoxfoq+EXuHoBWVM1QyVeDmOzthI+KU/mo UTKYYNahts6eygzoKYwGcR+UHEa7dVeT4T2SHaAzj3dblEE2RFwze6YG8kaFxMLx 4SWbQMa4mo2CEhpj9Na50iECw6bg5E7KIaqRxnIf3Mizue8a39kgwkYx89sZVdQv CHshEO7R+D+awyyEGe5e9LJjGiPQWQEPOw2pI/quuNHfCiBPlu7g3WwyKb7Ql2E9 M/P4JR81zRDzJFcmgFqsLNOClcrAVbq8C+JHLkGwsTqbxd0qau8uVDyAOD6AU2Sv P1stjeEbJEo7XkIU2vmwaXbbUKFM7L6FwLmhn/zQKtbSRA8Y46W4oiTuEKxNzov+ E+mBKI0YebN6yi26ayl/zGHb5iTpY4TGBLpPwsSwMN/JRTieq6p1Z3DqQG+poYY5 lj5QJ5Kzli04sqbkJTiMRU8mTJ4HoIxBBNsDjJ4fI3toqTBeB1s=
    =keYc
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Kitterman@21:1/5 to All on Tue Jan 18 14:10:02 2022
    On Tuesday, January 18, 2022 3:17:31 AM EST Neil Williams wrote:
    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.

    TIL py3versions has long option names ...

    -d, --default print the default python3 version
    -s, --supported print the supported python3 versions
    -r, --requested print the python3 versions requested by a build; the
    argument is either the name of a control file or the value
    of the X-Python3-Version attribute
    -i, --installed print the installed supported python3 versions

    Scott K
    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEE53Kb/76FQA/u7iOxeNfe+5rVmvEFAmHmu1YACgkQeNfe+5rV mvHhyRAAq45wn/zfIazYKkDuKxcvRG2vQT6ompGEHzhReYbVAVPuy3ExNmJB1tAU eCmKThQaBsfPYyrPbldMv8Ml/6gT9XC6gdKKRhaHtaQWNE/MOxhsWL5thyJf11bG OiU8OU4KLyWKgeIl0C7GCQqOxJ728ZlRRMWWusfdPb1434L5pU5axZAqTajRsrwc KZc56cxcsV+ifQoG8yx8W1qRs4nSNPNYqBqJtzF02A9yL+fWL3uhPgMp/IRy0L6f yjDoEEMQ47qSlw50d5SJCdzwTo334C/qp0R6XSyRyyhejotpl+wItsoQw7nSVsLX RyKAvFgP6lhtOMgCbVPJGEVjzP9jZvNPNTtQkuKRnr0Xv4INKTbOd1OVWz0MqTTP i6Ph8Nz1m4YsCj18uZ8x88lTkuiW+JNQ+dZpNSj6AFsyXvwQHAQSzyQpPc2oaRpG pjjPCrMTUGb2mTo30C5doywed/EdLA3K7+85VpJSKPHSnPpZwV8ufAefbHhcoHxY jaakC+Ezwzq+efWZASrE9IuZycXc4rDlUIjmWSFA2xOIaocgXRY1FOtVLXtIT8h4 zdLZxCbP6Z6wPJ3Sy0Atji1w8d+KHITfdo9lqFPfRmebSvZUWPh/1IkZs3O4cm0w DXKkxFoz2XCerqJkn3JyLaSujnKgFL2Awnl+Aa+2nm+DTYxFhw4=
    =LeQ1
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Goirand@21:1/5 to All on Tue Jan 18 15:40:02 2022
    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.

    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


    +1 (very much)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Julian Gilbey@21:1/5 to Thomas Goirand on Wed Jan 19 20:30:03 2022
    On Tue, Jan 18, 2022 at 03:37:13PM +0100, Thomas Goirand wrote:
    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.
    [...]

    Dear all,

    The lintian maintainers have indeed taken this suggestion on board and
    have made most this change (modulo some minor wording differences):
    the current wording is attached below. I wonder whether with the use
    of py3versions --supported with X-Python3-Version present, the message
    should recommend removing the X-Python3-Version field as the preferred
    option, as it does with the other case?


    On some of the more general points, I scanned through every source
    package in unstable and found the following:

    * 6 packages use py3versions -d (--default) in their test suite; this
    is clearly an error in some packages (brial, ogre, sfepy, sinntp),
    and possibly an error in two others (numpy, scipy) - I haven't
    looked in detail at the last two

    * Quite a few packages use py3versions -i (--installed) in their test
    suite; this is almost certainly wrong (though it probably does the
    right thing in an autopkgtest if it depends on python3-all)

    As far as X-Python3-Version goes:

    * 5 packages have X-Python3-Version: ${python3:Versions}, which is
    surely wrong?

    * 2 packages have commented-out X-Python3-Version lines; these could
    probably just be removed

    * about 166 packages have X-Python3-Version: >= 3.x, where 0 <= x <=
    3.7. All of these packages would work in oldstable (buster) or
    later without this line

    * 8 packages have >= 3.8 and 3 packages have >= 3.9; these would work
    in stable (bullseye) or later without this line

    * 6 packages have just 3.9 (calibre, pytorch-audio, pytorch-ignite,
    pytorch-text, pytorch-vision, skorch); these will no longer work in
    testing (bookworm) once Python has fully migrated to 3.10.

    * 6 packages have "all" or "current"; I have filed bug reports on
    these.

    So of the entire archive, only 6 packages have a correct and current
    use of X-Python3-Version.


    Here is the current Lintian wording:

    For use of py3versions --requested/-r without a corresponding X-Python3-Version: https://salsa.debian.org/lintian/lintian/-/blob/master/tags/d/declare-python-versions-for-test.tag

    Tag: declare-python-versions-for-test
    Severity: warning
    Check: testsuite
    Renamed-from:
    declare-requested-python-versions-for-test
    Explanation: 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 declare
    any versions with the field <code>X-Python3-Version</code>.
    .
    Please choose between two suggested remedies:
    .
    In most circumstances, it is probably best to replace the argument
    <code>--requested</code> with <code>--supported</code>. That will
    exercise the test with all available Python versions.
    .
    Should your installable require only specific Python versions, please add
    the field <code>X-Python3-Version</code> with the appropriate information
    to the source stanza in the <code>debian/control</code> file.
    .
    No redirection of the output, as in <code>2 &gt; /dev/null</code>, is
    needed in either case.
    See-Also:
    py3versions(1),
    Bug#1001677


    For the use of py3versions --supported/-s with the presence of X-Python3-Version (a rare occurrence): https://salsa.debian.org/lintian/lintian/-/blob/master/tags/q/query-declared-python-versions-in-test.tag

    Tag: query-declared-python-versions-in-test
    Severity: warning
    Check: testsuite
    Renamed-From:
    query-requested-python-versions-in-test
    Explanation: 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 query only the requested versions with the command
    <code>py3versions --requested</code>.
    See-Also:
    py3versions(1),
    Bug#1001677


    Best wishes,

    Julian

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