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

2021-03-03 Thread 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

2021-01-25 Thread 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

2021-01-25 Thread 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."

2021-01-14 Thread 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

2021-01-12 Thread 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')

2020-12-08 Thread 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')

2020-12-08 Thread 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)

2020-12-08 Thread 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...)

2020-10-30 Thread 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...)

2020-10-30 Thread 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

2020-08-19 Thread 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

2020-08-19 Thread 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))

2020-08-11 Thread 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))

2020-07-22 Thread 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)

2020-07-22 Thread 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

2020-06-13 Thread 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

2020-05-29 Thread 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)

2020-05-16 Thread 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)

2020-05-10 Thread 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

2020-04-28 Thread 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

2020-04-27 Thread 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)

2020-04-15 Thread 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)

2020-04-15 Thread 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)

2020-04-14 Thread 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)

2020-04-09 Thread 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

2020-04-08 Thread 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

2020-04-05 Thread 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

2020-04-05 Thread 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)

2020-03-30 Thread 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

2020-03-26 Thread 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

2020-03-25 Thread 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

2020-03-17 Thread 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

2020-03-15 Thread 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)

2020-03-14 Thread 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

2020-03-05 Thread 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

2020-03-05 Thread 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

2020-02-27 Thread 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

2020-02-20 Thread 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

2020-02-20 Thread 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



Re: influxdb-python FTBFS with pandas 0.25.3

2020-02-05 Thread Andreas Tille
Hi Alexandre,

since a Debian Med package is affected as reverse-depends of
influxdb-python I had a look.  Unfortunately this Python package
is not maintained by the Python modules team.  I would consider
it a good idea to move this package into team maintenance.  I'd
volunteer to do that move but wanted to ask for permission first.

If you argee I would upgrade the package to 5.2.3 despite I
realised that there are open issues

https://github.com/influxdata/influxdb-python/issues/738
and
https://github.com/influxdata/influxdb-python/issues/696

Could you please comment on these?

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Bug#937177: obitools: Python2 removal in sid/bullseye

2020-01-12 Thread Andreas Tille
Control: tags -1 help


Hi Scott,

On Sun, Jan 12, 2020 at 07:27:59AM -0500, Scott Kitterman wrote:
> On Fri, 30 Aug 2019 07:28:59 + Matthias Klose  wrote:
> ...
> 
> I don't see any evidence of upstream progress on converting to python3.

This seems to be correct.

> This 
> package is blocking several others.  Would it be best to remove it?  It can 
> always be re-introduced if a python3 port appears.

Since some time I've pushed a 2to3 based port to Git.  I've now fixed
some issues of this and I wonder whether we might give it a try to do
the port inside Debian.  For the moment I'm running into the following
issue:

   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:217: cd 
/build/obitools-1.2.13+dfsg/.pybuild/cpython3_3.7_obitools/build; python3.7 -m 
unittest discover -v 
obitools (unittest.loader._FailedTest) ... ERROR

