Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
> On Nov 29, 2019, at 01:28, Simon McVittie wrote: > > Is there consensus that the top-level module name is what matters, and not > following the recommendation is a bug? > https://www.debian.org/doc/packaging-manuals/python-policy/module_packages.html > says "The binary package for module foo should preferably be named > python3-foo, if the module name allows" and "import foo should import > the module", which suggests that it is indeed the name of the top-level > importable module, and not the name of the egg, that matters (which would > imply that -dbus and -gi are correct, and -pypubsub is not). If the module name has upper case in it, it would actually break Policy §5.6.1 For example one of my package has module name fontParts, and if folllowing Python policy, the name would be python3-fontParts, and it would be a policy violation. So it has to be using all lower-case name, therefore running tests generated by autopkgtest fails. I have to generate the testing script manually and modify accordingly. Yao Wei (This email is sent from a phone; sorry for HTML email if it happens.)
Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
On November 28, 2019 5:27:53 PM UTC, Simon McVittie wrote: >On Thu, 28 Nov 2019 at 11:15:31 -0500, Sandro Tosi wrote: >> if you install `pubsub` as top-level module, your package must be >> named pythonN-pubsub, if not it violates the policy and it's RC >buggy. > >That's what I had thought, but I've also seen people asserting that the >Debian package name ought to reflect the egg name in cases where it >differs from the top-level Python module name. > >Some examples of where the difference between egg name and module name >matters: > >- this one: > - module: pubsub (-> python3-pubsub) > - egg: pypubsub-*.egg-info (-> python3-pypubsub) > - is actually python3-pypubsub (named for the egg) > >- src:dbus-python: > - module: dbus (-> python3-dbus) > - egg: dbus_python-1.2.14.egg-info (-> python3-dbus-python) > - is actually python3-dbus (named for the module) > >- src:pygobject: > - module: gi (-> python3-gi) and pygtkcompat > - egg: PyGObject-3.34.0.egg-info (-> python3-pygobject) > - is actually python3-gi (named for the module) > >(Maybe python3-gi should also have Provides: python3-pygtkcompat?) > >Is there consensus that the top-level module name is what matters, and >not >following the recommendation is a bug? >https://www.debian.org/doc/packaging-manuals/python-policy/module_packages.html >says "The binary package for module foo should preferably be named >python3-foo, if the module name allows" and "import foo should import >the module", which suggests that it is indeed the name of the top-level >importable module, and not the name of the egg, that matters (which >would >imply that -dbus and -gi are correct, and -pypubsub is not). > >Is there consensus that not following this recommendation is a *RC* >bug? >The bits I quoted above say "should" rather than "must". > >Thanks, >smcv Python Policy is not Debian Policy. It's not a "policy" violation in the sense of a serious bug. That said, it would be better to change it. Scott K
Re: Severity bump script
Hi, čt 28. 11. 2019 v 19:07 odesílatel Sandro Tosi napsal: > this is live now, with the following header: > cool, thanks again! -- Best regards Ondřej Nový
Bug#945792: RM: fpconst -- RoM; obsolete; no Python 3 support and no reverse deps
Package: ftp.debian.org Severity: normal User: debian-python@lists.debian.org Usertags: py2removal The only release was in 2005. https://www.python.org/dev/peps/pep-0754/ was abouyt including it into stdlib and it failed. The only revdep, jack-mixer, was recently removed from the archive. Popcon 17k, much higher than jack-mixer had, but it was 110k in 2014 so I suspect it's just an old dep of some long gone or updated package. Reverse deps checked with dak rm -Rnb python-fpconst -- WBR, wRAR signature.asc Description: PGP signature
Re: Severity bump script
> I think we should use something simple/short like this: > > --cut-- > Raising severity of Python 2 removal bugs, for details see: > https://lists.debian.org/debian-devel-announce/2019/11/msg0.html > --cut-- this is live now, with the following header: # Part of the effort for the removal of python from bullseye # * https://wiki.debian.org/Python/2Removal # * http://sandrotosi.me/debian/py2removal/index.html # See https://lists.debian.org/debian-devel-announce/2019/11/msg0.html # for more details on this severity bump # python-apns-client is a module and has 0 external rdeps severity 935212 serious . -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
Hi, čt 28. 11. 2019 v 17:11 odesílatel Andreas Tille napsal: > Hmmm, what are the chances to get this applied? I've added > tbh dunno :) > in Git - but this will not reall fix the test. The only solution I'd see > otherwise is to deactivate the test. > you have two options: 1. deactivate the test (remove Testsuite: autopkgtest-pkg-python from d/control) 2. call `autodep8 >debian/tests/control` and edit result -- Best regards Ondřej Nový
Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
On Thu, 28 Nov 2019 at 11:15:31 -0500, Sandro Tosi wrote: > if you install `pubsub` as top-level module, your package must be > named pythonN-pubsub, if not it violates the policy and it's RC buggy. That's what I had thought, but I've also seen people asserting that the Debian package name ought to reflect the egg name in cases where it differs from the top-level Python module name. Some examples of where the difference between egg name and module name matters: - this one: - module: pubsub (-> python3-pubsub) - egg: pypubsub-*.egg-info (-> python3-pypubsub) - is actually python3-pypubsub (named for the egg) - src:dbus-python: - module: dbus (-> python3-dbus) - egg: dbus_python-1.2.14.egg-info (-> python3-dbus-python) - is actually python3-dbus (named for the module) - src:pygobject: - module: gi (-> python3-gi) and pygtkcompat - egg: PyGObject-3.34.0.egg-info (-> python3-pygobject) - is actually python3-gi (named for the module) (Maybe python3-gi should also have Provides: python3-pygtkcompat?) Is there consensus that the top-level module name is what matters, and not following the recommendation is a bug? https://www.debian.org/doc/packaging-manuals/python-policy/module_packages.html says "The binary package for module foo should preferably be named python3-foo, if the module name allows" and "import foo should import the module", which suggests that it is indeed the name of the top-level importable module, and not the name of the egg, that matters (which would imply that -dbus and -gi are correct, and -pypubsub is not). Is there consensus that not following this recommendation is a *RC* bug? The bits I quoted above say "should" rather than "must". Thanks, smcv
Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
On Thu, Nov 28, 2019 at 11:15:31AM -0500, Sandro Tosi wrote: > > Hmmm, what are the chances to get this applied? I've added > > > >X-Python-Module-Name: pubsub > > > > in Git - but this will not reall fix the test. The only solution I'd see > > otherwise is to deactivate the test. > > if you install `pubsub` as top-level module, your package must be > named pythonN-pubsub, if not it violates the policy and it's RC buggy. > please rename the package. OK, just to make sure the package currently named python3-pypubsub installs files ... /usr/lib/python3/dist-packages/Pypubsub-4.0.3.egg-info /usr/lib/python3/dist-packages/Pypubsub-4.0.3.egg-info/PKG-INFO /usr/lib/python3/dist-packages/Pypubsub-4.0.3.egg-info/dependency_links.txt /usr/lib/python3/dist-packages/Pypubsub-4.0.3.egg-info/not-zip-safe /usr/lib/python3/dist-packages/Pypubsub-4.0.3.egg-info/top_level.txt /usr/lib/python3/dist-packages/pubsub /usr/lib/python3/dist-packages/pubsub/__init__.py /usr/lib/python3/dist-packages/pubsub/core /usr/lib/python3/dist-packages/pubsub/core/__init__.py /usr/lib/python3/dist-packages/pubsub/core/annotations.py /usr/lib/python3/dist-packages/pubsub/core/callables.py ... No idea about /usr/lib/python3/dist-packages/Pypubsub-4.0.3.egg-info but it seems I need to rename to python3-pubsub since there is the real module, right? Kind regards Andreas. -- http://fam-tille.de
Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
On Thu, Nov 28, 2019 at 11:11 AM Andreas Tille wrote: > > On Thu, Nov 28, 2019 at 04:18:07PM +0100, Ondrej Novy wrote: > > > > > Is there any trick to enable autopkgtest-pkg-python detecting the correct > > > module name? > > > > > > > no (not yet? See: https://salsa.debian.org/ci-team/autodep8/merge_requests/6 > > ) > > Hmmm, what are the chances to get this applied? I've added > >X-Python-Module-Name: pubsub > > in Git - but this will not reall fix the test. The only solution I'd see > otherwise is to deactivate the test. if you install `pubsub` as top-level module, your package must be named pythonN-pubsub, if not it violates the policy and it's RC buggy. please rename the package. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
On Thu, Nov 28, 2019 at 04:18:07PM +0100, Ondrej Novy wrote: > > > Is there any trick to enable autopkgtest-pkg-python detecting the correct > > module name? > > > > no (not yet? See: https://salsa.debian.org/ci-team/autodep8/merge_requests/6 > ) Hmmm, what are the chances to get this applied? I've added X-Python-Module-Name: pubsub in Git - but this will not reall fix the test. The only solution I'd see otherwise is to deactivate the test. Kind regards Andreas. -- http://fam-tille.de
Bug#945781: ITP: python-ibm-cloud-sdk-core -- Client library for the IBM Cloud services
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-ibm-cloud-sdk-core Version : 1.5.1 Upstream Author : Erika Dsouza * URL : https://github.com/IBM/python-sdk-core/ * License : Apache-2 Programming Lang: Python Description : Client library for the IBM Cloud services This project contains the core functionality used by Python SDK's generated by the IBM OpenAPI 3 SDK Generator (openapi-sdkgen). Python code generated by openapi-sdkgen will depend on the function contained in this project. . It supports the following types of authentication: * Basic Authentication * Bearer Token * Identity and Access Management (IAM) * Cloud Pak for Data * No Authentication I intend to maintain this package as part of DPMT. It is a requirement for newer versions of pyhton-imb-watson. -BEGIN PGP SIGNATURE- iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl3f6U0RHGZsYWRpQGRl Ymlhbi5vcmcACgkQ/9PIi5l90WqQxgf+KVW6/UuvEXHn39hErsWNuUNV5+5BS7qj W+phPzgtf9UlST5/vBKLNw/WZgFvJZb/5A4l5WViN92g3WHZp7AA2JoSGLKSPnl5 QM8B5lJ0vm1LYTCQM9J9DpYz6owlJB/JAijccHaZubYyzjG2VHFqPMoq5Qgh8DH2 SAxe5M69l9tqVarA6818Z70z1wnqDCjXb3teDK8uFrwFDzboVLH1t32BuI5gBztK vxCoYMGavpw1r3ueGcthrmX2lxt04VeYO89F0zhao5sKPO8jDwNFGq8geP55kzMu s6h6WL/8+DMCxFBnBEo1+c3+mVgfSPVqR4XjpihhtkQIKuv40VDWSw== =YhB1 -END PGP SIGNATURE-
Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
Hi, čt 28. 11. 2019 v 16:04 odesílatel Andreas Tille napsal: > Is there any trick to enable autopkgtest-pkg-python detecting the correct > module name? > no (not yet? See: https://salsa.debian.org/ci-team/autodep8/merge_requests/6 ) -- Best regards Ondřej Nový
autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
On Thu, Nov 28, 2019 at 12:46:34PM +0100, Paul Gevers wrote: > Source: python-pypubsub > Version: 4.0.3-2 > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: regression > > ... > > [1] https://qa.debian.org/excuses.php?package=python-pypubsub > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pypubsub/3403470/log.gz > > autopkgtest [15:15:47]: test autodep8-python3: set -e ; for py in > $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing > with $py:" ; $py -c "import pypubsub; print(pypubsub)" ; done > autopkgtest [15:15:47]: test autodep8-python3: [--- > Testing with python3.7: > Traceback (most recent call last): > File "", line 1, in > ModuleNotFoundError: No module named 'pypubsub' > autopkgtest [15:15:47]: test autodep8-python3: ---] The test is correct since the correct module name is pubsub (rather than pypubsub). It seems that's a usual pattern since if I check python3-pyvcf[1] it ends up in: autopkgtest [08:47:45]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import pyvcf; print(pyvcf)" ; done autopkgtest [08:47:45]: test autodep8-python3: [--- Testing with python3.8: Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'pyvcf' autopkgtest [08:47:46]: test autodep8-python3: ---] autopkgtest [08:47:46]: test autodep8-python3: - - - - - - - - - - results - - - - - - - - - - autodep8-python3 FAIL non-zero exit status 1 Is there any trick to enable autopkgtest-pkg-python detecting the correct module name? Kind regards Andreas. [1] https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-pyvcf/3462810/log.gz -- http://fam-tille.de
Bug#945775: python-sponge: should this package be removed.
Package: python-sponge Severity: serious x-debbugs-cc: debian-python@lists.debian.org While looking at some python2 removal issues, I came across python sponge. I noticed the following about the package. * Python 2 only. * Only one maintainer upload (and one NMU) ever. * Not in stable or testing * RC buggy for nearly two years with no maintainer response. * Upstream seems inactive (no commits since 2010, no releases since the one that was packaged for Debian in 2009) * No rdeps. To me this adds up to a package that is not in a fit state to remain in Debian, if noone disagrees I will likely convert this bug to a removal request in the not too distant future.
Re: Severity bump script
Hi, čt 28. 11. 2019 v 4:12 odesílatel Sandro Tosi napsal: > i'm not sure we can: in > https://lists.debian.org/debian-python/2019/10/msg00096.html you say > "We need to prepare draft of RC-bumper email", is this draft ready? > ah, you are right. > add the description to the header (as comment) of a mail to control@? > this is only way to go imho. I think we should use something simple/short like this: --cut-- Raising severity of Python 2 removal bugs, for details see: https://lists.debian.org/debian-devel-announce/2019/11/msg0.html --cut-- Thanks Sandro for working on this. -- Best regards Ondřej Nový
