python-schedule should be probably moved to Debian Python Team
Hi, I've just fixed #1002316 by upgrading to latest upstream version. When looking at the package it might make sense to move it to Debian Python team instead of private maintainership. I'd volunteer to move the package over if all involved people agree. Kind regards Andreas. -- http://fam-tille.de
Re: Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian
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 requested by your sources with the command py3versions --requested but your sources do not actually declare those versions with the field X-Python3-Version. . Please query all supported Python versions with the command py3versions --supported in your test instead. 2. Change the desc for tag query-requested-python-versions-in-test to The specified test queries all supported Python versions with the command py3versions --supported but your sources request a specific set of versions via the field X-Python3-Version. . Please delete the field X-Python3-Version, 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)
Re: Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian
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 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, --defaultprint 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 signature.asc Description: This is a digitally signed message part.
Re: Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian
On Mon, 17 Jan 2022 12:47:44 -0500 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. 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/ pgp6eGTQw_JDx.pgp Description: OpenPGP digital signature