==
ERROR: obitools (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: obitools
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/obitools-1.2.13+dfsg/.pybuild/cpython3_3.7_obitools/build/obitools/__init__.py",
 line 23, in 
from _obitools import BioSequence,NucSequence,AASequence, \
ModuleNotFoundError: No module named '_obitools'


--
Ran 1 test in 0.000s

FAILED (errors=1)
E: pybuild pybuild:341: test: plugin distutils failed with: exit code=1: cd 
/build/obitools-1.2.13+dfsg/.pybuild/cpython3_3.7_obitools/build; python3.7 -m 
unittest discover -v 
dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13
make: *** [debian/rules:15: build] Error 255
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
I: copying local configuration
E: Failed autobuilding of package
I: user script /var/cache/pbuilder/build/cow.1543005/tmp/hooks/C99_failed_build 
starting
Installing convenience apps: mc less bash-completion 
root@energija:/# cd build/obitools-1.2.13+dfsg/
root@energija:/build/obitools-1.2.13+dfsg# find . -name "*.so"
./.pybuild/cpython3_3.7_obitools/build/obitools/options/_options.cpython-37m-x86_64-linux-gnu.so

 =
./.pybuild/cpython3_3.7_obitools/build/obitools/options/_bioseqfilter.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/profile/_profile.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/utils/_utils.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/_obitools.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/tools/_solexapairend.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/fasta/_fasta.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_upperbond.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_rassemble.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_freeendgapfm.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_nwsdnabyprot.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_assemble.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_freeendgap.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_qsrassemble.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_gprofilenws.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_dynamic.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_nws.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_lcs.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_qsassemble.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_profilenws.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/align/_codonnws.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/format/_format.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/format/genericparser/_genericparser.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/fastq/_fastq.cpython-37m-x86_64-linux-gnu.so
./.pybuild/cpython3_3.7_obitools/build/obitools/word/_binary.cpython-37m-x86_64-linux-gnu.so

Re: python-datrie: FTBFS with recent hypothesis version

2020-01-09 Thread Andreas Tille
On Thu, Jan 09, 2020 at 07:45:09PM +0100, Michael Crusoe wrote:
> https://patches.ubuntu.com/p/python-datrie/python-datrie_0.7.1-3ubuntu1.patch
> 
> I can confirm that this patch fixes the build and I've opened a merge
> request at
> https://salsa.debian.org/python-team/modules/python-datrie/merge_requests/1
> 
> Can someone with more permissions than I have accept that merge request and
> upload the new package?

Uploaded.  Thanks for the merge request (which was accepted by Steffen)

   Andreas.

-- 
http://fam-tille.de



Re: Removing python-xmlbuilder from Debian

2019-12-25 Thread Andreas Tille
On Wed, Dec 25, 2019 at 12:26:59PM +0100, Thomas Goirand wrote:
> Currently, the only reverse dependency of this package is
> python-pbcommand.

Not in unstable.

> So we have 2 choices:
> 
> 1/ Fix python-xmlbuilder
> 2/ Get python-xmlbuilder and python-pbcommand removed from Debian.
> 
> Your thoughts?

3/ Remove just python-xmlbuilder.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: kmer: Python2 removal in sid/bullseye

2019-12-19 Thread Andreas Tille
Hi Scott,

thanks a lot for your hint.

On Thu, Dec 19, 2019 at 01:34:08PM -0500, Scott Talbert wrote:
> 
> The 'file' class doesn't exist anymore in Python 3.  You'll have to rewrite
> myfile to not use it.

OK, I simply went with

...
@@ -608,6 +608,11 @@ Last-Update: Thu, 19 Dec 2019 10:43:09 +0100
  
  # from __future__ import generators  # Necessary before Python 2.3
  
+-class myfile(file):
++class myfile():
+ "A temporary anonymous file"
+ def __init__(self):
+ filename = tempfile.mktemp()
 @@ -27,8 +27,8 @@ class ListLikeFileIter:
  self._fileIter = iter(self._fileptr.readline,"")
  def __del__(self):
...


This brings me to the next error where a Module written in C is not
found:



python3 /usr/bin/../lib/atac/bin/AtacDriver.py 
/tmp/atac-test.XqdEPl/results/work/LeprvsTuber.matches.extended

Traceback (most recent call last):
  File "/usr/bin/../lib/atac/bin/AtacDriver.py", line 26, in 
import localAlignerInterface
ModuleNotFoundError: No module named 'localAlignerInterface'
PYTHONPATH=/usr/bin/../lib/atac/lib
Chainer failed.



The file /usr/lib/atac/lib/localAlignerInterfacemodule.so exists
but it seems the Python3 script can't load it.


Kind regards

Andreas.

-- 
http://fam-tille.de



Re: kmer: Python2 removal in sid/bullseye

2019-12-19 Thread Andreas Tille
Control: tags -1 help

Hi,

I tried to convert kmer to Python3 in Git[1].  Unfortunately I'm stumbling
upon an issue in the test suite:

...
python3 /usr/bin/../lib/atac/bin/AtacDriver.py 
/tmp/atac-test.doxZJ4/results/work/LeprvsTuber.matches.extended

Traceback (most recent call last):
  File "/usr/bin/../lib/atac/bin/AtacDriver.py", line 18, in 
import MyFile
  File "/usr/lib/atac/lib/MyFile.py", line 6, in 
class myfile(file):
NameError: name 'file' is not defined
PYTHONPATH=/usr/bin/../lib/atac/lib
Chainer failed.


Any idea what's wrong here?

Kind regards

Andreas.


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

-- 
http://fam-tille.de



Re: Help needed (Was: Bug#943083: libncl: Python2 removal in sid/bullseye)

2019-12-16 Thread Andreas Tille
On Mon, Dec 16, 2019 at 01:31:02PM +0500, Andrey Rahmatullin wrote:
> On Mon, Dec 16, 2019 at 09:17:50AM +0100, Andreas Tille wrote:
> > inputParentPath = lineIter.next().strip()
> > AttributeError: '_io.StringIO' object has no attribute 'next'
> This should be changed to next(lineIter).strip(), 2to3 for some reason
> missed it.

I'm afraid 2to3 skipped this very file.  I retried manually:

$ 2to3 -w roundTripNCLTest.py 
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: Can't parse roundTripNCLTest.py: ParseError: bad input: 
type=22, value='=', context=('', (41, 93))
RefactoringTool: No files need to be modified.
RefactoringTool: There was 1 error:
RefactoringTool: Can't parse roundTripNCLTest.py: ParseError: bad input: 
type=22, value='=', context=('', (41, 93))


I also had to replace a call to file() by open() - now it works.

Is this by any chance a bug in 2to3?

Kind regards

Andreas.

-- 
http://fam-tille.de



Help needed (Was: Bug#943083: libncl: Python2 removal in sid/bullseye)

2019-12-16 Thread Andreas Tille
Control: tags -1 help

Hi,

I tried 2to3 on the Python files belonging to libncl test suite.
Upstream is using a somehow complex method to read config files.
Before trying a complete rewrite I wonder whether someone might
be able to make some sense out of:

...
make  check-local
make[4]: Entering directory 
'/build/libncl-2.1.21+git20190531.feceb81/example/ncltest'
/usr/bin/python3 ../../test/roundTripNCLTest.py ../../example/ncltest/ncltest 
../../test/OldValidIn ../../test/OldValidOut
Traceback (most recent call last):
  File "../../test/roundTripNCLTest.py", line 243, in 
inputParentPath = lineIter.next().strip()
AttributeError: '_io.StringIO' object has no attribute 'next'
make[4]: *** [Makefile:626: check-local] Error 1
...


Kind regards

  Andreas.

-- 
http://fam-tille.de



Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye)

2019-12-13 Thread Andreas Tille
On Fri, Dec 13, 2019 at 10:49:45PM +0500, Andrey Rahmatullin wrote:
> > I think at least this is solved now:
> > 
> >
> > https://salsa.debian.org/med-team/pdb2pqr/commit/1f4ee901456641140ef18ca8e91e4701e1175410
> 
> Nice catch, "env.Append(LIBS=[python_lib])" where "python_lib = 'python' +
> gcv('VERSION')" is definitely the cause.

Yes.  I've now a state where the package builds and installs.  However,
just calling pdb2pqr fails with

i$ pdb2pqr
Traceback (most recent call last):
  File "/usr/bin/pdb2pqr", line 52, in 
from main import mainCommand
  File "/usr/share/pdb2pqr/main.py", line 77, in 
import extensions
  File "/usr/share/pdb2pqr/extensions/__init__.py", line 56, in 
extDict[extName] = __import__(extName,globals(),locals(),[], -1)
ValueError: level must be >= 0


So I tried:

--- a/extensions/__init__.py
+++ b/extensions/__init__.py
@@ -53,7 +53,7 @@ _extList = [name for _, name, _ in 
pkgutil.iter_modules(__path__)]
 extDict = {}
 
 for extName in _extList:
-extDict[extName] = __import__(extName,globals(),locals(),[], -1)
+extDict[extName] = __import__(extName,globals(),locals(),[], 0)^M
 
 def setupExtensionsOptions(parser):
 """


which leads to:

$ pdb2pqr
Traceback (most recent call last):
  File "/usr/bin/pdb2pqr", line 52, in 
from main import mainCommand
  File "/usr/share/pdb2pqr/main.py", line 77, in 
import extensions
  File "/usr/share/pdb2pqr/extensions/__init__.py", line 57, in 
extDict[extName] = __import__(extName,globals(),locals(),[], 0)
ModuleNotFoundError: No module named 'chi'


I admit I have no clue whether my change was valid nor what to try next.

Kind regards

   Andreas.

-- 
http://fam-tille.de



Re: Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

2019-12-13 Thread Andreas Tille
On Fri, Dec 13, 2019 at 03:16:32PM +0100, Andreas Tille wrote:
> 
> ...
> g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so 
> -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os -L/usr/lib 
> -lpython3.7m -lpython3.7
> /usr/bin/ld: cannot find -lpython3.7
> collect2: error: ld returned 1 exit status
> ...
> 
> AAArgh, now we just need to get rid of the unwanted stuff.  Any scons
> expert around?

I think at least this is solved now:

   
https://salsa.debian.org/med-team/pdb2pqr/commit/1f4ee901456641140ef18ca8e91e4701e1175410

I might come back with other issues

 Andreas.

-- 
http://fam-tille.de



Re: Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

2019-12-13 Thread Andreas Tille
On Fri, Dec 13, 2019 at 05:46:42PM +0500, Andrey Rahmatullin wrote:
> > 
> > Thanks for that additional hint.  I can confirm that I checked whether
> > pkgconfig can be used before I was asking here.  But we seem to agree
> > that this is not the case.  I admit I have no real clue how to convince
> > scons to link to the correct library name. :-(
> I have no idea either. It seems that it just uses the scons compilation
> code by creating an env.LoadableModule.

I tried a patch to use pkg-config which **partly** works:

...
g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so 
-Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os -L/usr/lib 
-lpython3.7m -lpython3.7
/usr/bin/ld: cannot find -lpython3.7
collect2: error: ld returned 1 exit status
...

AAArgh, now we just need to get rid of the unwanted stuff.  Any scons
expert around?

Kind regards, Andreas.


[1] 
https://salsa.debian.org/med-team/pdb2pqr/commit/dbee7b96cdb8cad7b60e8c6acffea068664ebe7c

-- 
http://fam-tille.de



Re: Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

2019-12-13 Thread Andreas Tille
Hi Andrey,

On Fri, Dec 13, 2019 at 05:18:45PM +0500, Andrey Rahmatullin wrote:
> On Fri, Dec 13, 2019 at 09:49:47AM +0100, Andreas Tille wrote:
> > g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so 
> > -Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os -L/usr/lib 
> > -lpython3.7
> > /usr/bin/ld: cannot find -lpython3.7
> Actually, it's a different problem, sorry.
> There is no -lpython3.7, only -lpython3.7m. If the build system used
> pkgconfig it would know that. I guess the library name is hardcoded
> instead? I see that it got -I/usr/include/python3.7m from somewhere, so
> it's not completely broken.

Thanks for that additional hint.  I can confirm that I checked whether
pkgconfig can be used before I was asking here.  But we seem to agree
that this is not the case.  I admit I have no real clue how to convince
scons to link to the correct library name. :-(

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

2019-12-13 Thread Andreas Tille
On Fri, Dec 13, 2019 at 03:23:19PM +0500, Andrey Rahmatullin wrote:
> On Fri, Dec 13, 2019 at 09:49:47AM +0100, Andreas Tille wrote:
> > So how can I enable proper linking to -lpython3.7 which is obviously not
> > in the library search path (but package libpython3.7 is definitely
> > installed in the pbuilder chroot).
> To link to a library you need to install its -dev package (this is not just
> for libpython*).

Thus python3-dev is in the Build-Depends, yes.  The library is just not found
by the linker.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

2019-12-13 Thread Andreas Tille
Hi Scott,

On Thu, Dec 12, 2019 at 04:34:09PM -0500, Scott Talbert wrote:
> On Thu, 12 Dec 2019, Andreas Tille wrote:
> > mkdir -p /build/pdb2pqr-2.1.1+dfsg/debian/tmp/usr/share/pdb2pqr
> > scons \
> >URL="http://localhost/pdb2pqr/; \
> >PREFIX="/build/pdb2pqr-2.1.1+dfsg/debian/tmp/usr/share/pdb2pqr"
> > scons: Reading SConscript files ...
> > not using opal
> > scons: done reading SConscript files.
> > scons: Building targets ...
> > CopySubAction("pdb2pqr.py", "pdb2pqr.py.in")
> > scons: *** [pdb2pqr.py] Can't write target file pdb2pqr.py
> > scons: building terminated because of errors.
> 
> I think you need to change the other open() call in that function to write
> in text mode also.

Thanks a lot for your patience and your always helpful hints.  After
changing this and some other issues with the C++ code I was (hopefully)
able to solve myself[1] I'm facing the next stumbling stone which is
most probably easy to solve for someone more experienced than me:


...
scons \
URL="http://localhost/pdb2pqr/; \
PREFIX="/usr/share/pdb2pqr"
scons: Reading SConscript files ...
not using opal 
scons: done reading SConscript files.
scons: Building targets ...
CopySubAction("pdb2pqr.py", "pdb2pqr.py.in")
Chmod("pdb2pqr.py", 0755)
CopySubAction("apbs_cgi.cgi", "apbs_cgi.py")
Chmod("apbs_cgi.cgi", 0755)
CopySubAction("visualize.cgi", "visualize.py")
Chmod("visualize.cgi", 0755)
CopySubAction("querystatus.cgi", "querystatus.py")
Chmod("querystatus.cgi", 0755)
CopySubAction("src/aconf.py", "src/aconf.py.in")
CopySubAction("html/server.html", "html/server.html.in")
Copy("pdb2pqr.cgi", "pdb2pqr.py")
g++ -o pdb2pka/substruct/Algorithms.os -c -g -fPIC -I/usr/include/python3.7m 
-I/usr/lib/python3/dist-packages/numpy/core/include 
pdb2pka/substruct/Algorithms.cpp
In file included from /usr/include/python3.7m/numpy/ndarraytypes.h:1830,
 from /usr/include/python3.7m/numpy/ndarrayobject.h:12,
 from /usr/include/python3.7m/numpy/arrayobject.h:4,
 from pdb2pka/substruct/Algorithms.cpp:43:
/usr/include/python3.7m/numpy/npy_1_7_deprecated_api.h:17:2: warning: #warning 
"Using deprecated NumPy API, disable it with " "#define NPY_NO_DEPRECATED_API 
NPY_1_7_API_VERSION" [-Wcpp]
   17 | #warning "Using deprecated NumPy API, disable it with " \
  |  ^~~
pdb2pka/substruct/Algorithms.cpp: In function 'PyObject* initAlgorithms()':
pdb2pka/substruct/Algorithms.cpp:333:1: warning: control reaches end of 
non-void function [-Wreturn-type]
  333 | };
  | ^
g++ -o pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so 
-Wl,-z,relro -Wl,-z,now -shared pdb2pka/substruct/Algorithms.os -L/usr/lib 
-lpython3.7
/usr/bin/ld: cannot find -lpython3.7
collect2: error: ld returned 1 exit status
scons: *** [pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so] Error 
1
scons: building terminated because of errors.

TARGETS: ['pdb2pqr.py', 'apbs_cgi.cgi', 'visualize.cgi', 'querystatus.cgi', 
'src/aconf.py', 'html/server.html', 'pdb2pqr.cgi', 
'pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so', 
'pdb2pka/_pMC_mult.cpython-37m-x86_64-linux-gnu.so']


Configuration Parameters


Version: 2.1.1
Install directory: /usr/share/pdb2pqr/
pdb2pka and ligand support: True
Path to the website directory: http://localhost/pdb2pqr/
PDB2PQR jobs run via the web interface will be forked on the server.

The preferred way to configure the build is by editing the file build_config.py

Run scons with the python3 that you intend to use with pdb2pqr.
For example: "scons" will setup pdb2pqr to be run with Debian default Python3 
interpreter

Run "scons install" to install pdb2pqr in /usr/share/pdb2pqr/

Run "scons basic-test" for a basic functionality test
Run "scons advanced-test" for a single test of ligand and PROPKA support. 
Requires numpy and PDB2PKA support compiled.
Run "scons complete-test" for a complete test of all functionality EXCEPT 
PDB2PKA. Requires numpy and PDB2PKA support compiled.
Run "scons pdb2pka-test" for a test of PDB2PKA functionality.
Requires numpy, PDB2PKA support compiled AND the APBS python3 libraries 
compiled and installed in the pdb2pka directory.

To setup a web service create a symbolic link to /usr/share/pdb2pqr/ that 
enables you to view http://localhost/pdb2pqr/ after running "scons install"

Run "scons msvs" to build Visual Studio projects for the Algorithms and 
pMC_mult modules.
VS project generation is not well supported in scons. Resulting projects should 

Re: Bug#937262: Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

2019-12-12 Thread Andreas Tille
On Thu, Dec 12, 2019 at 03:49:13PM -0500, Scott Talbert wrote:
> > 
> > That hint was helpful anyway and I get further now.  I think now the
> > problem is to convince scons to install in $(CURDIR)/debian/tmp which
> > seems to try rather /usr/share/pdb2pqr directly:
> 
> Looks like the debian/rules file is specifying /usr/share/pdb2pqr as PREFIX:
> 
> https://salsa.debian.org/med-team/pdb2pqr/blob/master/debian/rules#L33

Arrghh, good if somebody else is proof-reading.  However, setting this
does not help:



mkdir -p /build/pdb2pqr-2.1.1+dfsg/debian/tmp/usr/share/pdb2pqr
scons \
URL="http://localhost/pdb2pqr/; \
PREFIX="/build/pdb2pqr-2.1.1+dfsg/debian/tmp/usr/share/pdb2pqr"
scons: Reading SConscript files ...
not using opal 
scons: done reading SConscript files.
scons: Building targets ...
CopySubAction("pdb2pqr.py", "pdb2pqr.py.in")
scons: *** [pdb2pqr.py] Can't write target file pdb2pqr.py
scons: building terminated because of errors.

TARGETS: ['pdb2pqr.py', 'apbs_cgi.cgi', 'visualize.cgi', 'querystatus.cgi', 
'src/aconf.py', 'html/server.html', 'pdb2pqr.cgi', 
'pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.so', 
'pdb2pka/_pMC_mult.cpython-37m-x86_64-linux-gnu.so']


Configuration Parameters


Version: 2.1.1
Install directory: /build/pdb2pqr-2.1.1+dfsg/debian/tmp/usr/share/pdb2pqr/
pdb2pka and ligand support: True
Path to the website directory: http://localhost/pdb2pqr/
PDB2PQR jobs run via the web interface will be forked on the server.

The preferred way to configure the build is by editing the file build_config.py

Run scons with the python3 that you intend to use with pdb2pqr.
For example: "scons" will setup pdb2pqr to be run with Debian default Python3 
interpreter

Run "scons install" to install pdb2pqr in 
/build/pdb2pqr-2.1.1+dfsg/debian/tmp/usr/share/pdb2pqr/

Run "scons basic-test" for a basic functionality test
Run "scons advanced-test" for a single test of ligand and PROPKA support. 
Requires numpy and PDB2PKA support compiled.
Run "scons complete-test" for a complete test of all functionality EXCEPT 
PDB2PKA. Requires numpy and PDB2PKA support compiled.
Run "scons pdb2pka-test" for a test of PDB2PKA functionality.
Requires numpy, PDB2PKA support compiled AND the APBS python3 libraries 
compiled and installed in the pdb2pka directory.

To setup a web service create a symbolic link to 
/build/pdb2pqr-2.1.1+dfsg/debian/tmp/usr/share/pdb2pqr/ that enables you to 
view http://localhost/pdb2pqr/ after running "scons install"

Run "scons msvs" to build Visual Studio projects for the Algorithms and 
pMC_mult modules.
VS project generation is not well supported in scons. Resulting projects should 
build using NMAKE but cannot be used for debugging.
The resulting projects will need to modified to use VS natively to compile the 
code or debug.

FAILED
Failed building pdb2pqr.py: Can't write target file pdb2pqr.py
make[1]: *** [debian/rules:29: override_dh_auto_configure] Error 2
make[1]: Leaving directory '/build/pdb2pqr-2.1.1+dfsg'
make: *** [debian/rules:13: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
I: copying local configuration
E: Failed autobuilding of package


I intentionally created the dir
  /build/pdb2pqr-2.1.1+dfsg/debian/tmp/usr/share/pdb2pqr/
before the fixed scons call - but the result is the same. :-(

Kind regards

  Andreas.


-- 
http://fam-tille.de



Help with scons needed (Was: Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye))

2019-12-12 Thread Andreas Tille
Hi Scott,

On Thu, Dec 12, 2019 at 11:31:09AM -0500, Scott Talbert wrote:
> On Thu, 12 Dec 2019, Andreas Tille wrote:
> 
> I don't see any Python3 changes in that repository.  Did you push your
> changes?

Argh, its pushed now.
 
> Anyway, the problem is likely in CopySubAction in site_scons/site_init.py.
> 
> On line 111, the file 'sourcefile' is opened as binary.  Then, when then
> next line, 'contents = r.read()' is executed, contents ends up as a bytes
> object.  Thus on line 123, when 'contents = contents.replace(k, v)' is
> executed, contents is a bytes object, whereas k and v are strings.  You
> can't mix strings and bytes objects like that in Python 3.
> 
> You could perhaps try opening the file as a text file instead (remove the
> 'b') from the open function call.

That hint was helpful anyway and I get further now.  I think now the
problem is to convince scons to install in $(CURDIR)/debian/tmp which
seems to try rather /usr/share/pdb2pqr directly:

...
scons: Reading SConscript files ...
not using opal.
scons: done reading SConscript files.
scons: Building targets ...
CopySubAction("pdb2pqr.py", "pdb2pqr.py.in")
scons: *** [pdb2pqr.py] Can't write target file pdb2pqr.py
scons: building terminated because of errors.

TARGETS: ['pdb2pqr.py', 'apbs_cgi.cgi', 'visualize.cgi', 'querystatus.cgi', 
'src/aconf.py', 'html/server.html', 'pdb2pqr.cgi', 
'pdb2pka/substruct/Algorithms.cpython-37m-x86_64-linux-gnu.


Configuration Parameters


Version: 2.1.1
Install directory: /usr/share/pdb2pqr/
pdb2pka and ligand support: True
Path to the website directory: http://localhost/pdb2pqr/
PDB2PQR jobs run via the web interface will be forked on the server.

The preferred way to configure the build is by editing the file build_config.py

Run scons with the python3 that you intend to use with pdb2pqr.
For example: "scons" will setup pdb2pqr to be run with Debian default Python3 
interpreter

Run "scons install" to install pdb2pqr in /usr/share/pdb2pqr/

Run "scons basic-test" for a basic functionality test
Run "scons advanced-test" for a single test of ligand and PROPKA support. 
Requires numpy and PDB2PKA support compiled.
Run "scons complete-test" for a complete test of all functionality EXCEPT 
PDB2PKA. Requires numpy and PDB2PKA support compiled.
Run "scons pdb2pka-test" for a test of PDB2PKA functionality.
Requires numpy, PDB2PKA support compiled AND the APBS python3 libraries 
compiled and installed in the pdb2pka directory.

To setup a web service create a symbolic link to /usr/share/pdb2pqr/ that 
enables you to view http://localhost/pdb2pqr/ after running "scons install"

Run "scons msvs" to build Visual Studio projects for the Algorithms and 
pMC_mult modules.
VS project generation is not well supported in scons. Resulting projects should 
build using NMAKE but cannot be used for debugging.
The resulting projects will need to modified to use VS natively to compile the 
code or debug.

FAILED
Failed building pdb2pqr.py: Can't write target file pdb2pqr.py



Inside the pbuilder chroot I realised that some file .variables.cache
was created from where scons is reading the "environment" (it does
not read some PREFIX variable from shell environment as my debugging
showed).  So I changed this to:


/build/pdb2pqr-2.1.1+dfsg# cat .variables.cache 
PREFIX = '/build/pdb2pqr-2.1.1+dfsg/debian/tmp/usr/share/pdb2pqr/'
URL = 'http://localhost/pdb2pqr/'
DEBUG = True


but it did not helped in the end even after creating the dir manually.
So I have no idea where scons magically tries to write to but fails.
Is there anybody with some scons knowledge?

Kind regards

  Andreas.

-- 
http://fam-tille.de



Help needed (Was: pdb2pqr: Python2 removal in sid/bullseye)

2019-12-12 Thread Andreas Tille
Control: tags -1 help

Hi,

it seems pdb2pqr is orphaned upstream.  However, it seems to be worth
keeping inside Debian thus I tried my luck to port it to Python3 in
Git[1].  Unfortunately the build runs into

  scons: Building targets ...
  CopySubAction("pdb2pqr.py", "pdb2pqr.py.in")
  scons: *** [pdb2pqr.py] TypeError : a bytes-like object is required, not 
'str'
  Traceback (most recent call last):
File "/usr/lib/scons/SCons/Action.py", line 1209, in execute
  result = self.execfunction(target=target, source=rsources, env=env)
File "/usr/lib/scons/SCons/Action.py", line 1371, in __call__
  return self.parent.actfunc(*args, **kw)
File "./site_scons/site_init.py", line 123, in CopySubAction
  contents = contents.replace(k, v)
  TypeError: a bytes-like object is required, not 'str'
  scons: building terminated because of errors.

I wonder whether it might just be a scons issue.  Please note that I'm
using scons 3.1.1-4 from experimental that is supposed to run with
Python3.

Any hint would be welcome.

Kind regards

   Andreas.


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

-- 
http://fam-tille.de



Re: python-datrie: FTBFS with recent hypothesis version

2019-12-09 Thread Andreas Tille
Hi,

I have upgraded python-datrie in Git[1] to latest upstream version
(0.8).  It shows the same issue - so I admit I have no better clue than
reporting the issue upstream which I'd rather leave to the official
Uploader of the package.

BTW, we probably should expect build issues with Python 3.8[2]

Kind regards

 Andreas.

[1] https://salsa.debian.org/python-team/modules/python-datrie
[2] https://github.com/pytries/datrie/issues/73

-- 
http://fam-tille.de



[Help] Please switch to Python 3

2019-12-07 Thread Andreas Tille
Control: tags -1 help

Hi,

I upgraded python-pbcommand Git[1] to latest upstream commit which is
work in progress to Python3.  Unfortunately I'm facing some remaining
test suite errors:

...
[gw3] [ 98%] PASSED 
tests/test_validators.py::TestValidators::test_validate_report 
tests/test_validators.py::TestValidators::test_validate_report_fails 
[gw3] [ 99%] PASSED 
tests/test_validators.py::TestValidators::test_validate_report_fails 
[gw0] [100%] FAILED 
tests/test_testkit_xunit.py::TestXunitOutput::test_merge_junit_files_cmdline 

=== FAILURES ===
___ TestMalformedReport.test_bad_01 
[gw0] linux -- Python 3.8.0 /usr/bin/python3.8

self = 

def test_bad_01(self):
r = Report("stuff", uuid=1234)
>   d = r.to_dict()

tests/test_models_report.py:355: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
pbcommand/models/report.py:778: in to_dict
_d = dict(v=pbcommand.get_version(),
pbcommand/__init__.py:19: in get_version
return ".".join([str(i) for i in VERSION])
pbcommand/__init__.py:19: in 
return ".".join([str(i) for i in VERSION])
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

.0 = 

>   VERSION = (int(x) for x in __VERSION__.split('.'))
E   ValueError: invalid literal for int() with base 10: 'unknown'

pbcommand/__init__.py:9: ValueError
 TestReportModel.test_from_simple_dict _
[gw2] linux -- Python 3.8.0 /usr/bin/python3.8

self = 

def test_from_simple_dict(self):
r = Report.from_simple_dict("pbcommand_test", {"n_reads": 50},
"pbcommand")
>   json_dict = json.loads(r.to_json())

tests/test_models_report.py:34: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
pbcommand/models/report.py:801: in to_json
s = _to_json_with_decoder(self.to_dict())
pbcommand/models/report.py:778: in to_dict
_d = dict(v=pbcommand.get_version(),
pbcommand/__init__.py:19: in get_version
return ".".join([str(i) for i in VERSION])
pbcommand/__init__.py:19: in 
return ".".join([str(i) for i in VERSION])
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

.0 = 

>   VERSION = (int(x) for x in __VERSION__.split('.'))
E   ValueError: invalid literal for int() with base 10: 'unknown'

pbcommand/__init__.py:9: ValueError
 TestXunitOutput.test_merge_junit_files_cmdline 
[gw0] linux -- Python 3.8.0 /usr/bin/python3.8

self = 

def test_merge_junit_files_cmdline(self):
x1, x2 = self._get_junit_files()
x_merged = tempfile.NamedTemporaryFile(suffix=".xml").name
args = ["python3", "-m" "pbcommand.testkit.merge_junit_files",
"-o", x_merged, x1, x2, "--quiet"]
>   assert subprocess.call(args) == 0
E   assert 1 == 0
E -1

E +0

tests/test_testkit_xunit.py:106: AssertionError
- Captured stderr call -
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/testkit/merge_junit_files.py",
 line 43, in 
sys.exit(main())
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/testkit/merge_junit_files.py",
 line 39, in main
setup_log_func=setup_log)
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/cli/core.py",
 line 212, in pacbio_args_runner
dump_alarm_on_error=dump_alarm_on_error)
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/cli/core.py",
 line 160, in _pacbio_main_runner
alog.info("Using pbcommand v{v}".format(v=pbcommand.get_version()))
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/__init__.py",
 line 19, in get_version
return ".".join([str(i) for i in VERSION])
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/__init__.py",
 line 19, in 
return ".".join([str(i) for i in VERSION])
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/__init__.py",
 line 9, in 
VERSION = (int(x) for x in __VERSION__.split('.'))
ValueError: invalid literal for int() with base 10: 'unknown'
- generated xml file: 
/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/nosetests.xml
 -
--- coverage: platform linux, python 3.8.0-final-0 ---
Coverage XML written to file 

[Help] consensuscore: Python2 removal in sid/bullseye

2019-12-07 Thread Andreas Tille
Control: tags -1 help

Hi,

I tried to port consensuscore to Python3 in Git[1].  Unfortunately 2to3
was not completely successfully since I get:


   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python3.8 setup.py build.
WARNING: '' not a valid package name; please use only .-separated package names 
in setup.py
running build
Traceback (most recent call last):
  File "tools/find_boost", line 56, in 
boost = find_boost()
  File "tools/find_boost", line 44, in find_boost
best_boost = max(boosts_found, key=lambda t: t[1])[0]
TypeError: '>' not supported between instances of 'NoneType' and 'tuple'
error: Failed to configure ConsensusCore build
E: pybuild pybuild:341: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3.8 setup.py build.


Any hint how to fix this?

Kind regards

Andreas.


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

-- 
http://fam-tille.de



pytest help needed

2019-12-04 Thread Andreas Tille
Hi,

I try to prepare the latest git commit from upstream of python-pbcore[1].
Unfortunately the build time test fails with:

...
  dh_auto_test
I: pybuild base:217: python3.8 setup.py test
running pytest
running egg_info
writing pbcore.egg-info/PKG-INFO
writing dependency_links to pbcore.egg-info/dependency_links.txt
writing entry points to pbcore.egg-info/entry_points.txt
writing requirements to pbcore.egg-info/requires.txt
writing top-level names to pbcore.egg-info/top_level.txt
reading manifest file 'pbcore.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
/usr/lib/python3.8/distutils/dist.py:274: UserWarning: Unknown distribution 
option: 'test_requires'
  warnings.warn(msg)
warning: no files found matching '*.txt'
writing manifest file 'pbcore.egg-info/SOURCES.txt'
running build_ext
ERROR: usage: setup.py [options] [file_or_dir] [file_or_dir] [...]
setup.py: error: unrecognized arguments: -n --dist=loadscope --cov=./pbcore 
--cov-report=xml:coverage.xml
  inifile: /build/python-pbcore-1.7.1+git20191121.7947eb7+dfsg/pytest.ini
  rootdir: /build/python-pbcore-1.7.1+git20191121.7947eb7+dfsg

E: pybuild pybuild:341: test: plugin custom failed with: exit code=4: python3.8 
setup.py test
dh_auto_test: pybuild --test --test-pytest -i python{version} -p "3.8 3.7" 
returned exit code 13
...

Those arguments are mentioned in pytest.ini which reads:


[pytest]
markers =
pbtestdata: requires the 'PacBioTestData' package to be installed
internal_data: requires access to internal data on 
'/pbi/dept/secondary/siv/testdata'
constools: requires 'pbindex', 'samtools' and 'pbmerge' in PATH

addopts =
-v -n auto --dist=loadscope --durations=20 --junitxml=nosetests.xml 
--cov=./pbcore --cov-report=xml:coverage.xml


Any hints what options I should use instead?

Kind regards

   Andreas.

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

-- 
http://fam-tille.de



Lintian warning for this issue (Was: autopkgtest-pkg-python fails if package name is python-pyMODULENAME)

2019-12-04 Thread Andreas Tille
On Fri, Nov 29, 2019 at 12:02:44PM +0100, Andreas Tille wrote:
> > I've opened
> > https://salsa.debian.org/cpython-team/python3-defaults/merge_requests/2
> > to clarify this. Comments welcome, particularly if you don't think my
> > proposed change reflects consensus.
> 
> Thanks.  This is more clear.  I just uploaded with python3-pubsub to new.

BTW, I think the issue deserves a lintian warning:
   package-name-different-than-loadable-python-module
or something like this. 

Kind regards, Andreas.

-- 
http://fam-tille.de



Any reason why python-scipy version 1.3.1 remains in experimental?

2019-12-01 Thread Andreas Tille
Hi,

according to the answer to an issue I opened agains scikit-bio[1] the
test suite would work with scipy version 1.3.1.  I wonder what might be
the reason to stick to version 1.2.2 instaed of upgrading to the version
in experimental.  In case this situation would not change in the next
weeks I'd consider to simply deactivate the said test.

Kind regards

Andreas.

[1] https://github.com/biocore/scikit-bio/issues/1678

-- 
http://fam-tille.de



Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

2019-11-29 Thread Andreas Tille
On Fri, Nov 29, 2019 at 10:42:45AM +, Simon McVittie wrote:
> 
> I've opened
> https://salsa.debian.org/cpython-team/python3-defaults/merge_requests/2
> to clarify this. Comments welcome, particularly if you don't think my
> proposed change reflects consensus.

Thanks.  This is more clear.  I just uploaded with python3-pubsub to new.
(To bad that this will need another iteration for a source-only upload :-()

Kind regards

 Andreas.

-- 
http://fam-tille.de



Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

2019-11-28 Thread Andreas Tille
On Thu, Nov 28, 2019 at 11:15:31AM -0500, Sandro Tosi wrote:
> > Hmmm, what are the chances to get this applied?  I've added
> >
> >X-Python-Module-Name: pubsub
> >
> > in Git - but this will not reall fix the test.  The only solution I'd see
> > otherwise is to deactivate the test.
> 
> if you install `pubsub` as top-level module, your package must be
> named pythonN-pubsub, if not it violates the policy and it's RC buggy.
> please rename the package.

OK, just to make sure the package currently named python3-pypubsub
installs files


...
/usr/lib/python3/dist-packages/Pypubsub-4.0.3.egg-info
/usr/lib/python3/dist-packages/Pypubsub-4.0.3.egg-info/PKG-INFO
/usr/lib/python3/dist-packages/Pypubsub-4.0.3.egg-info/dependency_links.txt
/usr/lib/python3/dist-packages/Pypubsub-4.0.3.egg-info/not-zip-safe
/usr/lib/python3/dist-packages/Pypubsub-4.0.3.egg-info/top_level.txt
/usr/lib/python3/dist-packages/pubsub
/usr/lib/python3/dist-packages/pubsub/__init__.py
/usr/lib/python3/dist-packages/pubsub/core
/usr/lib/python3/dist-packages/pubsub/core/__init__.py
/usr/lib/python3/dist-packages/pubsub/core/annotations.py
/usr/lib/python3/dist-packages/pubsub/core/callables.py
...


No idea about /usr/lib/python3/dist-packages/Pypubsub-4.0.3.egg-info
but it seems I need to rename to python3-pubsub since there is
the real module, right?

Kind regards

   Andreas.
 

-- 
http://fam-tille.de



Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

2019-11-28 Thread Andreas Tille
On Thu, Nov 28, 2019 at 04:18:07PM +0100, Ondrej Novy wrote:
> 
> > Is there any trick to enable autopkgtest-pkg-python detecting the correct
> > module name?
> >
> 
> no (not yet? See: https://salsa.debian.org/ci-team/autodep8/merge_requests/6
> )

Hmmm, what are the chances to get this applied?  I've added

   X-Python-Module-Name: pubsub

in Git - but this will not reall fix the test.  The only solution I'd see
otherwise is to deactivate the test.

Kind regards

 Andreas.

-- 
http://fam-tille.de



autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')

2019-11-28 Thread Andreas Tille


On Thu, Nov 28, 2019 at 12:46:34PM +0100, Paul Gevers wrote:
> Source: python-pypubsub
> Version: 4.0.3-2
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: regression
> 
> ...
> 
> [1] https://qa.debian.org/excuses.php?package=python-pypubsub
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pypubsub/3403470/log.gz
> 
> autopkgtest [15:15:47]: test autodep8-python3: set -e ; for py in
> $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing
> with $py:" ; $py -c "import pypubsub; print(pypubsub)" ; done
> autopkgtest [15:15:47]: test autodep8-python3: [---
> Testing with python3.7:
> Traceback (most recent call last):
>   File "", line 1, in 
> ModuleNotFoundError: No module named 'pypubsub'
> autopkgtest [15:15:47]: test autodep8-python3: ---]


The test is correct since the correct module name is pubsub (rather than
pypubsub). It seems that's a usual pattern since if I check python3-pyvcf[1]
it ends up in:


autopkgtest [08:47:45]: test autodep8-python3: set -e ; for py in $(py3versions 
-r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c 
"import pyvcf; print(pyvcf)" ; done
autopkgtest [08:47:45]: test autodep8-python3: [---
Testing with python3.8:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'pyvcf'
autopkgtest [08:47:46]: test autodep8-python3: ---]
autopkgtest [08:47:46]: test autodep8-python3:  - - - - - - - - - - results - - 
- - - - - - - -
autodep8-python3 FAIL non-zero exit status 1


Is there any trick to enable autopkgtest-pkg-python detecting the correct
module name?

Kind regards

 Andreas.


[1] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-pyvcf/3462810/log.gz

-- 
http://fam-tille.de



Help with upgrading psychopy needed (Was: Python2 removal in sid/bullseye)

2019-11-20 Thread Andreas Tille
Control: tags -1 help

Hi,

I've tried to upgraded psychopy[1] to the latest upstream version.
Unfortunately I failed to run the test suite successfully:


   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:217: cd /build/psychopy-3.2.4+dfsg/.pybuild/cpython3_3.7/build; 
python3.7 -m pytest 
= test session starts ==
platform linux -- Python 3.7.5, pytest-4.6.6, py-1.8.0, pluggy-0.13.0
rootdir: /build/psychopy-3.2.4+dfsg, inifile: setup.cfg
collected 22 items / 21 errors / 1 selected
INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 
206, in wrap_session
INTERNALERROR> session.exitstatus = doit(config, session) or 0
INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 
249, in _main
INTERNALERROR> config.hook.pytest_collection(session=session)
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 
286, in __call__
INTERNALERROR> return self._hookexec(self, self.get_hookimpls(), kwargs)
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 
92, in _hookexec
INTERNALERROR> return self._inner_hookexec(hook, methods, kwargs)
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 
86, in 
INTERNALERROR> firstresult=hook.spec.opts.get("firstresult") if hook.spec 
else False,
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 
208, in _multicall
INTERNALERROR> return outcome.get_result()
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 
80, in get_result
INTERNALERROR> raise ex[1].with_traceback(ex[2])
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 
187, in _multicall
INTERNALERROR> res = hook_impl.function(*args)
INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 
259, in pytest_collection
INTERNALERROR> return session.perform_collect()
INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 
496, in perform_collect
INTERNALERROR> self.config.pluginmanager.check_pending()
INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 
275, in check_pending
INTERNALERROR> % (name, hookimpl.plugin),
INTERNALERROR> pluggy.manager.PluginValidationError: unknown hook 
'pytest_namespace' in plugin 
2.0298  WARNING Monitor specification not found. Creating a temporary 
one...
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/pytest.py", line 102, in 
raise SystemExit(pytest.main())
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 82, in 
main
return config.hook.pytest_cmdline_main(config=config)
  File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286, in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92, in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 86, in 
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 208, in 
_multicall
return outcome.get_result()
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 80, in 
get_result
raise ex[1].with_traceback(ex[2])
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in 
_multicall
res = hook_impl.function(*args)
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 243, in 
pytest_cmdline_main
return wrap_session(config, _main)
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 236, in 
wrap_session
session=session, exitstatus=session.exitstatus
  File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286, in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92, in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 86, in 
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 203, in 
_multicall
gen.send(outcome)
  File "/usr/lib/python3/dist-packages/_pytest/terminal.py", line 662, in 
pytest_sessionfinish
outcome.get_result()
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 80, in 
get_result
raise ex[1].with_traceback(ex[2])
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in 
_multicall
res = hook_impl.function(*args)
  File 

Re: Bug#937657: Issue with numpy under Python 3.8

2019-11-17 Thread Andreas Tille
Hi Graham,

On Sun, Nov 17, 2019 at 02:16:29PM +0200, Graham Inggs wrote:
> If you look on the numpy tracker page [1], you'll see there is a note:
> 
> "This package is part of the ongoing testing transition known as
> python3.8. Please avoid uploads unrelated to this transition, they
> would likely delay it and require supplementary work from the release
> managers."

I wonder in how far this is relevant to simply *build* a package.  I'm
trying to build python-colormap in a pbuilder chroot and it fails and I
wonder why.
 
> [1] https://tracker.debian.org/pkg/numpy

-- 
http://fam-tille.de



Re: Bug#937657: Issue with numpy under Python 3.8

2019-11-16 Thread Andreas Tille
Hi Rebecca,

On Sat, Nov 16, 2019 at 09:16:17AM +, Rebecca N. Palmer wrote:
> I think that just means "numpy hasn't yet been rebuilt for Python 3.8". (In
> Python modules that include a C extension, the .py files are shared but the
> C part is compiled separately for each Python version.)
> 
> As there are ~500 modules requiring such a rebuild
> (https://release.debian.org/transitions/html/python3.8.html), this may take
> some time.  (numpy itself will probably be a source upload, to move 1.17
> from experimental to unstable.)
> 
> For testing, it may be easiest to use an Ubuntu chroot for now.

Its not about testing.  Its the usual build time test.  If I'd do a
source upload of this package it will FTBFS under the current state
of the archive.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Issue with numpy under Python 3.8 (Was: python-colormap: Python2 removal in sid/bullseye)

2019-11-15 Thread Andreas Tille
Control: tags -1 help

Hi,

I have dropped the Python2 package in Git[1] and tried to build which
ended up in:

...
I: pybuild base:217: cd 
/build/python-colormap-1.0.2/.pybuild/cpython3_3.8_colormap/build; python3.8 -m 
nose -v test
nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$']
test_colors.test_hex2web ... ok
test_colors.test_web2hex ... ok
test_colors.test_rgb2yuv ... ok
test_colors.test_rgb2hsv ... ok
test_colors.test_rgb2hls ... ok
test_colors.test_hex2dec ... ok
test_colors.test_rgb2hex ... ok
test_colors.testColors ... ok
test_colors.test_normalise ... ok
test_colors.test_to_intensity ... ok
test_colors.test_colormap ... ok
test_colors.test_HEX ... ok
test_get_cmap.test_get_cmap ... ERROR
 
==
ERROR: test_get_cmap.test_get_cmap
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 17, in 

from . import multiarray
  File "/usr/lib/python3/dist-packages/numpy/core/multiarray.py", line 14, in 

from . import overrides
  File "/usr/lib/python3/dist-packages/numpy/core/overrides.py", line 7, in 

from numpy.core._multiarray_umath import (
ModuleNotFoundError: No module named 'numpy.core._multiarray_umath'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/build/python-colormap-1.0.2/.pybuild/cpython3_3.8_colormap/build/test/test_get_cmap.py",
 line 5, in test_get_cmap
get_cmap("heat")
  File 
"/build/python-colormap-1.0.2/.pybuild/cpython3_3.8_colormap/build/colormap/get_cmap.py",
 line 41, in cmap_builder
return c.get_cmap_heat()
  File 
"/build/python-colormap-1.0.2/.pybuild/cpython3_3.8_colormap/build/colormap/colors.py",
 line 891, in get_cmap_heat
return self.cmap(
  File 
"/build/python-colormap-1.0.2/.pybuild/cpython3_3.8_colormap/build/colormap/colors.py",
 line 852, in cmap
import numpy as np
  File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 142, in 
from . import core
  File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 47, in 

raise ImportError(msg)
ImportError:.

IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!

Importing the numpy c-extensions failed.
- Try uninstalling and reinstalling numpy.
- If you have already done that, then:
  1. Check that you expected to use Python3.8 from "/usr/bin/python3.8",
 and that you have no directories in your PATH or PYTHONPATH that can
 interfere with the Python and numpy version "1.17.4" you're trying to use.
  2. If (1) looks fine, you can open a new issue at
 https://github.com/numpy/numpy/issues.  Please include details on:
 - how you installed Python
 - how you installed numpy
 - your operating system
 - whether or not you have multiple versions of Python installed
 - if you built from source, your compiler versions and ideally a build log

- If you're working with a numpy git repository, try `git clean -xdf`
  (removes all files not under version control) and rebuild numpy.

Note: this error has many possible causes, so please don't comment on
an existing issue about this - open a new one instead.

Original error was: No module named 'numpy.core._multiarray_umath'


--
Ran 13 tests in 0.056s

FAILED (errors=1)
E: pybuild pybuild:341: test: plugin distutils failed with: exit code=1: cd 
/build/python-colormap-1.0.2/.pybuild/cpython3_3.8_colormap/build; python3.8 -m 
nose -v test
dh_auto_test: pybuild --test --test-nose -i python{version} -p "3.8 3.7" 
returned exit code 13
make: *** [debian/rules:13: build] Error 255


Seems there is some issue with numpy.  Any idea how to fix this?

Kind regards

  Andreas.


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

-- 
http://fam-tille.de



[Help] graphlan: Python2 removal in sid/bullseye

2019-11-08 Thread Andreas Tille
Hi,

I started an attempt to port graphlan to Python3 in Git[1] but its
autopkgtest throws errors:



Running test script ./IBD_biogeography/run.sh .
Traceback (most recent call last):
  File "/usr/bin/graphlan_annotate", line 26, in 
from src.graphlan_lib import CircTree as CTree
  File "/usr/share/graphlan/src/graphlan_lib.py", line 99, in 
legal_options = 
set(zip(*clade_attr+ext_attr+int_attr+structural_attr+global_graphical_attr+branch_attr+leg_attr)[0])
 | set(['class'])
TypeError: 'zip' object is not subscriptable
Traceback (most recent call last):
  File "/usr/bin/graphlan", line 29, in 
from src.graphlan_lib import CircTree as CTree
  File "/usr/share/graphlan/src/graphlan_lib.py", line 99, in 
legal_options = 
set(zip(*clade_attr+ext_attr+int_attr+structural_attr+global_graphical_attr+branch_attr+leg_attr)[0])
 | set(['class'])
TypeError: 'zip' object is not subscriptable



Any hint how to fix this?

Kind regards

   Andreas.


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

-- 
http://fam-tille.de



Help needed for issue in test suite for Python3 (Was: Bug#937698: python-dendropy: Python2 removal in sid/bullseye)

2019-10-08 Thread Andreas Tille
Control: tags -1 help

Hi,

I have prepared a fix for this package in Git[1].  Unfortunately I'm
stumbling upon a test suite error which was discussed with upstream
previously.  It happens only for Python3 and was ignored before but
this strategy seems to be inappropriate now after droping Python2.
You can simply reproduce the issue even in the unpackaged source:

$ python3 setup.py test
-setup.py: DendroPy version 4.4.0
-setup.py: using setuptools 
('/usr/lib/python3/dist-packages/setuptools/__init__.py')
-setup.py: searching for packages
-setup.py: packages identified:
   - dendropy
   - dendropy.legacy 
   - dendropy.utility
   - dendropy.mathlib
   - dendropy.dataio 
   - dendropy.interop
   - dendropy.datamodel  
   - dendropy.model  
   - dendropy.calculate  
   - dendropy.simulate   
   - dendropy.utility.libexec
-setup.py: scripts identified:
   - applications/sumtrees/sumtrees.py  
   - applications/sumlabels/sumlabels.py
-setup.py: setuptools command extensions are available
running test
running egg_info
writing src/DendroPy.egg-info/PKG-INFO
writing dependency_links to src/DendroPy.egg-info/dependency_links.txt
writing entry points to src/DendroPy.egg-info/entry_points.txt
writing requirements to src/DendroPy.egg-info/requires.txt
writing top-level names to src/DendroPy.egg-info/top_level.txt
reading manifest template 'MANIFEST.in'
warning: no files found matching 'doc/Makefile'
warning: no files found matching '*' under directory 'doc/source'
warning: no previously-included files matching '.DS_Store' found anywhere in 
distribution
warning: no previously-included files matching '*.pyc' found anywhere in 
distribution
warning: no previously-included files matching '.gitignore' found anywhere in 
distribution
warning: no previously-included files matching '.gitattributes' found anywhere 
in distribution
warning: no previously-included files matching '.idea' found anywhere in 
distribution
warning: no previously-included files matching '__pycache__' found anywhere in 
distribution
writing manifest file 'src/DendroPy.egg-info/SOURCES.txt'
running build_ext
Traceback (most recent call last):
  File "setup.py", line 192, in 
**EXTRA_KWARGS
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 145, in 
setup
return distutils.core.setup(**attrs)
  File "/usr/lib/python3.7/distutils/core.py", line 148, in setup
dist.run_commands()
  File "/usr/lib/python3.7/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
  File "/usr/lib/python3.7/distutils/dist.py", line 985, in run_command
cmd_obj.run()
  File "/usr/lib/python3/dist-packages/setuptools/command/test.py", line 229, 
in run
self.run_tests()
  File "/usr/lib/python3/dist-packages/setuptools/command/test.py", line 251, 
in run_tests
exit=False,
  File "/usr/lib/python3.7/unittest/main.py", line 100, in __init__
self.parseArgs(argv)
  File "/usr/lib/python3.7/unittest/main.py", line 147, in parseArgs
self.createTests()
  File "/usr/lib/python3.7/unittest/main.py", line 159, in createTests
self.module)
  File "/usr/lib/python3.7/unittest/loader.py", line 220, in loadTestsFromNames
suites = [self.loadTestsFromName(name, module) for name in names]
  File "/usr/lib/python3.7/unittest/loader.py", line 220, in 
suites = [self.loadTestsFromName(name, module) for name in names]
  File "/usr/lib/python3.7/unittest/loader.py", line 191, in loadTestsFromName
return self.loadTestsFromModule(obj)
  File "/usr/lib/python3/dist-packages/setuptools/command/test.py", line 47, in 
loadTestsFromModule
for file in resource_listdir(module.__name__, ''):
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1162, 
in resource_listdir
return get_provider(package_or_requirement).resource_listdir(
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 364, in 
get_provider
return _find_adapter(_provider_factories, loader)(module)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1392, 
in __init__
self.module_path = os.path.dirname(getattr(module, '__file__', ''))
  File "/usr/lib/python3.7/posixpath.py", line 156, in dirname
p = os.fspath(p)
TypeError: expected str, bytes or os.PathLike object, not NoneType


Any hint would be welcome.

Kind regards

  Andreas.


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

-- 
http://fam-tille.de



Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-18 Thread Andreas Tille
Hi Michael,

On Mon, Sep 16, 2019 at 11:56:48AM +0200, Michael Kesper wrote:
> But honestly, it should better be ripped out and use
> real encryption. The docstring tells so:
> The rotor module has been removed from the Python 2.4
> distribution because
> 
>   the rotor module uses an insecure algorithm and is deprecated.
>   ==

While I for sure agree with you on principle this would mean becoming
upstream for cycle.  If there is some volunteer for doing this I'd be
really happy.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Reviving maintenance of python-pyface

2019-09-18 Thread Andreas Tille
Hi,

pyface was lagging extremely behind upstream.  To cope with Qt5 and
Python3 migration I simply pushed the latest upstream version to
the packaging Git[1]

==
ERROR: pyface.action.tests.test_action_item (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: pyface.action.tests.test_action_item
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/loader.py", line 436, in _find_test_path
module = 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/python-pyface-6.1.2/.pybuild/cpython3_3.7_pyface/build/pyface/action/tests/test_action_item.py",
 line 7, in 
from pyface.image_cache import ImageCache
  File 
"/build/python-pyface-6.1.2/.pybuild/cpython3_3.7_pyface/build/pyface/image_cache.py",
 line 19, in 
from .toolkit import toolkit_object
  File 
"/build/python-pyface-6.1.2/.pybuild/cpython3_3.7_pyface/build/pyface/toolkit.py",
 line 27, in 
toolkit = toolkit_object = find_toolkit('pyface.toolkits')
  File 
"/build/python-pyface-6.1.2/.pybuild/cpython3_3.7_pyface/build/pyface/base_toolkit.py",
 line 281, in find_toolkit
return import_toolkit('null', entry_point)
  File 
"/build/python-pyface-6.1.2/.pybuild/cpython3_3.7_pyface/build/pyface/base_toolkit.py",
 line 209, in import_toolkit
raise RuntimeError(msg)
RuntimeError: No pyface.toolkits plugin found for toolkit null


==
ERROR: pyface.action.tests.test_action_manager (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: 
pyface.action.tests.test_action_manager
Traceback (most recent call last):
  File "/usr/lib/python3.7/unittest/loader.py", line 436, in _find_test_path
module = 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/python-pyface-6.1.2/.pybuild/cpython3_3.7_pyface/build/pyface/action/tests/test_action_manager.py",
 line 8, in 
from ..action_item import ActionItem
  File 
"/build/python-pyface-6.1.2/.pybuild/cpython3_3.7_pyface/build/pyface/action/action_item.py",
 line 25, in 
from pyface.toolkit import toolkit_object
  File 
"/build/python-pyface-6.1.2/.pybuild/cpython3_3.7_pyface/build/pyface/toolkit.py",
 line 27, in 
toolkit = toolkit_object = find_toolkit('pyface.toolkits')
  File 
"/build/python-pyface-6.1.2/.pybuild/cpython3_3.7_pyface/build/pyface/base_toolkit.py",
 line 281, in find_toolkit
return import_toolkit('null', entry_point)
  File 
"/build/python-pyface-6.1.2/.pybuild/cpython3_3.7_pyface/build/pyface/base_toolkit.py",
 line 209, in import_toolkit
raise RuntimeError(msg)
RuntimeError: No pyface.toolkits plugin found for toolkit null

...


I hope the reason are just some missing (Build-)Depends since at least
according to the docs Qt5 and Python3 are supported.  Any help to
finalise the packaging is welcome.  Feel free to do the team upload
without bothering me - I just want to get this fixed somehow since some
Debian Med package (python-mne) is affected.

Kind regards

   Andreas.


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

-- 
http://fam-tille.de



Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-16 Thread Andreas Tille
Hi Peter,

On Sun, Sep 15, 2019 at 02:47:50PM +0100, peter green wrote:
> > > tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))
> > 
> > Thanks to this hint
> This hint was *wrong*, it will introduce garbage into the string and the 
> "rotor" code is clearly designed to work with byte strings, not unicode 
> strings.
> 
> Change it to
> 
> "tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )"

Thanks a lot for your patience.  Unfortunately this is not
yet the final solution:

...
Traceback (most recent call last):
  File "/usr/bin/cycle", line 83, in OnCloseWindow
Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/usr/share/cycle/save_load.py", line 46, in Save_Cycle
tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )
  File "/usr/share/cycle/p_rotor.py", line 63, in encrypt
return self.cryptmore(buf, 0)
  File "/usr/share/cycle/p_rotor.py", line 88, in cryptmore
c = rotors[i][c ^ pos[i]]
TypeError: unsupported operand type(s) for ^: 'int' and 'float'


Kind regards

   Andreas. 

-- 
http://fam-tille.de



Python3 issue with Tkinter (Was: Bug#938447: scoary: Python2 removal in sid/bullseye)

2019-09-13 Thread Andreas Tille
Hi,

I think I ported scoary successfully to Python3 in Git[1].  The
command line applications seem to work but the GUI is just ending
with

   Need the following installed: Tkinter, tkFileDialog, ttk

For the more simple inspection I copy here the beginning which leads to
this:


import sys, os
import threading

try:
import tkinter
except ImportError:
#Python 3 issues
try:
import tkinter as Tkinter
except:
sys.exit("Need to have Tkinter / tkinter installed")

try:
import tkinter.filedialog
except ImportError:
# Python 3 issues
try:
from tkinter import filedialog
tkFileDialog = filedialog
except:
sys.exit("Could not find tkFileDialog / filedialog")

try:
import tkinter.ttk
except ImportError:
# Python 3 issues
try:
from tkinter import ttk as ttk
except:
sys.exit("Could not find ttk / tkinter.ttk")

try:
ttk
Tkinter
except NameError:
sys.exit("Need the following installed: Tkinter, tkFileDialog, ttk")


I have no idea what the call to tkk is supposed to do and why it ends up
in a NameError.  Any hints?

Kind regards

 Andreas.

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

-- 
http://fam-tille.de



Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-13 Thread Andreas Tille
Hi,

On Thu, Sep 12, 2019 at 09:08:04PM +0200, Michael Kesper wrote:
> > Since I do not have much experience with hashlib I'd be happy if 
> > someone might be able to proof-read `def Save_Cycle` in 
> > save_load.py.
> 
> This does not have anything to do with hashlib per se.
> It's just the usual mess of mixing bytestrings with strings.
> You often don't notice in Python2, it just introduces subtle bugs.
> Python3 is more strict here and doesn't allow it.
> 
> Try this:
> 
> tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))

Thanks to this hint and the other hints by Peter Green, I'm now a
bit further.
 
> As an explanation:
> 
> Python 3.7.3 (default, Apr  3 2019, 05:39:12)
> ...

Thanks as well.

> P.S.: The code is in a bad state regarding whitespace / indentation.
> This is critical to get right in Python (e.g. after a for there _has to_
> be an indentation added, Python normally uses four spaces, no tabs).

I'm aware that the code is not good - there are other issues than spaces
and tabs for instance I removed an instance of os.tempnam where upstream
simply had overridden the automatic warning.  Its unmaintained upstream
as well.

I've seen other code in Debian which is not good as well.  Its rather a
philosophical question whether it is better to drop it from Debian (and
leave its users alone may be fiddling around with the upstream code
themselves) or whether we try our best to make the code at least
acceptable.  I usually subscribe to the latter and think there is no
right or wrong here.

I'm not really sure whether we might manage in this case.  After
implementing all hints I'm now stumbling upon:


Traceback (most recent call last):
  File "/usr/bin/cycle", line 83, in OnCloseWindow
Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/usr/share/cycle/save_load.py", line 46, in Save_Cycle
tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))
  File "/usr/share/cycle/p_rotor.py", line 63, in encrypt
return self.cryptmore(buf, 0)
  File "/usr/share/cycle/p_rotor.py", line 88, in cryptmore
c = rotors[i][c ^ pos[i]]
TypeError: unsupported operand type(s) for ^: 'str' and 'int'


I think an  "int(c) ^ pos[i]"  could do here - but I'd like
to get some confirmation first.

Kind regards

 Andreas.

-- 
http://fam-tille.de



Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-12 Thread Andreas Tille
On Thu, Sep 12, 2019 at 01:57:32PM +0500, Andrey Rahmatullin wrote:
> > > There are circular imports in the code so you most likely broke that by
> > > reordering imports in various files.
> > 
> > s/you most likely broke/2to3 most likely broke/
> 2to3 doesn't do that. You mentioned autopep8, it could do that.

Ahhh, well, that might be another way to mess up the sequence.  Put a
mental note to warn me about autodep8.
 
> > So may be I misinterpreted your hint but even reverting the reordering
> > of 2to3 in my latest commit does not help.
> I also said that other changes may be problematic too. I didn't check
> them.

OK, I redid the patching in git[1] now.  Some more wxPython 4 porting
was needed as well but I somehow got the user interface working.  May be
some final helping hint could be how to fix leaving the program that
leads to:


Traceback (most recent call last):
  File "/usr/bin/cycle", line 83, in OnCloseWindow
Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/usr/share/cycle/save_load.py", line 27, in Save_Cycle
m.update(passwd)
TypeError: Unicode-objects must be encoded before hashing


I tried

  m.update(passwd.encode())

but this leads later to

Traceback (most recent call last):
  File "cycle.py", line 83, in OnCloseWindow
Save_Cycle(cycle.name, cycle.passwd, cycle.file)
  File "/home/andreas/debian-maintain/salsa/med-team/cycle/save_load.py", line 
46, in Save_Cycle
tmp=rt.encrypt( 'Cycle'+pickle.dumps(objSave) )
TypeError: can only concatenate str (not "bytes") to str


Since I do not have much experience with hashlib I'd be happy if someone
might be able to proof-read `def Save_Cycle` in save_load.py.

Kind regards

  Andreas.


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

-- 
http://fam-tille.de



Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])

2019-09-12 Thread Andreas Tille
Hi Michael,

On Thu, Sep 12, 2019 at 09:22:06AM +0200, Michael Kesper wrote:
> On 12.09.19 08:30, Thomas Goirand wrote:
> > I wont comment on the relative import ambiguity problem, as Ghislain
> > replied correctly. However, I do want to comment on 2to3.
> > 
> > I generally recommend against using it, in the favor of other tools. 
> ...
> > 
> > The advantage is that you'll get a source code that will work on both
> > Python 2 and 3. It's generally a way more easy to submit upstream, which
> > may not want to loose Python 2 compatibility.
> 
> We should stop caring about that.
> Python2 will be EOL'ed at January 1, 2020 [0].
> Python2 will vanish from next Debian release.
> Please convert into idiomatic Python3 code, that's the sane way going forward.

I agree here.  @Thomas:  We talked about sixer at DebConf (thanks for
the hint in any case).  But I consider the additional dependency it
introduces something I'd like to avoid if possible.  So I first try my
luck with 2to3 (and I admit I observed some surprises which did not made
me that lucky at all) before I'd use sixer as fallback.

Kind regards

   Andreas.

-- 
http://fam-tille.de



Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-12 Thread Andreas Tille
Hi Andrey,

On Wed, Sep 11, 2019 at 07:32:33PM +0500, Andrey Rahmatullin wrote:
> > $ cycle
> > Traceback (most recent call last):
> >   File "/usr/bin/cycle", line 12, in 
> > from dialogs import *
> >   File "/usr/share/cycle/dialogs.py", line 8, in 
> > from cal_year import cycle, Val
> >   File "/usr/share/cycle/cal_year.py", line 9, in 
> > from dialogs import Note_Dlg
> > ImportError: cannot import name 'Note_Dlg' from 'dialogs' 
> > (/usr/share/cycle/dialogs.py)
> There are circular imports in the code so you most likely broke that by
> reordering imports in various files.

s/you most likely broke/2to3 most likely broke/

I admit I did not really checked what 2to3 created but I can assure you
I did not simply fired up an editor and had fun reverting some import
sequences.

> "from cal_year import *; from dialogs import *" works, the reverse
> doesn't, so the /usr/bin/cycle code is definitely problematic, not sure
> about other changes.

I can not confirm that

   from cal_year import *

works at all.  It works in the unpatched Python2 version.

   git clone https://salsa.debian.org/med-team/cycle
   cd cycle
   echo "from cal_year import *" | python
   quilt push -a
   echo "from cal_year import *" | python3
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py", line 
9, in 
from dialogs import Note_Dlg
  File "/home/andreas/debian-maintain/salsa/med-team/cycle/dialogs.py", line 
12, in 
from cal_year import cycle, Val
ImportError: cannot import name 'cycle' from 'cal_year' 
(/home/andreas/debian-maintain/salsa/med-team/cycle/cal_year.py)


So may be I misinterpreted your hint but even reverting the reordering
of 2to3 in my latest commit does not help.

Kind regards

  Andreas.

-- 
http://fam-tille.de



[Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

2019-09-11 Thread Andreas Tille
Control: tags -1 help

On Wed, Sep 11, 2019 at 09:33:54AM -0300, Antonio Terceiro wrote:
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> ~[100]$ cycle
>   File "/usr/bin/cycle", line 29
> if lang_find:
> ^
> TabError: inconsistent use of tabs and spaces in indentation

Argh.  That's fixed via autopep8 in Git[1] now.  However, when calling
cycle I get

$ cycle
Traceback (most recent call last):
  File "/usr/bin/cycle", line 12, in 
from dialogs import *
  File "/usr/share/cycle/dialogs.py", line 8, in 
from cal_year import cycle, Val
  File "/usr/share/cycle/cal_year.py", line 9, in 
from dialogs import Note_Dlg
ImportError: cannot import name 'Note_Dlg' from 'dialogs' 
(/usr/share/cycle/dialogs.py)


Any idea how to fix this?

Kind regards

 Andreas.


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

-- 
http://fam-tille.de



2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])

2019-09-09 Thread Andreas Tille
Hi,

in the process of the Python3 migration the package lefse was converted
using 2to3.  The changes can be found in git[1].  I'm wondering about
the following diff created by 2to3:

  - from lefse import *
  + from .lefse import *

When calling a random binary of the resulting binary package lefse I
experienced:

$ plot_features 
Traceback (most recent call last):
  File "/usr/bin/plot_features", line 6, in 
from .lefse import *
ModuleNotFoundError: No module named '__main__.lefse'; '__main__' is not a 
package


I think the line

   from lefse import *

should remain to keep that script functional.  I now checked another
package (cain - nothing pushed yet) and here also 2to3 is changing

   from something import *

to

   from .something import *

Could somebody please enlighten me about this added '.' which does not
seem to work?

Kind regards

  Andreas.

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

-- 
http://fam-tille.de



Re: [Help] Bug#938668: tifffile: Python2 removal in sid/bullseye

2019-09-05 Thread Andreas Tille
Hi Andrey,

On Thu, Sep 05, 2019 at 11:06:22PM +0500, Andrey Rahmatullin wrote:
> > Depends: python3-numpy (>= 1:1.16.0~rc1), python3-numpy-abi9, python3:any, 
> > python:any
> > 
> > 
> > How can I get rid of the python:any dependency?
> You ship a Python 2 script, /usr/bin/tifffile. It also doesn't work, for
> obvious reasons. Fix its shebang.

Argh.  Thanks a lot for opening my eyes.

> It would also be a good idea to test it
> before the last upload, but as nobody noticed that the package doesn't
> work since it was broken in December and got into buster, maybe it should
> just be RMed?

Good question.  I admit I'm actually a bit pissed since the former
maintainer introduced several packages into the team and than
simply left the team.  I tried my best to get the packages in a
decent state but in this case failed obviously.  I've just checked
popcon of "vote" which is not really amazing.

> I've just filed an RC bug for it.

Fixed in new upload.

> Also, my understanding is that public modules should be packaged
> separately as python3-foo packages and private modules should be put into
> private paths, but this package ships a public module and the changelog
> entry says "The package does not really provide a Python module for
> inclusion into other projects." See
> https://www.debian.org/doc/packaging-manuals/python-policy/programs.html#current_version_progs

Thanks for the hint.  I admit I try to concentrate on other Python3
migration issues.  In case some more problems come up with tifffile I'll
reconsider RM.

Kind regards

   Andreas.

-- 
http://fam-tille.de



[Help] Bug#938668: tifffile: Python2 removal in sid/bullseye

2019-09-05 Thread Andreas Tille
Control: tags -1 help

Hi,

for some reason I do not understand are the dependencies of the
binary package

Depends: python3-numpy (>= 1:1.16.0~rc1), python3-numpy-abi9, python3:any, 
python:any


How can I get rid of the python:any dependency?

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Test suite errors with Python3 (Was: Why is dh_auto_clean calling python2.7? (Was: Bug#937624: python-burrito: ...))

2019-08-31 Thread Andreas Tille
On Sat, Aug 31, 2019 at 04:47:42PM -0400, Sandro Tosi wrote:
> burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"
> 
> is the file there?

No, that file does not exist.

 $ grep -R /tmp/fixed.txt
burrito/tests/test_util.py:f = open('/tmp/fixed.txt','w')
burrito/tests/test_util.py:result['fixed_file'] = 
ResultPath(Path='/tmp/fixed.txt')
burrito/tests/test_util.py:result['fixed_file'] = 
ResultPath(Path='/tmp/fixed.txt')

The code snippet that should create the file is

...
#generate some stderr
print('I am stderr', file=stderr)

# Write the fixed file
f = open('/tmp/fixed.txt','w')
f.writelines(['I am fixed file'])
f.close()
...

I have no idea why it might fail.

Kind regards

 Andreas.

> > ...
> > ==
> > ERROR: CLAppTester: Alternative TmpDir functions as expected
> > --
> > Traceback (most recent call last):
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 304, in __call__
> > result_paths)
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 330, in _handle_app_result_build_failure
> > raise ApplicationError("Error constructing CommandLineAppResult.")
> > burrito.util.ApplicationError: Error constructing CommandLineAppResult.
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/tests/test_util.py",
> >  line 769, in test_TmpDir
> > result = app()
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 308, in __call__
> > raise e1
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 299, in __call__
> > result_paths=result_paths)
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 104, in __init__
> > raise ApplicationError('Could not open %s' % value.Path)
> > burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"
> >
> > ==
> > ERROR: CLAppTester: TmpDir functions as expected w space in name
> > --
> > Traceback (most recent call last):
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 304, in __call__
> > result_paths)
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 330, in _handle_app_result_build_failure
> > raise ApplicationError("Error constructing CommandLineAppResult.")
> > burrito.util.ApplicationError: Error constructing CommandLineAppResult.
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/tests/test_util.py",
> >  line 797, in test_TmpDir_w_space
> > result = app()
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 308, in __call__
> > raise e1
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 299, in __call__
> > result_paths=result_paths)
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 104, in __init__
> > raise ApplicationError('Could not open %s' % value.Path)
> > burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"
> >
> > ==
> > ERROR: CLAppTester: WorkingDir functions as expected
> > --
> > ...
> > ==
> > ERROR: CLAppTester: parameters turned on, no data, space in command
> > --
> > Traceback (most recent call last):
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 304, in __call__
> > result_paths)
> >   File 
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> >  line 330, in _handle_app_result_build_failure
> > raise ApplicationError("Error constructing CommandLineAppResult.")
> > burrito.util.ApplicationError: Error constructing CommandLineAppResult.
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> >   File 
> > 

Test suite errors with Python3 (Was: Why is dh_auto_clean calling python2.7? (Was: Bug#937624: python-burrito: ...))

2019-08-31 Thread Andreas Tille
Control: tags -1 help

On Sat, Aug 31, 2019 at 11:50:16AM +0200, Ondrej Novy wrote:
> > I see that python-all is still present in Build-Depends (line 9).
> 
> yep, that's reason. pybulid detects python{,-all} in B-D and if they are
> present, it runs clean for Python 2.

Thanks for pointing this out - it just came in an unexpected sequence.
Unfortunately it turns out that some build time tests are failing with:

...
==
ERROR: CLAppTester: Alternative TmpDir functions as expected
--
Traceback (most recent call last):
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 304, in __call__
result_paths)
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 330, in _handle_app_result_build_failure
raise ApplicationError("Error constructing CommandLineAppResult.")
burrito.util.ApplicationError: Error constructing CommandLineAppResult.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/tests/test_util.py",
 line 769, in test_TmpDir
result = app()
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 308, in __call__
raise e1
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 299, in __call__
result_paths=result_paths)
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 104, in __init__
raise ApplicationError('Could not open %s' % value.Path)
burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"

==
ERROR: CLAppTester: TmpDir functions as expected w space in name
--
Traceback (most recent call last):
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 304, in __call__
result_paths)
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 330, in _handle_app_result_build_failure
raise ApplicationError("Error constructing CommandLineAppResult.")
burrito.util.ApplicationError: Error constructing CommandLineAppResult.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/tests/test_util.py",
 line 797, in test_TmpDir_w_space
result = app()
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 308, in __call__
raise e1
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 299, in __call__
result_paths=result_paths)
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 104, in __init__
raise ApplicationError('Could not open %s' % value.Path)
burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"

==
ERROR: CLAppTester: WorkingDir functions as expected
--
...
==
ERROR: CLAppTester: parameters turned on, no data, space in command
--
Traceback (most recent call last):
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 304, in __call__
result_paths)
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 330, in _handle_app_result_build_failure
raise ApplicationError("Error constructing CommandLineAppResult.")
burrito.util.ApplicationError: Error constructing CommandLineAppResult.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/tests/test_util.
result = app()
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 3
raise e1
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 2
result_paths=result_paths)
  File 
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
 line 1
raise ApplicationError('Could not open %s' % value.Path)
burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"

--
Ran 116 tests in 1.323s

FAILED (errors=12)
E: pybuild pybuild:341: test: plugin distutils failed with: exit code=1: cd 

Why is dh_auto_clean calling python2.7? (Was: Bug#937624: python-burrito: Python2 removal in sid/bullseye)

2019-08-31 Thread Andreas Tille
Hi,

I have removed the Python2 package from d/control and all python-*
Build-Depends in Git[1].  However, the build in a pbuilder chroot fails
with:

dh clean --with python3 --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py clean 
Traceback (most recent call last):
  File "setup.py", line 11, in 
from setuptools import find_packages, setup
ImportError: No module named setuptools
E: pybuild pybuild:341: clean: plugin distutils failed with: exit code=1: 
python2.7 setup.py clean 
dh_auto_clean: pybuild --clean -i python{version} -p 2.7 returned exit code 13
make: *** [debian/rules:10: clean] Error 255


Any idea how I can stop pybuild from calling python2.7?

Kind regards

  Andreas.

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

-- 
http://fam-tille.de



python-confluent-kafka Python2 migration and maintenance in Debian Python Modules Team

2019-08-01 Thread Andreas Tille
Hi Christos,

when inspecting rdepends of python-avro I stumbled upon your package
python-confluent-kafka.  I checked whether the Python2 package has any
further rdepends which does not seem to be the case.  Thus we should
probably drop it from Debian.  While doing so I upgraded the Git
repository[1] to the latest upstream version (please inspect the
changes I did with a routine-upgrade script which makes the packaging
more conform to policy).

I'm now stumbling upon 

In file included from confluent_kafka/src/confluent_kafka.c:17:
confluent_kafka/src/confluent_kafka.h:55:2: error: #error 
"confluent-kafka-python requires librdkafka v1.0.0 or later. Install the latest 
version of librdkafka from the Confluent repositories, see 
http://docs.confluent.io/current/installation.html;
 #error "confluent-kafka-python requires librdkafka v1.0.0 or later. Install 
the latest version of librdkafka from the Confluent repositories, see 
http://docs.confluent.io/current/installation.html;


Since you are maintaining librdkafka as well I wonder what might be
your plan to upgrade this library to its latest version.

Kind regards

   Andreas.

[1] https://salsa.debian.org/python-team/modules/python-confluent-kafka

-- 
http://fam-tille.de



Re: Use debhelper-compat instead of debian/compat

2019-07-22 Thread Andreas Tille
Hi Ondrej

On Thu, Jul 18, 2019 at 04:15:38PM -0300, Ondrej Novy wrote:
> according to debhelper man package it's recommended to use debhelper-compat
> instead of debian/compat file.
> 
> I would like to mass-commit this change to DPMT/PAPT, example:
> 
> https://salsa.debian.org/python-team/modules/python-geoip2/commit/bc5ce34dd9bbfe3ecb7951aead267dbdaba3376a
> 
> Any thoughts?

I wonder whether this is safe for backports and backports-sloppy.

Kind regards

 Andreas.

-- 
http://fam-tille.de



Re: python-intervaltree in Debian Python team maintenance

2019-07-22 Thread Andreas Tille
Hi Hilko,

On Mon, Jul 22, 2019 at 11:54:21AM +0200, Hilko Bengen wrote:
> * Andreas Tille:
> 
> > I noticed that python-intervaltree is not maintained in Debian Python
> > team.  I wonder whether you might want to move this package to the
> > team repository and follow the Debian Python policy (by putting the
> > list as maintainer and you as Uploader).
> 
> I don't seem to have permissions for the Salsa
> https://salsa.debian.org/python-team/modules tree and thus far, I never
> took the time to find out how to get them. This is the main reason why I
> didn't put the package under team maintenance in the first place.

Its described in DPMT policy how to become a member:

   
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
 
> Please consider my answer as permission to "hijack" the package on
> behalf of the Debian Python Team.

Thanks for the permission to "hijack".  I did such things in the past
and its way more relaxing with permission of quickly responding
maintainer than with no response at all. ;-)

However, I was told here at DebConf that I'm the DD with the most
packages (I have not checked) and I rather would love to change this
into the direction of less than more packages.  Specifically since I
realised that the dependency tree which is including
python-intervalltree is very improbable to be ported to Python3 and
I might need to remove these packages from Debian anyway.  Thus my
motivation to maintain that package is even lower.

I'd be really happy if you apply for DPMT membership, put the
Mailinglist as Maintainer and yourself as Uploader.  The time is very
fortunate I'd volunteer to ping DPMT maintainers here at DebConf to
process your application quickly and give you permissions as quick as
possible. ;-)

Kind regards

Andreas.

-- 
http://fam-tille.de



python-intervaltree in Debian Python team maintenance

2019-07-21 Thread Andreas Tille
Hi Hilko,

I noticed that python-intervaltree is not maintained in Debian Python
team.  I wonder whether you might want to move this package to the
team repository and follow the Debian Python policy (by putting the
list as maintainer and you as Uploader).

Kind regards and thanks for maintaining python-intervaltree

   Andreas.

-- 
http://fam-tille.de



Please remove repositories for python-pytz and pyomo from Salsa

2019-06-26 Thread Andreas Tille
Hi,

I realised that

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

is hanging around on Salsa but should not.  Pytz os packaged as python-tz
(see #836261) so this repository should vanish.

I please also remove

   https://salsa.debian.org/python-team/applications/pyomo

Pyomo was removed from Debian.  The Debian Science team wants to
re-introduce it and has continued the packaging[1] in Debian Science
repository since all interested persons are members of this team.  So
please remove the outdated repository.

Kind regards

 Andreas.


[1] https://salsa.debian.org/science-team/pyomo

-- 
http://fam-tille.de



Re: Please enable me pushing to python-team/applications

2019-03-28 Thread Andreas Tille
On Thu, Mar 28, 2019 at 02:50:22PM +0100, Piotr Ożarowski wrote:
> I added you to the team Andreas, sorry for the delay.

Thanks.  No need to sorry - I know you are very busy. ;-)

I've pushed the changes I did for the atheist upload.

Kind regards, Andreas. 

-- 
http://fam-tille.de



Re: Packaging python-xrayutilities

2019-03-21 Thread Andreas Tille
On Thu, Mar 21, 2019 at 03:23:52PM +0500, Andrey Rahmatullin wrote:
> On Thu, Mar 21, 2019 at 10:09:22AM +, MARIE Alexandre wrote:
> > override_dh_installdocs:
> > ln -s /usr/share/javascript/mathjax/MathJax.js 
> > $(CURDIR)/doc/build/html/_static/MathJax.js
> > find doc/build/html -name "*.html" -exec sed -i 
> > "s|https://cdn.mathjax.org/mathjax/latest/MathJax.js|_static/MathJax.js|" 
> > {} \;
> > dh_installdocs -ppython-xrayutilities-doc doc/build/html
> Is there really the leading tab only on the second line?
> 
> > But it does not seem to work.
> What exactly doesn't seem to work?

Wild guessing: The files to be changed might reside in debian/tmp - thus


find debian ...

could be the solution.

Kind regards

 Andreas.

-- 
http://fam-tille.de



Re: Please enable me pushing to python-team/applications

2019-03-21 Thread Andreas Tille
On Thu, Mar 21, 2019 at 09:22:05AM +0100, W. Martin Borgert wrote:
> On 2019-03-21 00:47, Thomas Goirand wrote:
> > Can't you guys just simply give write access to Andreas? What's the
> > issue? Why is it taking so long? This really give the feeling the "team"
> > is still very much dysfunctional,
> 
> Maybe two, three people more can get "owner" permissions?

According to

   
https://salsa.debian.org/groups/python-team/applications/-/group_members?sort=access_level_desc

there are five owners and at least three of them are very active here on
this list (according to my perception).  I thinks that should be qualify
for "sufficient manpower" - but I might be wrong and misinterpret the
ownership in this subteam.

Kind regards

Andreas. 

-- 
http://fam-tille.de



Re: Please enable me pushing to python-team/applications

2019-03-19 Thread Andreas Tille
On Tue, Mar 19, 2019 at 07:18:43PM +0300, Dmitry Shachnev wrote:
> 
> I hope you will be added to the team, but while you are not, why can’t
> you just use merge requests?

In principle I could do this.  However, I provided patches for some PAPT
maintained packages on Alioth easily and I'd love to lower the hurdles
to simply commit my work easily (even if I agree that that hurdle for a
merge request is not very hight).

Thank you

  Andreas.

-- 
http://fam-tille.de



Re: Please enable me pushing to python-team/applications

2019-03-19 Thread Andreas Tille
Hi,

I need to admit that it is a bit demotivating to care for RC bugs on
behalf of PAPT but beeing prevented to easily commit what simply
should be commited.  Its not working for me even now and I might
decide to remove my local Git clone to save some disk space.  Those
who preventing me to help can try to assemble single commits on
their own than.

Sorry, for beeing a bit harsh, but I'm afraid that things like
this are effectively preventing newcomers to this team
  Andreas.

On Fri, Mar 15, 2019 at 04:22:50PM +0100, Andreas Tille wrote:
> Hi,
> 
> On Fri, Mar 15, 2019 at 02:12:57PM +0100, Ondrej Novy wrote:
> > Hi,
> > 
> > ne 24. 2. 2019 v 20:39 odesílatel Andreas Tille  napsal:
> > 
> > > I just have push permissions for python-team/modules but when I tried
> > > to push changes to atheist to fix #918827, I have no commit permissions
> > > to https://salsa.debian.org/python-team/applications/atheist .
> > >
> > 
> > you need to request access to second (sub-)team independently and accept
> > PAPT policy.
> 
> Well, I hope my mail qualifies as "request access" and I confirm I have
> read
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> and that I accept it.
> 
> Kind regards
> 
>  Andreas.

-- 
http://fam-tille.de



Re: Please enable me pushing to python-team/applications

2019-03-15 Thread Andreas Tille
Hi,

On Fri, Mar 15, 2019 at 02:12:57PM +0100, Ondrej Novy wrote:
> Hi,
> 
> ne 24. 2. 2019 v 20:39 odesílatel Andreas Tille  napsal:
> 
> > I just have push permissions for python-team/modules but when I tried
> > to push changes to atheist to fix #918827, I have no commit permissions
> > to https://salsa.debian.org/python-team/applications/atheist .
> >
> 
> you need to request access to second (sub-)team independently and accept
> PAPT policy.

Well, I hope my mail qualifies as "request access" and I confirm I have
read
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
and that I accept it.

Kind regards

 Andreas.

-- 
http://fam-tille.de



Re: Please enable me pushing to python-team/applications

2019-03-06 Thread Andreas Tille
Hi again,

On Sun, Feb 24, 2019 at 08:39:03PM +0100, Andreas Tille wrote:
> I just have push permissions for python-team/modules but when I tried
> to push changes to atheist to fix #918827, I have no commit permissions
> to https://salsa.debian.org/python-team/applications/atheist .

Meanwhile atheist entered testing.  I'd love to push my local changes.

Thank you

Andreas.

-- 
http://fam-tille.de



Please enable me pushing to python-team/applications

2019-02-24 Thread Andreas Tille
Hi,

I just have push permissions for python-team/modules but when I tried
to push changes to atheist to fix #918827, I have no commit permissions
to https://salsa.debian.org/python-team/applications/atheist .

Kind regards

Andreas.

-- 
http://fam-tille.de



  1   2   3   4   >