Re: rdflib: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p "3.10 3.9" returned exit code 13

2022-02-24 Thread Nilesh Patra

On 2/24/22 6:10 PM, Andreas Tille wrote:

Sorry for dragging you into this - the experimental branch was way
advanced which I learned in bug #995675.  This leaves the question how
we can proceed.  It makes probably sense to run ratt or something like
this to learn about packages that are broken.


Looks like I made some wasted effort there :/
Although, Michael's changes are pretty similar to mine


Unfortunately I did
never got ratt working (since I failed to setup sbuild properly).


Would be nice if you could do this. There's also a ruby-team/meta[1] these are 
all
shell scripts so maybe you could use
maybe you can replace sbuild with pdebuild (or whatever you use) and try


On the other hand in the current situation with two open RC bugs all
other packages are broken anyway and will be removed from testing if
we do not act upon the issue.  So may be we should upload to unstable?

What do you think?


Pseudo excuses do not look too bad[2] and package in testing this is broken 
anyway,
you can upload IMO

[1]: https://salsa.debian.org/ruby-team/meta
[2]: https://release.debian.org/britney/pseudo-excuses-experimental.html#rdflib

Regards,
Nilesh




OpenPGP_signature
Description: OpenPGP digital signature


Re: rdflib: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p "3.10 3.9" returned exit code 13

2022-02-24 Thread Nilesh Patra

On 2/24/22 6:00 PM, Nilesh Patra wrote:

One really odd thing I noticed is that there is no dh_auto_build is overridden 
but not triggered inside it again,
and so dh_auto_build happening at all.

^

Wow, in a hurry I wrote really sloppy english there
I meant there is a override_dh_auto_build in d/rules, but nothing sensible is 
happening there except for
building docs, i.e. dh_auto_build is not called again in the override, and so 
there is no build happening at all.
I fixed this thing.



OpenPGP_signature
Description: OpenPGP digital signature


Re: rdflib: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p "3.10 3.9" returned exit code 13

2022-02-24 Thread Nilesh Patra

On 2/24/22 3:36 PM, Andreas Tille wrote:

Please consider releasing rdflib v6 which in my brief testing is
compatible with pyparser v3.


I tried to follow your suggestion to upgrade rdflib to version 6 in Git.
Unfortunately I'm stumbling upon a different issue in the new test
suite[1].


One really odd thing I noticed is that there is no dh_auto_build is overridden 
but not triggered inside it again,
and so dh_auto_build happening at all.
So I enabled this, which got the tests running.
Next there were some tests that need internet access or trying to open tcp 
ports, so I disabled them;
after which the package is building.

I am simply running these tests also as autopkgtest with "needs-internet" 
restriction which should be a good
enough scrutiny.

All changes in salsa. But please kindly check this properly before you do a 
dput.

Hope that helps.

Regards,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature


Re: Salsa python-team write access for tiledb-py ?

2022-02-18 Thread Nilesh Patra

On 2/18/22 9:33 PM, Dirk Eddelbuettel wrote:


Hi debian-python,
[...]
I cannot write to https://salsa.debian.org/python-team/packages/tiledb-py so
I created a (temporary ?) copy at https://salsa.debian.org/edd/tiledb-py
If you're ok with me updating the team repo, I can reset origin and push to
existing one.


I granted you access to that repo; I however do not have enough powers to add 
you into
the team.
But I hope that helps you, anyway.

Regards,
Nilesh




OpenPGP_signature
Description: OpenPGP digital signature


Re: Should we allow Janitor to commit directly to all DPT packages?

2022-02-17 Thread Nilesh Patra

On 2/18/22 2:23 AM, Sandro Tosi wrote:

I admit I'm hesitating a bit for different reasons.  While I agree that
direct commits are better than MRs I found several DPT packages with
very sensible changes in Git but no uploads following these.  For
instance fixing VCS fields and Maintainer name should be followed by an
according upload to make those changes visible to users and developers
of the *packages* in Debian.

In the Debian Med team for instance we do those automatic changes before
uploading a package - say when upgrading to new upstream versions or
fixing some bugs.  Than we run the Janitor scripts and other automatic
changes which is all done in routine-update.  I personally find this
workflow more convenient.  That way Debian Med team (as well as pkg-r
team) are blacklisted for Janitor to not have competing changes inside
the package.


thanks for bringing the perspective of how things are done in the Med
team, but it feels none of the points you mentioned nor the specific
Med team workflow apply here,


I suppose the highlight was the usage of routine-update[1] package before upload
and we could use it with DPT too.
This does similar(same?) changes as in janitor.

But that said, I agree with what you wrote:


or are relevant to just let Janitor
commit directly to our packages.


I vote a in for/OK for janitor to commit directly as well.

[1]: https://tracker.debian.org/pkg/routine-update

Regards,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature


Re: Please make a separate package for mistune 2.x

2022-02-05 Thread Nilesh Patra

On 2/6/22 12:20 AM, Julian Gilbey wrote:

On Fri, Feb 04, 2022 at 09:27:59PM +0530, Nilesh Patra wrote:

On 2/4/22 9:18 PM, Julian Gilbey wrote:

[...]
_mistune.py within the Debian package,
and have nbconvert do "import nbconvert.filters._mistune as mistune"
(see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
That seems like an eminently sensible solution to this problem.


But that'd lead to a number of mistune's embedded copies in a huge number of 
packages; since majority of
the rev-deps (when I last checked) haven't adapted to this new version. When 
they do,
and it becomes a overhead to fix each one later.
Even worse, if we discover a security problem sometime later, then all such 
packages would be
effected, and that honestly does not look like a good idea to me.


I have just had another idea, which might solve all of the problems:
create a new Debian package called mistune0 (or mistune1), which
contains the legacy version of mistune, but with the Python module
called "mistune0" instead of "mistune".  Then it will be
co-installable with mistune 2.x, and the packages which still depend
on mistune 0.8.4 could be patched to say "import mistune0 as mistune"
until they are updated upstream.  This will also avoid having multiple
copies of the legacy code in the archive, which addresses the security
issue, and allow those packages which have migrated to mistune 2.x to
still say "import mistune".


Ah, looks like we just had to think in the reverse direction from the initial 
proposal (mistune-{0,1} instead of mistune-{1,2}).
Indeed, that sounds like a much better plan.
I hope PEB agrees with this as well, would like to hear from them :)

