Hi Stuart and python-qrcode maintainers-- In https://bugs.debian.org/782762 , Stuart Prescott wrote: > the python-qrcode source already supports Python 3 -- it would be great if > we could ship the relevant package in Debian.
thanks for this! A couple comments below. > From: Stuart Prescott <[email protected]> > Date: Fri, 17 Apr 2015 16:17:23 +1000 > Subject: [PATCH 4/5] Fix d/watch and signature checking > > * move to pypi.debian.net instead of chasing pypi upstream pages [...] > diff --git a/debian/watch b/debian/watch > index 008e261..8efaad1 100644 > --- a/debian/watch > +++ b/debian/watch > @@ -1,2 +1,2 @@ > version=3 > -opts=pgpsigurlmangle=s/$/.asc/ > https://pypi.python.org/packages/source/q/qrcode/qrcode-(.*).tar.gz > +opts=pgpsigurlmangle=s/$/.asc/ > http://pypi.debian.net/qrcode/qrcode-(.*).tar.gz This moves from an https URL to a cleartext http URL. This seems like an overall loss to me, even at the cost of "chasing" pypi a bit. I'd generally prefer to stick with the secure URL. If pypi isn't being stable, maybe we should ask them if they can try to stabilize? I note you didn't update the debhelper version requirements (or debian/compat) to 9, as recommended in https://wiki.debian.org/Python/LibraryStyleGuide Do we not need to worry about dh versioning? I generally think we should go with compat 9 where possible. I also note that the updated d/rules doesn't include PYBUILD_NAME, which i understood was a necessary value to export. > + This package contains the Python 2 module; the command line tools are in > + the python3-qrcode package. This is the biggest possible change to the package, and i'm not sure what to do about it. The change is: * python-qrcode used to include /usr/bin/qr (and its associated manpage) * in the new configuration, python3-qrcode ships this binary. This means that someone who has installed python-qrcode for the purposes of using /usr/bin/qr might be surprised to find that interface disappear from their system. I don't think there are any debian packages that have this dependency (the only rdepends are python-freeipa and keysync, which i think use the python modules and not /usr/bin/qr) but it's conceivable that some user had installed it this way and is now bummed. Python3 porters: what is the right way forward for packages like this? If we decide on a case-by-case basis, what is a reasonable rule of thumb to follow? I'm tempted to say that for this package, with its few reverse dependencies, and no explicit use of /usr/bin/qr that i can see, we can just move the script from python-qrcode to python3-qrcode. Alternately, we could have some sort of alternatives system so they could both provide the script, but this seems like it would be overkill. Any thoughts? I'm inclined to push changes like this (including Stuart's edits, and the move of /usr/bin/qr to python3-qrcode) to collab-maint and prepare an NMU once i've had the chance to test them. --dkg -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
