Possible MBF for SyntaxWarning with Python 3.8
Hi all,
Python 3.8 generates a SyntaxWarning when it sees code that is most probably
incorrect such as
if foo is 0:
...
if bar is not 'quux':
...
if baz is ():
...
When the Debian package is installed, py3compile sees such code and causes a
pile of SyntaxWarning messages to be spewed in the middle of the apt run.
Since code like the above is wrong and errors are unwelcome for the user (and
are likely to generate quite a lot of support requests), I propose an MBF on
the issue.
Looking through piuparts installation logs for packages in sid, I've so far
identified 75 binary packages that emit SyntaxWarning on installation, but that
is only the subset of python packages that happen to have been installed by
piuparts over the last 60 days. I guess we'll need to continue to look at
piuparts logs and that we will find more.
Any thoughts?
cheers
Stuart
raw entries from piuparts logs: https://people.debian.org/~stuart/swlog
data for bug reports: https://people.debian.org/~stuart/swbugs
ddlist: https://people.debian.org/~stuart/swddlist
bug template:
Subject: {package} generates SyntaxWarning at install time
Package: {package}
Version: {version}
Severity: important
Tags: sid bullseye
User: debian-python@lists.debian.org
Usertags: py38syntaxwarning
Dear maintainer,
Python 3.8 introduced a series of checks that look for code that is highly
likely to be buggy. When the code is processed by Python 3.8, it emits a
SyntaxWarning complaining about the code. For Debian packages, these
warnings will be visible at package install time.
This package generates SyntaxWarning output during package install:
{output}
Fixing this class of bug is generally straightforward and the upstream
developers may have already done so.
If there are questions, please ask for help on IRC #debian-python, or
the debian-python@lists.debian.org mailing list.
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Prefered way to RFS
On 19-12-05 01 h 50, Håvard Flaget Aasen wrote: > Thanks! > > Is this something that could be added here? > https://wiki.debian.org/Python/GitPackaging#Sponsoring.2C_mentoring.2C_reviewing Sure. This is also documented on this page, although it might not be the best place for it: https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Joining PAPT
Hi, I'm already a member of DPMT, I would like to join PAPT as well so I can also contribute to those packages. I have read the policy and accept it. Salsa ID: swt2c-guest Thanks, Scott
Re: Joining the DPMT Team
Hi, st 4. 12. 2019 v 17:07 odesílatel Boyuan Yang napsal: > ... Can > anyone add me into the DPMT Team? My Salsa account is @byang. > done. -- Best regards Ondřej Nový
Re: Severity bump script
Hi, On 03-12-2019 13:19, Matthias Klose wrote: > It's unfortunate that issues for some packages only get attention when the > severity of an issue is raised. Following your proposal means that the issue > is > probably ignored forever, and you don't propose a better way going forward, > just > saying we should stop earlier. I don't think that's the correct choice. For > now these seem to be single packages, so please could you name those, and we > can > look at those with a priority? That's at least a path that is forward > looking, > or feel free to propose another approach better than your current proposal for > not getting the attention of maintainers. I guess what I'm asking for could be fulfilled by an announcement to d-d-a with a package list (including via which package(s) they are affected) attached including the standard grouping by DD. And then some time to react. Paul PS, my original typed reply below. After having writing it, the idea above emerged. My problem with the current approach is that the way that developers learn that they (potentially transitively) (build) depend on a Python 2 package is by the autoremoval message. I don't think that is acceptable socially in the project. My proposal is to give the maintainers about those packages a heads up. Via a bug report may be a bit weird in cases, but in some cases may be the appropriate thing as the package could work around the (build) dependency. At least adding "affects" helps a tiny bit and direct e-mails to the maintainers (e.g. via the @packages.debian.org address will at least give them a heads up. Even if the RM bug is coming eventually. Again, I don't have a problem with Python 2 removal, even at the price of packages that don't care that their dependency is written in Python. I do care about proper communication. Using RC severity to trigger autoremoval for non-leaf packages just yet is not appropriate in the opinion of the release team. Even though I am well aware of the Python 2 removal effort I can tell from personal experience (cacti) that receiving an autoremoval e-mail as the first sign of such a dependency isn't nice, that's the problem I'm having and that needs solving in my opinion. signature.asc Description: OpenPGP digital signature
