Re: MBF proposal: python modules that fail to import
Em 16-04-2018 17:16, Helmut Grohne escreveu: > On Mon, Apr 16, 2018 at 04:14:21PM -0300, Herbert Fortes wrote: >> Package python3-dj-static is on the dd-list. But I can import it. >> >> # on a bananapi >> >> $ python3 >> Python 3.5.3 (default, Jan 19 2017, 14:11:04) >> [GCC 6.3.0 20170124] on linux >> Type "help", "copyright", "credits" or "license" for more information. > import static # dependency > import dj_static # module > > > For most of these bug reports there exists a setting in which the > modules can be imported. E.g. a significant chunk of them becomes > importable after installing python3-pkg-resources. > >> If I understood correct (about the test), please note the diff: >> >> python3-dj-static # Debian package >> dj_static # module >> >> The package name uses '-' and the module '_'. > > In my initial mail there is a draft.gz that contains the proposed bug > reports. Searching for python3-dj-static yields: > > | After installing python3-dj-static importing the module dj_static > | into a python interpreter fails with the following error: > | > | Traceback (most recent call last): > | File "", line 1, in > | File "/usr/lib/python3/dist-packages/dj_static.py", line 5, in > | from django.conf import settings > | ModuleNotFoundError: No module named 'django' > > So my heuristic did select the right module and it failed to import, > because no dependency on python3-django was declared. Thus the bug > report seems legitimate to me. > -1 bug report. :) running checksum: verify checksums before uploading running suite-mismatch: check the target distribution for common errors running gpg: check GnuPG signatures before the upload Uploading dj-static_0.0.6-5.dsc Uploading dj-static_0.0.6.orig.tar.gz Uploading dj-static_0.0.6-5.debian.tar.xz Uploading dj-static_0.0.6-5_amd64.buildinfo Uploading dj-static_0.0.6-5_amd64.changes
Re: MBF proposal: python modules that fail to import
> > In my initial mail there is a draft.gz that contains the proposed bug > reports. Searching for python3-dj-static yields: > > | After installing python3-dj-static importing the module dj_static > | into a python interpreter fails with the following error: > | > | Traceback (most recent call last): > | File "", line 1, in > | File "/usr/lib/python3/dist-packages/dj_static.py", line 5, in > | from django.conf import settings > | ModuleNotFoundError: No module named 'django' > > So my heuristic did select the right module and it failed to import, > because no dependency on python3-django was declared. Thus the bug > report seems legitimate to me. > That is true. The package does not make sense without Django. It is a Django middleware. I also checked manually in a chroot without Django and got an 'ImportError'. I will fix the dependency. Regards, Herbert
Re: MBF proposal: python modules that fail to import
On Tuesday, April 17, 2018 10:45:29 AM Paul Wise wrote: > On Tue, Apr 17, 2018 at 5:00 AM, Helmut Grohne wrote: > > The difficult one is deriving the module name from the list of files. > > It should be just reading top_level.txt from the egg-info directory? For packages that use setuptools, which isn't all of them. Possibly not even a majority. Scott K
Re: MBF proposal: python modules that fail to import
On Tue, Apr 17, 2018 at 5:00 AM, Helmut Grohne wrote: > The difficult one is deriving the module name from the list of files. It should be just reading top_level.txt from the egg-info directory? -- bye, pabs https://wiki.debian.org/PaulWise
Re: MBF proposal: python modules that fail to import
On Mon, Apr 16, 2018 at 12:00:24PM +0200, Ondrej Novy wrote: > I tried to do my best :) > > https://sources.debian.org/src/autodep8/0.11.1/support/python/generate/ > > Feel free to add more "magic" for module name detection. There is an easy improvement and a difficult one I can propose. The easy one is adding -examples to the list of ignored package suffixes. The difficult one is deriving the module name from the list of files. My initial mail contains a genlist.py that shows my technique for computing the module name. Essentially it looks for all *.py files, trims .py, then trims /__init__ and then looks for a common prefix of all .py files. If there is a single prefix, then we found the module name. This finds things such as: * python-azure-storage -> azure.storage (likely the binary package should be renamed to python-azure.storage) * python-ball -> BALL * python-bd2k -> bd2k.util * python-bpfcc -> bcc * python-distutils-extra -> DistUtilsExtra * python-djangorestframework-gis -> rest_framework_gis * python-dogpile.cache -> dogpile * python-fftw -> fftw3 * python-pastewebkit -> paste.webkit (again rename to python-paste.webkit?) * python-pyscss -> scss * python-pysnmp4 -> pysnmp * python-tcpwrap -> pytcpwrap I'm not sure how I'd add this to the generate script, but there clearly is room for improvement over s/-/_/. There also is room for improving our package naming. Would it help to get a list of binary packages that could be covered by the current autodep8 if they were named correctly (according to the Python Policy)? Actually renaming them might make ftp masters a bit grumpy though. Helmut
Re: MBF proposal: python modules that fail to import
Hi On 16-04-18 12:03, Ondrej Novy wrote: > I think it's good idea to mass commit this (adding Testsuite: > autopkgtest-pkg-python) into Git repos. We should probably merge this > list with Debian CI whitelist one. I assume you mean you want to mass commit the packages that are currently on the whitelist. We (the CI team) want to reduce (or get rid of) the whitelists as much as possible as it is not well maintainable in the team and they have other issues like Scott pointed out. They are/should be used to bootstrap an autodep8 language, but shouldn't be considered long term solutions. Paul signature.asc Description: OpenPGP digital signature
Re: MBF proposal: python modules that fail to import
On Mon, Apr 16, 2018 at 04:14:21PM -0300, Herbert Fortes wrote: > Package python3-dj-static is on the dd-list. But I can import it. > > # on a bananapi > > $ python3 > Python 3.5.3 (default, Jan 19 2017, 14:11:04) > [GCC 6.3.0 20170124] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import static # dependency > >>> import dj_static # module > >>> For most of these bug reports there exists a setting in which the modules can be imported. E.g. a significant chunk of them becomes importable after installing python3-pkg-resources. > If I understood correct (about the test), please note the diff: > > python3-dj-static # Debian package > dj_static # module > > The package name uses '-' and the module '_'. In my initial mail there is a draft.gz that contains the proposed bug reports. Searching for python3-dj-static yields: | After installing python3-dj-static importing the module dj_static | into a python interpreter fails with the following error: | | Traceback (most recent call last): | File "", line 1, in | File "/usr/lib/python3/dist-packages/dj_static.py", line 5, in | from django.conf import settings | ModuleNotFoundError: No module named 'django' So my heuristic did select the right module and it failed to import, because no dependency on python3-django was declared. Thus the bug report seems legitimate to me. Helmut
Re: MBF proposal: python modules that fail to import
On Mon, Apr 16, 2018 at 01:44:48PM +0200, Piotr Ożarowski wrote:
> [Helmut Grohne, 2018-04-15]
> > Piotr Ożarowski
> >python-changelog (U)
> >python-sphinx-paramlinks (U)
> >python3-changelog (U)
> >python3-sphinx-paramlinks (U)
>
> These packages provide sphinx plugins and have Enhances: python{,3}-sphinx
> Missing module is available after installing python{,3}-sphinx
I understand that sphinx plugins are meant to extend sphinx. What I
don't understand is why they shouldn't simply depend on sphinx.
Please elaborate how you can use sphinx plugins without installing
sphinx.
To me it looks like this simply is a missing dependency and adding it
the right course of action. Thus the bug reports against these packages
seem warranted to me.
Helmut
Re: MBF proposal: python modules that fail to import
On Mon, 16 Apr 2018 at 16:14:21 -0300, Herbert Fortes wrote: > Package python3-dj-static is on the dd-list. But I can import it. ... > The package name uses '-' and the module '_'. I think this is a false positive in the preparation of the dd-list. /usr/share/autodep8/support/python/generate correctly applies s/-/_/g to the module name before trying to import it. smcv
Re: MBF proposal: python modules that fail to import
Hi, Em 15-04-2018 15:56, Helmut Grohne escreveu: > Hi, > > I was surprised to find a python module that failed to import thinking > that our qa would catch this. So I wondered how many other python > modules would fail to import and started a little yak shaving journey. > > It turns that this happens for 251 python modules. Since failure to > import the main module of a python library indicates that the modules > doesn't work at all, I propose to file this at severity serious. > > Actually, there is autodep8 at ci.debian.net testing this already. It > has a whitelist > (https://salsa.debian.org/ci-team/debian-ci-config/blob/master/cookbooks/debci/files/default/whitelist-python.txt) > of around 800 packages opting in to import testing. Unfortunately, the > results do not seem to be synced into tracker.d.o. The main difficulty > is determining the name of the python module. Sometimes capitalization > differs from the package name. Other times a completely different name > is used. Thus I am attaching a genlist.py that tries to compute the > module name and it succeeds in about 4300 packages. > > Thus I tried installing and importing all of these and figured that 251 > packages would fail. The process of installing and importing is rather > simple and implemented in autodep8 already, so I'm not attaching my > crude hacks here. Nonetheless I am attaching a draft of the proposed bug > reports since each of them includes a specific error. I also include a > dd-list of affected packages. > > The most common issues is missing dependencies. Very often, > pkg_resources is missing. Also six, numpy, tkinter and distutils are > missing several times. A fair number of strange exceptions is included > as well. When dealing with C extensions, we are faced with two > segmentation faults, one assertion failure and three missing symbols. > Package python3-dj-static is on the dd-list. But I can import it. # on a bananapi $ python3 Python 3.5.3 (default, Jan 19 2017, 14:11:04) [GCC 6.3.0 20170124] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import static # dependency >>> import dj_static # module >>> If I understood correct (about the test), please note the diff: python3-dj-static # Debian package dj_static # module The package name uses '-' and the module '_'.
Re: MBF proposal: python modules that fail to import
Hi,
Quoting Adam Borowski (2018-04-15 22:30:47)
> On Sun, Apr 15, 2018 at 09:45:45PM +0200, Helmut Grohne wrote:
> > On Sun, Apr 15, 2018 at 09:38:27PM +0200, Christoph Biedl wrote:
> > > The src:file package doesn't ship python{,3}-magic any longer, the change
> > > was two months ago. Mind to check how file got on this list?
> > I used "apt-cache showsrc python-magic" to get the source package and
> > Testsuite header. It seems that this is not the best approximation as it
> > includes non-recent versions. The list thus needs to be treated as an
> > overapproximation. I don't have a good idea how to fix that part atm.
> You can write a script to read apt-avail, parse it as 822, drop all entries
> that have an entry with same Package but higher Version.
>
> Not exactly brain surgery, but tedious enough that it should be providen
> _somewhere_. And at least one moron has written exactly that but misplaced
> the script somewhere -- one more reason to have the wheel around so no one
> needs to reinvent it.
Alternatively, use "apt-cache showsrc --no-all-versions" which will print the
candidate version. The candidate version is usually the highest version
available to apt. If you combine this approach with chdist, then you should not
run into false positives anymore.
Or, if you want to follow Adam's approach reading apt-avail, and only retain
the highest version of each package you can use botch-latest-version to do the
filtering.
Thanks!
cheers, josch
signature.asc
Description: signature
Re: MBF proposal: python modules that fail to import
[Helmut Grohne, 2018-04-15]
> Piotr Ożarowski
>python-changelog (U)
>python-sphinx-paramlinks (U)
>python3-changelog (U)
>python3-sphinx-paramlinks (U)
These packages provide sphinx plugins and have Enhances: python{,3}-sphinx
Missing module is available after installing python{,3}-sphinx
same situation most probably also in: python3-sphinxcontrib.autoprogram,
python3-sphinxcontrib.plantuml, python3-sphinxcontrib.rubydomain,
python3-sphinxcontrib.youtube
--
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: MBF proposal: python modules that fail to import
Hi Ondrej, On Mon, Apr 16, 2018 at 11:58:17AM +0200, Ondrej Novy wrote: > > sry. I only removed useless Testsuite: autopkgtest-pkg in git. > > Checking if d/tests already exists before adding autopkgtest-pkg-python is > really important. You can add autopkgtest-pkg-python even if there is > d/tests, but you should rename d/tests/control to d/tests/control.autodep8 OK, this was new to me. I added autopkgtest-pkg-python to python-csb and renamed d/tests/control to d/tests/control.autodep8. Thanks for the hint Andreas. -- http://fam-tille.de
Re: MBF proposal: python modules that fail to import
Hi, 2018-04-15 21:27 GMT+02:00 Helmut Grohne : > Note that autopkgtest-pkg-python is only applicable when the module name > matches the package name. That's true for the majority of packages, but > not for all (e.g. capitalization). Nevertheless, a lot of packages are > missing the flag. Since I have the data at hand, I figured it would be > easy to generate a dd-list of packages named after their module that > lack the tag. You find that list attached. > I think it's good idea to mass commit this (adding Testsuite: autopkgtest-pkg-python) into Git repos. We should probably merge this list with Debian CI whitelist one. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: MBF proposal: python modules that fail to import
Hi, 2018-04-15 21:32 GMT+02:00 Mattia Rizzolo : > On Sun, Apr 15, 2018 at 09:27:30PM +0200, Helmut Grohne wrote: > > Note that autopkgtest-pkg-python is only applicable when the module name > > matches the package name. That's true for the majority of packages, but > > not for all (e.g. capitalization). > > This could be fixed in autodep8. > File a bug maybe? > I tried to do my best :) https://sources.debian.org/src/autodep8/0.11.1/support/python/generate/ Feel free to add more "magic" for module name detection. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: MBF proposal: python modules that fail to import
Hi, 2018-04-16 11:56 GMT+02:00 Ondrej Novy : > already done in git. > sry. I only removed useless Testsuite: autopkgtest-pkg in git. Checking if d/tests already exists before adding autopkgtest-pkg-python is really important. You can add autopkgtest-pkg-python even if there is d/tests, but you should rename d/tests/control to d/tests/control.autodep8 -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: MBF proposal: python modules that fail to import
Hi, 2018-04-16 11:47 GMT+02:00 Andreas Tille : > > W: python-csb source: unnecessary-testsuite-autopkgtest-field > ... > So before doing a MBF "Missing Testsuite: autopkgtest-pkg-python" > this should be checked as well. > already done in git. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: MBF proposal: python modules that fail to import
Hi Helmut, On Sun, Apr 15, 2018 at 09:27:30PM +0200, Helmut Grohne wrote: > > For more information: https://wiki.debian.org/Python/LibraryStyleGuide > > Note that autopkgtest-pkg-python is only applicable when the module name > matches the package name. That's true for the majority of packages, but > not for all (e.g. capitalization). Nevertheless, a lot of packages are > missing the flag. Since I have the data at hand, I figured it would be > easy to generate a dd-list of packages named after their module that > lack the tag. You find that list attached. Thanks for assembling this list. > ... > Andreas Tille > ... >python-csb (U) I'd consider this a false positive since the package has a dedicated test suite. When adding "Testsuite: autopkgtest-pkg-python" you get a lintian warning: W: python-csb source: unnecessary-testsuite-autopkgtest-field N: N:You do not need to specify a Testsuite: autopkgtest field if a N:debian/tests/control file exists. It is automatically added by N:dpkg-source(1) since dpkg 1.17.1. N: N:Please remove this line from your debian/control file. N: N:Severity: normal, Certainty: certain N: N:Check: testsuite, Type: source N: So before doing a MBF "Missing Testsuite: autopkgtest-pkg-python" this should be checked as well. Kind regards Andreas (just updated five other packages accordingly) -- http://fam-tille.de
Re: MBF proposal: python modules that fail to import
On Sun, Apr 15, 2018 at 09:45:45PM +0200, Helmut Grohne wrote:
> On Sun, Apr 15, 2018 at 09:38:27PM +0200, Christoph Biedl wrote:
> > > Christoph Biedl
> > >file
> >
> > The src:file package doesn't ship python{,3}-magic any longer, the
> > change was two months ago. Mind to check how file got on this list?
>
> I used "apt-cache showsrc python-magic" to get the source package and
> Testsuite header. It seems that this is not the best approximation as it
> includes non-recent versions. The list thus needs to be treated as an
> overapproximation. I don't have a good idea how to fix that part atm.
You can write a script to read apt-avail, parse it as 822, drop all
entries that have an entry with same Package but higher Version.
Not exactly brain surgery, but tedious enough that it should be providen
_somewhere_. And at least one moron has written exactly that but misplaced
the script somewhere -- one more reason to have the wheel around so no one
needs to reinvent it.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC?
⠈⠳⣄
Re: MBF proposal: python modules that fail to import
On Sun, Apr 15, 2018 at 09:38:27PM +0200, Christoph Biedl wrote:
> > Christoph Biedl
> >file
>
> The src:file package doesn't ship python{,3}-magic any longer, the
> change was two months ago. Mind to check how file got on this list?
I used "apt-cache showsrc python-magic" to get the source package and
Testsuite header. It seems that this is not the best approximation as it
includes non-recent versions. The list thus needs to be treated as an
overapproximation. I don't have a good idea how to fix that part atm.
Helmut
Re: MBF proposal: python modules that fail to import
Helmut Grohne wrote...
> Note that autopkgtest-pkg-python is only applicable when the module name
> matches the package name. That's true for the majority of packages, but
> not for all (e.g. capitalization). Nevertheless, a lot of packages are
> missing the flag. Since I have the data at hand, I figured it would be
> easy to generate a dd-list of packages named after their module that
> lack the tag. You find that list attached.
> Christoph Biedl
>file
The src:file package doesn't ship python{,3}-magic any longer, the
change was two months ago. Mind to check how file got on this list?
Christoph, otherwise happy to support qa efforts
signature.asc
Description: PGP signature
Re: MBF proposal: python modules that fail to import
On Sun, Apr 15, 2018 at 09:27:30PM +0200, Helmut Grohne wrote: > On Sun, Apr 15, 2018 at 09:08:55PM +0200, Mattia Rizzolo wrote: > > BTW, last I heard from terceiro about this, I understood that whitelist > > is a workaround and packages are expected to add > > Testsuite: autopkgtest-pkg-python > > to their d/control. > > > > For more information: https://wiki.debian.org/Python/LibraryStyleGuide > > Note that autopkgtest-pkg-python is only applicable when the module name > matches the package name. That's true for the majority of packages, but > not for all (e.g. capitalization). This could be fixed in autodep8. File a bug maybe? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: MBF proposal: python modules that fail to import
On Sunday, April 15, 2018 09:08:55 PM Mattia Rizzolo wrote: > On Sun, Apr 15, 2018 at 08:56:34PM +0200, Helmut Grohne wrote: > > Actually, there is autodep8 at ci.debian.net testing this already. It > > has a whitelist > > (https://salsa.debian.org/ci-team/debian-ci-config/blob/master/cookbooks/d > > ebci/files/default/whitelist-python.txt) of around 800 packages opting in > > to import testing. > > BTW, last I heard from terceiro about this, I understood that whitelist > is a workaround and packages are expected to add > Testsuite: autopkgtest-pkg-python > to their d/control. It was also not opt-in. Scott K
Re: MBF proposal: python modules that fail to import
On Sun, Apr 15, 2018 at 09:08:55PM +0200, Mattia Rizzolo wrote: > BTW, last I heard from terceiro about this, I understood that whitelist > is a workaround and packages are expected to add > Testsuite: autopkgtest-pkg-python > to their d/control. > > For more information: https://wiki.debian.org/Python/LibraryStyleGuide Note that autopkgtest-pkg-python is only applicable when the module name matches the package name. That's true for the majority of packages, but not for all (e.g. capitalization). Nevertheless, a lot of packages are missing the flag. Since I have the data at hand, I figured it would be easy to generate a dd-list of packages named after their module that lack the tag. You find that list attached. Helmut "Super" Nathan Weber aafigure A Mennucc1 freevo (U) pygame (U) pygooglechart acrefoot mandrill Adam C. Powell, IV pysparse (U) Adrian Alves python-cluster (U) python-stopit (U) Adrian Vondendriesch htmlmin (U) Afif Elghraoui pbalign (U) pbh5tools (U) python-avro (U) python-cobra (U) python-colormap (U) python-easydev (U) python-pbcommand (U) python-pbcore (U) python-pysam (U) swiglpk (U) Aggelos Avgerinos py-radix (U) Agustin Henze aiocoap docopt doit logbook natsort python-cbor python-livereload webassets yapsy Agustin Henze python-pygal (U) Aigars Mahinovs gphoto2-cffi hidapi-cffi isbnlib piggyphoto python-zipstream Al Stone python-jenkinsapi Alan Boudreault mapserver (U) Alastair McKinstry adios drslib ecflow fparser grib-api gsw iapws mathgl (U) metaconfig python-cdo python-xarray (U) spherepack usagestats xdmf Alberto Caso pydbus (U) Aleksey Kravchenko rhash-bindings Alessio Treglia laditools (U) python-pbkdf2 securepass-tools (U) Alexandre Fayolle python-scipy (U) Alexandre Gramfort python-mne (U) Alexandre Mestiashvili python-multipletau (U) Alexandre Quessy lunch (U) python-txosc (U) Alexandre Viau influxdb-python Alexey Nezhdanov python-xmpp Alexis Murzeau streamlink Ana Custura lexicon python-cymruwhois python-offtrac tldextract yapf Andrea Colangelo python-httplib2 python-roman (U) Andrea Corbellini python-iowait Andrea Palazzi python-quantities (U) Andreas Noteng python-easygui Andreas Tille manila (U) Andreas Tille cvxopt (U) gdcm (U) ngs-sdk (U) openslide-python (U) python-backports.tempfile (U) python-backports.weakref (U) python-biotools (U) python-burrito (U) python-cogent (U) python-csb (U) python-cutadapt (U) python-hl7 (U) python-jsondiff (U) python-pyfaidx (U) python-pyflow (U) python-pysam (U) python-qcli (U) python-ruffus (U) python-sqlsoup (U) python-treetime (U) python-xopen (U) r-cran-fastcluster (U) sphinxcontrib-autoprogram (U) tifffile (U) Andrew Bartlett samba (U) Andrew Gee python-xmltv Andrew Mitchell mocker (U) python-configglue Andrew Pollock pacparser (U) python-prctl (U) Andrew Shadura pydenticon pyte python-canonicaljson python-catcher python-ewmh (U) python-exconsole python-phonenumbers python-reconfigure python-signedjson python-unpaddedbase64 python-urlobject python-wheezy.template (U) waitress Andrew Starr-Bochicchio python-unipath (U) Andrew Starr-Bochicchio bzr (U) keybinder libcloud (U) python-digitalocean (U) pywapi (U) pyxdg (U) responses (U) smartypants (U) typogrify (U) Andrey Rahmatullin ipdb (U) Andriy Senkovych sqlparse Angel Ramos genetic Angelos Tzotsos geolinks (U) owslib (U) pycsw (U) python-osmapi (U) pywps (U) Anibal Monsalve Salazar pcp (U) Anthony Fok python-ly (U) Anthony Towns beanbag Antoine Beaupré pymediainfo (U) pyprind (U) python-colour (U) python-spake2 Antoine Musso python-gear (U) python-statsd (U) voluptuous (U) Antoine R. Dumont (@ardumont) python-msrest (U) python-msrestazure (U) Anton Gladky pycollada (U) pygts (U) pysparse (U) sfepy (U) woo (U) Antonio Terceiro elixir-lang (U) lxc (U) python-whitenoise (U) Antonio Valentino mipp (U) numexpr (U) pycoast (U) pykdtree (U) pyorbital (U) pyresample (U) pytables (U) python-mpop (U) Apollon Oikonomopoulos beanstalkc (U) python-hiredis (U) APT Development Team python-apt Arnaud Fontaine impacket ply pyscript python-mechanize (U) python-medusa ropemacs ropemode twill zc.buildout (U) zope.testbrowser (U) Arno Töll dput-ng (U) Arthur de Jong python-pskc python-stdnum Arthur Vuillard python-parse (U) Ask Hjorth Larsen python-ase (U) Aurelien Jarno d2to1 (U) libftdi libftdi1 stsci.distutils (U) Axel Beckert w
Re: MBF proposal: python modules that fail to import
On Sun, Apr 15, 2018 at 08:56:34PM +0200, Helmut Grohne wrote: > Actually, there is autodep8 at ci.debian.net testing this already. It > has a whitelist > (https://salsa.debian.org/ci-team/debian-ci-config/blob/master/cookbooks/debci/files/default/whitelist-python.txt) > of around 800 packages opting in to import testing. BTW, last I heard from terceiro about this, I understood that whitelist is a workaround and packages are expected to add Testsuite: autopkgtest-pkg-python to their d/control. For more information: https://wiki.debian.org/Python/LibraryStyleGuide > Any objections to me filing 251 rc bugs? Please, file them! :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
