Re: MBF proposal: python modules that fail to import

[Herbert Fortes]

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

[Herbert Fortes]

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

[Scott Kitterman]

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

[Paul Wise]

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

[Helmut Grohne]

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

[Paul Gevers]

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

[Helmut Grohne]

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

[Helmut Grohne]

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

[Simon McVittie]

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

[Herbert Fortes]

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

[Johannes Schauer]

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

[Piotr Ożarowski]

[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

[Andreas Tille]

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

[Ondrej Novy]

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

[Ondrej Novy]

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

[Ondrej Novy]

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

[Ondrej Novy]

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

[Andreas Tille]

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

[Adam Borowski]

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

[Helmut Grohne]

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

[Christoph Biedl]

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

[Mattia Rizzolo]

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

[Scott Kitterman]

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

[Helmut Grohne]

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 

Re: MBF proposal: python modules that fail to import

[Mattia Rizzolo]

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