Thanks for the discussion, Julian :)

Regards,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature


Re: Please make a separate package for mistune 2.x

2022-02-04 Thread Nilesh Patra

On 2/4/22 9:33 PM, Julian Gilbey wrote:

_mistune.py within the Debian package,
and have nbconvert do "import nbconvert.filters._mistune as mistune"
(see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
That seems like an eminently sensible solution to this problem.


But that'd lead to a number of mistune's embedded copies in a huge number of 
packages; since majority of
the rev-deps (when I last checked) haven't adapted to this new version. When 
they do,
and it becomes a overhead to fix each one later.
Even worse, if we discover a security problem sometime later, then all such 
packages would be
effected, and that honestly does not look like a good idea to me.


This is true, though there are only 7 reverse dependencies currently
in testing.


Yeah, in total the reverse-deps are 8 and there is one different 
reverse-build-dep (pasted at end of this mail)
But the problem is if these fall through the cracks, and close to the release 
we notice some
package is not looking nice.

Also, if you suppose that the upstreams are very slow, and we get to the new 
debian release with these things still
embedded, it'd be a real mess to upload fixes to stable, right...
 

I somehow do not understand the urgency of uploading this newer version, as the 
maintainer said:

| I intend to upload src:mistune 2.0.0 to unstable between March the
| 15th and April the 15th (depending on the progress of its
| reverse-dependencies).

We could simply wait a little more for the dust to settle, IMHO.


That would be a reasonable approach, but how long will it take for the
dust to settle?  With this major change, and no guidance from upstream
on how to migrate, and at least a number of upstream authors happy to
rely on setup.py having "mistune <1.0.0" in the install_requires
field, it might be several months or longer before things are fixed
upstream.

I think we could do this transition even a month or two before the soft freeze 
starts,
which is roughly an year from now (considering general trend timings of 
starting in feb in release year).
Situation might improve by then, I suppose.

If it does not, we could still go ahead with the older python3-mistune in the 
archive, I do not see
a huge problem there, except for maybe a few mistune uploads to stable if 
desired.


And what do we do when some packages have converted and
some haven't?


In such a case, we atleast will have a few examples to see how to go about 
doing the API changes the right way.
We could patch out at our end and send the changes upstream for review provided 
we are stuck in an unfortunate situation.

Let me know what you'd think about this?

Regards,
Nilesh


Reverse-Depends
* giara [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x]
* iredis
* lektor
* lookatme
* matrix-mirage [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x]
* python3-flasgger
* python3-m2r
* python3-schema-salad

Reverse-Testsuite-Triggers
* markdown-it-py

Reverse-Build-Depends
* lektor
* lookatme
* markdown-it-py
* python-flasgger
* python-m2r
* python-schema-salad






OpenPGP_signature
Description: OpenPGP digital signature


Re: Please make a separate package for mistune 2.x

2022-02-04 Thread Nilesh Patra

On 2/4/22 9:18 PM, Julian Gilbey wrote:

Basically, the mistune upstream author has completely messed up on
this by making what is essentially a completely different package with
superficially similar functionality but the same name.


True.
 

[...]
_mistune.py within the Debian package,
and have nbconvert do "import nbconvert.filters._mistune as mistune"
(see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
That seems like an eminently sensible solution to this problem.


But that'd lead to a number of mistune's embedded copies in a huge number of 
packages; since majority of
the rev-deps (when I last checked) haven't adapted to this new version. When 
they do,
and it becomes a overhead to fix each one later.
Even worse, if we discover a security problem sometime later, then all such 
packages would be
effected, and that honestly does not look like a good idea to me.

I somehow do not understand the urgency of uploading this newer version, as the 
maintainer said:

| I intend to upload src:mistune 2.0.0 to unstable between March the
| 15th and April the 15th (depending on the progress of its
| reverse-dependencies).

We could simply wait a little more for the dust to settle, IMHO.

Regards,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature


Re: Please enable me transfering python-bioblend to Debian Med team

2022-01-15 Thread Nilesh Patra

Hi Stefano/Ondřej,

On 1/11/22 8:03 PM, Andreas Tille wrote:

Hi,

I think we sorted out that the request to move python-bioblend to Debian
Med is valid.  I'm CCing Debian Python team maintainers to get this
finally done.

Could you process this transfer please? Moving python-bioblend from python->med 
team.
You have maintainer access in -med and owner in -python, hence please consider 
transferring this.

Regards,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature


Re: Transfering packages from Debian Med to DPT (Was: Please enable me transfering python-bioblend to Debian Med team)

2022-01-01 Thread Nilesh Patra

Before you/someone else makes a move, some of these packages are bioinformatics
and are better suited for med team:

* indexed-gzip - This one is mainly for NIFTI image files
* python-anndata - For gene annotation
* python-fitbit - For FITBIT API (more in med domain)
* python-cooler - For genomic interaction data

There are probably more, but please do not move these ^^

Nilesh



OpenPGP_signature
Description: OpenPGP digital signature


Re: Transfering packages from Debian Med to DPT (Was: Please enable me transfering python-bioblend to Debian Med team)

2021-12-23 Thread Nilesh Patra

On 12/23/21 1:54 PM, Andreas Tille wrote:

Hi again,

by chance I learned that I do not have permissions to create
repositories in salsa:python-team/packages thus moving packages would be
not as simple as transfering the projects.  Please grant me maintainer
permissions to enable moving packages smoothly.


AFAICS here[1] you do have maintainer permissions.

[1]: 
https://salsa.debian.org/groups/python-team/packages/-/group_members?search=tille

Regards,
Nilesh



Re: Please enable me transfering python-bioblend to Debian Med team

2021-12-22 Thread Nilesh Patra
Hi Pierre-Elliot,

On Wed, Dec 22, 2021 at 08:06:01PM +0100, Pierre-Elliott Bécue wrote:
> >> I'm sorry but pressuring to take over a package is not really fine. If
> >> you're not happy with the time it takes for an answer, you can try to
> >> fill an ITS and if the procedure goes to its end then you may take over.
> >
> > Please note:  The people involved are the same.  We are members of
> > both teams but consider the Debian Med team more appropriate.  We
> > are simply missing the permissions to do the move properly.
> 
> I am aware of that.
> 
> Yet, the fact that you are members of both teams doesn't entitle you to
> decide such a transfer, even if you had the technical rights to do so.

Hmm, I am not sure what the problem in such a case would be (permission in both 
teams)
Steffen is the maintainer (uploader if you might prefer it that way) and he has
agreed already[1] -- so what's the problem?

[1]: https://lists.debian.org/debian-med/2021/12/msg00119.html

> I therefore stand my point: the way Debian is made has not changed
> recently, and taking over still requires a formal approval from the
> maintainer, which you are not.
> 
> The only alternatives are either an ITS or MIA team orphaning their
> packages, but as the maintainer is an active team, the latter will not
> happen.

I do not think it is sensible to take consensus from an entire team to
move a single package.
Honestly speaking, we really do not need to make team transfer 
debian processes such a high friction ones -- it just stalls the work for no 
good reason.
The package has not seen uploads since more than two years, I really doubt 
anyone in the team feels strong
ly about not moving it.

If you are talking about Ondřej doing the uploads apart from the initial 
uploads,
then you probably are also aware that Ondřej does a number of team-maintained 
package
uploads to fix bugs, does updates and so on (a lot of us do so, for that matter 
albeit in other teams)
I really don't think that he has a personal interest in every single one of 
those packages (including this one)
but we should hear from him.

> >> and they could be willing to check that no one in the team objects.

Sure but how are you making a "check" here? I do have admin access in a few 
teams, and speaking for
myself: I  would send out
an email to the list, wait for a time frame (maximum 1 week) and check if 
someone has any comments
If not, I would make a move.
So we already have a mail in the debian-python mailing list, and no objections 
so far, so 

I would have probably done more to ask for consensus better (asking on IRC 
channels etc) but admittedly, we only
have 24 hours in the day, and several dozens of packages to do.

> I think you missed the second part of my sentence you're quoting.

I recetified this above.

> >> Steffen only did the first upload. I'd suggest to contact Ondrej (Cc-ed).
> >> 
> >> In the meantime, Nilesh is member of the Python team and therefore can
> >> do an update of the package (but not change the maintainer).
> >
> > I'm a member myself - but the upload should happen in the Debian
> > Med team.  This is the point of my mail.
> 
> I disagree.
> 
> Either the python team accepts the package to be transferred and it
> indeed should happen there. 

Please don't repeat your points. You wrote the same stuff above (wrt MIA, ITS 
etc)

> This probably means we should have a stanza in the DPT policy about
> transfer of maintainership.

This would be definitely helpful.

PS: I do not mean to be disrespectful, please do not interpret my reply that 
way, I am
only trying to reason it out.

Regards,
Nilesh


signature.asc
Description: PGP signature


Re: [RFH] Bug#1000812: pyrle: import fails on Python 3.10

2021-12-04 Thread Nilesh Patra

Hi Stefano,

On 12/4/21 9:00 PM, Stefano Rivera wrote:

Hi Nilesh (2021.12.04_15:15:05_+)

Would you have any hint on this?
Is it a bug with the python3 package itself?


You're waiting for python3-tabulate to be patched for Python 3.10
support.


Indeed. I was just being silly as it seems. I patched tabulate to work
with python3.10 (smoke tests go well, and I did a few manual tests) and 
uploaded.
Thanks a lot for your time.

Regards,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature


[RFH] Bug#1000812: pyrle: import fails on Python 3.10

2021-12-04 Thread Nilesh Patra
Dear Python team,

Would you have any hint on this?
Is it a bug with the python3 package itself?

Let me know.

Regards,
Nilesh

On Thu, 2 Dec 2021 12:02:59 +0530 Nilesh Patra  wrote:
> On Mon, 29 Nov 2021 20:35:40 +0100 Andreas Tille  wrote:
> > Am Mon, Nov 29, 2021 at 11:36:33PM +0530 schrieb Nilesh Patra:
> > > I rebuilt with python3.10, and now error is this.
> > > Something wrong with pandas?
> > 
> > As far as I understood we need to wait for pandas 1.3 to work
> > with Python3.10.
> 
> I retried autopkgtest now, and it still seems a non-bug with pyrle.
> @Rebecca, please re-assign this bug to relevant package.
> 
> autopkgtest [11:57:49]: test autodep8-python3: [---
> Testing with python3.10:
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/pyrle/__init__.py", line 1, in 
> from pyrle.rle import Rle
>   File "/usr/lib/python3/dist-packages/pyrle/rle.py", line 13, in 
> from tabulate import tabulate
>   File "/usr/lib/python3/dist-packages/tabulate.py", line 16, in 
> from collections import Iterable
> ImportError: cannot import name 'Iterable' from 'collections' 
> (/usr/lib/python3.10/collections/__init__.py)
> 
> """
> Minimal example to reproduce:
> 
> $ python3.10  
> Python 3.10.0+ (default, Nov 17 2021, 06:49:13) [GCC 11.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from tabulate import tabulate
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/tabulate.py", line 16, in 
> from collections import Iterable
> ImportError: cannot import name 'Iterable' from 'collections' 
> (/usr/lib/python3.10/collections/__init__.py)
> """
> 
> $ apt policy python3.10
> python3.10:
>   Installed: 3.10.0-5
>   Candidate: 3.10.0-5
>   Version table:
>  *** 3.10.0-5 500
> 500 http://deb.debian.org/debian sid/main amd64 Packages
> 100 /var/lib/dpkg/status


signature.asc
Description: PGP signature


Re: xcffib update for qtile packaging

2021-11-27 Thread Nilesh Patra

Hi Jérôme,

On 11/27/21 3:44 PM, Jérôme wrote:

Hello,

In the absence of a reply, I have worked on xcffib package to update it to the 
last upstream release as well as Debian standards. I intend to adopt it[1] but 
I am looking for a sponsor - or moving this package to DPT? - in order to 
upload it. Does anybody here have time for that please? And any review is 
welcome, here is the current repository:

 https://salsa.debian.org/jlebleu/xcffib


Moved to DPT and uploaded as well. I pushed some changes though, do consider 
taking a look at them.
Thank you very much for working on it and adopting the same. :-)

Regards,
Nilesh




OpenPGP_signature
Description: OpenPGP digital signature


Re: Bug#997772: python-cogent: FTBFS: You must configure the bibtex_bibfiles setting

2021-11-03 Thread Nilesh Patra

On 11/3/21 1:30 PM, Andreas Tille wrote:

Control: tags -1 pending

Hi Stuart,

Am Wed, Nov 03, 2021 at 09:43:40AM +1100 schrieb Stuart Prescott:

Extension error:
You must configure the bibtex_bibfiles setting
make[2]: *** [Makefile:40: html] Error 2


this is sphinxcontrib-bibtex saying that you need to add the following to
doc/conf.py:

bibtex_bibfiles = "path/to/references.bib"

However I can't see a .bib file anywhere in the source. I also can't see any
code in the rst files or the docstrings that would actually use sphinxcontrib-
bibtex so I'm not sure how this extension is actually used in these documents.
Perhaps it isn't actually needed at all.


Thanks for the good hint which helped me over this issue[1].  Unfortunately
now dh_auto_install has an issue that did not occured before:
[...]


Pushed to salsa, and now it works as it should.
I leave the onus of checking and uploading onto you.

Regards,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature


Re: platform.machine() on salsa i386 build?

2021-10-30 Thread Nilesh Patra

Hi Ole,

On 10/30/21 5:50 PM, Ole Streicher wrote:

Hi,
https://salsa.debian.org/debian-astro-team/pyraf/-/jobs/2130878#L2062

How can one find out the correct machine here?


I just committed something to salsa -- sort of a hack, but it works (i386 
pipeline passes). I do this
for one of my other package as well. Please consider taking a look.

Nilesh






OpenPGP_signature
Description: OpenPGP digital signature


Re: Bug#997758: nose: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 220)

2021-10-24 Thread Nilesh Patra
 (U)

Martin A. Brown 
   tldp

Martin Pitt 
   cssutils (U)

Martin Wimpress 
   python-rx (U)

Martin Zobel-Helas 
   python-caldav

Mathias Behrle 
   relatorio (U)

Mathieu Trudel-Lapierre 
   netplan.io (U)

Matthias Geerdsen 
   kopanocore (U)

Matthias Klose 
   i8c
   libi8x

Mattia Rizzolo 
   ubuntu-dev-tools (U)

Maximiliano Curia 
   python-intbitset

Mehdi Abaakouk 
   python-lzo (U)

Michael Fladischer 
   celery (U)
   django-assets (U)
   django-downloadview (U)
   django-nose (U)
   drf-extensions (U)
   pilkit (U)
   python-cement (U)
   python-elasticsearch (U)
   python-measurement (U)
   python-pamqp (U)
   python-sievelib (U)

Michael Fladischer 
   python-anyjson (U)

Michael Hanke 
   brian (U)
   mpi4py (U)
   nibabel (U)
   nipy (U)
   python-mne (U)
   pyxnat (U)
   scikit-learn (U)
   seaborn (U)
   statsmodels (U)

Michael Hanke 
   annexremote (U)
   datalad (U)
   dcmstack (U)
   dipy (U)
   lazyarray (U)
   neo (U)
   nitime (U)
   pynn (U)

Michael R. Crusoe 
   python-bx (U)
   python-pomegranate (U)
   python-pybedtools (U)
   python-screed (U)

Michael R. Crusoe 
   python-gffutils (U)
   python-rdflib-jsonld (U)

Michael Vogt 
   gdebi (U)
   python-defer (U)

Michal Arbet 
   designate-dashboard (U)
   kazoo (U)
   lz4tools (U)
   manila-ui (U)
   mistral (U)
   mistral-dashboard (U)
   murano (U)
   openstack-trove (U)
   pykafka (U)
   python-fluent-logger (U)
   python-jsonschema (U)
   python-kafka (U)
   python-tooz (U)
   swift (U)

Mihai Moldovan 
   dnf
   libdnf
   librepo
   x2gobroker (U)

Mikael Djurfeldt 
   python-csa

Mike Gabriel 
   lomiri-url-dispatcher (U)
   python-rx (U)
   x2gobroker (U)

Miriam Ruiz 
   deap

Mo Zhou 
   caffe (U)

Muammar El Khatib 
   amp (U)

Neil Muller 
   python-formencode (U)

Neil Williams 
   kazoo (U)

NeuroDebian Team 
   datalad

NeuroDebian Team 
   dcmstack
   imbalanced-learn

Nicholas D Steeves 
   elpy (U)

Nick Morrott 
   python-project-generator (U)
   valinor (U)
   yotta (U)

Nicolas CANIART 
   tap.py (U)

Nicolas Dandrimont 
   flask-limiter (U)
   moksha.common (U)
   piuparts (U)
   python-fedora (U)
   python-limits (U)
   python-pyramid-chameleon (U)

Nilesh Patra 
   cyvcf2 (U)
   h5sparse (U)
   nitime (U)
   python-xopen (U)
   seaborn (U)

Nilesh Patra 
   python-spectra (U)
   umap-learn (U)

Noah Meyerhans 
   python-boto (U)

Nobuhiro Iwamatsu 
   python-nubia (U)
   python-spinners

Ole Streicher 
   skimage (U)
   stsci.tools (U)
   yt (U)

Olivier Sallou 
   biomaj3 (U)
   biomaj3-cli (U)
   biomaj3-core (U)
   biomaj3-daemon (U)
   biomaj3-download (U)
   biomaj3-process (U)
   biomaj3-user (U)
   python-easydev (U)

Olof Johansson 
   svtplay-dl

Ondřej Kobližek 
   backblaze-b2 (U)
   python-logfury (U)
   python-tempita (U)

Ondřej Nový 
   backblaze-b2 (U)
   pytest (U)
   python-eventlet (U)
   python-flake8 (U)
   python-logfury (U)
   python-maxminddb (U)
   python-pyeclib (U)
   python-werkzeug (U)
   swift (U)
   swift-bench (U)

Ondřej Surý 
   blinker (U)

Otto Kekäläinen 
   py-stringmatching (U)

Oxan van Leeuwen 
   guessit (U)

Paul Belanger 
   python-statsd (U)
   voluptuous (U)

Paul Tagliamonte 
   dput-ng (U)

Paulo Roberto Alves de Oliveira (aka kretcheu) 
   rows

Peter Pentchev 
   createrepo-c

Philipp Huebner 
   yamllint (U)

Picca Frédéric-Emmanuel 
   vitables (U)

Pino Toscano 
   osinfo-db (U)

Piotr Ożarowski 
   aiohttp-mako
   beaker (U)
   dh-python
   pygments
   python-formencode (U)
   routes

piuparts developers team 
   piuparts

Python Applications Packaging Team 
   dodgy
   muttdown
   prospector
   voltron

Rebecca N. Palmer 
   libgpuarray (U)
   statsmodels (U)
   theano (U)

Robbie Harwood (frozencemetery) 
   python-gssapi

Robert S. Edmonds 
   voluptuous (U)

Ross Gammon 
   gramps

Ruben Undheim 
   python-zeroconf (U)

Ryan Pavlik 
   click-man

Samuel Thibault 
   dogtail

Sandro Tosi 
   guessit (U)
   matplotlib
   python-cycler

Sao I Kuan 
   cwlformat (U)
   insilicoseq (U)
   recan (U)

Sascha Steinbiss 
   ariba (U)
   fastaq (U)
   gfapy (U)
   gnome-keysign
   iva (U)

Sebastian Heinlein (devel) 
   python-defer

Sebastien Badia 
   python-ncclient
   python-xmltodict

Sebastien Delafond 
   hyperspy (U)
   python-param (U)
   python-twilio (U)

Sergio Durigan Junior 
   check-manifest (U)
   kitchen (U)
   pagure
   python-fedora (U)
   python-maxminddb (U)

Simon Eisenmann 
   kopanocore (U)

Simon McVittie 
   tap.py (U)

Sophie Brun 
   python-rx (U)
   python-twilio (U)

Stefano Karapetsas 
   trash-cli

Stefano Rivera 
   beautifulsoup4 (U)
   dh-python (U)
   python-confuse (U)
   python-flexmock (U)
   python-launchpadlib
   python-webencodings (U)
   ubuntu-dev-tools (U)

Steffen Moeller 
   bcbio (U)
   cyvcf2 (U)
   mirtop (U)
   nanosv (U)
   python-bx (U)
   python-datacache (U)
   python-deeptools (U)
   python-geneimpacts (U)
   python-gffutils (U)
   python-gtfparse (U)
   python-louvain
   python-pomegranate

Re: Why is isal limited to just three archs?

2021-10-17 Thread Nilesh Patra

Hi Thomas,

On 10/16/21 4:07 PM, Graham Inggs wrote:

Hi,

Did you look into the source package? isal is written in assembly
language...

I see at least an erasure_code/ppc64le directory.

I did a quick test build in Ubuntu and the package built and passed
its tests on armhf, ppc64el and riscv64, failing only because of
missing symbols.  Perhaps the reduced libisal2.symbols.arm64 can be
used for other architectures as well?


After Graham's tests, would it be possible to extend the arch list?
I could help test it across more archs if you would like -- porter boxes to 
rescue :)

