Re: Making py2dsp/pypi2deb the default tool to create Python-based packages in Debian

[Andreas Tille]

Am Mon, Jul 25, 2022 at 10:09:05AM +0200 schrieb Andreas Tille:
> I was able to run
> 
>   py2dsp pystow
> 
> with a sufficient result for my purposes...

While I've read here the suggestion to fetch the Tarball rather vom Github than
from pypi (and I agree with this) I would suggest to implement this suggestion
in what is planed to become a default tool.  With the command above the watch
file points to pypi and thus I tried:

$ py2dsp --github pystow
/usr/bin/py2dsp:163: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
E: py2dsp py2dsp:167: 404 {"message": "Not Found", "documentation_url": 
"https://docs.github.com/rest"}


Since the original thread started with opinions to make the tool the default
tool I'd suggest waiting a bit until it

   a) does not throw DeprecationWarnings
   b) works out of the box for simple usage

IMHO the suggestions where it should be advertised are perfectly fine
but its a bit bad timing when people stumble over it and run into
trouble at first usage.

Thanks for working on such a promising tools anyway

  Andreas.

-- 
http://fam-tille.de

Re: Making py2dsp/pypi2deb the default tool to create Python-based packages in Debian

[Andreas Tille]

Hi Sandro,

I was able to run

  py2dsp pystow

with a sufficient result for my purposes with the following patch:

diff --git a/pypi2deb/pypi.py b/pypi2deb/pypi.py
index 3e342c0..0639de3 100644
--- a/pypi2deb/pypi.py
+++ b/pypi2deb/pypi.py
@@ -38,8 +38,8 @@ log = logging.getLogger('pypi2deb')
 @asyncio.coroutine
 def get_pypi_info(name, version=None):
 url = PYPI_JSON_URL + '/' + name
-if version:
-url += '/' + version
+#   if version:
+#   url += '/' + version
 url += '/json'
 session = None
 try:

Since I do not really understand pypi2deb and what role version might have I do
not step further (MR or so) from this point but leave it to you to decide 
whether
this is useful or not.

Kind regards

Andreas.

-- 
http://fam-tille.de

Re: Making py2dsp/pypi2deb the default tool to create Python-based packages in Debian

[Andreas Tille]

Hi,

Am Sat, Jul 23, 2022 at 10:21:40AM -0400 schrieb Sandro Tosi:
> > I wonder whether you are able to reproduce the issue at your side since
> > in one of your last mails you asked whether the new version might have
> > fixed the issue.  This might implicitly mean it works for you since I
> > assume you fired up the command line at your side as well.
> 
> it never worked.

So is there anything I could do right now to automatically create pystow
packaging or should I do it manually for the moment.  Since you
advertised this tool here I wonder whether I did something wrong when
testing it.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Making py2dsp/pypi2deb the default tool to create Python-based packages in Debian

[Andreas Tille]

Hi Sandro,

Am Fri, Jul 22, 2022 at 11:39:50PM -0400 schrieb Sandro Tosi:
> 
> this seems to be related to
> https://discuss.python.org/t/backwards-incompatible-change-to-pypi-json-api/17154
> , although they say /pypi//json (what py2dsp uses to gather
> the latest released verison) still contains the releases key, what i
> noticed is that endpoint now returns 2 concatenated jsons, and aiohttp
> json() (quite understandably) returns the latest one, which does not
> contain releases.
> 
> appreciate if you can log a bug via reportbug

Done (#1015888).

I wonder whether you are able to reproduce the issue at your side since
in one of your last mails you asked whether the new version might have
fixed the issue.  This might implicitly mean it works for you since I
assume you fired up the command line at your side as well.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Making py2dsp/pypi2deb the default tool to create Python-based packages in Debian

[Andreas Tille]

Am Thu, Jul 21, 2022 at 05:50:05PM -0400 schrieb Sandro Tosi:
> > Are you sure thet the package version 3.20220721 contains the correct
> > executables?
> 
> yes, i simply forgot to bump the internal version; what really matters
> is: does the last release fix the problem you were having?

No, the problem persists:

$ py2dsp -v pystow
D: py2dsp py2dsp:156: version: 3.20220707
D: py2dsp py2dsp:157: ['/usr/bin/py2dsp', '-v', 'pystow']
/usr/bin/py2dsp:163: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
D: py2dsp py2dsp:44: args: Namespace(verbose=True, quiet=False, 
root='/tmp/result', clean=False, build=False, application=False, profile=None, 
github=None, distribution='UNRELEASED', revision='0~py2deb', 
message='converte0~py2deb', name='pystow')
E: py2dsp py2dsp:167: 'releases'
Traceback (most recent call last):
  File "/usr/bin/py2dsp", line 165, in 
loop.run_until_complete(main(args))
  File "/usr/lib/python3.10/asyncio/base_events.py", line 646, in 
run_until_complete
return future.result()
  File "/usr/bin/py2dsp", line 74, in main
fname = yield from download(name, version=version, destdir=args.root)
  File "/usr/share/pypi2deb/pypi2deb/pypi.py", line 124, in download
release = details['releases'].get(version, {})
KeyError: 'releases'


Kind regards

Andreas. 

-- 
http://fam-tille.de

Re: Making py2dsp/pypi2deb the default tool to create Python-based packages in Debian

[Andreas Tille]

Am Thu, Jul 21, 2022 at 02:52:38PM -0400 schrieb Sandro Tosi:
> 
> a fix for this was available in the git repo but not released, i took
> care of that with version 3.20220721 that has just been ACCEPTED.

Before I've sent my mail I also checked Git HEAD which was no change. 
Anyway, thanks for the quick response.  However, there seems to be
something wrong:


$ apt policy pypi2deb | grep Install
  Installed: 3.20220721
$ py2dsp --version
py2dsp 3.20220707
$ pypi2debian --version
/usr/bin/pypi2debian:63: DeprecationWarning: "@coroutine" decorator is 
deprecated since Python 3.8, use "async def" instead
  def run(self):
/usr/bin/pypi2debian:101: DeprecationWarning: "@coroutine" decorator is 
deprecated since Python 3.8, use "async def" instead
  def worker(self):
/usr/bin/pypi2debian:169: DeprecationWarning: "@coroutine" decorator is 
deprecated since Python 3.8, use "async def" instead
  def build_src_worker(self):
/usr/bin/pypi2debian:189: DeprecationWarning: "@coroutine" decorator is 
deprecated since Python 3.8, use "async def" instead
  def build_bin_worker(self):
pypi2debian 3.20220707


Are you sure thet the package version 3.20220721 contains the correct
executables?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Making py2dsp/pypi2deb the default tool to create Python-based packages in Debian

[Andreas Tille]

Hi Sandro,

Am Thu, Jul 07, 2022 at 11:10:01PM -0400 schrieb Sandro Tosi:
> My goal is to make py2dsp (contained in pypi2deb) the default tool
> used to create Python packages in Debian (like many other
> language-specific tools already do f.e. for go, rust, npm, etc). The
> new release contains several enhancements that should cover many of
> the packaging needs, in particular:

Sounds really great!
 
I just gave it a try:

$ py2dsp -v pystow
D: py2dsp py2dsp:156: version: 3.20220707
D: py2dsp py2dsp:157: ['/usr/bin/py2dsp', '-v', 'pystow']
/usr/bin/py2dsp:163: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
D: py2dsp py2dsp:44: args: Namespace(verbose=True, quiet=False, 
root='/home/andreas/debian-maintain/salsa/python-team/packages/0_prospective/result',
 clean=False, build=False, application=False, profile=None, github=None, 
distribution='UNRELEASED', revision='0~py2deb', message='converte0~py2deb', 
name='pystow')
E: py2dsp py2dsp:167: 'releases'
Traceback (most recent call last):
  File "/usr/bin/py2dsp", line 165, in 
loop.run_until_complete(main(args))
  File "/usr/lib/python3.10/asyncio/base_events.py", line 646, in 
run_until_complete
return future.result()
  File "/usr/bin/py2dsp", line 74, in main
fname = yield from download(name, version=version, destdir=args.root)
  File "/usr/share/pypi2deb/pypi2deb/pypi.py", line 124, in download
release = details['releases'].get(version, {})
KeyError: 'releases'
 

Am I missing something?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: List of packages of Python team that have no autopkgtest

[Andreas Tille]

Am Tue, Jul 19, 2022 at 08:35:55AM -0400 schrieb Sandro Tosi:
> > It does help a lot. Thanks a lot for this.
> 
> please be aware there is an almost complete solution (+Antonio in CC)
> to automatically have autopkgtests based on debian/rules and pybuild
> setup of tests (same way cli switches/skips/etc during build applied
> to autpkgtests). So if a package is currently missing autopkgtests i'd
> refrain from start add them in bulk as they may get it "for free" in
> the imminent future.

For sure this would be better.  As far as I understood the *current*
autopkgtest-pkg-python is just a superflous test - better than nothing
but not helpful for fast paced testing migration.  I'd love to see this
to be enhanced.

Kind regards

Andreas.

-- 
http://fam-tille.de

Re: List of packages of Python team that have no autopkgtest

[Andreas Tille]

Hi Neil,

Am Tue, Jul 19, 2022 at 08:00:49AM +0100 schrieb Neil Williams:
> It seems to be a list of source packages, yet it contains duplicates
> (pelican appears twice, for example, as does python-git).

I confirm that I noticed this.

> autopkgtest
> is source-package based, so can this be fixed?

I'm 100% sure this can be fixed. ;-P

> Maybe take the highest
> popcon of all binaries from each single source package?

I confirm that I don't like the situation but I can't spent more time
into this for the moment.  I'd recommend writing autopkgtest for the
duplicated packages first ... than these will vanish promptly. ;-P

Sorry for no better help at the moment - patches are always welcome

  Andreas.

-- 
http://fam-tille.de

Re: List of packages of Python team that have no autopkgtest

[Andreas Tille]

Hi,

Am Tue, Jul 19, 2022 at 10:26:55AM +0200 schrieb Thomas Goirand:
> > [1] 
> > https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/missing-autopkgtest
> 
> It does help a lot. Thanks a lot for this.

:-)
 
> We're really missing you in Prizren, btw.

Miss you all too.  There were really complex circumstances at my side
and the last reason that came up recently has proven my hard decision to
cancel DebConf22 the right thing to do. 

Wish you all a lot of fun and see you next year

  Andreas.

-- 
http://fam-tille.de

List of packages of Python team that have no autopkgtest

[Andreas Tille]

Hi Zigo,

you asked me for a list of packages without autopkgtest sorted by popcon
value as we create it for Debian Med team also for Python team.  I've
simply added it to the Debian Med dir for simplicity - feel free to take
over the code (or suggest some better place).  Here ist the list


https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/python-team-tests.txt

which is created by the script I'm using for Debian Med and Debian
Science[1].  It will be refreshed by a daily cron job.

Hope this helps

  Andreas.


[1] 
https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/missing-autopkgtest

-- 
http://fam-tille.de

Re: pygame: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" --system=custom --test-args "/usr/bin/xvfb-run {interpreter} -m pygame.tests.__main__ --exclude opengl" returned

[Andreas Tille]

Hi,

Am Wed, Mar 23, 2022 at 12:19:40AM +1100 schrieb Hugh McMaster:
> On Mon, 28 Feb 2022 at 16:40, Hugh McMaster wrote:
> 
> > I did some testing and found that pygame 2.1.0 is the first recent
> > version not affected by the FreeType test issue.
> >
> > I'll keep digging, but I'd strongly suggest migrating to the most
> > recent upstream version as soon as possible, as I had no problems
> > building it.
> 
> 
> Any progress on packaging the latest version of pygame?
> 
> The current package will be removed from testing next week.

If you ask me lets push pygame 2.1.0 and remove anything that does not
work with this version from testing (it would be removed from there
anyway).  I know its not good style but stagnation in the status quo
is also no good solution.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Thank you for helpful responses (Re: python-catalogue: AttributeError: type object 'EntryPoint' has no attribute '_from_text')

[Andreas Tille]

Hi,

I'd like to use the chance to express that I'm really thankful for every
helpful response I received here on this list.  My work in Debian
touches a lot of techniques and I can't gather expertise in every single
one.  It also happens that web searches I'm doing are not always as
successful as I wished.  So thanks a lot to those who have proven a
certain level of patience.  Your helpful responses enabled me to become
very productive in times of solved problems per time unit.

Thanks a lot

 Andreas.

-- 
http://fam-tille.de

python-catalogue: AttributeError: type object 'EntryPoint' has no attribute '_from_text'

[Andreas Tille]

Hi,

I intend to package python-catalogue[1] but there is a test suite
issue (see salsa-ci for complete log[2]):

platform linux -- Python 3.10.3, pytest-6.2.5, py-1.10.0, pluggy-1.0.0
rootdir: /builds/python-team/packages/python-catalogue/debian/output/source_dir
collected 8 items
catalogue/tests/test_catalogue.py ..F.   [100%]
=== FAILURES ===
__ test_entry_points ___
def test_entry_points():
# Create a new EntryPoint object by pretending we have a setup.cfg and
# use one of catalogue's util functions as the advertised function
ep_string = "[options.entry_points]test_foo\nbar = 
catalogue:check_exists"
>   ep = catalogue.importlib_metadata.EntryPoint._from_text(ep_string)
E   AttributeError: type object 'EntryPoint' has no attribute '_from_text'
catalogue/tests/test_catalogue.py:108: AttributeError
=== short test summary info 
FAILED catalogue/tests/test_catalogue.py::test_entry_points - AttributeError:...
= 1 failed, 7 passed in 0.06s ==

Any hint would be welcome

   Andreas.


[1] https://salsa.debian.org/python-team/packages/python-catalogue
[2] 
https://salsa.debian.org/python-team/packages/python-catalogue/-/jobs/2579949

-- 
http://fam-tille.de

Please care for arm64 autopkgtest of rdflib (Was: Any reason not to upload rdflib 6 to unstable)

[Andreas Tille]

Am Thu, Feb 24, 2022 at 09:54:24PM +0100 schrieb Andreas Tille:
> Am Thu, Feb 24, 2022 at 01:40:51PM +0100 schrieb Andreas Tille:
> > 
> > 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?
> 
> I'm tempted to upload rdflib 6.1.1 to unstable if nobody has good
> reasons not to do so.

I did so and realised that autopkgtest fails for arm64.  Since I'm
on vacation this week it would be great if someone would care about

   
https://ci.debian.net/data/autopkgtest/testing/arm64/c/cwltool/19607842/log.gz

Kind regards

   Andreas.

-- 
http://fam-tille.de

Any reason not to upload rdflib 6 to unstable (Was: rdflib: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p "3.10 3.9" returned exit code 13)

[Andreas Tille]

Am Thu, Feb 24, 2022 at 01:40:51PM +0100 schrieb Andreas Tille:
> 
> 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?

I'm tempted to upload rdflib 6.1.1 to unstable if nobody has good
reasons not to do so.

Kind regards

   Andreas. 

-- 
http://fam-tille.de

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

[Andreas Tille]

Hi Nilesh,

Am Thu, Feb 24, 2022 at 06:00:03PM +0530 schrieb Nilesh Patra:
> On 2/24/22 3:36 PM, Andreas Tille wrote:
> > 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.

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.  Unfortunately I did
never got ratt working (since I failed to setup sbuild properly).

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?

Kind regards

   Andreas.


-- 
http://fam-tille.de

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

[Andreas Tille]

Control: tags -1 confirmed
Control: tags -1 help

Hi Jonas,

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

Any help is welcome
 Andreas.


[1] https://salsa.debian.org/python-team/packages/rdflib/-/jobs/2505872

-- 
http://fam-tille.de

Re: pygame: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" --system=custom --test-args "/usr/bin/xvfb-run {interpreter} -m pygame.tests.__main__ --exclude opengl" returned

[Andreas Tille]

Hi Stefano,

Am Wed, Feb 23, 2022 at 01:56:11AM + schrieb Stefano Rivera:
> Hi Andreas (2022.02.22_07:57:25_+)
> > I've put all developers mentioned as Uploader in CC.  Given that the
> > last non-team upload was two years ago which might have lead to the
> > situation that following upstream changes is stalled it would be great
> > if you confirm that you intend to continue working on this package.
> 
> I think it's high time to get pygame 2 into Debian. There's probably
> some transition required, and maybe some rev-deps will need to be
> removed, but pygame 1.9 isn't supportable forever.

Missing myself the slightest insight into pygame I'd say we should start
rather sooner than later.
 
> I've done some of the recent uploads, kicking the can down the road, but
> they're getting harder and harder.

Definitely.  And thanks for keeping it alife so far.

Kind regards

Andreas. 

-- 
http://fam-tille.de

