Possible MBF for SyntaxWarning with Python 3.8

2019-12-05 Thread Stuart Prescott
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?


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:


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

2019-12-05 Thread Louis-Philippe Véronneau
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:


  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org

Description: OpenPGP digital signature

Joining PAPT

2019-12-05 Thread Scott Talbert


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


Re: Joining the DPMT Team

2019-12-05 Thread Ondrej Novy

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.


Best regards
 Ondřej Nový

Re: Severity bump script

2019-12-05 Thread Paul Gevers

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.


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

Description: OpenPGP digital signature