Bug#960756: python-biopython FTBFS on 32bit: test_NCBI_BLAST_tools.BlastDB failures
Perhaps makeblastdb itself failed (and our wrapper didn't notice)? Those
are the first files looked for after calling makeblastdb, to see if it
could make a BLAST database. Are there any GenBank/NC_005816.fna.n* or
GenBank/NC_005816.faa.p* files present?
If it helps, the commands our script was trying to run were:
$ makeblastdb -dbtype nucl -in GenBank/NC_005816.fna \
-parse_seqids -hash_index -max_file_sz 20MB -taxid 10
and:
$ makeblastdb -dbtype prot -in GenBank/NC_005816.faa \
-parse_seqids -hash_index -max_file_sz 20MB -taxid 10
I'm not sure I have remote access to any 32bit machines right now...
Peter
On Sat, May 16, 2020 at 2:22 PM Andreas Tille wrote:
> Control: tags -1 upstream
> Control: forwarded -1 Peter Cock
>
> Hi Peter,
>
> it seems the patch applied does not work for 32bit architectures.
>
> Kind regards
>
> Andreas.
>
> On Sat, May 16, 2020 at 02:25:20PM +0300, Adrian Bunk wrote:
> > Source: python-biopython
> > Version: 1.76+dfsg-2
> > Severity: serious
> > Tags: ftbfs
> >
> >
> https://buildd.debian.org/status/package.php?p=python-biopython&suite=sid
> >
> > ...
> > ==
> > FAIL: test_fasta_db_nucl (test_NCBI_BLAST_tools.BlastDB)
> > Test makeblastdb wrapper with nucleotide database.
> > --
> > Traceback (most recent call last):
> > File
> "/<>/.pybuild/cpython3_3.8/build/Tests/test_NCBI_BLAST_tools.py",
> line 249, in test_fasta_db_nucl
> > self.assertTrue(os.path.isfile("GenBank/NC_005816.fna.nhd"))
> > AssertionError: False is not true
> >
> > ==
> > FAIL: test_fasta_db_prot (test_NCBI_BLAST_tools.BlastDB)
> > Test makeblastdb wrapper with protein database.
> > --
> > Traceback (most recent call last):
> > File
> "/<>/.pybuild/cpython3_3.8/build/Tests/test_NCBI_BLAST_tools.py",
> line 208, in test_fasta_db_prot
> > self.assertTrue(os.path.isfile("GenBank/NC_005816.faa.phd"))
> > AssertionError: False is not true
> >
> > --
> > Ran 518 tests in 330.272 seconds
> >
> > FAILED (failures = 1)
> > Skipping any tests requiring internet access
> > Python version: 3.8.3 (default, May 14 2020, 11:03:12)
> > [GCC 9.3.0]
> > Operating system: posix linux
> > E: pybuild pybuild:352: test: plugin custom failed with: exit code=1:
> set -e; \
> > mkdir -p
> /<>/.pybuild/cpython3_3.8/build/home; \
> > mkdir -p
> /<>/.pybuild/cpython3_3.8/build/Doc/examples; \
> > cp -a Doc/Tutorial.tex
> /<>/.pybuild/cpython3_3.8/build/Doc; \
> > cp -a Doc/Tutorial
> /<>/.pybuild/cpython3_3.8/build/Doc; \
> > cp -a Doc/examples
> /<>/.pybuild/cpython3_3.8/build/Doc; \
> > cp -a Tests
> /<>/.pybuild/cpython3_3.8/build; \
> > cd
> /<>/.pybuild/cpython3_3.8/build/Tests; \
> > env DIALIGN2_DIR=/usr/share/dialign
> EMBOSS_ROOT=/usr/lib/emboss
> HOME=/<>/.pybuild/cpython3_3.8/build/home python3.8
> run_tests.py --offline
> > dh_auto_test: error: pybuild --test -i python{version} -p 3.8 --test
> --system=custom "--test-args=set -e; \\\
> > mkdir -p {build_dir}/home; \\\
> > mkdir -p {build_dir}/Doc/examples; \\\
> > cp -a Doc/Tutorial.tex {build_dir}/Doc; \\\
> > cp -a Doc/Tutorial {build_dir}/Doc; \\\
> > cp -a Doc/examples {build_dir}/Doc; \\\
> > cp -a Tests {build_dir}; \\\
> > cd {build_dir}/Tests; \\\
> > env DIALIGN2_DIR=/usr/share/dialign
> EMBOSS_ROOT=/usr/lib/emboss HOME={build_dir}/home {interpreter}
> run_tests.py --offline" returned exit code 13
> > make[1]: *** [debian/rules:83: override_dh_auto_test] Error 25
> >
> > ___
> > 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
>
Bug#959587: Info received (Bug#959587: python-biopython: FTBFS: AssertionError: False is not true)
The small patch on this pull request ought to solve the immediate Debian testing issue for biopython: https://github.com/biopython/biopython/pull/2890 Peter On Wed, May 6, 2020 at 3:06 PM Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Thank you for the additional information you have supplied regarding > this Bug report. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian Med Packaging Team > > If you wish to submit further information on this problem, please > send it to 959...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 959587: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959587 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#959587: python-biopython: FTBFS: AssertionError: False is not true
Thanks for the heads up, logged as: On Tue, May 5, 2020 at 7:40 PM Andreas Tille wrote: > Control: tags -1 upstream > Control: forwarded -1 Peter Cock > > Hi Peter, > > with the upload of ncbi-blast+ version 2.10 Biopython test is running > into failures (see > >https://bugs.debian.org/959587#10 > > ) > > Could you please adjust the Biopython test suite accordingly? > > Kind regards > > Andreas. > > On Tue, May 05, 2020 at 11:38:23AM -0400, Aaron M. Ucko wrote: > > > > > Since there is a strong relation in time with your upload and this > > > FTBFS of biopython do you think that this could be connected: > > > > Yes, per https://www.ncbi.nlm.nih.gov/books/NBK131777/, the upgrade to > > 2.10.0 changed the default database version (controlled by makeblastdb's > > -blastdb_version flag) from 4 to 5, causing some output files to change > > names (and formats): > > > > *.nsd -> *.nnd > > *.nsi -> *.nni > > *.psd -> *.pnd > > *.psi -> *.pni > > > > Thanks for checking! > > -- > http://fam-tille.de >
Bug#959587: python-biopython: FTBFS: AssertionError: False is not true
Thanks for the heads up, logged as: https://github.com/biopython/biopython/issues/2863 Peter On Tue, May 5, 2020 at 7:40 PM Andreas Tille wrote: > Control: tags -1 upstream > Control: forwarded -1 Peter Cock > > Hi Peter, > > with the upload of ncbi-blast+ version 2.10 Biopython test is running > into failures (see > >https://bugs.debian.org/959587#10 > > ) > > Could you please adjust the Biopython test suite accordingly? > > Kind regards > > Andreas. > > On Tue, May 05, 2020 at 11:38:23AM -0400, Aaron M. Ucko wrote: > > > > > Since there is a strong relation in time with your upload and this > > > FTBFS of biopython do you think that this could be connected: > > > > Yes, per https://www.ncbi.nlm.nih.gov/books/NBK131777/, the upgrade to > > 2.10.0 changed the default database version (controlled by makeblastdb's > > -blastdb_version flag) from 4 to 5, causing some output files to change > > names (and formats): > > > > *.nsd -> *.nnd > > *.nsi -> *.nni > > *.psd -> *.pnd > > *.psi -> *.pni > > > > Thanks for checking! > > -- > http://fam-tille.de >
Bug#956324: python-biopython: FTBFS on mipsel
I agree this is most likely a clustalo error. I think the first two examples use temporary input files created during the Biopython tests. However, the third failing example ought to be useful in isolation: clustalo -i Fasta/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force The input file is here (plain text with no extension): https://github.com/biopython/biopython/blob/master/Tests/Fasta/f002 Peter On Fri, Apr 10, 2020 at 6:29 AM Andreas Tille wrote: > Control: forwarded -1 Peter Cock > > Hi Peter, > > the log that is linked to below says in the end: > > > == > ERROR: test_input_filename_with_space > (test_ClustalOmega_tool.ClustalOmegaTestNormalConditions) > Test an input filename containing a space. > -- > Traceback (most recent call last): > File > "/<>/.pybuild/cpython3_3.8/build/Tests/test_ClustalOmega_tool.py", > line 175, in test_input_filename_with_space > self.standard_test_procedure(cline) > File > "/<>/.pybuild/cpython3_3.8/build/Tests/test_ClustalOmega_tool.py", > line 63, in standard_test_procedure > output, error = cline() > File > "/<>/.pybuild/cpython3_3.8/build/Bio/Application/__init__.py", > line 530, in __call__ > raise ApplicationError(return_code, str(self), > Bio.Application.ApplicationError: Non-zero return code 138 from 'clustalo > -i "Clustalw/temp horses.fasta" -o temp_test.aln --outfmt clustal --force', > message 'Bus error' > > == > ERROR: test_large_fasta_file > (test_ClustalOmega_tool.ClustalOmegaTestNormalConditions) > Test a large fasta input file. > -- > Traceback (most recent call last): > File > "/<>/.pybuild/cpython3_3.8/build/Tests/test_ClustalOmega_tool.py", > line 210, in test_large_fasta_file > self.standard_test_procedure(cline) > File > "/<>/.pybuild/cpython3_3.8/build/Tests/test_ClustalOmega_tool.py", > line 63, in standard_test_procedure > output, error = cline() > File > "/<>/.pybuild/cpython3_3.8/build/Bio/Application/__init__.py", > line 530, in __call__ > raise ApplicationError(return_code, str(self), > Bio.Application.ApplicationError: Non-zero return code 138 from 'clustalo > -i temp_cw_prot.fasta -o temp_cw_prot.aln --outfmt clustal --force', > message 'Bus error' > > == > ERROR: test_newtree_files > (test_ClustalOmega_tool.ClustalOmegaTestNormalConditions) > Test requesting a guide tree. > -- > Traceback (most recent call last): > File > "/<>/.pybuild/cpython3_3.8/build/Tests/test_ClustalOmega_tool.py", > line 224, in test_newtree_files > self.standard_test_procedure(cline) > File > "/<>/.pybuild/cpython3_3.8/build/Tests/test_ClustalOmega_tool.py", > line 63, in standard_test_procedure > output, error = cline() > File > "/<>/.pybuild/cpython3_3.8/build/Bio/Application/__init__.py", > line 530, in __call__ > raise ApplicationError(return_code, str(self), > Bio.Application.ApplicationError: Non-zero return code 138 from 'clustalo > -i Fasta/f002 --guidetree-out temp_test.dnd -o temp_test.aln --outfmt > clustal --force', message 'Bus error' > > -- > > > I'm not sure whether you have any clue about this since it looks rather > like a clustalo issue - but I guess you could be interested. Please let > us know what you think about this. > > Kind regards > >Andreas. > > On Thu, Apr 09, 2020 at 10:38:04PM +0200, Sebastian Ramacher wrote: > > Source: python-biopython > > Version: 1.76+dfsg-1 > > Severity: serious > > Tags: ftbfs sid bullseye > > Justification: fails to build from source (but built successfully in the > past) > > > > python-biopython failed to build on mipsel: > > > https://buildd.debian.org/status/fetch.php?pkg=python-biopython&arch=mipsel&ver=1.76%2Bdfsg-1%2Bb1&stamp=1586419338&raw=0 > > > > Cheers > > -- > > Sebastian Ramacher > > > > > ___ > > 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 >
Bug#944242: Test issues with BioPython 1.75
We (upstream) have just released Biopython 1.76 which thanks to the Debian team's feedback from 1.75 should be less problematic on alternative CPUs: https://www.open-bio.org/2019/12/20/biopython-1-76-released/ https://pypi.python.org/pypi/biopython/1.76 These are the commits which I think you might want to consider back-porting for the Biopython 1.75 package if there are still problems with the Debian tests: https://github.com/biopython/biopython/commit/4045706f7ccb4a55421071fbfa7a9bdc242c4004 https://github.com/biopython/biopython/commit/8ebe305a6bfd8efd7470b8dd2c49d20d046f6196 https://github.com/biopython/biopython/commit/f82deab3f37739ffe1811a96bc30c0d73d1f14b5 Michael Crusoe has assisted in getting ARM64 etc included as part of our usual TravisCI testing (although they do sometimes timeout), which hopefully will stop this particular problem reoccurring. Thank you all, Peter
Bug#937606: Droping Python2 support for Biopython
We (upstream) have just released Biopython 1.76 which should be the final release to support Python 2 anyway: https://www.open-bio.org/2019/12/20/biopython-1-76-released/ https://pypi.python.org/pypi/biopython/1.76 Peter On Thu, Dec 12, 2019 at 1:02 PM Andreas Tille wrote: > > Control: tags -1 pending > > Hi, > > I just removed Python2 support for Biopython in Git since I managed to > port the latest reverse dependencies requiring python-biopython > yesterday. I'm hesitating to upload since Michael is discussing test > suite errors on arm64 with upstream. > > I wonder whether we should upload anyway after excluding the test in > question and file a bug report about this to make sure it will not be > forgotten. This bug report could also serve as a sensible place to > discuss that issue. > > Kind regards > >Andreas. > > -- > http://fam-tille.de >
Bug#944242: Test issues with BioPython 1.75
Yes, ignore that one please. That test has since been disabled (and replaced with a more robust one). We eventually traced test_chapter_align_line_02819 failing on 32 bit systems with a different overflow error: https://github.com/biopython/biopython/pull/2297 Thanks, Peter On Wed, Dec 4, 2019 at 4:22 PM Andreas Tille wrote: > > On Wed, Dec 04, 2019 at 01:55:26PM +, Peter Cock wrote: > > Good. If you are still missing Tests/Fasta/flowers.pro.gz that's odd, > > since it was in the official tar ball: > > > > https://files.pythonhosted.org/packages/33/55/becf2b99556588d22b542f3412990bfc79b674e198d9bc58f7bbc333439e/biopython-1.75.tar.gz > > Arghh again. The test script is unzipping all files before running the > test since in the Debian doc dir most files are gzipped. After gzipping > it again this test is fine. > > So the only remaining issue is: > > == > ERROR: test_doctests (test_Tutorial.TutorialTestCase) > Run tutorial doctests. > -- > Traceback (most recent call last): > File "/tmp/autopkgtest.hiPio2/autopkgtest_tmp/Tests/test_Tutorial.py", line > 260, in test_doctests > (len(failures), ", ".join(failures))) > ValueError: 1 Tutorial doctests failed: test_chapter_align_line_02819 > > -- > Ran 194 tests in 204.479 seconds > > > and I think we agreed that I'll ignore this test. > > Kind regards > > Andreas. > > -- > http://fam-tille.de
Bug#944242: Test issues with BioPython 1.75
Good. If you are still missing Tests/Fasta/flowers.pro.gz that's odd,
since it was in the official tar ball:
https://files.pythonhosted.org/packages/33/55/becf2b99556588d22b542f3412990bfc79b674e198d9bc58f7bbc333439e/biopython-1.75.tar.gz
Peter
On Tue, Dec 3, 2019 at 9:13 PM Andreas Tille wrote:
>
> Hi Peter,
>
> On Mon, Dec 02, 2019 at 03:42:21PM +, Peter Cock wrote:
> > This was included in Biopython 1.74 and 1.75, yet your copy of
> > Tests/test_psw.py
> > would seem to date from Biopython 1.73 or older.
> >
> > I suspect an old cached copy of the test folder is largely to blame?
>
> Arghhh, sorry for wasting your time. The test examples are in
> python-biopython-doc package which I forgot to update on my local
> machine. I just get:
>
> ==
> ERROR: test_gzip_fasta (test_SeqIO.TestZipped)
> Testing FASTA with gzip.
> --
> Traceback (most recent call last):
> File "/tmp/autopkgtest.vFO6HI/autopkgtest_tmp/Tests/test_SeqIO.py", line
> 156, in test_gzip_fasta
> with gzip.open("Fasta/flowers.pro.gz", mode) as handle:
> File "/usr/lib/python2.7/gzip.py", line 34, in open
> return GzipFile(filename, mode, compresslevel)
> File "/usr/lib/python2.7/gzip.py", line 94, in __init__
> fileobj = self.myfileobj = __builtin__.open(filename, mode or 'rb')
> IOError: [Errno 2] No such file or directory: 'Fasta/flowers.pro.gz'
>
> ==
>
>
> (now with the real data).
>
> Kind regards
>
> Andreas.
>
> --
> http://fam-tille.de
Bug#944242: Test issues with BioPython 1.75
There are indeed a LOT of errors in there (and a sprinkling of harmless warnings which ought really to be silenced within the test framework). Picking on the very last one as a simple case, you got: ``` == FAIL: test_ColumnUnit (test_psw.TestPSW) -- Traceback (most recent call last): File "/tmp/python-biopython-test.HGclMQ/Tests/test_psw.py", line 75, in test_ColumnUnit "ColumnUnit(unit=0, column=33, SEQUENCE)") AssertionError: "ColumnUnit(unit=0, column=33, kind='SEQUENCE')" != 'ColumnUnit(unit=0, column=33, SEQUENCE)' - ColumnUnit(unit=0, column=33, kind='SEQUENCE') ? --- + ColumnUnit(unit=0, column=33, SEQUENCE) ``` This change relates to adding __repr__ to some of the PSW objects, https://github.com/biopython/biopython/commit/37f235066616c950a6b4b5544785a5c4a88f1ea1 This was included in Biopython 1.74 and 1.75, yet your copy of Tests/test_psw.py would seem to date from Biopython 1.73 or older. I suspect an old cached copy of the test folder is largely to blame? Peter On Mon, Dec 2, 2019 at 3:28 PM Andreas Tille wrote: > > Hi Peter, > > On Wed, Nov 20, 2019 at 01:36:50PM +0100, Andreas Tille wrote: > > > > > > https://github.com/biopython/biopython/issues/2350 > > Since I urgently need Biopython >= 1.74 to fix some other bugs I decided > to try to ignore those issues we discussed here and made sure that build > time tests will not fail. However the Debian package is also running a > Continuous Integration test (autopkgtest in Debian terminology). The > test for biopython is basically copying the test files to a temporary dir > and execute the tests[1]. > > In the attached log I injected a `set -x` and was running: > >sh run-unit-test 2>&1 | tee > tes_suite_errors.out > > Unfortunately there are more errors than I expected. Do you have any > idea why? > > Kind regards > > Andreas. > > > [1] > https://salsa.debian.org/med-team/python-biopython/blob/master/debian/tests/run-unit-test > > -- > http://fam-tille.de
Bug#944242: Test issues with BioPython 1.75
It seems we have some invalid doctests in the C code (which might reveal a bug or two, but are mostly likely harmless oversights). There is some key difference in your build setup and our continuous integration which is not looking at the C code's docstests: https://github.com/biopython/biopython/issues/2350 Peter Peter On Tue, Nov 19, 2019 at 10:25 PM Andreas Tille wrote: > > On Tue, Nov 19, 2019 at 10:03:25AM +0000, Peter Cock wrote: > > > > Do you have a list of things still depending on Biopython & Python 2.7 > > handy? We're discussing when exactly to drop Python 2.7 support - > > with a final compatible release in December 2019 or January 2020 > > looking most likely. > > Speaking about droping Python2 and just running tests with Python3 > I was running into other errors: > > == > FAIL: kmedoids (Bio.Cluster._cluster) > Doctest: Bio.Cluster._cluster.kmedoids > -- > Traceback (most recent call last): > File "/usr/lib/python3.8/doctest.py", line 2196, in runTest > raise self.failureException(self.format_failure(new.getvalue())) > AssertionError: Failed doctest test for Bio.Cluster._cluster.kmedoids > File > "/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so", > line unknown line number, in kmedoids > > -- > File > "/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so", > line ?, in Bio.Cluster._cluster.kmedoids > Failed example: > distance = array([[0.0, 1.1, 2.3], > [1.1, 0.0, 4.5], > [2.3, 4.5, 0.0]]) > Exception raised: > Traceback (most recent call last): > File "/usr/lib/python3.8/doctest.py", line 1328, in __run > exec(compile(example.source, filename, "single", > File "", line 1, in > distance = array([[0.0, 1.1, 2.3], > NameError: name 'array' is not defined > -- > File > "/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so", > line ?, in Bio.Cluster._cluster.kmedoids > Failed example: > distance = array([1.1, 2.3, 4.5]) > Exception raised: > Traceback (most recent call last): > File "/usr/lib/python3.8/doctest.py", line 1328, in __run > exec(compile(example.source, filename, "single", > File "", line 1, in > distance = array([1.1, 2.3, 4.5]) > NameError: name 'array' is not defined > -- > File > "/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so", > line ?, in Bio.Cluster._cluster.kmedoids > Failed example: > distance = [array([]), > array([1.1]), > array([2.3, 4.5])] > Exception raised: > Traceback (most recent call last): > File "/usr/lib/python3.8/doctest.py", line 1328, in __run > exec(compile(example.source, filename, "single", > File "", line 1, in > distance = [array([]), > NameError: name 'array' is not defined > > > == > FAIL: pca (Bio.Cluster._cluster) > Doctest: Bio.Cluster._cluster.pca > -- > Traceback (most recent call last): > File "/usr/lib/python3.8/doctest.py", line 2196, in runTest > raise self.failureException(self.format_failure(new.getvalue())) > AssertionError: Failed doctest test for Bio.Cluster._cluster.pca > File > "/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so", > line unknown line number, in pca > > -- > File > "/build/python-biopython-1.75+dfsg/.pybuild/cpython3_3.8/build/Bio/Cluster/_cluster.cpython-38-x86_64-linux-gnu.so", > line ?, in Bio.Cluster._cluster.pca > Failed example: > columnmean + dot(coordinates, pc) > Exception raised: > Traceback (most recent call last): > File "/usr/lib/python3.8/doctest.py", line 1328, in __run > exec(compile(example.source, filen
Bug#944242: Test issues with BioPython 1.75
On Tue, Nov 19, 2019 at 10:03 AM Peter Cock wrote: > > I mean I would not worry about this particular test failing - and would > consider whitelisting this test acceptable. > > Without yet being able to reproduce this and test it, does this work?: > > https://github.com/peterjc/biopython/commit/5af680b5043c9f160a19e4bb0deab0ccc271280d > If that works, this pull request will apply the change upstream to Biopython: https://github.com/biopython/biopython/pull/2347 Peter
Bug#944242: Test issues with BioPython 1.75
On Tue, Nov 19, 2019 at 9:43 AM Andreas Tille wrote: > > Hi Peter, > > I'd like to give you credit as the fastest upstream answering a > question. ;-) Thanks a lot for it! Lucky timing. > On Tue, Nov 19, 2019 at 09:17:17AM +, Peter Cock wrote: > > Curious - do you have the Python 2.7 version and build details? > > I've attached the full build log. Thanks - I'v had a quick look. There must be something different to how the build or installed directories are setup - our TravisCI tests do not pick up the C modules at all. > > Missing docstrings are unfortunate (and in this case they are in C > > code which is a bit different), but ultimately this is harmless. What > > puzzles me is what has triggered this, that we fail to see it on our > > own testing. > > Hmmm, you say its harmless but its breaking the build of the Debian > package anyway. So it would be good to have some means against it. I mean I would not worry about this particular test failing - and would consider whitelisting this test acceptable. Without yet being able to reproduce this and test it, does this work?: https://github.com/peterjc/biopython/commit/5af680b5043c9f160a19e4bb0deab0ccc271280d If not, we could explicitly exclude the C modules from testing, maybe here: https://github.com/biopython/biopython/blob/biopython-175/Tests/run_tests.py#L151 i.e. Add "Bio/KDTree/_CKDTree" etc to EXCLUDE_DOCTEST_MODULES (with the proviso that to date I've only used this with Python modules, you might need to include the .so extension?) > Since you are asking about the 2.7 version: We need to get rid of > Python2 as soon as all reverse depends of biopython are ported to > Python3 (or removed from Debian). This might take some time but if > we could move this kind of doc string generation to be done by Python3 > this would be some step in the right direction. Do you have a list of things still depending on Biopython & Python 2.7 handy? We're discussing when exactly to drop Python 2.7 support - with a final compatible release in December 2019 or January 2020 looking most likely. Peter
Bug#944242: Test issues with BioPython 1.75
Curious - do you have the Python 2.7 version and build details? Missing docstrings are unfortunate (and in this case they are in C code which is a bit different), but ultimately this is harmless. What puzzles me is what has triggered this, that we fail to see it on our own testing. As an aside, for Python 3.8 you would ideally include this, it didn't get in the tag or tar-ball, but was in the Python 3.8 wheels: https://github.com/biopython/biopython/commit/3b8e984e25bca84ea3cb56d8a1eb67006dcd26be Regards, Peter On Tue, Nov 19, 2019 at 8:27 AM Andreas Tille wrote: > > Hi, > > it seems that BioPython 1.75 has solved all issues with Python 3.8. > However, when trying to build the Debian package I get the following > issues in the Build-Time test suite: > > ... > == > ERROR: Bio.KDTree._CKDTree > -- > Traceback (most recent call last): > File "run_tests.py", line 367, in runTest > optionflags=doctest.ELLIPSIS) > File "/usr/lib/python2.7/doctest.py", line 2412, in DocTestSuite > raise ValueError(module, "has no docstrings") > ValueError: ( '/build/python-biopython-1.75+dfsg/.pybuild/cpython2_2.7/build/Bio/KDTree/_CKDTree.so'>, > 'has no docstrings') > == > ERROR: Bio.Nexus.cnexus > -- > Traceback (most recent call last): > File "run_tests.py", line 367, in runTest > optionflags=doctest.ELLIPSIS) > File "/usr/lib/python2.7/doctest.py", line 2412, in DocTestSuite > raise ValueError(module, "has no docstrings") > ValueError: ( '/build/python-biopython-1.75+dfsg/.pybuild/cpython2_2.7/build/Bio/Nexus/cnexus.so'>, > 'has no docstrings') > == > ERROR: Bio.PDB.QCPSuperimposer.qcprot > -- > Traceback (most recent call last): > File "run_tests.py", line 367, in runTest > optionflags=doctest.ELLIPSIS) > File "/usr/lib/python2.7/doctest.py", line 2412, in DocTestSuite > raise ValueError(module, "has no docstrings") > ValueError: ( '/build/python-biopython-1.75+dfsg/.pybuild/cpython2_2.7/build/Bio/PDB/QCPSuperimposer/qcprotmodule.so'>, > 'has no docstrings') > == > ERROR: Bio.PDB.kdtrees > -- > Traceback (most recent call last): > File "run_tests.py", line 367, in runTest > optionflags=doctest.ELLIPSIS) > File "/usr/lib/python2.7/doctest.py", line 2412, in DocTestSuite > raise ValueError(module, "has no docstrings") > ValueError: ( '/build/python-biopython-1.75+dfsg/.pybuild/cpython2_2.7/build/Bio/PDB/kdtrees.so'>, > 'has no docstrings') > -- > Ran 519 tests in 287.024 seconds > > FAILED (failures = 4) > Skipping any tests requiring internet access > Python version: 2.7.17 (default, Oct 19 2019, 23:36:22) > [GCC 9.2.1 20191008] > ... > > > Any hint how to solve this? > > Greetings from Biohackathon > > Andreas. > > -- > http://fam-tille.de
Bug#913064: ReportLab 3.5 breaking Biopython tests
Cross reference upstream Biopython issue: https://github.com/biopython/biopython/issues/1737 I think the following would suffice as a minimal patch, turning on the reportlab invariant mode. Regards, Peter -- diff --git a/Tests/test_GenomeDiagram.py b/Tests/test_GenomeDiagram.py index 457ca932df..a43f56a0a6 100755 --- a/Tests/test_GenomeDiagram.py +++ b/Tests/test_GenomeDiagram.py @@ -47,6 +47,9 @@ from Bio.Graphics.GenomeDiagram._Graph import GraphData from Bio.Graphics.GenomeDiagram._Colors import ColorTranslator +from reportlab import rl_config +rl_config.invariant = True + def fill_and_border(base_color, alpha=0.5): try:
Bug#880236: python-biopython: FTBFS: Test failures
The key part of the log http://aws-logs.debian.net/2017/10/30/python-biopython_1.70+dfsg-2_unstable.log is this bit: == FAIL: test_index (test_BWA_tool.BwaTestCase) Test for creating index files for the reference genome fasta file -- Traceback (most recent call last): File "/<>/python-biopython-1.70+dfsg/.pybuild/pythonX.Y_2.7/build/Tests/test_BWA_tool.py", line 102, in test_index % (cmdline, stdout)) AssertionError: FASTA indexing failed: bwa index -a bwtsw BWA/human_g1k_v37_truncated.fasta Stdout: -- This has been reported upstream, and we suspect it is due to a change in the command line tool bwa: https://github.com/biopython/biopython/issues/1431
Bug#872222: python-biopython: broken symlinks
As part of Biopython 1.69 we renamed the extension-less text files to *.rst and created symlinks intended for backward compatibility: https://github.com/biopython/biopython/commit/91e7eb02c2bbc1b91949171947b226c9fa09ace2 https://github.com/biopython/biopython/commit/4677c7def7e906ae2494dfcc4ecd590f46050366 Both the *.rst files and the symlinks should be included in the Biopython release tar-ball via our MANIFEST.in file: https://github.com/biopython/biopython/commit/9e7a01dbd88d239c0efc397f924cbbc65d6ac8ee My guess is that Debian needs to move/copy the new *.rst files now (eg NEWS.rst), in addition to or instead of the old names which are now symlinks (eg NEWS). (As some point I'd be happy to remove the symlinks) Peter
Bug#824048: Any change in blastp? (Was: Bug#824048: python-biopython: FTBFS: AssertionError: 10 != 1)
Great - I'm glad that made sense, my email had more typos than usual as I was in a hurry to leave the office earlier. Thanks, Peter On Thu, May 19, 2016 at 4:20 PM, Andreas Tille wrote: > Hi Peter, > > I've just uploaded a package featuring the patch. > > Thanks a lot for the quick and helpful response > > Andreas. > > On Thu, May 19, 2016 at 03:31:59PM +0100, Peter Cock wrote: >> RE: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824048 >> >> I've committed this as "fix", >> >> https://github.com/biopython/biopython/commit/cb5b8f7cf16dfa9aada8d3c71ab8d588ebf0693f >> >> This was a sanity test which failed due to a change in the NCBI output. >> >> We don't currently try to parse the plain text output in this test >> (the NCBI discourage parsing the plain text output, and we'd like >> to drop our plain text BLAST parser anyway). >> >> If it is easier, you could just comment out or remote this for >> the Biopython 1.66 Debian package? >> >> Thanks for letting us know, >> >> Peter >> > > -- > http://fam-tille.de
Bug#824048: Any change in blastp? (Was: Bug#824048: python-biopython: FTBFS: AssertionError: 10 != 1)
RE: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824048 I've committed this as "fix", https://github.com/biopython/biopython/commit/cb5b8f7cf16dfa9aada8d3c71ab8d588ebf0693f This was a sanity test which failed due to a change in the NCBI output. We don't currently try to parse the plain text output in this test (the NCBI discourage parsing the plain text output, and we'd like to drop our plain text BLAST parser anyway). If it is easier, you could just comment out or remote this for the Biopython 1.66 Debian package? Thanks for letting us know, Peter
Bug#813262: python-biopython: FTBFS: ApplicationError: Non-zero return code 255 from 'phyml -i Phylip/interlaced2.phy -d aa'
On Mon, Feb 1, 2016 at 12:08 PM, Andreas Tille wrote: > Hi Peter, > > ... > > Yes. BioPython is OK - I need to reassign the bug - probably to > libhmsbeagle-dev which is possibly not featuring the correct > dependencies. I just wanted to investigate the issue before I > do the reassigning since for the moment it is just the BioPython > *package* *in* *debian* that fails. Understood. > ... > > My plan for this years GSoC is to find a student who could add as much > testing to Debian Med packages as possible. In this sense BioPython is > a great test suite since it somehow adds tests to those packages that > come without one. :-) Nice idea. We might be able to do that under the Open Bioinformatics Foundation as a GSoC umbrella organisation if we're accepted into GSoC this year [I'm not directly involved but am on the OBF board]: http://mailman.open-bio.org/pipermail/open-bio-l/2016-January/001423.html The Biopython tests here are generally for our command line tool wrappers (and often catch changes to their command line API), and/or checking we can parse the latest output from the command line tools (Bioinformatics file formats are sadly often fluid). > Thanks again for getting involved into this bug report. I think > I will use the upcoming Debian Med sprint[1] to sort these things > out. I hope to come along to another Debian Med sprint next time one's close to home :) Thanks, Peter
Bug#813262: python-biopython: FTBFS: ApplicationError: Non-zero return code 255 from 'phyml -i Phylip/interlaced2.phy -d aa'
Hi all, I spotted this via an automated @DebianBug Twitter posting: https://twitter.com/DebianBug/status/693569490655776768 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813262 Andreas has dealt with other issues like this in the past, but I wanted to make this explicit on the issue tracker: This isn't a problem in Biopython itself, but a Biopython test case calling phyml indicates there is a problem with the Debian phyml package. Should the phyml GPU problem be filed under the phyml Debian package, perhaps adding a simple basic check to its tests?: phyml -i Phylip/interlaced2.phy -d aa This sample input test file is available here, also used as an example in the EMBOSS suite: https://github.com/biopython/biopython/blob/master/Tests/Phylip/interlaced2.phy I suspect any PHYLIP input file would work for checking the binary works and might help catch this apparent compilation issue earlier. Looking over the upstream Makefile it was not obvious that there is any testing like this being done at the moment, but there are example files likely to be useful for adding such a test: https://github.com/stephaneguindon/phyml Thanks, Peter (Biopython developer)
Bug#799820: python-biopython: FTBFS: No such file or directory: 'Phylip/interlaced2.phy_phyml_tree.txt'
Thanks Andreas, I've logged this as: https://github.com/biopython/biopython/issues/623 Which version of phyml is being used here? Eric - can you look at this please? Peter On Wed, Sep 23, 2015 at 12:48 PM, Andreas Tille wrote: > Hi BioPython developers, > > the problem is fixed by the patch you can find here: > > > https://anonscm.debian.org/viewvc/debian-med/trunk/packages/python-biopython/trunk/debian/patches/fix_test_phyml_tool.patch?view=markup > > Please review and include it in your next release. > > Kind regards and thanks for providing BioPython as free software > > Andreas. > > On Tue, Sep 22, 2015 at 11:30:39PM +0100, Chris West (Faux) wrote: >> Source: python-biopython >> Version: 1.65+dfsg-1 >> Severity: serious >> Justification: fails to build from source >> Tags: sid stretch >> User: reproducible-bui...@lists.alioth.debian.org >> Usertags: ftbfs >> X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org >> >> Dear Maintainer, >> >> The package fails to build: >> >> Bio.PDB.Selection docstring test ... ok >> == >> ERROR: test_phyml (test_phyml_tool.AppTests) >> Run PhyML using the wrapper. >> -- >> Traceback (most recent call last): >> File >> "/python-biopython-1.65+dfsg/.pybuild/pythonX.Y_2.7/build/Tests/test_phyml_tool.py", >> line 50, in test_phyml >> tree = Phylo.read(EX_PHYLIP + '_phyml_tree.txt', 'newick') >> File >> "/python-biopython-1.65+dfsg/.pybuild/pythonX.Y_2.7/build/Bio/Phylo/_io.py", >> line 65, in read >> tree = next(tree_gen) >> File >> "/python-biopython-1.65+dfsg/.pybuild/pythonX.Y_2.7/build/Bio/Phylo/_io.py", >> line 52, in parse >> with File.as_handle(file, 'r') as fp: >> File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__ >> return self.gen.next() >> File >> "/python-biopython-1.65+dfsg/.pybuild/pythonX.Y_2.7/build/Bio/File.py", line >> 90, in as_handle >> with open(handleish, mode, **kwargs) as fp: >> IOError: [Errno 2] No such file or directory: >> 'Phylip/interlaced2.phy_phyml_tree.txt' >> >> -- >> Ran 219 tests in 81.776 seconds >> >> FAILED (failures = 1) >> >> Full build log: >> https://reproducible.debian.net/rb-pkg/unstable/amd64/python-biopython.html >> >> -- System Information: >> Debian Release: stretch/sid >> APT prefers unstable >> APT policy: (500, 'unstable') >> Architecture: amd64 (x86_64) >> >> ___ >> Debian-med-packaging mailing list >> debian-med-packag...@lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging >> > > -- > http://fam-tille.de
Bug#751277: python-biopython: FTBFS on mips* powerpc s390x
On Thu, Aug 14, 2014 at 9:38 AM, Andreas Tille wrote: > Hi, > > On Tue, Aug 05, 2014 Peter Cock wrote >> > Unfortunately, on mips (BE) >> > test test_Cluster.py failed under Python 3.4. >> > Any progress on this issue? > >> No. See discussion on https://github.com/biopython/biopython/pull/340 > > Do you have any suggestion what to do regarding the Debian package? > I see the following options: > > 1. waiting for your confirmation / patch > 2. deactivating the specific test > 3. exclude mips for biopython > 4. ? any better idea ? > > In the current state all the work we spent in biopython over the last > monthes will not migrate to testing for the simple reason that the > current package in testing just does not run the test suite at build > time and moreover python3 is not supported. > > Kind regards > > Andreas. I would suggest (2), deactivate this test (at least for for mips) as the most practical short term solution for the Debian packages. Or if you prefer (3), don't target mips for the Biopython package (yet). Medium term, I hope we can fix the C code to handle either Endian platform - option (1). Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751277: python-biopython: FTBFS on mips* powerpc s390x
On Mon, Aug 4, 2014 at 6:10 PM, Dejan Latinovic wrote: > > Hello, > I took a look at test failures on mips/mipsel. > > Test that fails is based on a result of dnal tool. > dnal is part of a debian package wise. > > ... > > With this fix, package python-biopython > successfully builds for mipsel. > Patch that includes this fix is attached. That sounds useful for the wise package :) > Unfortunately, on mips (BE) > test test_Cluster.py failed under Python 3.4. > Any progress on this issue? No. See discussion on https://github.com/biopython/biopython/pull/340 Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751277: python-biopython: FTBFS on mips* powerpc s390x
On Mon, Jun 16, 2014 at 5:31 AM, Michiel de Hoon wrote: > >> This commit verifies the errors are thrown (and they are not > >> under Python 3 on the Mac): > >> > https://github.com/peterjc/biopython/commit/5b99854a82f08321ad78feaf0b362002d2d1fd2b > >> > >> I'm going to have to pass this one to Michiel to look at... but it > >> looks like a glitch in the bytes vs unicode handling, which for > >> some reason mostly works - but breaks under some unusual > >> platforms? > > Was there a bug report filed for this issue? Then I can have a look at it. > Best, > -Michiel There is now, https://github.com/biopython/biopython/pull/340 Peter P.S. A replacement mail server is being setup for lists.open-bio.org, waiting DNS propagation etc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751277: python-biopython: FTBFS on mips* powerpc s390x
On Fri, Jun 13, 2014 at 11:05 PM, Andreas Tille wrote: > Hi Peter, > > thanks for your quick response. > > On Fri, Jun 13, 2014 at 02:57:37PM +0100, Peter Cock wrote: >> > I have updated the Debian package to version 1.64 (BTW, it is fine to >> > ping debian-...@lists.debian.org about new upstream versions - we might >> > become more quick in packaging new versions). >> >> Good point. I used to email the Phillipe & Charles when there was >> a change I anticipated might cause trouble. >> >> Should we just email debian-...@lists.debian.org after each new >> Biopython release? > > Yes, that's perfectly OK. It might happen that certain persons might be > busy with other things. I also see no point to waste the chance to make > new versions of BioPython even more popular - so let readers of the > Debian Med list know about what you are doing. > >> If so we can add that to our build process: >> http://biopython.org/wiki/Building_a_release > > +1 Done. We can add other Linux etc packaging contacts too... >> > Jakub Wilk was kind enough to point to the real problems of the tests >> > which can be read below (since the end of the build log does not say >> > a lot). >> > >> > It would be great if you give some advise how to deal with these >> > problems. >> >> Most of these are tests where we call an external command line >> tool (i.e. muscle, dnal, dialign2-2). The purpose of the tests is >> in part to check our command line wrappers are current (and >> catch any API changes), but also in many cases to check we >> can parse the current output (to catch any format changes). >> >> I would *guess* that some of these platforms have problems >> in these underlying tools - or a very different version is being >> tested? i.e. Older than the mainstream platforms. > > Usually all these tools are in sync. However, not all of these are > tested since most are missing unit tests - so BioPython is a great > test for these tools. Indirectly yes :) >> -- >> >> The final category of failures was from test_Cluster.py under >> powerpc and s390x, under Python 3.4, which suggests it >> could be something in the C code for Bio.Cluster - probably >> Python 3 specific. >> >> From line 138-141, >> >> clusterid, error, nfound = kcluster(data, nclusters=nclusters, >> mask=mask, weight=weight, >> transpose=0, npass=100, >> method='a', dist='e') >> >> Line 210-212, >> >> distance = clusterdistance(data, mask=mask, weight=weight, >>index1=c1, index2=c2, dist='e', >>method='a', transpose=0) >> >> Line 289-290, >> >> tree = treecluster(data=data1, mask=mask1, weight=weight1, >>transpose=0, method='a', dist='e') >> >> Line 555-557, >> >> clusterid, celldata = somcluster(data=data, mask=mask, weight=weight, >> transpose=0, nxgrid=10, nygrid=10, >> inittau=0.02, niter=100, dist='e') >> >> This all give the following error via C function distance_converter >> in Bio/Cluster/clustermodule.c >> >> ValueError: distance should be a single character >> >> Yet in all those examples, dist='e' which is a single character... >> >> The good news is I can reproduce a related problem on Mac OS X >> under Python 3.3 and 3.4 where this error is not raised: >> >> Test branch: >> https://github.com/peterjc/biopython/tree/cluster_single_char >> >> This commit makes the error messages more explicit: >> https://github.com/peterjc/biopython/commit/fa597040cfb7e5f18d55257367397e88274563b8 >> >> This commit verifies the errors are thrown (and they are not >> under Python 3 on the Mac): >> https://github.com/peterjc/biopython/commit/5b99854a82f08321ad78feaf0b362002d2d1fd2b >> >> I'm going to have to pass this one to Michiel to look at... but it >> looks like a glitch in the bytes vs unicode handling, which for >> some reason mostly works - but breaks under some unusual >> platforms? > > I'll try to ask porters to check this patch on the different > architectures. I think Jakub is correct that the original problem is a big-endian issue, but it appears to have helped me spot a Python 3 specific problem in our error handling as well (the work on that branch). Thanks, Peter P.S. There is a problem with our mail server, which is being looked, at but some of these messages may have been lost and never appear on the Biopython archives :( -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751277: python-biopython: FTBFS on mips* powerpc s390x
Hi Andreas, Jakub, On Fri, Jun 13, 2014 at 1:55 PM, Andreas Tille wrote: > Hi BioPython developers, > > I have updated the Debian package to version 1.64 (BTW, it is fine to > ping debian-...@lists.debian.org about new upstream versions - we might > become more quick in packaging new versions). Good point. I used to email the Phillipe & Charles when there was a change I anticipated might cause trouble. Should we just email debian-...@lists.debian.org after each new Biopython release? If so we can add that to our build process: http://biopython.org/wiki/Building_a_release > Thanks for adopting the patches we sended to you. > No problem - while some of your tweaks are Debian specific, where it makes sense to incorporate fixes into Biopython we try to do that. > Since the Debian package is built on different hardware architectures, > we were facing different problems in the test suite. Here you have an > overview about all build logs: > > > https://buildd.debian.org/status/package.php?p=python-biopython&suite=unstable > > Jakub Wilk was kind enough to point to the real problems of the tests > which can be read below (since the end of the build log does not say > a lot). > > It would be great if you give some advise how to deal with these > problems. Most of these are tests where we call an external command line tool (i.e. muscle, dnal, dialign2-2). The purpose of the tests is in part to check our command line wrappers are current (and catch any API changes), but also in many cases to check we can parse the current output (to catch any format changes). I would *guess* that some of these platforms have problems in these underlying tools - or a very different version is being tested? i.e. Older than the mainstream platforms. -- The final category of failures was from test_Cluster.py under powerpc and s390x, under Python 3.4, which suggests it could be something in the C code for Bio.Cluster - probably Python 3 specific. >From line 138-141, clusterid, error, nfound = kcluster(data, nclusters=nclusters, mask=mask, weight=weight, transpose=0, npass=100, method='a', dist='e') Line 210-212, distance = clusterdistance(data, mask=mask, weight=weight, index1=c1, index2=c2, dist='e', method='a', transpose=0) Line 289-290, tree = treecluster(data=data1, mask=mask1, weight=weight1, transpose=0, method='a', dist='e') Line 555-557, clusterid, celldata = somcluster(data=data, mask=mask, weight=weight, transpose=0, nxgrid=10, nygrid=10, inittau=0.02, niter=100, dist='e') This all give the following error via C function distance_converter in Bio/Cluster/clustermodule.c ValueError: distance should be a single character Yet in all those examples, dist='e' which is a single character... The good news is I can reproduce a related problem on Mac OS X under Python 3.3 and 3.4 where this error is not raised: Test branch: https://github.com/peterjc/biopython/tree/cluster_single_char This commit makes the error messages more explicit: https://github.com/peterjc/biopython/commit/fa597040cfb7e5f18d55257367397e88274563b8 This commit verifies the errors are thrown (and they are not under Python 3 on the Mac): https://github.com/peterjc/biopython/commit/5b99854a82f08321ad78feaf0b362002d2d1fd2b I'm going to have to pass this one to Michiel to look at... but it looks like a glitch in the bytes vs unicode handling, which for some reason mostly works - but breaks under some unusual platforms? Thanks, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747494: python3-biopython: Does not use C implementations of cpairwise2 functions
Hi Andreas, This was reported directly to Biopython and fixed two months ago: https://github.com/biopython/biopython/pull/299 https://github.com/biopython/biopython/commit/daf3e3b5ba317fbbea1f7eebae3c5f8b06a40d6b If you want to apply the one line fix to Biopython 1.63 for the Debian Python 3 package, that would be great. Otherwise (under Python 3) the optimised C code is never used, just the pure Python fallback. (Note I'm hoping we can get Biopython 1.64 out later this month.) On a separate note, is there a mechanism to alert upstream projects (in this case Biopython) when a bug is reported in the Debian package? Thanks, Peter On Fri, May 9, 2014 at 12:55 PM, Andreas Tille wrote: > Hi, > > while I have just closed this bug report since I assumed it was a wrong > usage of the import statement I would like to forward this issue to > upstream Biopython developers anyway. It seems there are cases when > cpairwise2 is not used and things might work slower than necessary. > > I just forward this for your consideration to make sure that everything > works as expected from your side. > > Kind regards > > Andreas. > > On Fri, May 09, 2014 at 01:32:37PM +0200, Jakub Wilk wrote: >> * Andreas Tille , 2014-05-09, 13:15: >> >thanks for your bug report. I think this should work out of the >> >box but I personally not comfortable with cpython to know how this >> >could be fixed. I keep the Debian Python list in CC - perhaps >> >they might have some helpful advise. >> >> The relvant code in Bio/pairwaise2.py is: >> >> # Try and load C implementations of functions. If I can't, >> # then just ignore and use the pure python implementations. >> try: >>from cpairwise2 import rint, _make_score_matrix_fast >> except ImportError: >>pass >> >> But in Python 3 imports as always absolute, unless explicitly >> requested, so the import fails, and this code snippet is no-op. >> Changing the import line to: >> >>from .cpairwise2 import rint, _make_score_matrix_fast >> >> should do the trick. >> >> Before: >> $ python3 -c 'from Bio.pairwise2 import rint; print(rint.__module__)' >> Bio.pairwise2 >> >> After: >> $ python3 -c 'from Bio.pairwise2 import rint; print(rint.__module__)' >> Bio.cpairwise2 >> >> >It seems this module is not affected by the test suite since this >> >runs fine. >> >> Yeah, as the code comment says, if the import fails, everything(?) >> still works, just slower. >> >> -- >> Jakub Wilk >> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#746484: file not distributable
On Wed, Apr 30, 2014 at 2:30 PM, Andreas Tille wrote: > Hi Peter, > > thanks for your super-fast response. > > On Wed, Apr 30, 2014 at 02:24:42PM +0100, Peter Cock wrote: >> Are you specifically asking about Biopython 1.63 here? > > Yes. Since I have added python3 binary packages Biopython 1.63 went > through manual inspection by ftpmaster and this issue was noticed. Very through of them - thanks! Also thank you for doing the Debian Python3 packaging of Biopython :) >> I think you >> can reasonable exclude this DTD file (and any others under the >> Bio/Entrez/DTD file). Biopython 1.63 will warn if they are missing >> but attempt to download them automatically. > > OK. > >> We're looking at dropping all the NCBI Entrez related DTD files, >> since the next Biopython release (v1.64) will automatically download >> AND cache them - see recent discussion, e.g. >> >> http://lists.open-bio.org/pipermail/biopython-dev/2014-March/011205.html > > That's fine. > >> We haven't actually removed the files on GitHub yet, but this >> might be an incentive to do so. > > OK, meanwhile (as long as 1.64 is not yet released) I will remove the > file from the Debian archive. > > Thanks for the clarification > > Andreas. Great, Peter P.S. I'm skimming over the Debian patches to see what we can fix: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/python-biopython/trunk/debian/patches/ e.g. https://github.com/biopython/biopython/commit/2f098ac5311e0eec3d6737f4fff60e18c50b9481 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#746484: file not distributable
Hi Andreas, Are you specifically asking about Biopython 1.63 here? I think you can reasonable exclude this DTD file (and any others under the Bio/Entrez/DTD file). Biopython 1.63 will warn if they are missing but attempt to download them automatically. We're looking at dropping all the NCBI Entrez related DTD files, since the next Biopython release (v1.64) will automatically download AND cache them - see recent discussion, e.g. http://lists.open-bio.org/pipermail/biopython-dev/2014-March/011205.html We haven't actually removed the files on GitHub yet, but this might be an incentive to do so. Thanks, Peter On Wed, Apr 30, 2014 at 2:17 PM, Andreas Tille wrote: > Hello, > > our ftpmaster has detected an issue with one of the DTDs which are > distributed with BioPython source. > > I can confirm that after applying the following patch > > > --- a/Bio/Entrez/DTDs/modules.ent > +++ b/Bio/Entrez/DTDs/modules.ent > @@ -350,13 +350,6 @@ Version Reason/Occasion > "mathmlsetup.ent"> > > > - > - -PUBLIC > -"-//W3C//ENTITIES MathML 2.0 Qualified Names 1.0//EN" > -"mathml/mathml2-qname-1.mod" > > - > - > >"-//W3C//DTD MathML 2.0//EN" > > > the file in question can be removed from the archive without breaking > the build (including the test suite). I would like to suggest to drop > the file in question from your distribution tarball in case my analysis > that it is not needed is correct. > > Kind regards > > Andreas. > > On Wed, Apr 30, 2014 at 02:25:09PM +0200, Thorsten Alteholz wrote: >> Package: python-biopython >> Version: 1.63-2 >> Severity: serious >> User: alteh...@debian.org >> Usertags: ftp >> X-Debbugs-CC: ftpmas...@ftp-master.debian.org >> thanks >> >> Dear Maintainer, >> >> according to: >> http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231 >> the file >> biopython-1.63\Bio\Entrez\DTDs\mathml2-qname-1.mod >> may not be modified and such this file is not distributable in main. >> >> Thorsten >> >> ___ >> Debian-med-packaging mailing list >> debian-med-packag...@lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging >> > > -- > http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