Re: pygame: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" --system=custom --test-args "/usr/bin/xvfb-run {interpreter} -m pygame.tests.__main__ --exclude opengl" returned

[Andreas Tille]

Control: tags -1 confirmed

Hi,

I had a look into this issue since a Debian Med package received a
testing removal warning.  I can confirm the build fails with

   Segmentation fault

in the build time test suite.  I realised that this package is lagging
quite a bit behind upstream and my personal approach would be to do an
upgrade to latest upstream.  However, the package has a number of
dependencies which I have no idea about and thus I'm hesitating to go on
with this idea which takes probably some time to review all the patches.
So for the moment I've just commited the changes of lintian-brush (=
made myself Debian Janitor ;-) )

I've put all developers mentioned as Uploader in CC.  Given that the
last non-team upload was two years ago which might have lead to the
situation that following upstream changes is stalled it would be great
if you confirm that you intend to continue working on this package.

Kind regards

 Andreas.

-- 
http://fam-tille.de

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

[Andreas Tille]

Am Fri, Feb 18, 2022 at 02:31:13AM +0530 schrieb Nilesh Patra:
> On 2/18/22 2:23 AM, Sandro Tosi wrote:
> > 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.

Yes.

> This does similar(same?) changes as in janitor.

I asked Jelmer what Janitor is doing and included those calls into
routine-update.
 
> 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.

Just in case this was not clear from my previous mail:  I'm fine with
direct commits.

My additional point was that I consider it sensible to let those commits
follow actual uploads which I was missing for several DPT packages which
I touched by chance.

Kind regards

  Andreas.

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

-- 
http://fam-tille.de

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

[Andreas Tille]

Hi,

Am Thu, Feb 17, 2022 at 12:39:54PM -0500 schrieb Sandro Tosi:
> I receive notifications for all MRs opened against DPT packages, and
> Janitor's are always pretty much ready to merge as is, and so i think
> we should let Janitor commit directly to the team packages.

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.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: New version of mayavi2 fails to build

[Andreas Tille]

Hi Scott,

Am Thu, Feb 17, 2022 at 11:27:12AM -0500 schrieb Scott Talbert:
> Looking at the full log, it appears as if something in the build process is
> trying to open an X display and fails.  Perhaps try running dh_auto_build
> with Xvfb?

Yes, thanks for the very helpful hint

  Andreas.

-- 
http://fam-tille.de

New version of mayavi2 fails to build

[Andreas Tille]

Hi,

as you can see in Salsa-CI build log[1] the new version of mayavi2 fails
with something like:

...
 File 
"/builds/python-team/packages/mayavi2/debian/output/source_dir/mayavi/mlab.py", 
line 16 in 
  File "", line 228 in _call_with_frames_removed
  File "", line 850 in exec_module
  File "", line 680 in _load_unlocked
  File "", line 986 in _find_and_load_unlocked
  File "", line 1007 in _find_and_load
  File "", line 228 in _call_with_frames_removed
  File "", line 1058 in _handle_fromlist
  File 
"/builds/python-team/packages/mayavi2/debian/output/source_dir/setup.py", line 
138 in mlab_reference
  File 
"/builds/python-team/packages/mayavi2/debian/output/source_dir/setup.py", line 
176 in run
  ...
Aborted (core dumped)
E: pybuild pybuild:367: build: plugin distutils failed with: exit code=134: 
/usr/bin/python3 setup.py build 

Any idea what might be wrong here?

Kind regards

  Andreas.


[1] https://salsa.debian.org/python-team/packages/mayavi2/-/pipelines/349803

-- 
http://fam-tille.de

Re: scikit-learn in unstable FTBFS on arm64, armel, armhf, i386, ppc64el and s390x

[Andreas Tille]

Hi,

Am Wed, Feb 16, 2022 at 12:09:23PM +0100 schrieb John Paul Adrian Glaubitz:
> 
> So, I have skimmed over the build logs and one of the main issues is the use 
> of
> -march flags to enforce a certain baseline [1]:
> 
> powerpc64le-linux-gnu-gcc: error: unrecognized command-line option 
> ‘-march=native’; did you mean ‘-mcpu=native’?
> 
> This is a policy violation and must be fixed in any case. Blacklisting 
> architectures
> is not enough in this case as forcing the baseline of the buildds can lead to 
> code
> that won't run on the user's machines.

I confirm this is a problem and the critical string can also be found in
the amd64 build log[2]:

...
running build_clib
customize UnixCCompiler
customize UnixCCompiler using build_clib
CCompilerOpt.cc_test_flags[1013] : testing flags (-march=native)
C compiler: x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare 
-DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
-Werror=format-security -g -fwrapv -O2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC

creating /tmp/tmpk22ehoi2/usr
creating /tmp/tmpk22ehoi2/usr/lib
creating /tmp/tmpk22ehoi2/usr/lib/python3
creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages
creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages/numpy
creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages/numpy/distutils
creating /tmp/tmpk22ehoi2/usr/lib/python3/dist-packages/numpy/distutils/checks
compile options: '-c'
extra options: '-march=native'
CCompilerOpt.cc_test_flags[1013] : testing flags (-O3)
C compiler: x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare 
-DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
-Werror=format-security -g -fwrapv -O2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC
...


I admit I'm not sure at what point / what tool might inject this string and
I'm also not sure whether the option -march=native is really used in the
amd64 case.

Kind regards

 Andreas.

> > [1] 
> > https://buildd.debian.org/status/fetch.php?pkg=scikit-learn=ppc64el=1.0.2-1=1644956229=0

[2] 
https://buildd.debian.org/status/fetch.php?pkg=scikit-learn=amd64=1.0.2-1=1644952702=0

-- 
http://fam-tille.de

Re: [Help] Re: python-envisage: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" returned exit code 13

[Andreas Tille]

Hi Scott,

thanks a lot for your hints.

Am Sun, Feb 13, 2022 at 10:28:15PM -0500 schrieb Scott Talbert:
> I spent some time looking into this.  The problem is that upstream includes
> binary eggs (which are Python version specific) as part of its test suite.
> The problem here is that there are no eggs included for Python 3.10.
> Upstream is aware of this[1] but unfortunately, that patch can't be applied
> because it is a binary patch.  They have also later[2] removed the binary
> eggs completely, but that patch can't be applied either because it involves
> files that are not in the PyPI distribution.  The best solution might be do
> what Fedora did[3], but for that we'd probably have to switch to using a
> GitHub tarball instead of the PyPI tarball because the PyPI tarball is
> missing files.

I switched to Github downloads and followed the Fedora approach.
I'd be happy if you could review my changes[1].

Kind regards

 Andreas.


[1] 
https://salsa.debian.org/python-team/packages/python-envisage/-/commit/1498f59734676a667d7ba64a2cc622a5c4f07f7b

-- 
http://fam-tille.de

[Help] Re: python-envisage: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" returned exit code 13

[Andreas Tille]

Control: tags -1 help

Hi,

I've updated python-envisage in Salsa[1] to the latest upstream version
and bumped its failing predepends to their according latest upstream and
fixed all bugs in those.  For envisage I'm stumbling upon a Python3.10
related bug I'd like to ask for help:

...
==
ERROR: test_exclude_multiple 
(envisage.tests.test_egg_plugin_manager.EggPluginManagerTestCase)
exclude multiple
--
Traceback (most recent call last):
  File 
"/build/python-envisage-6.0.1/.pybuild/cpython3_3.10_envisage/build/envisage/tests/test_egg_plugin_manager.py",
 line 115, in test_exclude_multiple
self._add_eggs_on_path([self.egg_dir])
  File 
"/build/python-envisage-6.0.1/.pybuild/cpython3_3.10_envisage/build/envisage/tests/test_egg_based.py",
 line 59, in _add_eggs_on_path
raise SystemError("Cannot find eggs %s" % errors)
SystemError: Cannot find eggs {}

==
ERROR: test_exclude_specific 
(envisage.tests.test_egg_plugin_manager.EggPluginManagerTestCase)
exclude specific
--
Traceback (most recent call last):
  File 
"/build/python-envisage-6.0.1/.pybuild/cpython3_3.10_envisage/build/envisage/tests/test_egg_plugin_manager.py",
 line 91, in test_exclude_specific
self._add_eggs_on_path([self.egg_dir])
  File 
"/build/python-envisage-6.0.1/.pybuild/cpython3_3.10_envisage/build/envisage/tests/test_egg_based.py",
 line 59, in _add_eggs_on_path
raise SystemError("Cannot find eggs %s" % errors)
SystemError: Cannot find eggs {}


Any idea to deal with this issue in
   envisage/tests/test_egg_based.py", line 59
?

Kind regards

  Andreas.


[1] https://salsa.debian.org/python-team/packages/python-envisage


-- 
http://fam-tille.de

Re: Help for python-subby needed

[Andreas Tille]

Am Tue, Feb 01, 2022 at 08:26:54AM -0500 schrieb Scott Kitterman:
> 
> Add build-depends on pybuild-plugin-pyproject.
> 
> Drop build-depends on flit.
> 
> Drop the "export PYBUILD_SYSTEM=flit" line in d/rules.

Thanks, this works now.
 
> That should get you close.

Yep.  Thanks a lot

 Andreas.

-- 
http://fam-tille.de

Re: Help for python-subby needed

[Andreas Tille]

Am Sat, Jan 29, 2022 at 01:50:22AM +0500 schrieb Andrey Rahmatullin:
> On Fri, Jan 28, 2022 at 09:48:00PM +0100, Andreas Tille wrote:
> > Hi,
> > 
> > I need python-subby as a new dependency for some Debian Med package.
> > Unfortunately it does not build easily[1]:
> > 
> >dh_auto_build -O--buildsystem=pybuild
> > E: pybuild pybuild:367: build: plugin flit failed with: Neither [project] 
> > nor [tool.flit.metadata] found in pyproject.toml
> > E: pybuild pybuild:367: build: plugin flit failed with: Neither [project] 
> > nor [tool.flit.metadata] found in pyproject.toml
> > dh_auto_build: error: pybuild --build -i python{version} -p "3.10 3.9" 
> > returned exit code 13
> It indeed uses poetry, not flit, but you have export PYBUILD_SYSTEM=flit.

Where can I find an example how to use poetry?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: Moving deepdiff to the Python Team? (and maybe taking over)

[Andreas Tille]

Hi Louis-Philippe,
Am Sat, Jan 29, 2022 at 06:59:48PM -0500 schrieb Louis-Philippe Véronneau:
> CleverCSV and ordered-set went through NEW 2 days ago, so I tweaked what
> Andreas had done and uploaded the latest upstream version of deepdiff to
> unstable.

:-)

Thanks a lot

  Andreas.

-- 
http://fam-tille.de

Help for python-subby needed

[Andreas Tille]

Hi,

I need python-subby as a new dependency for some Debian Med package.
Unfortunately it does not build easily[1]:

   dh_auto_build -O--buildsystem=pybuild
E: pybuild pybuild:367: build: plugin flit failed with: Neither [project] nor 
[tool.flit.metadata] found in pyproject.toml
E: pybuild pybuild:367: build: plugin flit failed with: Neither [project] nor 
[tool.flit.metadata] found in pyproject.toml
dh_auto_build: error: pybuild --build -i python{version} -p "3.10 3.9" returned 
exit code 13

Any help would be welcome

  Andreas.

[1] https://salsa.debian.org/python-team/packages/python-subby/-/jobs/2408409

-- 
http://fam-tille.de

python-schedule should be probably moved to Debian Python Team

[Andreas Tille]

Hi,

I've just fixed #1002316 by upgrading to latest upstream version.  When
looking at the package it might make sense to move it to Debian Python
team instead of private maintainership.  I'd volunteer to move the package
over if all involved people agree.

Kind regards

 Andreas.

-- 
http://fam-tille.de

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

[Andreas Tille]

Am Sat, Jan 15, 2022 at 07:23:14PM + schrieb Stefano Rivera:
> > 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.
> 
> Transferred: https://salsa.debian.org/med-team/python-bioblend

Thanks a lot for moving - package is uploaded on behalf of the Debian
Med team now.
 
Kind regards

  Andreas.

-- 
http://fam-tille.de

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

[Andreas Tille]

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.  I'm not sure whether making me the owner of that actual
repository is sufficient to enable me transfering the archive.
Alternatively I could make one of the DPT owners maintainer on Debian
Med project and let this person do the transfer.  If this is all to
complicated I'll create a new repository in Debian Med and will ask for
removal here once the package was uploaded.

Kind regards
   Andreas.

Am Wed, Dec 22, 2021 at 09:33:17PM +0100 schrieb Pierre-Elliott Bécue:
> 
> Nilesh Patra  wrote on 22/12/2021 at 20:45:53+0100:
> 
> > [[PGP Signed Part:No public key for 00BAE74B343369F1 created at 
> > 2021-12-22T20:45:49+0100 using RSA]]
> > 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 guess the problem is that the python-team doesn't seem to have been
> Cc-ed in your exchange, which was not quoted in the initial mail of this
> thread.
> 
> As I'm not subscribed to the list, it really looked like you were
> intending to take over a package without any maintainer of it having
> been asked for it before.
> 
> As it seems not to be the case, it's not the same at all.
> 
> >> 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.
> 
> I did not suggest to wait for a consensus, but rather that an admin asks
> if someone is against and waits for a reasonable delay (72 hours?) and
> then makes the transfer if they're happy with it.
> 
> > 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.
> 
> There is no real difference between teams and individual developers on
> that part: a take over has to be approved or to follow due procedures,
> whether we like it or not.
> 
> Here, as Steffen gave his approval, the topic is a bit moot.
> 
> > 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.
> 
> I was under the (false) impression that Steffen was not currently
> available to reply to your query. Ondřej being an admin of the team and
> having done all the uploads apart from those done by Steffen, he clearly
> seemed the best second contact point to ask this transfer.
> 
> >> >> 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.
> 
> Asking globally on the list and waiting a reasonable amount of time for
> a potential grunt is fine with me.
> 
> >> I think you missed the second part of my 

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

[Andreas Tille]

Am Sun, Jan 02, 2022 at 09:00:27PM +0100 schrieb Andreas Tille:
...
Continuing with moving packages from Debian Med to Debian Python Team
  
> python-sinfo 0.3.1-2
> python3-sinfo : print different version information for loaded modules

Moved to Debian Python Team.

> python-spectra 0.0.11-3
> python3-spectra : Easy color scales and color conversion for
> Python (Python 3 version)

Moved to Debian Python Team.

> python-stdlib-list 0.8.0-4
> python3-stdlib-list : List of Python Standard Libraries (2.6-7, 3.2-9)

Moved to Debian Python Team.

> python-streamz 0.6.3-1
> python3-streamz : build pipelines to manage continuous streams of data

Moved to Debian Python Team.
Unfortunately there is a build time test issue in my local pbuilder environment:
___ test_from_iterable_backpressure 

def test_from_iterable_backpressure():
it = iter(range(5))
source = Source.from_iterable(it)


wait_for(lambda: L == [0], 1, period=0.01)
>   assert next(it) == 2  # 1 is in blocked _emit
E   assert 1 == 2
E+  where 1 = next()

streamz/tests/test_sources.py:151: AssertionError

However, salsa-ci is fine:
  
https://salsa.debian.org/python-team/packages/python-streamz/-/pipelines/333644
(besides i386 build which also failed before)

Could somebody please check and upload?

> python-stubserver 1.1-2
> python3-stubserver : mock tester of external web dependencies for Python

Moved to Debian Python Team.

> python-tinyalign 0.2-5
> python3-tinyalign : numerical representation of differences between 
> strings

This is mentioned in med-* tasks and directly used by Biologists.  I think
we should keep it inside Debian Med team.

> python-typechecks 0.1.0+ds-2
> python3-typechecks : express constraints on types

Moved to Debian Python Team.

> python-upsetplot 0.6.0-2
> python3-upsetplot : Draw Lex et al.'s UpSet plots with Pandas and 
> Matplotlib

Moved to Debian Python Team.

> python-wdlparse 0.1.0-2
> python3-wdlparse : Workflow Description Language (WDL) parser for Python

This is mentioned in med-* tasks and directly used by Biologists.  I think
we should keep it inside Debian Med team.

> python-wordcloud 1.8.1+dfsg-2
> python3-wordcloud : little word cloud generator in Python

Moved to Debian Python Team.

> python-xopen 1.2.1-3
> python3-xopen : Python3 module to open compressed files transparently

Moved to Debian Python Team.

> smart-open 5.2.1-3
> python3-smart-open : utils for streaming large files

Moved to Debian Python Team.

> sorted-nearest 0.0.31+dfsg-1
> python3-sorted-nearest : Cython helper library for pyranges

This is just a helper for pyranges which is clearly a Debian Med package.
I see no real value in moving this to Debian Python Team.