Nilesh




OpenPGP_signature
Description: OpenPGP digital signature


Why is isal limited to just three archs?

2021-10-16 Thread Nilesh Patra

Hi Ondřej,

I see that isal package is limited to amd64, arm64 and kfreebsd-amd64.
Is there a particular reason for this? -- Is it possible to extend support to 
other archs?

Actually, a -med team package fastp has started to depend on libisal-dev, and 
this
now is limited to the few archs isal supports. So it would be really nice if 
isal
can build on more archs.

Please do let me know.

Nilesh




OpenPGP_signature
Description: OpenPGP digital signature


Re: request to join python-team/packages group on salsa

2021-10-10 Thread Nilesh Patra



On 11 October 2021 4:17:48 am IST, Emmanuel Arias  
wrote:
>El dom, 10 de oct. de 2021 a la(s) 17:36, Afif Elghraoui (a...@debian.org)
>escribió:
>Hi,
>
>You need to be patient.
>that a good exercise to understand the "upload process", also some DD
>prefer
>use mentors.

Hi, Afif is already a DD since some years.

@Afif, you might want to ping once on #debian-python IRC. Maybe someone could 
do it quickly that way.


Nilesh

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: RFS: python-mockito/1.2.2-2 -- Spying framework for Python - documentation

2021-09-19 Thread Nilesh Patra


