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: 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
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: 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
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ý