> sphinxcontrib-autoprogram 0.1.7-1
> python3-sphinxcontrib.autoprogram : automated documentation of CLI
> programs for Sphinx (Python 3)

Moved to Debian Python Team.
 
> Thanks,

You are welcome.  I'd love to see an additional Uploader for all these
moved packages.  Please let me know if you see some additional room for
enhancement of the cooperation between Debian Python Team and Debian Med
Team. 

Kind regards

Andreas.

-- 
http://fam-tille.de

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

[Andreas Tille]

Am Sun, Jan 02, 2022 at 11:25:40AM +0100 schrieb Andreas Tille:
> Am Sun, Jan 02, 2022 at 10:00:09AM +0100 schrieb Andreas Tille:
> > ...
> Continuing with moving packages from Debian Med to Debian Python Team
 
> python-duckpy 3.2.0-2
> python3-duckpy : simple Python library for searching on DuckDuckGo

Moved to Debian Python Team

> python-easydev 0.12.0+dfsg-1
> python3-easydev : common utilities to ease the development of
> Python packages (Python 3)

Moved to Debian Python Team

> python-etelemetry 0.2.0-4
> python3-etelemetry : lightweight Python3 client to communicate
> with the etelemetry server

That's pretty clearly a Debian Med topic

> python-hdmedians 0.14.2-3
> python3-hdmedians : high-dimensional medians in Python3

Moved to Debian Python Team

> python-leidenalg 0.8.8-1
> python3-leidenalg : Python3 implementation of the Leiden algorithm in C++

Seems pretty related to Debian Med topic even if not that obvious.

> python-lzstring 1.0.4-1.1
> python3-lzstring : LZ-based compression algorithm for Python
> (Python 3 version)

Moved to Debian Python Team

> python-matplotlib-venn 0.11.6-2
> python3-matplotlib-venn : Python 3 plotting area-proportional two-
> and three-way Venn diagrams

Moved to Debian Python Team

> python-multipletau 0.3.3+ds-3
> python-multipletau-doc : documentation for multipletau Python module
> python3-multipletau : multiple-tau algorithm for Python3/NumPy

Moved to Debian Python Team

> python-multisplitby 0.0.1-4
> python3-multisplitby : Python3 module to create iterables split on
> arbitrary separators

Moved to Debian Python Team

> python-ncls 0.0.63+ds-1
> python3-ncls : datastructure for interval overlap queries

Moved to Debian Python Team

> python-pipdeptree 2.2.0-2
> python3-pipdeptree : display dependency tree of the installed
> Python 3 packages

Moved to Debian Python Team

> python-pyflow 1.1.20-3
> python3-pyflow : lightweight parallel task engine for Python

Workflows are a very hot topic in Debian Med team.  If there is no strong
reason to move this package to Debian Python team I'd prefer to leave it
where it is.

> python-pynndescent 0.5.2+dfsg-1
> python3-pynndescent : nearest neighbor descent for approximate
> nearest neighbors

Moved to Debian Python Team Git but source does not build - most
possibly due problems with Python3.10 and numba.  The latest upstream
version fails as well (with even more errors).  I'd be happy if someone
from Debian Python Team could serve as Uploader and care for this.

> python-pypubsub 4.0.3-5
> python3-pubsub : Python 3 publish-subcribe library

Moved to Debian Python Team

I'll continue with the next batch soon.

Kind regards

  Andreas.

> python-sinfo 0.3.1-2
> python3-sinfo : print different version information for loaded modules
> python-spectra 0.0.11-3
> python3-spectra : Easy color scales and color conversion for
> Python (Python 3 version)
> python-stdlib-list 0.8.0-4
> python3-stdlib-list : List of Python Standard Libraries (2.6-7, 3.2-9)
> python-streamz 0.6.3-1
> python3-streamz : build pipelines to manage continuous streams of data
> python-stubserver 1.1-2
> python3-stubserver : mock tester of external web dependencies for Python
> python-tinyalign 0.2-5
> python3-tinyalign : numerical representation of differences between 
> strings
> python-typechecks 0.1.0+ds-2
> python3-typechecks : express constraints on types
> python-upsetplot 0.6.0-2
> python3-upsetplot : Draw Lex et al.'s UpSet plots with Pandas and 
> Matplotlib
> python-wdlparse 0.1.0-2
> python3-wdlparse : Workflow Description Language (WDL) parser for Python
> python-wordcloud 1.8.1+dfsg-2
> python3-wordcloud : little word cloud generator in Python
> python-xopen 1.2.1-3
> python3-xopen : Python3 module to open compressed files transparently
> smart-open 5.2.1-3
> python3-smart-open : utils for streaming large files
> sorted-nearest 0.0.31+dfsg-1
> python3-sorted-nearest : Cython helper library for pyranges
> sphinxcontrib-autoprogram 0.1.7-1
> python3-sphinxcontrib.autoprogram : automated documentation of CLI
> programs for Sphinx (Python 3)
> 
> Thanks,
> -- 
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi
> 

-- 
http://fam-tille.de

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

[Andreas Tille]

Am Sun, Jan 02, 2022 at 10:00:09AM +0100 schrieb Andreas Tille:
> ...
Continuing with moving packages from Debian Med to Debian Python Team

> > python-ciso8601 2.2.0-1
> > python3-ciso8601 : fast ISO8601 date time parser for Python written in C

Moved to Debian Python Team

> > python-colormap 1.0.4-2
> > python3-colormap : ease manipulation of matplotlib colormaps and
> > color codecs (Python 3)

Moved to Debian Python Team

> > python-colormath 3.0.0-1.1
> > python3-colormath : Abstracts common color math operations (Python
> > 3 version)

Moved to Debian Python Team 

> > python-cooler 0.8.11-1
> > python3-cooler : library for a sparse, compressed, binary persistent 
> > storage
> > python3-cooler-examples : library for a sparse, compressed, binary
> > persistent storage (examples)

Should remain in Debian Med team (see
   https://lists.debian.org/debian-python/2022/01/msg2.html )

> > python-depinfo 1.7.0-1
> > python3-depinfo : retrieve and print Python 3 package dependencies

Moved to Debian Python Team 

> > python-fitbit 0.3.1-2
> > python-fitbit-doc : FitBit REST API Client Implementation - 
> > Documentation
> > python3-fitbit : FitBit REST API Client Implementation - Python 3

Should remain in Debian Med team (see   


https://lists.debian.org/debian-python/2022/01/msg2.html )  

  

Will be continued later.

Kind regards

Andreas.

> > python-duckpy 3.2.0-2
> > python3-duckpy : simple Python library for searching on DuckDuckGo
> > python-easydev 0.12.0+dfsg-1
> > python3-easydev : common utilities to ease the development of
> > Python packages (Python 3)
> > python-etelemetry 0.2.0-4
> > python3-etelemetry : lightweight Python3 client to communicate
> > with the etelemetry server
> > python-hdmedians 0.14.2-3
> > python3-hdmedians : high-dimensional medians in Python3
> > python-leidenalg 0.8.8-1
> > python3-leidenalg : Python3 implementation of the Leiden algorithm in 
> > C++
> > python-lzstring 1.0.4-1.1
> > python3-lzstring : LZ-based compression algorithm for Python
> > (Python 3 version)
> > python-matplotlib-venn 0.11.6-2
> > python3-matplotlib-venn : Python 3 plotting area-proportional two-
> > and three-way Venn diagrams
> > python-multipletau 0.3.3+ds-3
> > python-multipletau-doc : documentation for multipletau Python module
> > python3-multipletau : multiple-tau algorithm for Python3/NumPy
> > python-multisplitby 0.0.1-4
> > python3-multisplitby : Python3 module to create iterables split on
> > arbitrary separators
> > python-ncls 0.0.63+ds-1
> > python3-ncls : datastructure for interval overlap queries
> > python-pipdeptree 2.2.0-2
> > python3-pipdeptree : display dependency tree of the installed
> > Python 3 packages
> > python-pyflow 1.1.20-3
> > python3-pyflow : lightweight parallel task engine for Python
> > python-pynndescent 0.5.2+dfsg-1
> > python3-pynndescent : nearest neighbor descent for approximate
> > nearest neighbors
> > python-pypubsub 4.0.3-5
> > python3-pubsub : Python 3 publish-subcribe library
> > python-sinfo 0.3.1-2
> > python3-sinfo : print different version information for loaded modules
> > python-spectra 0.0.11-3
> > python3-spectra : Easy color scales and color conversion for
> > Python (Python 3 version)
> > python-stdlib-list 0.8.0-4
> > python3-stdlib-list : List of Python Standard Libraries (2.6-7, 3.2-9)
> > python-streamz 0.6.3-1
> > python3-streamz : build pipelines to manage continuous streams of data
> > python-stubserver 1.1-2
> > python3-stubserver : mock tester of external web dependencies for Python
> > python-tinyalign 0.2-5
> > python3-tinyalign : numerical representation of differences between 
> > strings
> > python-typechecks 0.1.0+ds-2
> > python3-typechecks : express constraints on types
> > python-upsetplot 0.6.0-2
> > python3-upsetplot : Draw Lex et al.'s UpSet plots with Pandas and 
> > Matplotlib
> > python-wdlparse 0.1.0-2
> > python3-wdlparse : Workflow Description Language (WDL) parser for Python
> > python-wordcloud 1.8.1+dfsg-2
> > python3-wordcloud : little word cloud generator in Python
> > python-xopen 1.2.1-3
> > python3

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

[Andreas Tille]

Am Sun, Jan 02, 2022 at 01:04:46PM +0530 schrieb 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

I fully agree here but I'd be happy to habd this over (and just did so)
since I feel the competence for NIFTI quite sparsely settled in our team
and thus I consider it well hosted in Debian Python Team.

> * python-anndata - For gene annotation

ACK (and wrote this also in my mail.

> * 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 ^^
 
I will not move these.

Kind regards

   Andreas.

-- 
http://fam-tille.de

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

[Andreas Tille]

Am Sat, Jan 01, 2022 at 09:28:10PM -0500 schrieb Sandro Tosi:
> > In general we are open to hand over general packages that are not
> > directly touching the medical / biological field to competent hands.  So
> > just ping me and I'll try to respond as quick as possible.
> 
> with UDD-mirror U now, i was able to generate the below list. This
> is in no way a request to move them, just a potential source of data
> for your consideration
> 
> arcp 0.2.1-3
> python3-arcp : (Archive and Package) URI parser and generator

Moved to Debian Python Team

> enlighten 1.7.2-1
> python3-enlighten : console progress bar module for Python3
> python3-enlighten-doc : console progress bar module for Python3
> (documentation)
> python3-enlighten-examples : console progress bar module for
> Python3 (examples)

Moved to Debian Python Team - I packaged version 1.8.0 which is the
last one that does not need the module prefixed (which is a new
dependency since version 1.9.0).  Unfortunately the build time test
fails with:

...
WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, 
status=None)) after connection broken by 'ProxyError('Cannot connect to 
proxy.', NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection 
refused'))': /simple/blessed/
WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, 
status=None)) after connection broken by 'ProxyError('Cannot connect to 
proxy.', NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection 
refused'))': /simple/blessed/
ERROR: Could not find a version that satisfies the requirement 
backports.functools-lru-cache>=1.2.1 (from blessed)
ERROR: No matching distribution found for backports.functools-lru-cache>=1.2.1