On 9/19/21 2:29 PM, Fabrice Bauzac-Stehly wrote:
>  python-mockito (1.2.2-2) unstable; urgency=medium
>  .
>* Source-only upload.

Hi, I do not see these changes in salsa. Still the old changelog.
can you push? I'll happily sponsor

Cheers,

-- 
Nilesh Patra

Debian Developer, Uploading
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  
  ⢿⡄⠘⠷⠚⠋   nil...@debian.org / nileshpatra.info / tchncs.de
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature


Re: Python style guide checker (formerly called pep8)

2021-09-12 Thread Nilesh Patra



Hi Geert,

On 12 September 2021 1:53:25 pm IST, Geert Stappers  
wrote:
>Hello Debian-Python,
>
>In which package is a pep8 code style checker?

Is this what you seek? 

https://tracker.debian.org/pkg/autopep8

Corresponding binary package is python3-autopep8


Nilesh

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: RFS: python-click-log/0.3.2-1 -- Logging integration for Click - Python 3.x

2021-06-05 Thread Nilesh Patra


On 6/5/21 8:04 PM, Emmanuel Arias wrote:
> Hi,
> 
> I'm not DD, but I send you some review, to gain time:
> 
> * d/changelog says: `Bump debhelper from old 10 to 12.` but actuall> 
> debhelper-compat version is 13.
> * Please use UNRELEASED instead of unstable, that can be confused.

