How can I override module name in autopkgtest-pkg-python
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
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
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."
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
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')
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')
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)
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...)
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...)
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
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
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))
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))
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)
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
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
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)
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)
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
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
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)
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)
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)
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)
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
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
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
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)
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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)
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)
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)
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))
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))
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))
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))
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))
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))
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))
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)
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
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
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
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
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)
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?
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')
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')
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')
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')
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)
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
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
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)
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
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)
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
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
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
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)
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
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
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])
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
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
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])
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
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
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: ...))
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: ...))
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