=== log end 
ERROR: could not install deps [blessed]; v = 
InvocationError('/build/enlighten-1.8.0/.tox/py310/bin/python -m pip install 
blessed', 1)
___ summary 
ERROR:   py310: could not install deps [blessed]; v = 
InvocationError('/build/enlighten-1.8.0/.tox/py310/bin/python -m pip install 
blessed', 1)
E: pybuild pybuild:367: test: plugin distutils failed with: exit code=1: cd 
/build/enlighten-1.8.0/.pybuild/cpython3_3.10/build; tox -c 
/build/enlighten-1.8.0/tox.ini --sitepackages -e py310
I: pybuild base:237: cd /build/enlighten-1.8.0/.pybuild/cpython3_3.9/build; tox 
-c /build/enlighten-1.8.0/tox.ini --sitepackages -e py39


May be you want to have a look to finalise the move to Debian Python Tem.

> h5sparse 0.1.0-4
> python3-h5sparse : Scipy sparse matrix in HDF5

Moved to Debian Python Team

> indexed-gzip 1.6.4-1
> python3-indexed-gzip : fast random access of gzip files in Python

Moved to Debian Python Team

> pyrle 0.0.33-2
> python3-pyrle : run length arithmetic in Python

Moved to Debian Python Team

> python-anndata 0.7.8-2
> python3-anndata : annotated gene by sample numpy matrix
^^
I think this package is nicely maintained by Debian Med team since it is
in the field of bioinformatics.

> python-avro 1.10.2+dfsg-1
> python3-avro : Apache Avro serialization system (Python 3 library)

Moved to Debian Python Team.  After upgrading to latest upstream version
the build ends with

...
==
ERROR: test_server_with_path (avro.test.test_ipc.TestIPC)
--
Traceback (most recent call last):
  File 
"/build/python-avro-1.11.0+dfsg/.pybuild/cpython3_3.9_avro/build/avro/test/test_ipc.py",
 line 35, in test_server_with_path
client_with_custom_path = avro.ipc.HTTPTransceiver("apache.org", 80, 
"/service/article")
  File 
"/build/python-avro-1.11.0+dfsg/.pybuild/cpython3_3.9_avro/build/avro/ipc.py", 
line 442, in __init__
self.conn.connect()
  File "/usr/lib/python3.9/http/client.py", line 946, in connect
self.sock = self._create_connection(
  File "/usr/lib/python3.9/socket.py", line 823, in create_connection
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
  File "/usr/lib/python3.9/socket.py", line 954, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -3] Temporary failure in name resolution

--
Ran 396 tests in 10.738s

FAILED (errors=1, skipped=2)

Unfortunately my time to investigate into this ends now.



I will continue with your list ... and wished moves in the other
direction could be as simple and unbureaucratic as it can be.

Kind regards

   Andreas.


> python-ciso8601 2.2.0-1
> python3-ciso8601 : fast ISO8601 date time parser for Python written in C
> python-colormap 1.0.4-2
> python3-colormap : ease manipulation of matplotlib colormaps and
> color codecs (Python 3)
> 

Re: Moving deepdiff to the Python Team? (and maybe taking over)

[Andreas Tille]

Hi Louis-Philippe,

Am Mon, Dec 27, 2021 at 04:35:44PM -0500 schrieb Louis-Philippe Véronneau:
> >> https://github.com/rspeer/ordered-set
> 
> I've just uploaded this one to NEW, it's packaged at:
> 
> https://salsa.debian.org/python-team/packages/python-ordered-set

Nice.
 
> >> https://github.com/alan-turing-institute/CleverCSV
> 
> Were you planning to work on this one? I _could_ package it myself, but
> it depends on pandas and so far I've successfully avoided maintaining
> packages that touch it :)

I have way to much packages on my desk - so no, I do not plan to
package this.  I just intended to help out a bit since some Debian
Med packages received testing-removal warnings due to deepdiff.

It would be great if you could work on the preconditions for the
latest upstream version of this package.

Kind regards

 Andreas.


-- 
http://fam-tille.de

Re: Moving deepdiff to the Python Team? (and maybe taking over)

[Andreas Tille]

Hi Michael,

Am Fri, Dec 24, 2021 at 11:49:49PM +0100 schrieb Michael Banck:
> AFAICT, the newer deepdiff requires the following unpackaged modules:
> 
> https://github.com/rspeer/ordered-set
> https://github.com/alan-turing-institute/CleverCSV

Added as "TODO" entry in d/changelog
 
> It additionally needs python3-click, python3-pytest and python3-yaml.

Added to Build-Depends.

> In order to get #1001292 fixed, I've uploaded a 3.3.0-3 package for now
> until the new Build-Depends are packaged.

Makes sense

  Andreas. 

-- 
http://fam-tille.de

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

[Andreas Tille]

Hi Sandro,

Am Thu, Dec 23, 2021 at 09:52:49AM -0500 schrieb Sandro Tosi:
> > Thus I moved mypy now and moved it to DPT[2].  Feel free to add yourself
> > to Uploaders and upload with the new location.
> 
> thanks!

You are welcome.

> > Sandro, do you have any other packages in mind?
> 
> too many to scan by-eyes only, so i planned on running some queries on
> UDD to figure some other package out, but the udd-mirror is down, so
> i'm going to provide a list (if any) later on.

In general we are open to hand over general packages that are not
directly touching the medical / biological field to competent hands.  So
just ping me and I'll try to respond as quick as possible.  Please also
note:  I'd be really happy if for any of the DPT packages featuring my
ID as Uploader if somebody wants to add another ID and become an
Uploader of that package.  I have way more packages on my table than
I really want to have.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: Moving deepdiff to the Python Team? (and maybe taking over)

[Andreas Tille]

Hi Michael,

Am Thu, Dec 23, 2021 at 12:16:05PM +0100 schrieb Michael Banck:
> On Thu, Dec 23, 2021 at 10:57:47AM +0100, Andreas Tille wrote:
> > seems I was able to create repositories and simply my script to do so
> > starting with an existing local repository failed for reasons I don't
> > know.  Thus I pushed what I have here and hand over to those who might
> > want to fix
> 
> Thanks Andreas.

You are welcome.
 
> I'm not in
> https://salsa.debian.org/groups/python-team/packages/-/group_members
> AFAICT so either you will have to remove me as maintainer or add me to
> that group I guess.

I can not add you personally but I hope someone responsible will take
the needed action (either by replacing your ID or adding you to the
team ... if you ask me two Uploaders are better than one).

Kind regards

   Andreas. 

-- 
http://fam-tille.de

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

[Andreas Tille]

Hi,

Am Thu, Dec 23, 2021 at 02:07:45PM +0530 schrieb 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.

Hmmm, that's correct and I confirm I can create repositories manually
(just my script failed and I did not checked on salsa.)

Thus I moved mypy now and moved it to DPT[2].  Feel free to add yourself
to Uploaders and upload with the new location.

Sandro, do you have any other packages in mind?

Hope this helps

  Andreas.


[2] 
https://salsa.debian.org/python-team/packages/mypy/-/commit/8bca8da1ca92302b921755318d3325d53b6e0a47
 

-- 
http://fam-tille.de

Re: Moving deepdiff to the Python Team? (and maybe taking over)

[Andreas Tille]

Hi,

seems I was able to create repositories and simply my script to do so
starting with an existing local repository failed for reasons I don't
know.  Thus I pushed what I have here and hand over to those who might
want to fix

...
  dh_auto_test
I: pybuild base:237: python3.10 setup.py test
/usr/lib/python3/dist-packages/setuptools/dist.py:723: UserWarning: Usage of 
dash-separated 'description-file' will not be supported in future versions. 
Please use the underscore name 'description_file' instead
  warnings.warn(
running pytest
/usr/lib/python3/dist-packages/setuptools/dist.py:723: UserWarning: Usage of 
dash-separated 'description-file' will not be supported in future versions. 
Please use the underscore name 'description_file' instead
  warnings.warn(
/usr/lib/python3/dist-packages/setuptools/command/easy_install.py:158: 
EasyInstallDeprecationWarning: easy_install command is deprecated. Use build 
and pip and other standards-based tools.
  warnings.warn(
/usr/lib/python3/dist-packages/setuptools/command/install.py:34: 
SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip 
and other standards-based tools.
  warnings.warn(
WARNING: Testing via this command is deprecated and will be removed in a future 
version. Users looking for a generic test entry point independent of test 
runner are encouraged to use tox.
/usr/lib/python3/dist-packages/setuptools/installer.py:27: 
SetuptoolsDeprecationWarning: setuptools.installer is deprecated. Requirements 
should be satisfied by a PEP 517 installer.
  warnings.warn(
/usr/bin/python3.10: No module named pip
error: Command '['/usr/bin/python3.10', '-m', 'pip', 
'--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmpn1cz3ghu', 
'--quiet', 'xmlschema']' returned non-zero exit status 1.
E: pybuild pybuild:355: test: plugin custom failed with: exit code=1: 
python3.10 setup.py test

Kind regards

  Andreas.

Am Thu, Dec 23, 2021 at 09:21:55AM +0100 schrieb Andreas Tille:
> Hi,
> 
> Am Thu, Dec 23, 2021 at 12:53:36AM -0500 schrieb Louis-Philippe Véronneau:
> > One of the packages I maintain is currently broken by BTS 1001292 [1]
> > and it seems deepdiff is in need of some love.
> > 
> > Would you be open to moving it to the Python Team? I'd be more than
> > happy to update it to the latest upstream version (seems like it would
> > fix the bug in question). It doesn't seem like there's a VCS though, so
> > that might require some work on your side.
> > 
> > If you want, I'd also be happy to take over and maintain it in the
> > Python Team myself.
> 
> I tried to support this and was running
> 
> gbp import-dscs --debsnap --pristine-tar deepdiff
> 
> commited
> 
> diff --git a/debian/changelog b/debian/changelog
> index 1f2e93d..9585e28 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,10 @@
> +deepdiff (3.3.0-3) UNRELEASED; urgency=medium
> +
> +  * Team upload.
> +  * Move package to Debian Python Team
> +
> + -- Andreas Tille   Thu, 23 Dec 2021 09:07:37 +0100
> +
>  deepdiff (3.3.0-2) unstable; urgency=medium
>  
>* Team upload
> diff --git a/debian/control b/debian/control
> index 8cccbb3..48149c9 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -1,7 +1,8 @@
>  Source: deepdiff
>  Section: python
>  Priority: optional
> -Maintainer: Michael Banck 
> +Maintainer:  Debian Python Team 
> +Uploaders: Michael Banck 
>  Build-Depends: debhelper (>= 10),
> dh-python,
> python3-all,
> @@ -11,6 +12,8 @@ Build-Depends: debhelper (>= 10),
> python3-setuptools
>  Standards-Version: 4.1.3
>  X-Python3-Version: >= 3.6
> +Vcs-Browser: https://salsa.debian.org/python-team/packages/deepdiff
> +Vcs-Git: https://salsa.debian.org/python-team/packages/deepdiff.git
>  Homepage: https://github.com/seperman/deepdiff
>  Testsuite: autopkgtest-pkg-python
> 
> 
> Fixed the watch file and was running `routine-update`.  Than there might
> be some work needed (like Build-Depending python3-wheel).  I would have
> pushed this to the Vcs-Git location but I learned that I'm missing
> maintainer permissions and can't create repositories.  Please grant me
> some maintainer permissions if you are interested.
> 
> Kind regards
> 
>  Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

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

[Andreas Tille]

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.

Kind regards

  Andreas.

Am Wed, Dec 22, 2021 at 10:06:10PM +0100 schrieb Andreas Tille:
> Hi Sandro,
> 
> Am Wed, Dec 22, 2021 at 03:13:28PM -0500 schrieb Sandro Tosi:
> > > 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.
> > 
> > since you're talking about the appropriate team to maintain a given
> > package (and it seems debian-med may be more suited for bioblend), are
> > you also going to move all non-bio/med python packages from debian-med
> > to dpt? because that's the more appropriate place for things like
> > mypy.
> 
> Yes, for sure.  Some packages somehow appeared for historical reasons in
> Debian Med but I'm fine to move those packages you consider more
> sensible in Python team (without any bureaucracy - I think for the move
> into this direction I own the proper permissions). 
> 
> Feel free to make a list if there are more packages than mypy.
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Re: Moving deepdiff to the Python Team? (and maybe taking over)

[Andreas Tille]

Hi,

Am Thu, Dec 23, 2021 at 12:53:36AM -0500 schrieb Louis-Philippe Véronneau:
> One of the packages I maintain is currently broken by BTS 1001292 [1]
> and it seems deepdiff is in need of some love.
> 
> Would you be open to moving it to the Python Team? I'd be more than
> happy to update it to the latest upstream version (seems like it would
> fix the bug in question). It doesn't seem like there's a VCS though, so
> that might require some work on your side.
> 
> If you want, I'd also be happy to take over and maintain it in the
> Python Team myself.

I tried to support this and was running

gbp import-dscs --debsnap --pristine-tar deepdiff

commited

diff --git a/debian/changelog b/debian/changelog
index 1f2e93d..9585e28 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+deepdiff (3.3.0-3) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Move package to Debian Python Team
+
+ -- Andreas Tille   Thu, 23 Dec 2021 09:07:37 +0100
+
 deepdiff (3.3.0-2) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/control b/debian/control
index 8cccbb3..48149c9 100644
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,8 @@
 Source: deepdiff
 Section: python
 Priority: optional
-Maintainer: Michael Banck 
+Maintainer:  Debian Python Team 
+Uploaders: Michael Banck 
 Build-Depends: debhelper (>= 10),
dh-python,
python3-all,
@@ -11,6 +12,8 @@ Build-Depends: debhelper (>= 10),
python3-setuptools
 Standards-Version: 4.1.3
 X-Python3-Version: >= 3.6
+Vcs-Browser: https://salsa.debian.org/python-team/packages/deepdiff
+Vcs-Git: https://salsa.debian.org/python-team/packages/deepdiff.git
 Homepage: https://github.com/seperman/deepdiff
 Testsuite: autopkgtest-pkg-python


Fixed the watch file and was running `routine-update`.  Than there might
be some work needed (like Build-Depending python3-wheel).  I would have
pushed this to the Vcs-Git location but I learned that I'm missing
maintainer permissions and can't create repositories.  Please grant me
some maintainer permissions if you are interested.

Kind regards

 Andreas.

-- 
http://fam-tille.de

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

[Andreas Tille]

Hi Sandro,

Am Wed, Dec 22, 2021 at 03:13:28PM -0500 schrieb Sandro Tosi:
> > 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.
> 
> since you're talking about the appropriate team to maintain a given
> package (and it seems debian-med may be more suited for bioblend), are
> you also going to move all non-bio/med python packages from debian-med
> to dpt? because that's the more appropriate place for things like
> mypy.

Yes, for sure.  Some packages somehow appeared for historical reasons in
Debian Med but I'm fine to move those packages you consider more
sensible in Python team (without any bureaucracy - I think for the move
into this direction I own the proper permissions). 

Feel free to make a list if there are more packages than mypy.

Kind regards

   Andreas.

-- 
http://fam-tille.de

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

[Andreas Tille]

Am Wed, Dec 22, 2021 at 06:13:32PM +0100 schrieb Pierre-Elliott Bécue:
> 
> Andreas Tille  wrote on 21/12/2021 at 15:43:11+0100:
> 
> > Ping?  Could any admin of Debian Python Team help out?  We can simply
> > recreate the repository in Debian Med and move on ... but that might
> > be confusing for users who will find two clones in differen teams.
> > Thank you, Andreas.
> 
> 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.
 
> Apart from that, you'll need for an admin of the team to do the transfer,
> and they could be willing to check that no one in the team objects.

Yes, we need an admin and that was I'm asking for.
 
> 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.

Kind regards

   Andreas.

-- 
http://fam-tille.de

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

[Andreas Tille]

Ping?  Could any admin of Debian Python Team help out?  We can simply
recreate the repository in Debian Med and move on ... but that might
be confusing for users who will find two clones in differen teams.
Thank you, Andreas.

Am Sun, Dec 19, 2021 at 05:06:43PM +0100 schrieb Andreas Tille:
> Hi,
> 
> we want to take over python-bioblend to Debian Med team.  Unfortunately
> the transfer procedure requires owner permissions to remove the package
> from the old place.  Could someone grant Nilesh Patra or me owner
> permissions on this package?  Alternatively I can grant maintainer
> permissions to some python-team owner to move the package over.
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Please enable me transfering python-bioblend to Debian Med team

[Andreas Tille]

Hi,

we want to take over python-bioblend to Debian Med team.  Unfortunately
the transfer procedure requires owner permissions to remove the package
from the old place.  Could someone grant Nilesh Patra or me owner
permissions on this package?  Alternatively I can grant maintainer
permissions to some python-team owner to move the package over.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: Ball fails its autopkgtest - how to properly deal with sip files?

[Andreas Tille]

Control: tags -1 pending

I've fixed the dh_installdocs issue in Git[1] but wanted to solve
the autopkgtest issue as well.  At first I provided the proper
module name[2] which brought me back to the old discussion here:

Am Thu, Sep 23, 2021 at 11:59:50PM +0200 schrieb Étienne Mollier:
> Hi Nilesh,
> 
> Nilesh Patra, on 2021-09-23:
> > The problems that I see on a quick look are:
> > 1) the import name is wrong, it should be BALL instead of ball
> > this is trivial to fix
> > 2) This is the bigger problem. python3-ball is broken, it needed to compile
> > the .sip files, to make an so lib
> > and import that. This is not happening. Probably fixing this is also not
> > hard, just passing SIP_LIBRARY with cmake
> > might do the trick, but again no time.
> > 
> > Also, my understanding is that it was always broken, and has got barely
> > anything to do with my bug fix.
> > Since I am very very short on time, @Etienne, could you please fix this and
> > dput?
> 
> Thanks for drawing my attention on this!  I can have a look,
> sure, although I don't guarantee this will be solved this
> evening; it looks like quite the machine cycles hog.  It is the
> first time I hear about sip, it looks kinda similar to swig.
> Will run an overnight build to see if I can manage to do
> something with the SIP_LIBRARY environment variable; thanks for
> the tip!

For whatever reason python3-sip did not ended up in the package
dependencies. Thus I added it explicitly[3].  But the autopkg issue
remains[4]:

autopkgtest [17:09:54]: test autodep8-python3: [---
Testing with python3.9:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/BALL.py", line 5, in 
from BALLCore import *
ModuleNotFoundError: No module named 'BALLCore'
autopkgtest [17:09:55]: test autodep8-python3: ---]

and we have the sip file 

   /usr/lib/python3/dist-packages/BALL/BALLCore.sip

I have no idea why this is not found.

Kind regards

   Andreas.


[1] 
https://salsa.debian.org/med-team/ball/-/commit/451bb880214e04c1042fabd19acef30fbf1ede78
[2] 
https://salsa.debian.org/med-team/ball/-/commit/129417031797d553a3f87a9de5abfd05d6e848c0
[3] 
https://salsa.debian.org/med-team/ball/-/commit/df9bd210dd6c172563583bc14278cf3bbc0f047b
[4] https://salsa.debian.org/med-team/ball/-/jobs/2278393

-- 
http://fam-tille.de

[help] pymol: Deprecation warning during startup

[Andreas Tille]

Hi,

I think I've fixed the issue[1] and it works nicely at command line.  
Unfortunately
Salsa-CI[2] shows a new issue

   AttributeError: module 'importlib' has no attribute 'util'

which I do not understand at all since at command line there is the attribute 
'util'.

Any hint would be welcome
Andreas.


[1] 
https://salsa.debian.org/debichem-team/pymol/-/commit/66b5875cbc000870f3661c66a4578d4c58968446
[2] https://salsa.debian.org/debichem-team/pymol/-/jobs/2273661

-- 
http://fam-tille.de

Re: numba: FTBFS with Python 3.10

[Andreas Tille]

Hi,

I've commited version 0.54.1 to Git since I assume that we have better
chances for Python3.10 support in the more recent upstream version.
Unfortunately the build stops with

dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:237: python3.10 setup.py clean 
...
  from distutils import sysconfig
Traceback (most recent call last):
  File "/build/numba-0.54.1/setup.py", line 51, in 
_guard_py_ver()
  File "/build/numba-0.54.1/setup.py", line 48, in _guard_py_ver
raise RuntimeError(msg.format(cur_py, min_py, max_py))
RuntimeError: Cannot install on Python version 3.10.1; only versions 
>=3.7,<3.10 are supported.
E: pybuild pybuild:354: clean: plugin distutils failed with: exit code=1: 
python3.10 setup.py clean 


Hoping for an upstream fix of #7562 in their tracker now.

I think pushing for Python3.10 in Debian before such packages with lots
of rdepends (specifically python3-pandas) are ported is quite demanding.

Kind regards

   Andreas.

-- 
http://fam-tille.de

[Help] diskcache: FTBFS now even earlier due to Python3.10

[Andreas Tille]

Control: tags -1 help

Hi,

currently I'm running into


ERROR:   py310: could not install deps [django>=2.2.*, pytest, pytest-cov, 
pytest-django, pytest-xdist]; v = 
InvocationError("/build/diskcache-5.2.1/.tox/py310/bin/python -m pip install 
'django>=2.2.*' pytest pytest-cov pytest-django pytest-xdist", 1)
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: cd 
/build/diskcache-5.2.1/.pybuild/cpython3_3.10_diskcache/build; tox -c 
/build/diskcache-5.2.1/tox.ini --sitepa


Any help would be really welcome

  Andreas.


-- 
http://fam-tille.de

[help] New error in test cases of bmtk

[Andreas Tille]

Hi,

I think I've found a patch[1] to solve the original issue which just
seems to be a floating point precision issue.  However, meanwhile there
is another less simple issue:

 ERRORS 
_ ERROR collecting 
.pybuild/cpython3_3.10/build/bmtk/tests/builder/test_connection_map.py _
ImportError while importing test module 
'/build/bmtk-0.0.9+ds/.pybuild/cpython3_3.10/build/bmtk/tests/builder/test_connection_map.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3/dist-packages/pandas/__init__.py:30: in 
from pandas._libs import hashtable as _hashtable, lib as _lib, tslib as 
_tslib
/usr/lib/python3/dist-packages/pandas/_libs/__init__.py:13: in 
from pandas._libs.interval import Interval
E   ModuleNotFoundError: No module named 'pandas._libs.interval'

The above exception was the direct cause of the following exception:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
bmtk/tests/builder/test_connection_map.py:4: in 
from bmtk.builder.connection_map import ConnectionMap
bmtk/builder/__init__.py:23: in 
from .networks import DenseNetwork, NetworkBuilder
bmtk/builder/networks/__init__.py:23: in 
from .dm_network import DenseNetwork
bmtk/builder/networks/dm_network.py:32: in 
from bmtk.utils import sonata
bmtk/utils/sonata/__init__.py:24: in 
from .file import File
bmtk/utils/sonata/file.py:23: in 
from . import utils
bmtk/utils/sonata/utils.py:27: in 
import pandas as pd
/usr/lib/python3/dist-packages/pandas/__init__.py:34: in 
raise ImportError(
E   ImportError: C extension: No module named 'pandas._libs.interval' not 
built. If you want to import pandas from the source directory, you may need to 
run 'python setup.py build_ext --
_ ERROR collecting 
.pybuild/cpython3_3.10/build/bmtk/tests/builder/test_connector.py _
ImportError while importing test module 
'/build/bmtk-0.0.9+ds/.pybuild/cpython3_3.10/build/bmtk/tests/builder/test_connector.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3/dist-packages/pandas/__init__.py:30: in 
from pandas._libs import hashtable as _hashtable, lib as _lib, tslib as 
_tslib
/usr/lib/python3/dist-packages/pandas/_libs/__init__.py:13: in 
from pandas._libs.interval import Interval
E   ModuleNotFoundError: No module named 'pandas._libs.interval'

The above exception was the direct cause of the following exception:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
bmtk/tests/builder/test_connector.py:1: in 
from bmtk.builder import connector
bmtk/builder/__init__.py:23: in 
from .networks import DenseNetwork, NetworkBuilder
bmtk/builder/networks/__init__.py:23: in 
from .dm_network import DenseNetwork
bmtk/builder/networks/dm_network.py:32: in 
from bmtk.utils import sonata
bmtk/utils/sonata/__init__.py:2= test session 
starts ==


I updated the upstream version in Git (but the issue is the same for the version
in unstable) and you can see a full build log in Salsa CI[2].

Any idea how to fix this?

Kind regards

  Andreas.


[1] 
https://salsa.debian.org/med-team/bmtk/-/blob/master/debian/patches/precision_in_test.patch
[2] https://salsa.debian.org/med-team/bmtk/-/jobs/2206233#L2178

-- 
http://fam-tille.de

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

[Andreas Tille]

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:


   dh_auto_install -O--buildsystem=pybuild
I: pybuild base:232: /usr/bin/python3 setup.py install --root 
/build/python-cogent-2021.5.7a+dfsg/debian/python3-cogent3 
/usr/lib/python3/dist-packages/setuptools/dist.py:487: UserWarning: Normalizing 
'2021.5.7a' to '2021.5.7a0'
  warnings.warn(tmpl.format(**locals()))
running install
running build
running build_py
running install_lib
creating /build/python-cogent-2021.5.7a+dfsg/debian/python3-cogent3
creating /build/python-cogent-2021.5.7a+dfsg/debian/python3-cogent3/usr
...
byte-compiling 
/build/python-cogent-2021.5.7a+dfsg/debian/python3-cogent3/usr/lib/python3.9/dist-packages/cogent3/phylo/least_squares.py
 to least_squares.cpython-39.pyc
running install_egg_info
running egg_info
creating src/cogent3.egg-info
writing src/cogent3.egg-info/PKG-INFO
Traceback (most recent call last):
  File "/build/python-cogent-2021.5.7a+dfsg/setup.py", line 52, in 
setup(
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 153, in 
setup
return distutils.core.setup(**attrs)
  File "/usr/lib/python3.9/distutils/core.py", line 148, in setup
dist.run_commands()
  File "/usr/lib/python3.9/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
  File "/usr/lib/python3.9/distutils/dist.py", line 985, in run_command
cmd_obj.run()
  File "/usr/lib/python3/dist-packages/setuptools/command/install.py", line 61, 
in run
return orig.install.run(self)
  File "/usr/lib/python3.9/distutils/command/install.py", line 602, in run
self.run_command(cmd_name)
  File "/usr/lib/python3.9/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
  File "/usr/lib/python3.9/distutils/dist.py", line 985, in run_command
cmd_obj.run()
  File "/usr/lib/python3/dist-packages/setuptools/command/install_egg_info.py", 
line 51, in run
self.run_command('egg_info')
  File "/usr/lib/python3.9/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
  File "/usr/lib/python3.9/distutils/dist.py", line 985, in run_command
cmd_obj.run()
  File "/usr/lib/python3/dist-packages/setuptools/command/egg_info.py", line 
292, in run
writer(self, ep.name, os.path.join(self.egg_info, ep.name))
  File "/usr/lib/python3/dist-packages/setuptools/command/egg_info.py", line 
635, in write_pkg_info
metadata.write_pkg_info(cmd.egg_info)
  File "/usr/lib/python3.9/distutils/dist.py", line 1117, in write_pkg_info
self.write_pkg_file(pkg_info)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 182, in 
write_pkg_file
license = rfc822_escape(self.get_license())
  File "/usr/lib/python3.9/distutils/util.py", line 476, in rfc822_escape
lines = header.split('\n')
AttributeError: 'list' object has no attribute 'split'
E: pybuild pybuild:354: install: plugin distutils failed with: exit code=1: 
/usr/bin/python3 setup.py install --root 
/build/python-cogent-2021.5.7a+dfsg/debian/python3-cogent3 
dh_auto_install: error: pybuild --install -i python{version} -p 3.9 --dest-dir 
/build/python-cogent-2021.5.7a\+dfsg/debian/tmp returned exit code 13


Any idea what might be wrong here?

Kind regards

 Andreas.


[1] 
https://salsa.debian.org/med-team/python-cogent/-/commit/43aa41a0fbce1643211bd69ec6ecaca209397753

-- 
http://fam-tille.de

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

[Andreas Tille]

Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1 https://github.com/cogent3/cogent3/issues/977

Hi,

I wonder whether someone on the Python list might come up with some help

Am Sun, Oct 24, 2021 at 01:57:39PM +0200 schrieb Lucas Nussbaum:
> Source: python-cogent
> Version: 2021.5.7a+dfsg-2
> ...
> > make[2]: Entering directory '/<>/doc'
> > sphinx-build -b html -d _build/doctrees   . _build/html
> > Running Sphinx v4.2.0
> > making output directory... done
> > WARNING: html_static_path entry '_static' does not exist
> > WARNING: The config value `today' has type `date', defaults to `str'.
> > 
> > Extension error:
> > You must configure the bibtex_bibfiles setting
> > make[2]: *** [Makefile:40: html] Error 2

I suspect that this issue is caused by the Sphinx version bump.
When looking at other places where this error was discussed[1],
the recommendation is to use

sphinxcontrib-bibtex<2.0.0 to requirements.txt

which is no real option in the our packaging case.  Any help how
to adapt the code to python3-sphinxcontrib.bibtex 2.4.1 would
be appreciated.

Kind regards

  Andreas.


[1] https://github.com/executablebooks/jupyter-book/issues/1137

-- 
http://fam-tille.de

Re: Potential issue with numpy

[Andreas Tille]

On Wed, Sep 29, 2021 at 11:27:23AM -0400, Sandro Tosi wrote:
> Please do report bugs in the BTS when there's a problem with a package

#995318

Kind regards

 Andreas. 

-- 
http://fam-tille.de

Potential issue with numpy

[Andreas Tille]

Hi,

in the issue I filed against nipype I was asked to try to rebuild numpy
and see whether this might make a diffence.  So I tried

  dget http://deb.debian.org/debian/pool/main/n/numpy/numpy_1.19.5-1.dsc
  cd numpy-1.19.5

and have rebuild it in a recent pbuilder environment.  This ends up in

DISTUTILS.rst.txt:386: WARNING: Unparseable C cross-reference: '/**end 
repeat1**/'
Invalid C declaration: Expected identifier in nested name. [error at 0]
  /**end repeat1**/
  ^

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 280, in 
build_main
app.build(args.force_all, filenames)
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 337, in 
build
self.builder.build_update()
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 293, 
in build_update
self.build(to_build,
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 357, 
in build
self.write(docnames, list(updated_docnames), method)
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 531, 
in write
self._write_serial(sorted(docnames))
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 541, 
in _write_serial
self.write_doc(docname, doctree)
  File "/usr/lib/python3/dist-packages/sphinx/builders/html/__init__.py", line 
626, in write_doc
self.docwriter.write(doctree, destination)
  File "/usr/lib/python3/dist-packages/docutils/writers/__init__.py", line 78, 
in write
self.translate()
  File "/usr/lib/python3/dist-packages/sphinx/writers/html.py", line 70, in 
translate
self.document.walkabout(visitor)
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in 
walkabout
if child.walkabout(visitor):
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in 
walkabout
if child.walkabout(visitor):
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in 
walkabout
if child.walkabout(visitor):
  [Previous line repeated 1 more time]
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 206, in 
walkabout
visitor.dispatch_visit(self)
  File "/usr/lib/python3/dist-packages/sphinx/util/docutils.py", line 477, in 
dispatch_visit
method(node)
  File "/usr/lib/python3/dist-packages/sphinx/writers/html5.py", line 417, in 
visit_literal_block
highlighted = self.highlighter.highlight_block(
  File "/usr/lib/python3/dist-packages/sphinx/highlighting.py", line 149, in 
highlight_block
lexer = self.get_lexer(source, lang, opts, force, location)
  File "/usr/lib/python3/dist-packages/sphinx/highlighting.py", line 127, in 
get_lexer
lexer = lexer_classes[lang](**opts)
TypeError: 'NumPyLexer' object is not callable

Exception occurred:
  File "/usr/lib/python3/dist-packages/sphinx/highlighting.py", line 127, in 
get_lexer
lexer = lexer_classes[lang](**opts)
TypeError: 'NumPyLexer' object is not callable
The full traceback has been saved in /tmp/sphinx-err-h3bd2cwr.log, if you want 
to report the issue to the developers.
Please also report this if it was a user error, so that a better error message 
can be provided next time.
A bug report can be filed in the tracker at 
. Thanks!


While I think this could be worth a "does not build from source" bug
against numpy (I'd wait with this until somebody confirms) I wonder
what answer I should give to nipype upstream in the issue[1].

Kind regards

 Andreas.


[1] https://github.com/nipy/nipype/issues/3382

-- 
http://fam-tille.de

Placement of *.so files to be found by Python modules (Was: ont-fast5-api)

[Andreas Tille]

Hi,

there is a problem with ont-fast5-api[0]

On Wed, May 26, 2021 at 03:22:21AM +0530, Nilesh Patra wrote:   

 
> However, one problem - I'm being verbose so we are in loop:
> 
> - This package had .so files vendored in ont_fast5_api/vbz_plugin/* -- this 
> is a violation, and hence you repacked it - see this[1]
> - The so files it had, are basically the shared object files that 
> libvbz-hdf-plugin vendors, and that was why we packaged it
> - *Now*, we need to somehow tell this package to find the .so files at the 
> right location
> 
> I did not manage to do that, so I simply ended up symlinking the .so vendored 
> by libvbz-hdf-plugin in that directory. This looks like a bad workaround,
> and hence if you have some way to fixup paths, please have a look.
> The bad change I'm talking about is this one[2]

I can confirm if I disable Nilesh's patch[2] than the build time
tests are failing like:

==
ERROR: test_add_read_from_multi (test.test_compress_fast5.TestVbzConvert)
--
Traceback (most recent call last):
  File 
"/build/ont-fast5-api-3.1.5+dfsg/.pybuild/cpython3_3.9_ont_fast5_api/build/ont_fast5_api/fast5_read.py",
 line 104, in add_raw_data
self.handle[self.raw_dataset_group_name].create_dataset('Signal', 
data=data, dtype='i2',
  File "/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/group.py", 
line 136, in create_dataset
dsid = dataset.make_new_dset(self, shape, dtype, data, **kwds)
  File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/dataset.py", line 
137, in make_new_dset
dcpl = filters.fill_dcpl(
  File 
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/filters.py", line 
234, in fill_dcpl
raise ValueError("Unknown compression filter number: %s" % compression)
ValueError: Unknown compression filter number: 32020

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File 
"/build/ont-fast5-api-3.1.5+dfsg/.pybuild/cpython3_3.9_ont_fast5_api/build/test/test_compress_fast5.py",
 line 98, in test_add_read_from_multi
output_f5.add_existing_read(input_read, target_compression)
  File 
"/build/ont-fast5-api-3.1.5+dfsg/.pybuild/cpython3_3.9_ont_fast5_api/build/ont_fast5_api/multi_fast5.py",
 line 80, in add_existing_read
self._add_read_from_multi(read_to_add, target_compression)
  File 
"/build/ont-fast5-api-3.1.5+dfsg/.pybuild/cpython3_3.9_ont_fast5_api/build/ont_fast5_api/multi_fast5.py",
 line 97, in _add_read_from_multi
output_read.add_raw_data(raw_data, raw_attrs, 
compression=target_compression)
  File 
"/build/ont-fast5-api-3.1.5+dfsg/.pybuild/cpython3_3.9_ont_fast5_api/build/ont_fast5_api/fast5_read.py",
 line 107, in add_raw_data
raise_missing_vbz_error_read(e)
  File 
"/build/ont-fast5-api-3.1.5+dfsg/.pybuild/cpython3_3.9_ont_fast5_api/build/ont_fast5_api/compression_settings.py",
 line 73, in raise_missing_vbz_error_read
raise IOError(VBZ_ERROR_MESSAGE.format(register_plugin())) from err
OSError: Failed to read compressed raw data. VBZ compression filter (id=32020) 
may be missing from expected path: 
'/build/ont-fast5-api-3.1.5+dfsg/.pybuild/cpython3_3.9_ont_fast5_api/build/ont_fast5_api/vbz_plugin'

==
ERROR: test_compress_read_from_single (test.test_compress_fast5.TestVbzConvert)
--
...


I wonder if there is some trick to point the code to the proper
location of the plugins.  Just a warning:  The plugins are currently
in new[3] as well as its precondition libstreamvbyte[4].

Kind regards

  Andreas.


[0] https://salsa.debian.org/med-team/ont-fast5-api
> [1]: 
> https://salsa.debian.org/med-team/ont-fast5-api/-/commit/097a79d489062b82c6b3abfc45a970bee59893de
> [2]: 
> https://salsa.debian.org/med-team/ont-fast5-api/-/commit/eb74a43929768ab0455f549919df2c5a6607525d
[3] https://ftp-master.debian.org/new/libvbz-hdf-plugin_1.0.1-1.html
[4] https://ftp-master.debian.org/new/libstreamvbyte_0.4.1-1.html




-- 
http://fam-tille.de

How can I override module name in autopkgtest-pkg-python

[Andreas Tille]

Hi,

I worked on the package python-cython-blis[1] (there is no specific
reason to have it in Debian Science scope - I just found an existing
repository there and continued with this).

The package works nicely - but the autopkgtest (in Salsa CI[2] does
not):

autopkgtest [19:46:36]: test autodep8-python3: set -e ; for py in $(py3versions 
-r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c 
"import cython_blis; print(cython_blis)" ; done
autopkgtest [19:46:36]: test autodep8-python3: [---
Testing with python3.9:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'cython_blis'
autopkgtest [19:46:37]: test autodep8-python3: ---]


The actual module that needs to be importet is just blis.  How can
I teach autodep8-python3 the correct module name?

Kind regards

  Andreas.


[1] https://salsa.debian.org/science-team/python-cython-blis
[2] https://salsa.debian.org/science-team/python-cython-blis/-/jobs/1483087

-- 
http://fam-tille.de

Re: diskcache: ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found

[Andreas Tille]

On Mon, Jan 25, 2021 at 12:45:08PM -0500, Sandro Tosi wrote:
> and that's because
> https://github.com/grantjenks/python-diskcache/blob/master/tox.ini is
> not included in the pypi package (and, independently, the reason i
> start packaging tarballs from github, it's just easier than getting
> half baked pypi tarballs).

I injected a new tarball drained from Github.  It seems to need lots of
not yet packaged - I have no idea how to cope with this.
 
Kind regards

 Andreas.

-- 
http://fam-tille.de

diskcache: ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found

[Andreas Tille]

Hi,

to update python-cobra I need diskcache as new dependency.  Yaroslav
I assume it is OK if I team-hijacked your ITP.  I injected the packaging
into the existing but empty repository[1].  Unfortunately I have no idea
about tox and thus I need help to solve this:

   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:232: python3.9 setup.py test.
Warning: 'classifiers' should be a list, got type 'tuple'
running test
WARNING: Testing via this command is deprecated and will be removed in a future 
version. Users looking for a generic test entry point independent of test 
runner are encouraged to use tox.
running egg_info
writing diskcache.egg-info/PKG-INFO
writing dependency_links to diskcache.egg-info/dependency_links.txt
writing top-level names to diskcache.egg-info/top_level.txt
reading manifest file 'diskcache.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'diskcache.egg-info/SOURCES.txt'
running build_ext
ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found
E: pybuild pybuild:353: test: plugin distutils failed with: exit code=1: 
python3.9 setup.py test.
dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit 
code 13
make: *** [debian/rules:6: build] Error 25

Any help would be welcome.

Kind regards

   Andreas.


[1] https://salsa.debian.org/python-team/packages/diskcache

-- 
http://fam-tille.de

macsyfinder: Upstream released Python3 version but "error: 'setuptools' is not supported. Please use 'pip' instead."

[Andreas Tille]

Control: tags -1 - upstream

Hi,

upstream has released a Python3 version of macsyfinder which I pushed to
Git[1].  When trying to build I get a strange error:

   dh_auto_install -O--buildsystem=pybuild
I: pybuild base:232: /usr/bin/python3 setup.py install --root 
'/build/macsyfinder-2.0~rc1/debian/macsyfinder' 
running install
running build
running build_py
running install_lib
error: 'setuptools' is not supported. Please use 'pip' instead.
E: pybuild pybuild:353: install: plugin distutils failed with: exit code=1: 
/usr/bin/python3 setup.py install --root 
'/build/macsyfinder-2.0~rc1/debian/macsyfinder' 
dh_auto_install: error: pybuild --install -i python{version} -p 3.9 --dest-dir 
/build/macsyfinder-2.0\~rc1/debian/macsyfinder returned exit code 13
make: *** [debian/rules:7: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


Any help is welcome

  Andreas.


[1] https://salsa.debian.org/med-team/macsyfinder

-- 
http://fam-tille.de

Re: Bug#980005: lumpy-sv: lumpyexpress fails with no args

[Andreas Tille]

Control: tags -1 confirmed
Control: tags -1 help

Hi,

I confirm I can reproduce the issue in a minimal chroot while the
lumpyexpress command prints the help screen as expected.  This smells
like a missing dependency but I do not have any idea which one.  It
seems there is a similar known issue here

   
https://stackoverflow.com/questions/65028261/attributeerror-module-importlib-has-no-attribute-util-ii

but there is no answer here.

Any idea how to fix this?

Kind regards

  Andreas.

On Tue, Jan 12, 2021 at 08:05:26PM +, Ken Yamaguchi wrote:
> Package: lumpy-sv
> Version: 0.3.1+dfsg-4
> Severity: important
> X-Debbugs-Cc: deb...@knowledgesynthesis.com
> 
> Dear Maintainer,
> 
> I built a lumpy-sv Docker image with the attached Dockerfile. Running a 
> container for the image produces the following error:
> 
> Sourcing executables from /etc/lumpy-sv/lumpyexpress.config ...
> 
> Checking for required python modules (/usr/bin/python3)...
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: module 'importlib' has no attribute 'util'
> 
> Thanks,
> Ken
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: unable to detect
> 
> Versions of packages lumpy-sv depends on:
> ii  bamkit0.0.1+git20170413.ccd079d-2
> ii  libbamtools2.5.1  2.5.1+dfsg-7+b1
> ii  libc6 2.31-9
> ii  libgcc-s1 10.2.1-3
> ii  libgzstream0  1.5+dfsg-5
> ii  libhts3   1.11-4
> ii  libstdc++610.2.1-3
> ii  python3   3.9.1-1
> ii  python3-numpy 1:1.19.4-1+b1
> ii  python3-pysam 0.15.4+ds-3+b2
> ii  samblaster0.1.26-1
> ii  samtools  1.11-1
> 
> Versions of packages lumpy-sv recommends:
> pn  sambamba  
> 
> lumpy-sv suggests no packages.
> 
> -- no debconf information

> FROM debian:bullseye-slim
> 
> RUN apt-get update && \
> apt-get -y --no-install-recommends full-upgrade && \
> apt-get -y --no-install-recommends install \
> lumpy-sv \
> && \
> rm -rf /var/lib/apt/lists/*
> 
> RUN useradd -ms /bin/bash lumpy
> 
> USER lumpy
> 
> WORKDIR /home/lumpy
> 
> CMD ["lumpyexpress"]

> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Re: Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')

[Andreas Tille]

On Tue, Dec 08, 2020 at 11:11:27PM +0500, Andrey Rahmatullin wrote:
> https://github.com/nipy/nipy/issues/461

As far as I can see that's included into 0.4.3~rc1.  Yaroslav, would
you mind commenting on this?  It would be great to have some kind of
0.4.3~rc2 to get nipy fixed.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')

[Andreas Tille]

Control: tags -1 pending
Control: tags -1 help

Hi,

I've updated nipy Git[1] to version 0.4.3~rc1 which solves the
originally reported issue.  However, there are some remaining failures
in the build time test:

...
==
ERROR: Failure: TypeError (unsupported operand type(s) for *: 'GreaterThan' and 
'Add')
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest
raise self.exc_val.with_traceback(self.tb)
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 416, in 
loadTestsFromName
module = self.importer.importFromPath(
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in 
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in 
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python3.9/imp.py", line 234, in load_module
return load_source(name, filename, file)
  File "/usr/lib/python3.9/imp.py", line 171, in load_source
module = _load(spec)
  File "", line 711, in _load
  File "", line 680, in _load_unlocked
  File "", line 790, in exec_module
  File "", line 228, in _call_with_frames_removed
  File 
"/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/design.py",
 line 20, in 
from .hrf import glover
  File 
"/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/hrf.py",
 line 123, in 
_gexpr = gamma_expr(5.4, 5.2) - 0.35 * gamma_expr(10.8, 7.35)
  File 
"/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/hrf.py",
 line 106, in gamma_expr
coef * ((T >= 0) * (T+1.0e-14))**(shape-1)
TypeError: unsupported operand type(s) for *: 'GreaterThan' and 'Add'

==
ERROR: Failure: TypeError (unsupported operand type(s) for *: 'GreaterThan' and 
'Add')
--

... (more of this type) ...

==
FAIL: Doctest: nipy.modalities.fmri.utils.convolve_functions
--
Traceback (most recent call last):
  File "/usr/lib/python3.9/doctest.py", line 2204, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for 
nipy.modalities.fmri.utils.convolve_functions
  File 
"/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/utils.py",
 line 494, in convolve_functions

--
File 
"/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/utils.py",
 line 533, in nipy.modalities.fmri.utils.convolve_functions
Failed example:
f1 = (t > 0) * (t < 1)
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python3.9/doctest.py", line 1336, in __run
exec(compile(example.source, filename, "single",
  File "", line 
1, in 
f1 = (t > 0) * (t < 1)
TypeError: unsupported operand type(s) for *: 'StrictGreaterThan' and 
'StrictLessThan'
--
File 
"/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/utils.py",
 line 538, in nipy.modalities.fmri.utils.convolve_functions
Failed example:
tri = convolve_functions(f1, f1, [0, 2], [0, 2], 1.0e-3, name='conv')
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python3.9/doctest.py", line 1336, in __run
exec(compile(example.source, filename, "single",
  File "", line 
1, in 
tri = convolve_functions(f1, f1, [0, 2], [0, 2], 1.0e-3, name='conv')
NameError: name 'f1' is not defined
--
...
--
File 
"/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/utils.py",
 line 549, in nipy.modalities.fmri.utils.convolve_functions
Failed example:
y = ftri(x)
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python3.9/doctest.py", line 1336, in __run
exec(compile(example.source, filename, "single",
  File "", line 
1, in 
y = ftri(x)
NameError: name 'ftri' is not defined
--
File 
"/build/nipy-0.4.3~rc1/.pybuild/cpython3_3.9_nipy/build/nipy/modalities/fmri/utils.py",
 line 552, in nipy.modalities.fmri.utils.convolve_functions
Failed example:
x[np.argmax(y)]
Exception raised:
Traceback (most recent call last):
  File "/usr/lib/python3.9/doctest.py", line 1336, in __run

Python3.9 issue: '"yield from" can't be applied to "Condition"' (Was: Bug#976779: mypy FTBFS with only python 3.9)

[Andreas Tille]

Control: tags -1 pending
Control: tags -1 help

On Mon, Dec 07, 2020 at 11:24:34PM +0200, Adrian Bunk wrote:
> ...
> #set -e; for v in 3.9; do
> set -e; for v in 3.8; do \
>   PATH=$PATH:/<>/debian/mypy/usr/bin/ python$v -m pytest -n 
> auto \
>   -o testpaths=mypy/test -o python_files=test*.py \
>   -k "not StubtestMiscUnit" \
>   -o python_classes= -o python_functions=; \
> done
> bash: line 2: python3.8: command not found

I've dealt with this issue in Git.  Unfortunately there is a test suite
error remaining:


set -e; for v in 3.9; do \
PATH=$PATH:/build/mypy-0.790/debian/mypy/usr/bin/ python$v -m pytest -n 
auto \
-o testpaths=mypy/test -o python_files=test*.py \
-k "not StubtestMiscUnit" \
-o python_classes= -o python_functions=; \
done
= test session starts ==
platform linux -- Python 3.9.1rc1, pytest-4.6.11, py-1.9.0, pluggy-0.13.0
rootdir: /build/mypy-0.790, inifile: pytest.ini, testpaths: mypy/test
plugins: cov-2.8.1, forked-1.3.0, xdist-1.32.0
gw0 I / gw1 I / gw2 I / gw3 I
gw0 [266] / gw1 [266] / gw2 [266] / gw3 [266]

...s. [ 27%]
...F [ 54%]
ssss [ 81%]
...s...s.[100%]
=== FAILURES ===
__ SamplesSuite.test_samples ___
[gw3] linux -- Python 3.9.1 /usr/bin/python3.9
Sample check failed
- Captured stdout call -
test-data/samples/crawl.py:750: error: "yield from" can't be applied to 
"Condition"
test-data/samples/crawl.py:772: error: "yield from" can't be applied to 
"Semaphore"
test-data/samples/crawl.py:778: error: "yield from" can't be applied to 
"Condition"
Found 3 errors in 1 file (checked 1 source file)
=== 1 failed, 258 passed, 7 skipped in 81.97 seconds ===

Any hint would be welcome

 Andreas.


-- 
http://fam-tille.de

Re: Bug#971111: gubbins: FTBFS: pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse error at "'/build/g'": Expected W:(abcd...)

[Andreas Tille]

Control: tags -1 upstream
Control: forewarded -1 https://github.com/sanger-pathogens/gubbins/issues/286

On Fri, Oct 30, 2020 at 02:38:03PM +0500, Andrey Rahmatullin wrote:
> python/gubbins/common.py::parse_and_run() constructs an absolute path for
> the executable and then passes it to pkg_resources.get_distribution(). I
> have no idea what does this code want to achieve, as get_distribution()
> takes requirement specifications, not file paths.

Thanks for checking - I've forwarded the issue upstream.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: Bug#971111: gubbins: FTBFS: pkg_resources.extern.packaging.requirements.InvalidRequirement: Parse error at "'/build/g'": Expected W:(abcd...)

[Andreas Tille]

Control: tags -1 help
Control: forwarded -1 Aidan Delaney 

Hi,

I admit I have no idea what might have caused these pkg_resources
related errors and how to fix these.

Any help would be welcome

  Andreas.


On Sun, Sep 27, 2020 at 08:45:17PM +0200, Lucas Nussbaum wrote:
> Source: gubbins
> Version: 2.4.1-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200926 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > make[3]: Entering directory '/<>'
> > make[3]: Leaving directory '/<>'
> > make[2]: Leaving directory '/<>'
> > cd python && \
> > python3 setup.py test
> > running test
> > WARNING: Testing via this command is deprecated and will be removed in a 
> > future version. Users looking for a generic test entry point independent of 
> > test runner are encouraged to use tox.
> > running egg_info
> > creating gubbins.egg-info
> > writing gubbins.egg-info/PKG-INFO
> > writing dependency_links to gubbins.egg-info/dependency_links.txt
> > writing entry points to gubbins.egg-info/entry_points.txt
> > writing requirements to gubbins.egg-info/requires.txt
> > writing top-level names to gubbins.egg-info/top_level.txt
> > writing manifest file 'gubbins.egg-info/SOURCES.txt'
> > reading manifest file 'gubbins.egg-info/SOURCES.txt'
> > writing manifest file 'gubbins.egg-info/SOURCES.txt'
> > running build_ext
> > /<>/python/gubbins/common.py:538: DeprecationWarning: invalid 
> > escape sequence \d
> >   elif re.match('^\d', vcf_line) is not None:
> > /<>/python/gubbins/common.py:613: DeprecationWarning: invalid 
> > escape sequence \d
> >   search_obj = re.search('misc_feature([\d]+)..([\d]+)$', line)
> > /<>/python/gubbins/common.py:620: DeprecationWarning: invalid 
> > escape sequence \=
> >   search_taxa = re.search('taxa\=\"([^"]+)\"', line)
> > /usr/lib/python3/dist-packages/dendropy/utility/container.py:357: 
> > DeprecationWarning: Using or importing the ABCs from 'collections' instead 
> > of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it 
> > will stop working
> >   class CaseInsensitiveDict(collections.MutableMapping):
> > test_concatenate_fasta_files 
> > (gubbins.tests.test_alignment_python_methods.TestAlignmentMethods) ... ok
> > test_get_sequence_names_from_alignment 
> > (gubbins.tests.test_alignment_python_methods.TestAlignmentMethods) ... ok
> > test_number_of_sequences_in_alignment 
> > (gubbins.tests.test_alignment_python_methods.TestAlignmentMethods) ... ok
> > test_reconvert_fasta_file 
> > (gubbins.tests.test_alignment_python_methods.TestAlignmentMethods) ... ok
> > test_reinsert_gaps_into_fasta_file 
> > (gubbins.tests.test_alignment_python_methods.TestAlignmentMethods) ... ok
> > test_get_recombination_files 
> > (gubbins.tests.test_converging_recombinations.TestConvergingRecombinations) 
> > ... ok
> > test_multiple_files_have_one_match 
> > (gubbins.tests.test_converging_recombinations.TestConvergingRecombinations) 
> > ... ok
> > test_reading_embl_file 
> > (gubbins.tests.test_converging_recombinations.TestConvergingRecombinations) 
> > ... ok
> > test_two_files_are_different 
> > (gubbins.tests.test_converging_recombinations.TestConvergingRecombinations) 
> > ... ok
> > test_two_files_are_same 
> > (gubbins.tests.test_converging_recombinations.TestConvergingRecombinations) 
> > ... ok
> > test_cleanup (gubbins.tests.test_dependencies.TestExternalDependencies) ... 
> > ERROR
> > test_fasttree (gubbins.tests.test_dependencies.TestExternalDependencies) 
> > ... ERROR
> > test_hybrid (gubbins.tests.test_dependencies.TestExternalDependencies) ... 
> > ERROR
> > test_iqtree (gubbins.tests.test_dependencies.TestExternalDependencies) ... 
> > ERROR
> > test_raxml (gubbins.tests.test_dependencies.TestExternalDependencies) ... 
> > ERROR
> > test_rename_final_output 
> > (gubbins.tests.test_dependencies.TestExternalDependencies) ... ERROR
> > test_dont_filter_input_file_with_multiple_duplicate_sequences 
> > (gubbins.tests.test_pre_process_fasta.TestPreProcessFasta) ... ok
> > test_filter_out_alignments_with_too_much_missing_data 
> > (gubbins.tests.test_pre_process_fasta.TestPreProcessFasta) ... ok
> > test_input_file_with_all_duplicate_sequences 
> > (gubbins.tests.test_pre_process_fasta.TestPreProcessFasta) ... ok
> > test_input_file_with_multiple_duplicate_sequences 
> > (gubbins.tests.test_pre_process_fasta.TestPreProcessFasta) ... ok
> > test_input_file_with_no_duplicate_sequences 
> > (gubbins.tests.test_pre_process_fasta.TestPreProcessFasta) ... ok
> > test_input_file_with_one_duplicate_sequences 
> > (gubbins.tests.test_pre_process_fasta.TestPreProcessFasta) ... ok
> > test_filter_out_removed_taxa_from_tree 
> > (gubbins.tests.test_tree_methods.TestTreeMethods) ... ok
> > test_has_tree_been_seen_before 
> > (gubbins.tests.test_tree_methods.TestTreeMethods) ... ok
> > 

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

[Andreas Tille]

On Wed, Aug 19, 2020 at 10:31:55PM +0530, Nilesh Patra wrote:
> 
> 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.

BTW, its a regression compared to Python2.  When calling the

python2 test_mbox.py

everything works.

Kind regards

  Andreas.

-- 
http://fam-tille.de

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

[Andreas Tille]

Hi,

in the teammetrics project I'm trying to parse mailboxes.  This worked
with Python2 but after porting the code to Python3 I get some encoding
troubles.  A specific one seem to be an error in the mailbox module.
Please run the attached script test_mbox which downloads one of the
critical mbox files from aliot-lists.debian.net and calls the also
attached simple Python3 script which ends in:

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 

IMHO it is a bug if those mailboxes can't be read.  Am I missing
something?

Kind regards

   Andreas.

-- 
http://fam-tille.de
#!/bin/sh

wget 
https://alioth-lists.debian.net/pipermail/pkg-java-maintainers/2020-May.txt.gz
gunzip 2020-May.txt.gz

python3 test_mbox.py
#!/usr/bin/python3

import mailbox

mbox_file = mailbox.mbox('2020-May.txt')
if mbox_file.items() != []:
print("OK")

Help with new sphinx version needed (Was: Bug#966983: Most likely fixed in sphinx (2.4.3-5))

[Andreas Tille]

Hi,

I need some help with a sphinx error for python-skbio:

On Tue, Aug 11, 2020 at 10:26:10AM +0200, Sebastiaan Couwenberg wrote:
> On 8/11/20 9:41 AM, Andreas Tille wrote:
> > On Tue, Aug 11, 2020 at 07:17:30AM +0200, Sebastiaan Couwenberg wrote:
> >> A smiliar issue was reported for mapproxy in #966979, which was not an
> >> issue in mapproxy but in sphinx, and fixed in sphinx (2.4.3-5).
> >>
> >> I have not tested the build of this package, but the dh_sphinxdoc issue
> >> is mostl likely fixed with sphinx (2.4.3-5) as well.
> > 
> > Thanks for the hint but I get:
> > 
> > reading sources... [  0%] generated/skbio.alignment.AlignmentStructure
> > /build/python-skbio-0.5.6/.pybuild/cpython3_3.8_skbio/build/skbio/stats/ordination/_principal_coordinate_analysis.py:143:
> >  RuntimeWarning: The result contains negative eigenvalues. Please compare 
> > their magnitude with the magnitude of some of the largest positive 
> > eigenvalues. If the negative ones are smaller, it's probably safe to ignore 
> > them, but if they are large in magnitude, the results won't be useful. See 
> > the Notes section for more details. The smallest eigenvalue is 
> > -0.011492611219229537 and the largest is 16.021722090908206.
> >   warn(
> > /build/python-skbio-0.5.6/.pybuild/cpython3_3.8_skbio/build/skbio/stats/ordination/_ordination_results.py:285:
> >  UserWarning: Tight layout not applied. The left and right margins cannot 
> > be made large enough to accommodate all axes decorations. 
> >   fig.tight_layout()
> > 
> > Extension error:
> > Handler  for event 
> > 'autodoc-process-docstring' threw an exception (exception: module, class, 
> > method, function, traceback, frame, or code object was expected, got 
> > method_descriptor)
> > make[1]: *** [debian/rules:20: override_dh_auto_build-indep] Error 2
> 
> That's not the dh_sphinxdoc error this issue was filed for.
> 
> This failure is most likely caused by an extension not being compatible
> with sphinx 3.2.0.
> 
> sphinx was upgraded in unstable from 2.4.3-5 to 3.2.0-1 two days ago.

Any idea how to fix this?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Thanks (Was: pyarrow: Could NOT find Python3 (missing: Python3_LIBRARIES Python3_INCLUDE_DIRS))

[Andreas Tille]

On Wed, Jul 22, 2020 at 09:43:01AM -0400, Scott Talbert wrote:
> > Any idea why these variables are not sensibly set automatically and what
> > I can do to provide these?
> 
> Try adding python3-all-dev to Build-Depends.

Thanks - that was simple. ;-)

Kind regards, Andreas.

-- 
http://fam-tille.de

pyarrow: Could NOT find Python3 (missing: Python3_LIBRARIES Python3_INCLUDE_DIRS)

[Andreas Tille]

Hi,

I intend to package pyarrow[1] as a precondition for some Debian
Med package.  Unfortunately I get:

...
-- Build output directory: 
/build/python-pyarrow-0.17.1/build/temp.linux-x86_64-3.8/release
CMake Error at 
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
  Could NOT find Python3 (missing: Python3_LIBRARIES Python3_INCLUDE_DIRS
  Development NumPy) (found version "3.8.5")
Call Stack (most recent call first):
  /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 
(_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.16/Modules/FindPython/Support.cmake:2214 
(find_package_handle_standard_args)
  /usr/share/cmake-3.16/Modules/FindPython3.cmake:300 (include)
  cmake_modules/FindPython3Alt.cmake:46 (find_package)
  CMakeLists.txt:196 (find_package)


-- Configuring incomplete, errors occurred!
See also 
"/build/python-pyarrow-0.17.1/build/temp.linux-x86_64-3.8/CMakeFiles/CMakeOutput.log".
error: command 'cmake' failed with exit status 1


Any idea why these variables are not sensibly set automatically and what
I can do to provide these?

Kind regards

  Andreas.


[1] https://salsa.debian.org/med-team/python-pyarrow

-- 
http://fam-tille.de

Help needed to run tests in biocore-ntnu-ncls

[Andreas Tille]

Hi DPMT,

Steffen Möller has prepared biocore-ntnu-ncls[1] in the Debian Med
COVID-19 effort.  I did a review and realised that the build time test
does not work:

...
 ERRORS 
_ ERROR collecting .pybuild/cpython3_3.8_ncls/build/tests/test_ncls.py _
ImportError while importing test module 
'/build/biocore-ntnu-ncls-0.0+git20200225.f9894b0/.pybuild/cpython3_3.8_ncls/build/tests/test_ncls.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
tests/test_ncls.py:2: in 
from ncls import NCLS
../../../ncls/__init__.py:1: in 
from ncls.src.ncls import NCLS64
E   ModuleNotFoundError: No module named 'ncls.src.ncls'
!!! Interrupted: 1 errors during collection 
...

Any hint would be welcome.

Kind regards

 Andreas.


[1] https://salsa.debian.org/med-team/biocore-ntnu-ncls

-- 
http://fam-tille.de

Please transfer package presto from DPMT to med-team

[Andreas Tille]

Hi,

as you can read here

   https://lists.debian.org/debian-med/2020/05/msg00249.html

we would like to maintain presto in Debian Med.  Unfortunately I do not
have permissions to transfer the repository.  Please either give me
permissions or some kind soul could do the transfer to move the repository
smoothly.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Bug#953970: Taking over DPMT (Was: python-boto: autopkgtest failure with Python 3.8 as default)

[Andreas Tille]

On Mon, May 11, 2020 at 10:20:24PM -0400, Noah Meyerhans wrote:
> Control: tags -1 + patch
> 
> > I'll move this package to a cloud-team repository and prepare an upload
> > to unstable on Monday if nobody beats me to it.
> 
> https://salsa.debian.org/cloud-team/python-boto/-/merge_requests/1

Could somebody from the cloud-team please merge and upload?
I'm not a member of this team and can not do anything here.

Thanks a lot

Andreas. 

-- 
http://fam-tille.de

Re: Taking over DPMT (Was: python-boto: autopkgtest failure with Python 3.8 as default)

[Andreas Tille]

Hi,

this bug stays a source of autoremoval warnings noise.  I wonder if
someone might take action on this to move the package to team
maintenance.  Eric suggested the cloud team which is perfectly fine for
me - but can this please made happen.  It should not be that hard once
the repository is moved to inject the NMUs, the patches in this bug log
and upload.

Thank you

  Andreas.

-- 
http://fam-tille.de

Source only upload of validators

[Andreas Tille]

Hi Harley,

thanks for packaging validators as streamlit predepencency for our COVID-19
sprint.  I've done a source-only upload to enable testing migration of this
package.  I've done some automatic updates using routine-update.

Thanks again

 Andreas.

-- 
http://fam-tille.de

pauvre is missing sklearn despite the package is installed

[Andreas Tille]

Hi,

the Debian Med team is busy to package python-pauvre[1] which is part of
our COVID-19 sprint.  I think Etienne Mollier and I have put the packaging
in quite some shape in Git[1].  However, when I try to test the included
CLI interface I get:


$ pauvre -h
Traceback (most recent call last):
  File "/usr/bin/pauvre", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3252, 
in 
def _initialize_master_working_set():
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3235, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3264, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 583, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 900, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'sklearn' distribution was not found 
and is required by pauvre


Since sklearn is installed due to the dependencies I wonder what I might
miss here.  Any hints?

Kind regards

   Andreas.


[1] https://salsa.debian.org/med-team/python-pauvre

-- 
http://fam-tille.de

Re: Please move logbook to Debian Python Modules team (Was: src:logbook: Requires a package outside of Main)

[Andreas Tille]

Hi Sandro,

On Wed, Apr 15, 2020 at 09:41:27AM -0400, Sandro Tosi wrote:
> wait a second: i dont like this idea that DPMT/PAPT are a dumping
> ground you can throw away your packages you dont care about that much
> so that someone will take care of then.

I'm willing to care for team uploads for those packages that are
affecting any package I care for by testing removals.  So if for
instance logbook might have any RC bug I'm willing to care.  I do not
consider DPMT as a dumping ground but I think its better to have a team
controlling those packages than single maintainers.

> we still require a human
> maintainer behind the team name (either they be in Maintainer or
> Uploaders, with the different meaning they have in our teams).

My offer was that Agustin and Iñaki remain human maintainers.
 
> if nobody of the current human maintainers has time for properly
> maintaining logbook, please do orphan it, instead of moving it to DPMT

I know at least Agustin as a responsible person and I'm happily willing
to support him temporarily with team uploads.  IMHO moving a package to
DPMT enhances the general quality of the Python infrastructure since
there are regular automatic packaging enhancements done which finally
lead to a better quality.

Kind regards

  Andreas.
 
> On Wed, Apr 15, 2020 at 9:01 AM Andreas Tille  wrote:
> >
> > Hi Salsa admins,
> >
> > please be so kind to transfer
> >
> >  https://salsa.debian.org/debian/logbook
> >
> > to
> >
> >  https://salsa.debian.org/python-team/modules/logbook
> >
> > Thanks a lot
> >
> >  Andreas.
> >
> > On Wed, Apr 15, 2020 at 11:33:21AM +0200, Agustin Henze wrote:
> > > Hi Andreas, please go ahead and thank you :).
> > >
> > > Cheers,
> > >
> > > On 4/14/20 11:16 AM, Inaki Malerba wrote:
> > > > El 14/4/20 a las 10:43, Andreas Tille escribió:
> > > >> Hi Agustin and Iñaki,
> > > >>
> > > >> I wonder whether you would like to maintain the logbook package in
> > > >> Debian Python Modules team (by setting the mailing list as Maintainer
> > > >> and you two serve as Uploaders.)  This would possibly enhance the 
> > > >> number
> > > >> of people who are watching this package and would simplify doing a team
> > > >> upload for the package.
> > > >>
> > > >> Kind regards
> > > >>
> > > >>   Andreas.
> > > >>
> > > > Hi Andreas,
> > > >
> > > > I'm having troubles to find time to maintain my packages lately, so I
> > > > think that's the best way to go.
> > > >
> > > > I'll wait for Agustin's opinion, but it's ok for me!
> > > >
> > > > Thanks!
> > > >
> > > >
> > > --
> > > TiN
> > >
> > >
> >
> >
> >
> >
> > --
> > http://fam-tille.de
> >
> 
> 
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi
> 

-- 
http://fam-tille.de

Re: Please move logbook to Debian Python Modules team (Was: src:logbook: Requires a package outside of Main)

[Andreas Tille]

Hi Salsa admins,

please be so kind to transfer

 https://salsa.debian.org/debian/logbook

to

 https://salsa.debian.org/python-team/modules/logbook

Thanks a lot

 Andreas.

On Wed, Apr 15, 2020 at 11:33:21AM +0200, Agustin Henze wrote:
> Hi Andreas, please go ahead and thank you :).
> 
> Cheers,
> 
> On 4/14/20 11:16 AM, Inaki Malerba wrote:
> > El 14/4/20 a las 10:43, Andreas Tille escribió:
> >> Hi Agustin and Iñaki,
> >>
> >> I wonder whether you would like to maintain the logbook package in
> >> Debian Python Modules team (by setting the mailing list as Maintainer
> >> and you two serve as Uploaders.)  This would possibly enhance the number
> >> of people who are watching this package and would simplify doing a team
> >> upload for the package.
> >>
> >> Kind regards
> >>
> >>   Andreas.
> >>
> > Hi Andreas,
> >
> > I'm having troubles to find time to maintain my packages lately, so I
> > think that's the best way to go.
> >
> > I'll wait for Agustin's opinion, but it's ok for me!
> >
> > Thanks!
> >
> >
> -- 
> TiN
> 
> 




-- 
http://fam-tille.de

Please move logbook to Debian Python Modules team (Was: src:logbook: Requires a package outside of Main)

[Andreas Tille]

Hi Agustin and Iñaki,

I wonder whether you would like to maintain the logbook package in
Debian Python Modules team (by setting the mailing list as Maintainer
and you two serve as Uploaders.)  This would possibly enhance the number
of people who are watching this package and would simplify doing a team
upload for the package.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Thanks to Olek and Scott and for sure all other contributors (Was: Fwd: [covid] New Contributor for biohackathon)

[Andreas Tille]

Hi,

currently I'm experiencing a situation which I described in several
of my talks[1]:

  For me a team means:

  Waking up in the morning and realising that somebody else has solved
  your problem from yesterday.

Thanks a lot to all who contributed and let me enjoy my sleep at night

  Andreas.

PS: I took the freedom to add more items for Olek, Scott and also for
my wife who is tolerant all the time to let me work for the
sprint even on weekends and holidays.


https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/Covid-19-hackathon


[1] 
https://people.debian.org/~tille/talks/20200208_debian-med-sprint/sprints+mentoring.pdf#page=26
(I've re-used that slide frequently :-)


On Thu, Apr 09, 2020 at 01:45:38AM -0400, Olek Wojnar wrote:
> Hi Scott,
> 
> On Thu, Apr 9, 2020 at 12:43 AM Scott Kitterman 
> wrote:
> 
> >
> > I took care of the request, so they are in the team now and can push the
> > package to the team repo.  Once that's done they can request sponsorship
> > via
> > our usual process (either RFS mail to debian-python@l.d.o or put the name
> > of
> > the package in /topic on #debian-python).  The team is usually pretty
> > responsive about sponsoring.
> >
> 
> Great, thanks! (Harley, please let us know if you have any questions about
> how to do that)
> 
> I will try to stay away from sponsoring it since if I do that, I won't be
> > able
> > to process it through New.
> >
> 
> And we definitely want and appreciate you doing that! :)
> 
> -Olek

-- 
http://fam-tille.de

[Help] Re: Bug#953052: psychopy: python2 dependencies

[Andreas Tille]

Control: tags -1 help

Hi DPMT,

I need to admit I'm currentl overwhelmed with COVID-19 hackathon.
A quick view does not really show any suspicious things to me.
Any help (including team upload / NMU) would be appreciated.

Kind regards

  Andreas.

On Tue, Mar 03, 2020 at 09:34:24PM +0100, Bob wrote:
> Package: psychopy
> Version: 2020.1.1+dfsg-1
> Severity: important
> 
> Dear Maintainer,
> 
> Psychopy seems to have python2 dependencies.
> 
> I do not have any python2 packages installed anymore.
> When installing psychopy 2020.1.1 with apt-get from the official debian repo,
> it pulls in a selection of python2 packages:
> 
> ipython libpython-stdlib libpython2-stdlib libpython2.7-minimal
> libpython2.7-stdlib python
>   python-backports-shutil-get-terminal-size python-chardet python-decorator
> python-enum34 python-ipython
>   python-ipython-genutils python-minimal python-pathlib2 python-pexpect 
> python-
> pickleshare python-pkg-resources
>   python-prompt-toolkit python-ptyprocess python-pygments python-scandir
> python-simplegeneric python-six python-traitlets
>   python-wcwidth python2 python2-minimal python2.7 python2.7-minimal
> 
> When manually installing the deb with gdebi it does not install these python2
> packages.
> 
> Seems to be some kind of packaging error.
> 
> Best,
> Bob
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.5.0-7.1-liquorix-amd64 (SMP w/8 CPU cores; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
> TAINT_OOT_MODULE
> Locale: LANG=en_NL.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages psychopy depends on:
> ii  python33.7.5-3
> ii  python3-configobj  5.0.6-3
> ii  python3-freetype   2.1.0.post1-2
> ii  python3-future 0.18.2-1
> ii  python3-gevent 1.4.0-1+b1
> ii  python3-git3.0.7-1
> ii  python3-gitlab 1:2.0.1-1
> ii  python3-json-tricks3.11.0-2
> ii  python3-lxml   4.5.0-1
> ii  python3-matplotlib 3.1.2-2
> ii  python3-msgpack0.5.6-3
> ii  python3-msgpack-numpy  0.4.4-1
> ii  python3-numpy  1:1.17.4-5
> ii  python3-opengl 3.1.0+dfsg-2
> ii  python3-openpyxl   3.0.3-1
> ii  python3-pandas 0.25.3+dfsg-7
> ii  python3-pil6.2.1-2+b1
> ii  python3-psutil 5.6.7-1
> ii  python3-pygame 1.9.6+dfsg-2
> ii  python3-pyglet 1.4.10-1
> ii  python3-requests   2.22.0-2
> ii  python3-scipy  1.3.3-3
> ii  python3-serial 3.4-5.1
> ii  python3-soundfile  0.10.3+post1-1
> ii  python3-tables 3.6.1-2
> ii  python3-xlrd   1.1.0-5
> ii  python3-yaml   5.3-1
> ii  python3-zmq17.1.2-4
> 
> Versions of packages psychopy recommends:
> pn  ipython   
> ii  libxxf86vm1   1:1.1.4-1+b2
> ii  python3-cryptography  2.8-3
> ii  python3-distro1.4.0-1
> ii  python3-opencv4.2.0+dfsg-5
> ii  python3-pygame1.9.6+dfsg-2
> ii  python3-pyglet1.4.10-1
> ii  python3-pyo   1.0.0-2.1
> ii  python3-questplus 2019.4-2
> ii  python3-wxgtk4.0  4.0.7+dfsg-2
> ii  python3-xlib  0.23-2
> 
> Versions of packages psychopy suggests:
> pn  libavbin0   
> pn  python3-iolabs  
> pn  python3-pyxid   
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

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

[Andreas Tille]

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?

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?

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

[Andreas Tille]

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?

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
> 
> Thanks and regards
> Nilesh

-- 
http://fam-tille.de

Taking over DPMT (Was: python-boto: autopkgtest failure with Python 3.8 as default)

[Andreas Tille]

Hi Emmanuel,

thanks a lot for your patch.  Please note that you crafted it against
GIt which is lagging behind the latest NMU.  I intended to apply it
anyway - but it does not solve

==
ERROR: test_constructor (tests.unit.utils.test_utils.TestPassword)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest.Trbllh/autopkgtest_tmp/tests/unit/utils/test_utils.py", line 
104, in test_constructor
password.set('foo')
  File "/usr/lib/python3/dist-packages/boto/utils.py", line 787, in set
self.str = self.hashfunc(value).hexdigest()
  File 
"/tmp/autopkgtest.Trbllh/autopkgtest_tmp/tests/unit/utils/test_utils.py", line 
101, in 
hmac_hashfunc = lambda msg: hmac.new(b'mysecretkey', msg)
  File "/usr/lib/python3.8/hmac.py", line 153, in new
return HMAC(key, msg, digestmod)
  File "/usr/lib/python3.8/hmac.py", line 51, in __init__
raise TypeError("Missing required parameter 'digestmod'.")
TypeError: Missing required parameter 'digestmod'.

==
ERROR: test_hmac (tests.unit.utils.test_utils.TestPassword)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest.Trbllh/autopkgtest_tmp/tests/unit/utils/test_utils.py", line 
93, in test_hmac
self.clstest(HMACPassword)
  File 
"/tmp/autopkgtest.Trbllh/autopkgtest_tmp/tests/unit/utils/test_utils.py", line 
61, in clstest
self.assertNotEquals(password, 'foo')
  File "/usr/lib/python3.8/unittest/case.py", line 1410, in deprecated_func
return original_func(*args, **kwargs)
  File "/usr/lib/python3.8/unittest/case.py", line 918, in assertNotEqual
if not first != second:
  File "/usr/lib/python3/dist-packages/boto/utils.py", line 797, in __eq__
return str(self.hashfunc(other).hexdigest()) == str(self.str)
  File 
"/tmp/autopkgtest.Trbllh/autopkgtest_tmp/tests/unit/utils/test_utils.py", line 
88, in hmac_hashfunc
return hmac.new(b'mysecretkey', msg)
  File "/usr/lib/python3.8/hmac.py", line 153, in new
return HMAC(key, msg, digestmod)
  File "/usr/lib/python3.8/hmac.py", line 51, in __init__
raise TypeError("Missing required parameter 'digestmod'.")
TypeError: Missing required parameter 'digestmod'.

--
Ran 1730 tests in 5.640s

FAILED (SKIP=6, errors=3)


On Tue, Mar 24, 2020 at 11:10:28AM -0300, eamanu wrote:
> I prepare a non-maintainer upload patch that I attach.
> 
> Please consider apply it.
> 
> Also I make a MR [0]
> 
> [0] https://salsa.debian.org/eevans/python-boto/-/merge_requests/1


I wonder whether we should take over python-boto into DPMT maintenance
which would enable commits to Git way more easily. 

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: Python help needed for test suite in multiqc

[Andreas Tille]

Hi Andrey,

On Thu, Mar 26, 2020 at 12:34:11AM +0500, Andrey Rahmatullin wrote:
> http://bugs.debian.org/954640

Thanks a lot.  Multiqc builds with humanfriendly from Git.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Python help needed for test suite in multiqc

[Andreas Tille]

Hi Python folks,

the Debian Med team intends to package multiqc[1].  When running the build
time tests I get:


...
   debian/rules override_dh_auto_test
make[1]: Verzeichnis „/build/multiqc-1.8+dfsg“ wird betreten
cp -a multiqc*.egg-info 
/build/multiqc-1.8+dfsg/.pybuild/cpython3_3.8_multiqc/build
PYTHONPATH=/build/multiqc-1.8+dfsg/.pybuild/cpython3_3.8_multiqc/build 
dh_auto_test
I: pybuild base:217: cd 
/build/multiqc-1.8+dfsg/.pybuild/cpython3_3.7_multiqc/build; python3.7 -m 
unittest discover -v 
multiqc (unittest.loader._FailedTest) ... ERROR

==
ERROR: multiqc (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: multiqc
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/loader.py", line 470, in _find_test_path
package = self._get_module_from_name(name)
  File "/usr/lib/python3.7/unittest/loader.py", line 377, in 
_get_module_from_name
__import__(name)
  File 
"/build/multiqc-1.8+dfsg/.pybuild/cpython3_3.7_multiqc/build/multiqc/__init__.py",
 line 16, in 
from .multiqc import run
  File 
"/build/multiqc-1.8+dfsg/.pybuild/cpython3_3.7_multiqc/build/multiqc/multiqc.py",
 line 38, in 
from .utils import report, plugin_hooks, megaqc, util_functions, 
lint_helpers, config, log
  File 
"/build/multiqc-1.8+dfsg/.pybuild/cpython3_3.7_multiqc/build/multiqc/utils/log.py",
 line 7, in 
import coloredlogs
  File "/usr/lib/python3/dist-packages/coloredlogs/__init__.py", line 192, in 

from humanfriendly.terminal import ANSI_COLOR_CODES, ansi_wrap, 
terminal_supports_colors
ModuleNotFoundError: No module named 'humanfriendly.terminal'


--
Ran 1 test in 0.000s



I'm wondering what else I need to do besides adding
python3-humanfriendly to Build-Depends to let this test pass.

Kind regards

Andreas.


[1] https://salsa.debian.org/med-team/multiqc

-- 
http://fam-tille.de

Re: cannot allocate memory in static TLS block

[Andreas Tille]

Hi Faidon,

On Tue, Mar 17, 2020 at 01:29:59PM +0200, Faidon Liambotis wrote:
> Hi Andreas,
> 
> Thanks for reaching out. It sounds like this is already reported as
> #951704 (Cc'ed now).

OK.

> I'll need to give this a closer look, but I hope I
> can have an update within the next couple of weeks. Does this work?

Well, drmaa is certainly not the most important package inside Debian so
I see no reason to push you.  But it would be great to have all those
Python3 issues from the table sooner or later since it generated noise
for the most active Python 2->3 migrators.  Just take the time you need.

See you

  Andreas. 

-- 
http://fam-tille.de

Re: cannot allocate memory in static TLS block

[Andreas Tille]

Hi Faidon,

could you imagine to build jemalloc with --disable-initial-exec-tls
as Sergio suggests below to fix the issue in drmaa (and possibly other
packages)?

Should I open a separate bug report against jemalloc to request this?

Kind regards

  Andreas.

On Sat, Mar 14, 2020 at 05:18:49PM -0400, Sergio Durigan Junior wrote:
> > $ python3
> > Python 3.7.6 (default, Jan 19 2020, 22:34:52) 
> > [GCC 9.2.1 20200117] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
>  import drmaa
> > Traceback (most recent call last):
> >   File "", line 1, in 
> >   File 
> > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/__init__.py",
> >  line 65, in 
> > from .session import JobInfo, JobTemplate, Session
> >   File 
> > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/session.py",
> >  line 39, in 
> > from drmaa.helpers import (adapt_rusage, Attribute, 
> > attribute_names_iterator,
> >   File 
> > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/helpers.py",
> >  line 36, in 
> > from drmaa.wrappers import (drmaa_attr_names_t, drmaa_attr_values_t,
> >   File 
> > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/wrappers.py",
> >  line 58, in 
> > _lib = CDLL(libpath, mode=RTLD_GLOBAL)
> >   File "/usr/lib/python3.7/ctypes/__init__.py", line 364, in __init__
> > self._handle = _dlopen(self._name, mode)
> > OSError: /usr/lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate memory 
> > in static TLS block
> 
> This is an issue with jemalloc's handling of the TLS model when being
> dlopened..  See:
> 
>   https://github.com/jemalloc/jemalloc/issues/1237
> 
> The recommended way to build a libjemalloc that is suitable for being
> dlopened is to use '--disable-initial-exec-tls' when building it.  Take
> a look at the INSTALL.md file, and look for this option:
> 
>   https://github.com/jemalloc/jemalloc/blob/dev/INSTALL.md
> 
> There is a way to workaround this bug by doing an LD_PRELOAD of
> libjemalloc when invoking python, but this will only mask the problem
> and we can't expect users to do/know this.
> 
> The way I see it, you can try to convince jemalloc's maintainer to
> enable that flag.
> 
> BTW, the reason 'find_library' can't find drmaa's library is because the
> .so is being installed in a non-standard directory.  I don't know why
> the package was made like this, though.
> 
> Thanks,
> 
> -- 
> Sergio
> GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
> Please send encrypted e-mail if possible
> http://sergiodj.net/



-- 
http://fam-tille.de

cannot allocate memory in static TLS block (Was: Bug#953832: drmaa: autopkgtest failure: RuntimeError: Could not find drmaa library)

[Andreas Tille]

Control: tags -1 help
Control: retitle -1 cannot allocate memory in static TLS block

Hi Paul,

On Fri, Mar 13, 2020 at 11:09:31PM +0100, Paul Gevers wrote:
> 
> raise RuntimeError(('Could not find drmaa library.  Please specify
> its ' +
> RuntimeError: Could not find drmaa library.  Please specify its full
> path using the environment variable DRMAA_LIBRARY_PATH

I've fixed this in Git.  Unfortunately I get a new issue when importing
drmaa

$ python3
Python 3.7.6 (default, Jan 19 2020, 22:34:52) 
[GCC 9.2.1 20200117] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import drmaa
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/__init__.py", 
line 65, in 
from .session import JobInfo, JobTemplate, Session
  File 
"/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/session.py", 
line 39, in 
from drmaa.helpers import (adapt_rusage, Attribute, 
attribute_names_iterator,
  File 
"/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/helpers.py", 
line 36, in 
from drmaa.wrappers import (drmaa_attr_names_t, drmaa_attr_values_t,
  File 
"/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/wrappers.py", 
line 58, in 
_lib = CDLL(libpath, mode=RTLD_GLOBAL)
  File "/usr/lib/python3.7/ctypes/__init__.py", line 364, in __init__
self._handle = _dlopen(self._name, mode)
OSError: /usr/lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate memory in 
static TLS block


Any help would be welcome

 Andreas.

-- 
http://fam-tille.de

Re: Help for issues with lazyarray needed

[Andreas Tille]

On Thu, Mar 05, 2020 at 02:27:13PM +0530, Nilesh Patra wrote:
> 
> 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'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?

No need to work on this any more.  Upstream pointed me to Gitlab where
development is continued.  Status in Git is fine now.  Thanks a lot for
your attempt to help

 Andreas.

-- 
http://fam-tille.de

Help for issues with lazyarray needed

[Andreas Tille]

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

Help needed to make pkgconfig finding just built lib

[Andreas Tille]

Control: tags -1 help

Hi,

I'm trying to drop biosig4c++ with Python3 only in Git[1].
Unfortunately I get:


make[3]: Entering directory '/build/biosig4c++-1.9.5/python'
python3 setup.py build
Traceback (most recent call last):
  File "setup.py", line 11, in 
PKG=pkgconfig.parse('libbiosig')
  File "/usr/lib/python3/dist-packages/pkgconfig/pkgconfig.py", line 248, in 
parse
_raise_if_not_exists(package)
  File "/usr/lib/python3/dist-packages/pkgconfig/pkgconfig.py", line 103, in 
_raise_if_not_exists
raise PackageNotFoundError(package)
pkgconfig.pkgconfig.PackageNotFoundError: libbiosig not found
make[3]: [Makefile:14: build] Error 1 (ignored)
make[3]: Leaving directory '/build/biosig4c++-1.9.5/python'


libbiosig.so is actually build inside the pbuilder chroot:

root:/build/biosig4c++-1.9.5# find . -name "*.so"
./libgdf.so
./libphysicalunits.so
./libbiosig.so
./debian/tmp/usr/lib/x86_64-linux-gnu/libbiosig.so
./debian/tmp/usr/lib/x86_64-linux-gnu/libbiosig2.so


Any idea how to convince pkgconfig that the library is there?

Kind regards

   Andreas.

[1] https://salsa.debian.org/neurodebian-team/biosig4c


-- 
http://fam-tille.de

Re: Bug#950063: influxdb-python FTBFS with pandas 0.25.3

[Andreas Tille]

On Thu, Feb 20, 2020 at 10:31:41AM -0500, Alexandre Viau wrote:
> On Thu, Feb 20, 2020 at 4:15 AM Andreas Tille  wrote:
> > Regarding your wish to remove you from Maintainers: I did not intend to
> > take over the package from you personally.  I rather wanted to do
> > something like:
> >
> >   Maintainer: Debian Python Modules Team 
> > 
> >   Uploaders: Alexandre Viau 
> >
> > and you become a member of DPMT to maintain the package inside the team.
> > If you are short in time I could probably do a team upload to fix the
> > current issues, thought.
> 
> Okay that works.

Since I do not have sufficient permissions I asked for it in

   https://salsa.debian.org/salsa/support/issues/197

I'll keep you updated who the migration proceeds.

Kind regards

  Andreas.

> You may do the upload right now and I'll make sure that I am a member
> on salsa DPMT (I used to be on Alioth) before my next upload.
> 
> Thank you for caring about this package!
> 
> Cheers,
> 
> --
> Alexandre Viau
> av...@debian.org
> 

-- 
http://fam-tille.de

Re: influxdb-python FTBFS with pandas 0.25.3

[Andreas Tille]

Hi Alexandre,

On Wed, Feb 19, 2020 at 09:51:43AM -0500, Alexandre Viau wrote:
> Feel free to move influxdb-python to DPMT.

Thanks.
 
> However, if you do, please remove me from the maintainers and
> delete/move the existing salsa project.

For sure I can transfer the project on Salsa.

Regarding your wish to remove you from Maintainers: I did not intend to
take over the package from you personally.  I rather wanted to do
something like:

  Maintainer: Debian Python Modules Team 

  Uploaders: Alexandre Viau 

and you become a member of DPMT to maintain the package inside the team.
If you are short in time I could probably do a team upload to fix the
current issues, thought.

Kind regards

  Andreas.

-- 
http://fam-tille.de