Fixed

> * What about enable salsa-ci?

Enabled

> * What about adding an autopkgtest?

The test is running during build time.[1] I don't think running the same thing 
as autopkgtest does a very significant improvement.

@Fabrice, more review:

* The pristine tar contained .tar.gz.*, it should instead contain 
.orig.tar.gz for origtargz
both for the sake of consistency and for origtargz to run fine
* We are in freeze time, and a new version upload unless absolutely necessary 
isn't appropriate[2]. This package does not seem
to have any (RC) bug or affecting any package that a version bump would be 
desired.

Hence, this should be uploaded after bullseye release. Feel free to ping me 
then, and I'll happily sponsor. Also, please take a look at my commits in salsa.

Thanks a lot for your work!

[1]: 
https://salsa.debian.org/python-team/packages/python-click-log/-/blob/master/debian/rules#L13
[2]: https://release.debian.org/testing/freeze_policy.html

Nilesh



signature.asc
Description: OpenPGP digital signature


Re: Bug#985102: RFS: jupyter-packaging/0.7.12-1 [ITP] -- tools to help build and install Jupyter Python packages

2021-03-12 Thread Nilesh Patra
Hi,

I uploaded the one on salsa. It looked nice to me.
I am closing the RFS bug, then.
Thanks a lot for your work on this!

PS: Next time, please consider to first import, and then commit all your
changes systematically - for example, adding autopkgtests, modifying
copyright et. al. rather than a huge bulk of changes in "initial
commit"

Nilesh



Should Binaries provided by python-babel have a "python3-" prefix?

2020-11-26 Thread Nilesh Patra
Hi,

Currently src:python-babel provides 3 binaries:

* python3-babel
* python-babel-doc
* python-babel-localedata

of which python3-babel is the main binary, -babel-doc is for the
documentation and -babel-localedata is for storing locale data files used
by python3-babel.

Should this be renamed to a "python3-" prefix for both binaries? They do
not contain any actual code though

BTW this also has a RC bug, and I pushed the fix to salsa. If it needs a
renaming, it'd be great if someone could upload it to NEW.

If not, I'll do a source-only-upload.
Please let me know what you think of this.

Kind regards
Nilesh


Re: Issues when reading mailboxes from alioth-lists.debian.net

2020-08-19 Thread Nilesh Patra
Hi,

> Traceback (most recent call last):
>  File "./test_mbox.py", line 6, in 
>if mbox_file.items() != []:
>  File "/usr/lib/python3.8/mailbox.py", line 132, in items
>return list(self.iteritems())
>  File "/usr/lib/python3.8/mailbox.py", line 125, in iteritems
>value = self[key]
>  File "/usr/lib/python3.8/mailbox.py", line 73, in __getitem__
>return self.get_message(key)
>  File "/usr/lib/python3.8/mailbox.py", line 781, in get_message
>msg.set_from(from_line[5:].decode('ascii'))
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 37: 
> ordinal not in range(128)
> Exit code:   1 

For me the error goes way for me when I change line 781 in 
/usr/lib/python3.8/mailbox.py
 to:

msg.set_from(from_line[5:].decode('utf-8'))

May be this is a minor feature enhancement since at the moment messages with 
unicodes don't seem to be decoded.
Or there's an API change which I'm not aware of.

Either way this should act like a temorary fix for now. Let me know if this 
doesn't seem right.

Kinds Regards,
Nilesh



[RFS] djangorestframework-gis

2020-06-13 Thread Nilesh Patra
Hi,
djangorestframework-gis reports failing tests and has RC bug: #961901 filed
against it.
I've fixed this, and this builds in a clean chroot with passing tests.
My changes have been pushed to the team repo here[1].
(Many thanks to Utkarsh for granting access to this repo \o/)

This Needs review and sponsorship.

[1]: https://salsa.debian.org/python-team/modules/djangorestframework-gis

Regards,
Nilesh


Re: Request for joining DPMT

2020-06-13 Thread Nilesh Patra
Pardon me, I've read and accept the policy:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#maintainership

On Sat, 13 Jun 2020 at 15:32, Nilesh Patra  wrote:

>
>
> On Sat, 13 Jun 2020 at 15:31, Nilesh Patra  wrote:
>
>> Hi,
>> I'm interested in joining DPMT - I fix bugs for debian-python team and
>> also help package a few modules.
>> I've fixed RC bugs for DPMT packages before: #950050 and #952172 being
>> recent ones.
>> I also maintain several python packages under the debian med team
>>
>> I've a couple of more RC bug fixes for DPMT packages ready, and I wish to
>> push it directly to the team now.
>> Hence, I will be grateful if I'm granted access.
>>
>
> I forgot to mention this: my salsa username is: gi-boi-guest
>
> Regards
>


Re: Request for joining DPMT

2020-06-13 Thread Nilesh Patra
On Sat, 13 Jun 2020 at 15:31, Nilesh Patra  wrote:

> Hi,
> I'm interested in joining DPMT - I fix bugs for debian-python team and
> also help package a few modules.
> I've fixed RC bugs for DPMT packages before: #950050 and #952172 being
> recent ones.
> I also maintain several python packages under the debian med team
>
> I've a couple of more RC bug fixes for DPMT packages ready, and I wish to
> push it directly to the team now.
> Hence, I will be grateful if I'm granted access.
>

I forgot to mention this: my salsa username is: gi-boi-guest

Regards


Request for joining DPMT

2020-06-13 Thread Nilesh Patra
Hi,
I'm interested in joining DPMT - I fix bugs for debian-python team and also
help package a few modules.
I've fixed RC bugs for DPMT packages before: #950050 and #952172 being
recent ones.
I also maintain several python packages under the debian med team

I've a couple of more RC bug fixes for DPMT packages ready, and I wish to
push it directly to the team now.
Hence, I will be grateful if I'm granted access.

Kind regards
Nilesh


Re: [RFC] python-cobra, python3-sbml5

2020-04-05 Thread Nilesh Patra
On Sun, 5 Apr 2020, 15:50 Andreas Tille,  wrote:

> On Sun, Apr 05, 2020 at 03:40:56PM +0530, Nilesh Patra wrote:
> > > > '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a
> > > > provide) package. When I dug into looking at libsbml, I noticed that
> the
> > > > relevant file (libsbml.py) which throws error
> > > > is generated with swig-3.0 by the upstream [3]
> > >
> > > I admit I'm absolutely naive about swig - but if libsbml.py is really
> > > autogenerated what about re-generating it with swig-4?
> >
> > I think there's a miscommunication here. The file in the archive(on doing
> > $apt source python3-sbml5) is generated with swig-4 already, while it's
> > generated with swig-3 upstream.
> > Hence the issue.
>
> Ahhh, so it is regenerated in the Debian package build process but it
> conflicts with other parts of the upstream code?  Did I now understood
> correctly?
>

Yep.
That's my _suspicion_ though, that the rest of the upstream code isn't
compatible with the new version, and there are API changes needed.
Hence I sent the mail to confirm if I'm thinking in the right direction.


> I wonder if we should exclude this kind of autogenerated code inside
> the source tarball since we are repackaging the source anyway to exclude
> some files for policy reasons.  I'm doing so in other source tarballs
> for instance with cython files to be absolutely sure that this code
> is regenerated.  This would probably not solve the build issue but might
> be a good idea in general.  What do you think?
>

It seems like libsbml.py would be needed by the rest of the code. So we can
maybe keep the upstream's generated code and not generate it on our own -
this however does not seem DFSG compliant.
Not really sure what to do here.


> Kind regards
>
>   Andreas.
>
> > > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656
> > > >
> > > > [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10
> > > >
> > > > [3]:
> https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true=simple
>
> --
> http://fam-tille.de
>


Re: [RFC] python-cobra, python3-sbml5

2020-04-05 Thread Nilesh Patra
Hi

On Sun, 5 Apr 2020, 11:43 Andreas Tille,  wrote:

> Hi Nilesh,
>
> On Sat, Apr 04, 2020 at 06:53:55PM +0530, Nilesh Patra wrote:
> >
> > >From the logs, in the last message[2] it looks like an import-error for
> > '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a
> > provide) package. When I dug into looking at libsbml, I noticed that the
> > relevant file (libsbml.py) which throws error
> > is generated with swig-3.0 by the upstream [3]
>
> I admit I'm absolutely naive about swig - but if libsbml.py is really
> autogenerated what about re-generating it with swig-4?
>

I think there's a miscommunication here. The file in the archive(on doing
$apt source python3-sbml5) is generated with swig-4 already, while it's
generated with swig-3 upstream.
Hence the issue.


>
> > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656
> >
> > [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10
> >
> > [3]:
> >
> https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true=simple
> >
> > Thanks and regards
> > Nilesh
>
> --
> http://fam-tille.de
>


[RFC] python-cobra, python3-sbml5

2020-04-04 Thread Nilesh Patra
Hi,
Currently python-cobra FTBFS reported here [1].

>From the logs, in the last message[2] it looks like an import-error for
'_libsbml' file which corresponds to libsbml (with python3-sbml5 as a
provide) package. When I dug into looking at libsbml, I noticed that the
relevant file (libsbml.py) which throws error
is generated with swig-3.0 by the upstream [3]

While the same file in the apt archive (observed after $apt source
python3-sbml5) seems to be generated with swig-4.0, and that's the current
swig version in Debian now.

When I compared, the one generated with swig 4.0 looks pretty different
from the one generated by swig 3.0.
I "suspect" that the error is due to the swig version change to 4.0, and
corresponding API changes.

I would really appreciate if I could have more folks "confirm" that this is
the case, and I'm not missing out on anything else.
I'll then file a report upstream then, asking for corresponding code
changes needed for swig 4.0.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656

[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10

[3]:
https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true=simple

Thanks and regards
Nilesh


Re: [RFS] django-oauth-toolkit

2020-03-15 Thread Nilesh Patra
> Are you sure that debian/tests/pkg-python/import-name has the correct
value?
I guess yes.

> What does `cat debian/tests/pkg-python/import-name` show?
[debian/master][~/packages/oauth-toolkit/django-oauth-toolkit]$ cat
debian/tests/pkg-python/import-name
oauth2_provider

Seems correct. I'm not really sure what is causing this.

> Anyways, thanks for your help, I made some minor tweaks and uploaded
it a few hours ago.
Thanks a lot for sponsoring the upload, :)
Could you as well review my changes for pytds[1] that are done here[2]?
That would be great.
I'm  planning to fix more packages in coming days, :)

[1]: https://lists.debian.org/debian-python/2020/03/msg00023.html
[2]: https://salsa.debian.org/gi-boi-guest/pytds

Thanks and regards,
Nilesh




Re: Re: [RFS] django-oauth-toolkit

2020-03-15 Thread Nilesh Patra
> just a quick glance at the commits: you do not need to replace
autopkgtest-pkg-python with home-grown code, just tell it what to import:

> echo oauth2_provider > debian/tests/pkg-python/import-name

Thanks, I didn't know about that. However, when I added that in, autopkgtest 
seems to fail with:

Removing autopkgtest-satdep (0) ...
autopkgtest [15:10:19]: test autodep8-python3: set -e ; for py in $(py3versions 
-r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c 
"import django_oauth_toolkit; print(django_oauth_toolkit)" ; done
autopkgtest [15:10:19]: test autodep8-python3: [---
Testing with python3.7:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'django_oauth_toolkit'
autopkgtest [15:10:19]: test autodep8-python3: ---]
autopkgtest [15:10:20]: test autodep8-python3:  - - - - - - - - - - results - - 
- - - - - - - -
autodep8-python3 FAIL non-zero exit status 1
autopkgtest [15:10:20]:  summary
autodep8-python3 FAIL non-zero exit status 1

The command I used: sudo autopkgtest -B ../*.deb -- schroot 
unstable-amd64-sbuild
Am I missing something here? Need your guidance here.

Thanks and regards,
Nilesh



[RFS] django-oauth-toolkit

2020-03-15 Thread Nilesh Patra
Hi,
Currently django-oauth-toolkit FTBFS with python3.8. I have fixed it, and
build + autopkgtest pass.
My changes have been pushed here [1].
Needs review and sponsorship.

[1]: https://salsa.debian.org/gi-boi-guest/django-oauth-toolkit

Thanks and regards
Nilesh


[RFS] pytds

2020-03-14 Thread Nilesh Patra
Hi,
Currently pytds FTBFS with python3.8. I have fixed it, and build +
autopkgtests pass.
It is also lintian-clean.
There are however, a few build warnings which I am not sure how to fix:
I see a lot of:

Setting up python3-roman (2.0.0-3) ...
/usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering
(buffering=1) isn't supported in binary mode, the default buffer size will
be used
  self.stdin = io.open(p2cwrite, 'wb', bufsize)

similar warnings; I didn't find buffer=1 in any of the subprocess/file
descriptor based functions, not really sure what is causing this.

I also see dh_python related warnings as:
W: dh_python3 fs:112: Paths differ:
debian/python3-tds/usr/lib/python3.8/dist-packages/.test-cache/rootcert.pem
and
debian/python3-tds/usr/lib/python3/dist-packages/.test-cache/rootcert.pem
...
similar warnings; not sure what is wrong here either.

I have fixed rest of the warnings, that pytest reported. My changes have
been pushed here[1].
Needs review and sponsorship.

[1]: https://salsa.debian.org/gi-boi-guest/pytds

Thanks and regards,
Nilesh


Re: Help for issues with lazyarray needed

2020-03-05 Thread Nilesh Patra
On Thu, 5 Mar 2020, 14:16 Andreas Tille,  wrote:

> Control: tags -1 pending
>
> Hi,
>
> I have updated lazyarray in Git[1] (by moving it to Debian Science
> team).  The old package was lagging way behind upstream and a Python3
> port is available by upstream so I just create the python3-lazyarray
> package fixing the open bugs.
>
> Unfortunately there is an open issue[2].  Since the latest upstream
> commit has only one failure (in contrast to the latest tagges upstream
> version which is according to commit logs not really the latest) I
> based the source tarball on the latest commit.  Unfortunately there
> is one remaining issue for Python3.7 and two for Python3.8
>
>
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:217: cd
> /build/lazyarray-2.10.0+hg20170630.23ccca1/.pybuild/cpython3_3.7_lazyarray/build;
> python3.7 -m nose -v test
> test.test_lazyarray.test_create_with_int ... ok
> ...
> ==
> FAIL: test.test_lazyarray.test__issue4
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
>   File
> "/build/lazyarray-2.10.0+hg20170630.23ccca1/.pybuild/cpython3_3.7_lazyarray/build/test/test_lazyarray.py",
> line 701, in test__issue4
> assert_equal(b[mask1].shape, partial_shape(mask1, b.shape),
> a[mask1].shape)
> AssertionError: Tuples differ: (4, 1, 3) != (4,)
>




> First tuple contains 2 additional elements.
> First extra element 1:
> 1
>
> - (4, 1, 3)
> + (4,) : (4, 1, 3)
>
> --
> Ran 87 tests in 0.027s
>
> FAILED (failures=1)
>

I had tried this,
I think Passing [:-1] in the mask2 initialisation would fix this. We also
need to cast this into a numpy array.


>
>
> I continued manually in the pbuilder chroot to get Python3.8 issues:
>
> pbuilder-chroot# cd
> /build/lazyarray-2.10.0+hg20170630.23ccca1/.pybuild/cpython3_3.8_lazyarray/build;
> python3.8 -m nose -v test
> ...
> ==
> ERROR: test.support.testresult.get_test_runner_class
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> TypeError: get_test_runner_class() missing 1 required positional argument:
> 'verbosity'
>
> ==
> ERROR: test.support.testresult.get_test_runner
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> TypeError: get_test_runner() missing 2 required positional arguments:
> 'stream' and 'verbosity'
>
> --
> Ran 45 tests in 7.327s
>
> FAILED (SKIP=1, errors=2)
>

I'll try this by midnight today. If I can, I'll try a fix for this, and
make a MR, or a patch.
Would that work?


> I somehow suspect that the latter issue is not really hard and I wonder
> whether I can get some help from DPMT?
>
> My current plan is to ignore the test suite errors for the moment,
> upload a Python3 enabled package to new queue.  Once it has passed new I
> will see whether we found some solution for the said issues.  If not
> I'll file a new RC bug to prevent testing migration.  I'd like to do
> that means to get the latest version of pynn built to keep on with the
> Python3 migration for this package.
>
> Any help for the remaining issues is welcome.
>
> Kind regards
>
>   Andreas.
>
> [1] https://salsa.debian.org/science-team/lazyarray
> [2] https://bitbucket.org/apdavison/lazyarray/issues/6/test-failure
>
> --
> http://fam-tille.de
>
>