Bug#820060: Debian Bug#820060: python-biom-format: broken on big-endian architectures

[Liubov Chuprikova]

Hi Andreas,

It looks like the upstream fixed the issue in some recent version, as
according to the logs [1], the package builds now for big-endians as well.
Do you agree, that we can close the bug as well as the issue?

Best regards,
Liubov

[1] http://buildd.debian.org/python-biom-format

Bug#942404: Tests seem to work again

[Liubov Chuprikova]

Hi Paul,

I tried hard but wasn't able to reproduce the bug (in a clean chroot). Even
for the stable version (2.3.0-2) tests are passing (several times in a
row). Looking at the debci logs [1], tests are passing for quite some time.
Do you think, it makes sense to keep it longer?

Best regards,
Liubov

[1] https://ci.debian.net/packages/d/discosnp/unstable/amd64/

Bug#936802: kmer: Python2 removal in sid/bullseye

[Liubov Chuprikova]

Hi Andreas,

As I mentioned during today's Jitsi meeting, kmer builds and all the tests
passed in a clean sbuild schroot. Should we close the bug and make a
release then?

Regards,
Liubov

Bug#950842:

[Liubov Chuprikova]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/qiime2/qiime2/issues/520

Bug#950931: [rebecca_pal...@zoho.com: Bug#950931: q2templates: FTBFS with pandas 1.0: test failures]

[Liubov Chuprikova]

Hello,

The error seems to be related to this issue:
https://github.com/qiime2/q2templates/issues/41. We could possibly work on
it but the upstream is already going to fix the issue in the next release.

Best,
Liubov

Bug#940290: q2-types: triangular dependency with q2-types, q2cli

[Liubov Chuprikova]

Hi Andreas,

On Tue, 17 Sep 2019 at 14:39, Andreas Tille  wrote:

> Control: reassign -1 qiime
>
> Hi Liubov,
>
> On Tue, Sep 17, 2019 at 12:19:51PM +0200, Liubov Chuprikova wrote:
> > > This is the case if neither q2-types or q2cli are totally broken if
> > > qiime is not installed (do not import anything from qiime etc.)  If
> this
> > > assumption is wrong and both really need qiime to be installed than we
> > > should consider
> > >
> > >qiime: Recommends: q2cli, q2-types
> > >
> >
> > Yes, you are right, I have just moved q2 plugins into Recommends for
> qiime.
> > Is this OK that I made the required changes in qiime, but the bug will be
> > closed for q2-types?
>
> It should be OK.  The clean approach would be to reassign the bug - as I
> did above with this mail.
>

Thank you! I put the bug closure line in qiime and did the required changes.


> Just ping me if you are ready with the package (may be you intend more
> changes or so).
>

That's all for now, qiime is ready for upload!

Best regards,
Liubov


> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>

Bug#940290: q2-types: triangular dependency with q2-types, q2cli

[Liubov Chuprikova]

Hi Andreas,

On Tue, 17 Sep 2019 at 07:54, Andreas Tille  wrote:

> Hi Liubov,
>
> On Sun, Sep 15, 2019 at 12:18:45PM +0200, Bill Allombert wrote:
> > Package: q2-types
> > Version: 2019.7.0-1
> > Severity: important
> >
> > Hello Debian Med Packaging Team,
> >
> > There is a trianglar dependency between q2-types, q2cli and qiime:
> >
> > q2-types :Depends: qiime
> > q2cli  :Depends: qiime
> > qiime  :Depends: q2cli, q2-types
> >
> > Complex circular dependencies are known to cause problems during
> upgrade, so we
> > should try to avoid them.
>
> I think this can be broken by replacing the Depends by Recommends.  IMHO
> it could be:
>
>q2-types: Recommends: qiime
>
>
>q2cli   : Recommends: qiime
>
> This is the case if neither q2-types or q2cli are totally broken if
> qiime is not installed (do not import anything from qiime etc.)  If this
> assumption is wrong and both really need qiime to be installed than we
> should consider
>
>qiime: Recommends: q2cli, q2-types
>

Yes, you are right, I have just moved q2 plugins into Recommends for qiime.
Is this OK that I made the required changes in qiime, but the bug will be
closed for q2-types?

Best regards,
Liubov


> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>

Bug#932050: ITP: q2-taxa -- QIIME 2 plugin for working with feature taxonomy annotations

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: q2-taxa
  Version : 2019.4.0
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME 2 plugin for working with feature taxonomy
annotations
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome
analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used
analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis
pipeline.
 New functionality will regularly become available through QIIME 2 plugins.
You
 can view a list of plugins that are currently available on the QIIME 2
plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-taxa

Bug#932001: ITP: q2-feature-table -- QIIME 2 plugin supporting operations on feature tables

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: q2-feature-table
  Version : 2019.4.0
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME 2 plugin supporting operations on feature tables
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome
analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used
analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis
pipeline.
 New functionality will regularly become available through QIIME 2 plugins.
You
 can view a list of plugins that are currently available on the QIIME 2
plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-feature-table

Bug#931887: ITP: q2-feature-classifier -- QIIME 2 plugin supporting taxonomic classification

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: q2-feature-classifier
  Version : 2019.4.0
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME 2 plugin supporting taxonomic classification
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome
analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used
analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis
pipeline.
 New functionality will regularly become available through QIIME 2 plugins.
You
 can view a list of plugins that are currently available on the QIIME 2
plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-feature-classifier

Bug#931885: ITP: q2-quality-filter -- QIIME2 plugin for PHRED-based filtering and trimming

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: q2-quality-filter
  Version : 2019.4.0
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME2 plugin for PHRED-based filtering and trimming
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome
analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used
analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis
pipeline.
 New functionality will regularly become available through QIIME 2 plugins.
You
 can view a list of plugins that are currently available on the QIIME 2
plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-quality-filter

Bug#931249: ITP: q2-cutadapt -- QIIME 2 plugin to work with adapters in sequence data

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: q2-cutadapt
  Version : 2019.4.0
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME 2 plugin to work with adapters in sequence data
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome
analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used
analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis
pipeline.
 New functionality will regularly become available through QIIME 2 plugins.
You
 can view a list of plugins that are currently available on the QIIME 2
plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-cutadapt

Bug#930976: ITP: python-dnaio -- Python 3 library for fast parsing of FASTQ and FASTA files

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: python-dnaio
  Version : 0.3
  Upstream Author : Marcel Martin 
* URL : https://github.com/marcelm/dnaio
* License : MIT
  Programming Lang: Python
  Description : Python 3 library for fast parsing of FASTQ and FASTA
files
 dnaio is a Python 3 library for fast parsing of FASTQ and also FASTA files.
 The code was previously part of the cutadapt tool and has been improved
 since it has been split out.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/python-dnaio

Bug#930755: ITP: q2-metadata -- QIIME 2 plugin for working with and visualizing Metadata

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: q2-metadata
  Version : 2019.4.0
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME 2 plugin for working with and visualizing Metadata
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome
analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used
analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis
pipeline.
 New functionality will regularly become available through QIIME 2 plugins.
You
 can view a list of plugins that are currently available on the QIIME 2
plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-metadata

Bug#930152: ITP: q2-demux -- QIIME 2 plugin for demultiplexing of sequence reads

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: q2-demux
  Version : 2019.4.1
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME 2 plugin for demultiplexing of sequence reads
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome
analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used
analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis
pipeline.
 New functionality will regularly become available through QIIME 2 plugins.
You
 can view a list of plugins that are currently available on the QIIME 2
plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-demux

Bug#930151: ITP: q2templates -- Design template package for QIIME 2 Plugins

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: q2templates
  Version : 2019.4.0
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : Design template package for QIIME 2 Plugins
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome
analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used
analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis
pipeline.
 New functionality will regularly become available through QIIME 2 plugins.
You
 can view a list of plugins that are currently available on the QIIME 2
plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2templates

Bug#925909: [Help] Re: pbgenomicconsensus: autopkgtest regression

[Liubov Chuprikova]

Hi,

On Sun, 7 Apr 2019 at 11:30, Graham Inggs  wrote:

> Hi Andeas
>
> On Sun, 7 Apr 2019 at 07:50, Andreas Tille  wrote:
> > I have no idea why command1 is failing.  Anybody who can reproduce
> > this test result and can fix this test?
>
> The output of command1 is the following:
>
> autopkgtest [15:39:43]: test command1: unset GZIP && cp -r Makefile
> tests $AUTOPKGTEST_TMP && cd $AUTOPKGTEST_TMP && make tests
> autopkgtest [15:39:43]: test command1: [---
> # Unit tests
> # ignore tests requiring
> https://github.com/PacificBiosciences/PacBioTestData which is not
> packaged
> set -e ; \
> TMPDIR=$(mktemp -d /tmp/test_ignore_XX) ; \
> mv tests/unit/test_tool_contract.py ${TMPDIR} ; \
> py.test --junit-xml=nosetests.xml tests/unit ; \
> rm -rf tests/unit/__pycache__ ; \
> mv ${TMPDIR}/* tests/unit ; \
> rmdir ${TMPDIR}
> /bin/bash: line 3: py.test: command not found
> make: *** [Makefile:12: unit-tests] Error 127
> autopkgtest [15:39:44]: test command1: ---]
> autopkgtest [15:39:44]: test command1:  - - - - - - - - - - results -
> - - - - - - - - -
> command1 FAIL non-zero exit status 2
>
> I think all that is needed here is adding a test dependency on
> python-pytest.  See the 'available diffs' section on Steve Langasek's
> upload [1].
>

I have just added python-pytest and one more missing library. Now the tests
should pass.

With regards,
Liubov

Bug#925983: ITP: q2-alignment -- QIIME 2 plugin for generating and manipulating alignments

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: q2-alignment
  Version : 2019.1.0
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME 2 plugin for generating and manipulating
alignments
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome
analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used
analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis
pipeline.
 New functionality will regularly become available through QIIME 2 plugins.
You
 can view a list of plugins that are currently available on the QIIME 2
plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-alignment

Bug#925931: ITP: q2-types -- QIIME 2 plugin defining types for microbiome analysis

[Liubov Chuprikova]

Package: wnpp
Owner: Liubov Chuprikova 
Severity: wishlist

* Package name: q2-types
  Version : 2019.1.0
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME 2 plugin defining types for microbiome analysis
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome
analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used
analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis
pipeline.
 New functionality will regularly become available through QIIME 2 plugins.
You
 can view a list of plugins that are currently available on the QIIME 2
plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-types

Bug#925400: Processed: Bug#925400: ITP: q2cli -- Click-based command line interface for QIIME 2

[Liubov Chuprikova]

Dear Andreas,

On Sun, 24 Mar 2019 at 15:07, Andreas Tille  wrote:

> Dear Liubov,
>
> On Sun, Mar 24, 2019 at 12:30:03PM +, Debian Bug Tracking System wrote:
> > > owner 925400 Debian Med team 
> > Bug #925400 [wnpp] ITP: q2cli -- Click-based command line interface for
> QIIME 2
> > Owner changed from Liubov Chuprikova  to Debian
> Med team .
>
> While I think there is no harm done by changing the owner of this ITP
> bug its rather unusual.


Sorry for this mess! In the beginning, I set the bug owner to "Debian Med
Packaging Team " (just how I
did it earlier), but strangely it appeared truncated to "Debian Med
Packaging Team <". I was trying to fix this a couple of times. Then I had
tried to set the owner to "Debian Med team "
just to see if it also would appear truncated, but it was set properly.


> The changelog entry which will close the bug
> mentions your ID - so that ITP bug belongs to you and is closed by you.
>

Okay, next time I will set my ID then :-)

Just let me know if you consider the package ready for upload


Yes, I think it's ready for uploading. Thank you!

One more thing, related to QIIME 2. I have found recently that qiime2 and
q2cli are just frameworks for plugins [1][2] that do the real job. I am
fine with packaging all of them but in my case, it will not be very soon.
Are we in a big hurry to finish everything related to QIIME 2?

Un saludo,
Liubov

[1] https://docs.qiime2.org/2019.1/install/
[2] https://anaconda.org/qiime2/repo

Bug#922486: python3-sbml5: libsbml fails to import

[Liubov Chuprikova]

Hi Andreas,

On Sat, 2 Mar 2019 at 07:07, Andreas Tille  wrote:

> Hi Liubov,
>
> I've lost this a bit out of sight. Today is the last day for uploading
> anything without asking the release team for migration.

I definitely
> will not be able to work on the issue myself (sponsoring could be an
> option but not more).
>

I've found that the upstream dropped python3 support for this experimental
version [1],
maybe just temporarily. It is said here [2], they had some issues with
python3. They
recommend to install libsbml for python from PyPI [3], where the previous
5.17.0
version is the last one.

Un saludo,
Liubov

[1]
https://sourceforge.net/projects/sbml/files/libsbml/5.17.2-experimental/binaries/Linux/
[2] https://sourceforge.net/p/sbml/code/25696/
[3] https://pypi.org/project/python-libsbml/

Bug#907898: gmap: autopkgtest regression

[Liubov Chuprikova]

Hi Andreas,

I have just found the easiest bug to solve :-) This one was solved in the
very next version 2018-07-04-4 and since then the autopkgtest is passing
everywhere [1].

With regards,
Liubov

[1] https://ci.debian.net/packages/g/gmap/

Bug#912586: python-cobra still fails it's autopkg tests

[Liubov Chuprikova]

Hi,

I have just pushed a fix for this. In fact, the solution was proposed in
one of the previous messages [1]: the test suite was returning True some
time ago, but now it returns the exit code instead.

Some tests are `xfail`-ing (in the beginning I thought that's was the
problem) but as I understood they are expected to fail and that's why they
are ignored. For some other skipped tests, the extra dependencies are not
satisfied.

With regards,
Liubov

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

Bug#922486: python3-sbml5: libsbml fails to import

[Liubov Chuprikova]

Hi Andreas,

On Sat, 16 Feb 2019 at 22:43, Andreas Tille  wrote:

>
> If you see any chance to hunt this issue in libsbml down this would be
> really welcome.


I would like to fix this if I have time in the following week. I can't say
right now.

JFI: Just looking onto the files installed with the package, there is no
__init__.py
in the installation directory. So the question is whether it hasn't
generated during
the build or it just hasn't installed properly.

I'm busy with real life this weekend.
>

This is awesome! Have a nice weekend!

__
Liubov

Bug#922486: python3-sbml5: libsbml fails to import

[Liubov Chuprikova]

Package: python3-sbml5
Version: 5.17.2+dfsg-3
Severity: normal

Hi,

After installing python3-sbml5, it is not possible to import libsbml module:

Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'libsbml'

I have found it when I was looking into python-cobra package that has
python3-sbml5 in its extra dependencies.

Liubov

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#917143: t-coffee autopkgtest regression

[Liubov Chuprikova]

Hi Andreas,

On Sun, 27 Jan 2019 at 16:23, Andreas Tille  wrote:

> Control: tags -1 help upstream
> Control: forwarded -1 https://github.com/cbcrg/tcoffee/issues/13
>
> Hi Liubov,
>
> On Sun, Jan 27, 2019 at 04:06:51PM +0100, Liubov Chuprikova wrote:
> > I was trying to figure out the reason for the failure but without any
> > success. It appeared that the error is reproducible with the upstream's
> > source version, so I have just opened an issue [1] to inform the upstream
> > about this bug.
> >
> > [1] https://github.com/cbcrg/tcoffee/issues/13
>
> Thanks a lot,
>
>   Andreas.
>

I have just pushed a fix of this! The problem was with two processes
competing for the same temporary file, as the tempfile names were defined
static.

With regards,
Liubov

Bug#917143: t-coffee autopkgtest regression

[Liubov Chuprikova]

Hi,

I was trying to figure out the reason for the failure but without any
success. It appeared that the error is reproducible with the upstream's
source version, so I have just opened an issue [1] to inform the upstream
about this bug.

[1] https://github.com/cbcrg/tcoffee/issues/13

With regards,
Liubov

Bug#908599: ITP: unicycler -- hybrid assembly pipeline for bacterial genomes

[Liubov Chuprikova]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 

* Package name: unicycler
  Version : 0.4.7
  Upstream Author : Ryan R. Wick, Louise M. Judd, Claire L. Gorrie, Kathryn E. 
Holt
* URL : https://github.com/rrwick/Unicycler
* License : GPL-3+
  Programming Lang: C, Python
  Description : hybrid assembly pipeline for bacterial genomes
 Unicycler is an assembly pipeline for bacterial genomes. It can assemble
 Illumina-only read sets where it functions as a SPAdes-optimiser. It can
 also assembly long-read-only sets (PacBio or Nanopore) where it runs a
 miniasm+Racon pipeline. For the best possible assemblies, give it both
 Illumina reads and long reads, and it will conduct a hybrid assembly.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/unicycler

Bug#906980: kmer: autopkgtest fails with segfault in testing/unstable while it passes in stable

[Liubov Chuprikova]

Hi Andreas,

On Mon, 27 Aug 2018 at 17:02 Andreas Tille  wrote:

>
> Ah, finally a pretty simple solution for a quite hidden problem.
>

I admit I have expected something more serious :-)


> BTW, I wonder whether there are tools that would warn about issues
> described in[1] - I think there are good means to detect this
> automatically.
>

I checked clang-tidy and it can warn about such issues. One more tool I
would like to know now together with continuing of learning C.


> Would you please forward this solution to upstream?  May be once you
> contact upstream asking for a versioned release for download would be a
> good idea.
>

I wrote to upstream about the bug. Hope, they are interested in providing
new releases.


> Please note that I moved the data file into a separate package
> kmer-examples to avoid duplication of the data files and enable users
> installing the code without the data.  Thus the package needs to pass
> the new queue (hope this will happen soon).
>

Yes, thank you for this! I was not sure about putting data in a separate
package as the data were small and there were no lintian warnings about
this.

Thanks a lot for you fine work.  I think this issue is something you
> can be really proud about since your work uncovered an issue and you
> finally was able to fix it.


I was happy to finally delete kmer from my list as it was hanging for so
long :-P


> I really hope you will be able to
> continue this work even if GSoC is close to finished.  May be, if you
> have time you could continue a bit.

I'd be very happy about this.
>

Many, many thanks to you for mentoring me! I definitely have time till
September 10 before my master program starts. I would like to look into
unicycler and maybe something else.

With regards,
Liubov

Bug#906980: kmer: autopkgtest fails with segfault in testing/unstable while it passes in stable

[Liubov Chuprikova]

Hi Andreas,

On Thu, 23 Aug 2018 at 08:58 Andreas Tille  wrote:

>
> On Wed, Aug 22, 2018 at 09:42:13PM +0200, Liubov Chuprikova wrote:
> > An autopkgtest fails with segfault in testing and unstable [1].
> >
> > ```
> > /usr/bin/../lib/atac/bin/statsGenerator -a
> /tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/EcolivsSent.atac
> > -p
> /tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/stats/EcolivsSent
> > -g A >
> /tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/stats/EcolivsSent.stats
> >
> > Segmentation fault
> > Failed to ganerate statistics.
> > ```
> >
> > Notably, that building and testing in stable were successful (I tested
> > it in clean chroot). JFI, I tried installing an older version of gcc on
> > testing, the one that is used in stable (4:6.3.0-4), and this eliminated
> > the segfault.
>
> Thanks for this good catch which proves how important your Outreachy
> project is for providing stable and working packages in Debian Med.
>

Now I see!


> Thanks also for verifying that older compilers seem to produce working
> code while newer don't.
>

This seemed just something to go on.

I wonder whether you feel able to do some debugging what position of
> code causes the issue.

My first shout would be to grep for
>"Failed to ganerate statistics"
> which is probably in a wrapper around some code and than use some
> debugging techniques (either you are comfortable with gdb / want to
> become comfortable with gdb or simply use some
> printf("DEBUG %s(%i): ...", __FILE__, __LINE__, ...);
> statements in the code to watch what's happening.



> It might be helpful to lower / switch off optimisation options to see
> whether some optimisation feature of some later gcc will deal
> differently with some not properly specified code part.
>

Thanks a lot for your advise! I tried debugging with grep when I had just
caught the error for the first time, but it was without result at that
moment. Turning off optimization flags, as you recommended, also did not
help. After that I made one more attemp to debug with grep and printing
some statements and finally found what it is called classical non-bug in
gcc [1].

I have just uploaded a patch. Could you please sponsor an upload?

With regards,
Liubov

[1] https://gcc.gnu.org/bugs/#nonbugs_c

Bug#906980: kmer: autopkgtest fails with segfault in testing/unstable while it passes in stable

[Liubov Chuprikova]

Package: kmer
Version: 0~20150903+r2013-4
Severity: serious
Justification: reproducibility


An autopkgtest fails with segfault in testing and unstable [1].

```
/usr/bin/../lib/atac/bin/statsGenerator -a 
/tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/EcolivsSent.atac
-p 
/tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/stats/EcolivsSent
-g A > 
/tmp/autopkgtest-lxc.epng5fx9/downtmp/autopkgtest_tmp/results/stats/EcolivsSent.stats

Segmentation fault
Failed to ganerate statistics.
```

Notably, that building and testing in stable were successful (I tested
it in clean chroot). JFI, I tried installing an older version of gcc on
testing, the one that is used in stable (4:6.3.0-4), and this eliminated
the segfault.

[1] https://ci.debian.net/packages/k/kmer/

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#890787: (Bug#890787) fastdnaml: Please provide autopkgtest

[Liubov Chuprikova]

Hi Andreas,

I have just pushed an autopkgtest and other minor changes for
*fastdnaml* . Please,
take a look at the commits [1]!

With regards,
Liubov

[1] https://salsa.debian.org/med-team/fastdnaml/commits/master

Bug#890785: (Bug#890785) autodock-vina: Please provide autopkgtest

[Liubov Chuprikova]

Hi Andreas,

I pushed an autopkgtest for autodock-vina and also fixed some
lintian warnings as usual. By the way, lintian says that the newest version
of  Debian Policy (4.1.5) should be indicated. I did so, is it OK?

On Sat, 7 Jul 2018 at 09:37 Andreas Tille  wrote:

> Let me know if you need hints for picking other targets.


It would be great if you offer me a couple of packages to choose from that
you think are more relevant or urgent!

Kind regards,
Liubov

Bug#900752: ITP: genometester -- toolkit for performing set operations on k-mer lists

[Liubov Chuprikova]

Package: wnpp
Severity: wishlist
Owner: Liubov Chuprikova 

* Package name: genometester
  Version : 4.0
  Upstream Author : University of Tartu
* URL : https://github.com/bioinfo-ut/GenomeTester4
* License : GPL-3+
  Programming Lang: C
  Description : toolkit for performing set operations on k-mer lists
 Toolkit for performing set operations - union, intersection and
 complement - on k-mer lists.
 .
 GenomeTester4 toolkit, which contains a novel tool GListCompare for
 performing union, intersection and complement (difference) set
 operations on k-mer lists. It contains examples of how these
 general operations can be combined to solve a variety of biological
 analysis tasks.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/genometester

Bug#890993: (Bug#890993) primer3 FTBFS on big endian: test failure

[Liubov Chuprikova]

Hi Andreas, Hi all,

I tried to figure out what exactly could cause the failure. The error
refers to the test files in the kmer_lists directory that are in binary
format. It seems they were generated on a little-endian architecture, that
is why the test fails on big-endian when it tries to verify the file by
comparing its first bytes with a given magic.

kmer_list/readme.txt says that the test files could be downloaded from
http://primer3.ut.ee/lists.htm, which says the files can also be created by
*glistmaker* from GenomeTester4 package.

So one solution could be to generate a set of similar test files for
big-endian architectures. For this, only genome sequences in Fasta format
would be necessary. But at this point, I get stuck as I have never faced a
need to emulate big-endian. Are there other ways to deal with that type of
problem?

With regards,
Liubov

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

Hi Aaron,

On Wed, 23 May 2018 at 20:36 Aaron M. Ucko <u...@debian.org> wrote:

> Liubov Chuprikova <chuprikov...@gmail.com> writes:
>
> > Please, have a look at my two last commits (
> > https://salsa.debian.org/med-team/ncbi-tools6/commits/master). Actually,
> > the first one was made a month ago.
>
> All looks good except for one formality -- Lintian considers your
> additions to debian/copyright to be incomplete:
>
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 16)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 16)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 24)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 24)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 30)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 30)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 35)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 35)


Andreas helped me to figure out how to fill in the copyright and license
fields for the test data. I have just pushed these changes. Let me know if
something wrong.

With regards,
Liubov

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

On Wed, 23 May 2018 at 20:36 Aaron M. Ucko <u...@debian.org> wrote:

> Liubov Chuprikova <chuprikov...@gmail.com> writes:
>
> > Please, have a look at my two last commits (
> > https://salsa.debian.org/med-team/ncbi-tools6/commits/master). Actually,
> > the first one was made a month ago.
>
> All looks good except for one formality -- Lintian considers your
> additions to debian/copyright to be incomplete:
>
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 16)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 16)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 24)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 24)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 30)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 30)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 35)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 35)
>
> (It also issues a few unrelated complaints, which I'll be happy to
> address myself.)
>

I cannot reproduce the same lintian output on my computer. I tried it like
this:
lintian -i -I --show-overrides
ncbi-tools6_6.1.20170106-3_amd64.changes
I mistakenly decided that if NCBI copyright had already mentioned I could
skip it
for test data files as they were also taken from NCBI, except one...
trnascan-se_sample.output
I generated that file by running *trnascan-se* (another Debian Med
package), so I have no
idea what the license and copyright should be written for it. Could you
help me with this
problem?

__
Liubov

Bug#894781: bedtools: autopkgtest fails while it succeeded in the past

[Liubov Chuprikova]

Hi Andreas,

I have just pushed some changes to run-unit-test that are supposed to fix
the problem. Please, check my commit
.
It seems that upstream test/test.sh has been updated so that now it returns
an appropriate exit code in case of a failure. Therefore, we don't need to
check the stdout for "fail" anymore.

__
Liubov

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

Hi Aaron, Hi Andreas,

Please, have a look at my two last commits (
https://salsa.debian.org/med-team/ncbi-tools6/commits/master). Actually,
the first one was made a month ago.

On Tue, 17 Apr 2018 at 03:48 Aaron M. Ucko <u...@debian.org> wrote:

> Liubov Chuprikova <chuprikov...@gmail.com> writes:
>
> > At the moment, the following commands are still lacking tests:
> >
> >- *asn2ff*, *gbseqget*, *findspl* (their output indicates they are
> >obsolete and/or unsupported)
>
> - asn2ff plays the same general role as asn2flat, and should be possible to
>   test similarly.
>

I tried to run it in a similar way to *asn2asn*. It throws an error which
starts with "The asn2ff flatfile generator is obsolete and unsupported.  Please
switch to using asn2gb/SeqEntryToGnbk in the future."

- gbseqget is like insdseqget, but formally uses GenBank-specific
>   notation; as such, it requires network access.


I added a test for *gbseqget* within if statement which checks for internet
connection.


> - findspl also requires network access, and will need to be patched in the
>
  same fashion as taxblast; I'll take care of it when I get a chance.
>
> >- *asndhuff*, *nps2gps* (I can't figure out what kind of inputs they
> >require)
>
> - I'm not sure where you'd find input for asndhuff.
> - nps2gps takes a text Bioseq-set or Seq-entry of class nuc-prot, as
>   obtained by (for instance) idfetch -g1234.


A test for *nps2gps* also presents now.


> >- *fa2htgs*, *spidey* (they look too complicated for me and require
> much
>
>time to understand how they work)
>
> That's fair.  You can always come back to them later if you feel inspired.
>

I have also finished with *spidey* and *fa2htgs* today.


> >- *taxblast* doesn't generate an output file and only generates an
> >*incomplete* html
>
> I'm not sure what's up with that, but as previously noted, it requires
> network access anyway.
>
> >- *errhdr*, *sortbyquote* (I can't figure out even what they are
> >supposed to do)
>
> - errhdr is a developer tool, working with files of the format found in
>   errmsg/.
> - sortbyquote is also a developer tool, essentially a variant of sort
>   that ignores everything outside quotation marks (and generally has far
>   fewer options).



> I'm not sure any of these is critical to test, but some
>
should be relatively straightforward to work in at this point, and as
> noted I'm not quite ready to upload a new version anyway.
>

Aaron, thank you for the explanations! They helped me a lot!

Aaron, Andreas: what is your opinion about the whole test? Could we
consider it as completed?

With regards,
Liubov

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

Hi Aaron,

On Fri, 13 Apr 2018 at 02:04 Aaron M. Ucko <u...@debian.org> wrote:

> Liubov Chuprikova <chuprikov...@gmail.com> writes:
>
> > On Thu, 12 Apr 2018 at 17:30 Aaron M. Ucko <u...@debian.org> wrote:
> >
> >>
> >> That said, you did catch a bug in taxblast; I'll push a fix this
> >> evening.  (The binary will still require a network connection, just
> >> actually be able to use it now).
> >>
> >
> > Ok, thank you!
>
> Fix pushed, no problem.  I'd also be happy to sponsor the upload if
> you'd like.
>

Sorry for a delay, but I was planning to make one more effort on extending
the set of tests. At the moment, the following commands are still lacking
tests:

   - *asn2ff*, *gbseqget*, *findspl* (their output indicates they are
   obsolete and/or unsupported)
   - *asndhuff*, *nps2gps* (I can't figure out what kind of inputs they
   require)
   - *fa2htgs*, *spidey* (they look too complicated for me and require much
   time to understand how they work)
   - *taxblast* doesn't generate an output file and only generates an
   *incomplete* html
   - *errhdr*, *sortbyquote* (I can't figure out even what they are
   supposed to do)

If nothing critical is left without a test, then I'd like to ask you to
sponsor the upload. If you need any additional information about *taxblast*,
I'll be happy to provide it.

Thank you,
Liubov

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

On Thu, 12 Apr 2018 at 17:30 Aaron M. Ucko  wrote:

>
> That said, you did catch a bug in taxblast; I'll push a fix this
> evening.  (The binary will still require a network connection, just
> actually be able to use it now).
>

Ok, thank you!

With regards,
Liubov

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

On Thu, 12 Apr 2018 at 16:40 Andreas Tille  wrote:

>
> Just from reading the shell script it looks fine.  Requiring bash is
> also OK.
>

Ok, thanks!

SSL I'm getting suspicious:  The test suite needs to be run in a machine
> that is disconnected from the internet (similarly when the package is
> build).
>

Ops, it's escaped my attention somehow that tests are usually run on a
disconnected machine. I thought the opposite way.. Then I also need to
comment tests for *insdseqget* and *idfetch*.. Thank you for the
clarification!

With regards,
Liubov

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

Hi Aaron,

On Thu, 5 Apr 2018 at 23:30 Aaron M. Ucko <a...@alum.mit.edu> wrote:

> Liubov Chuprikova <chuprikov...@gmail.com> writes:
>
> > the same directory. What do you think about the whole test at this stage?
>
> Great, thanks!  I suppose you could check for specific output contents
> (via grep, not necessarily 100% identity), but this otherwise all looks
> good, and is a clear improvement over not having autopkgtests at all.
>

I have added simple checks for specific output content. What do you think
about my last commits? Is it an acceptable way to check or maybe you have
another idea how it should look like?

Apart from that, could you please help me with *taxblast*. I have tried to
run it providing SeqAnnot ASN.1 file as required. But I got the same error
message each time:

[taxblast] REJECT: Secure socket layer (SSL) has not been properly
initialized in the NCBI Toolkit.  Have you forgotten to call
SOCK_SetupSSL()?
[taxblast] ERROR: [URL_Connect;
https://www.ncbi.nlm.nih.gov:443/Service/dispd.cgi?service=TaxService=stretch.localdomain(127.0.1.1)=LINUX
]  Failed to connect: Not supported
... (here the previous line repets)
[taxblast] ERROR: [HTTP;
https://www.ncbi.nlm.nih.gov/Service/dispd.cgi?service=TaxService=stretch.localdomain(127.0.1.1)=LINUX
]  Too many failed attempts (3), giving up
[taxblast] ERROR: [TaxService]  Service not found
[taxblast] ERROR: [TaxService]  Cannot connect to service
[taxblast] ERROR: NI_ServiceGet [no error] ()

Do you have any suggestions what could be wrong with it?

Thank you,
Liubov

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

Hi Aaron, Hi Andreas,

On Wed, 4 Apr 2018 at 01:41 Aaron M. Ucko <u...@debian.org> wrote:

> Liubov Chuprikova <chuprikov...@gmail.com> writes:
>
> > Last two days I have been figuring out how to test *tbl2asn* and
> > *asnmacro*. Please, take a look at the last commits
> > <https://salsa.debian.org/med-team/ncbi-tools6/commits/master>.
>
> These all look OK offhand, apart from one purely cosmetic consideration:
> Sc_16.sbt has a lot of trailing whitespace that would be best to clean up.


Did it and also configured my vim to always show them.


> > I could not understand where a macro file for *asnmacro* can be taken
> > from. Is it possible to generate such a file by any program?
>
> Just by a generic text editor, sorry.  However, this package does
> already ship a macro file you may be able to test with:
> /usr/share/ncbi/data/autofix.prt.


Thanks, I've included this macro file into the test. Also, I've added a
test for *vecscreen *since I've noticed UniVec database already built at
the same directory. What do you think about the whole test at this stage?

With regards,
Liubov

Bug#894781: bedtools: autopkgtest fails while it succeeded in the past

[Liubov Chuprikova]

Hi Andreas, hi Charles,

On Thu, 5 Apr 2018 at 09:34 Andreas Tille  wrote:

> Hi,
>
> I confirm that the tests are throwing errors (despite I can not
> reproduce the issue uncovered at ci.debian.net[1]) when running the also
> user accessible script /usr/share/doc/bedtools/run-unit-test on the
> local machine.  Alternatively there are some issues with the new version
> of samtools / tabix.
>
> It somehow seems the test script is not adapted to the output of the
> changed upstream code.
>
> Charles, I keep you in CC since you once wrote the test script.
> Liubov, I keep you in CC since you might have a look once you
> are finished with ncbi-tools6.
>

I'll be able to take on this bug today's evening or tomorrow.

Regards,
Liubov

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

Dear Andreas, dear Aaron,

On Thu, 29 Mar 2018 at 18:14 Andreas Tille <andr...@an3as.eu> wrote:

> On Thu, Mar 29, 2018 at 02:35:01PM +0000, Liubov Chuprikova wrote:
> >
> > Thanks a lot for your attention to my work on the project!
>
> I'd like to confirm that this is because of your pretty good work. ;-)


Thanks again!

On Thu, 29 Mar 2018 at 19:30 Aaron M. Ucko <u...@debian.org> wrote:

> Liubov Chuprikova <chuprikov...@gmail.com> writes:
>
> > Please, have an eye on my last commits
> > <https://salsa.debian.org/med-team/ncbi-tools6/commits/master>! I'd
> like to
> > ask one question (most likely it is to Aaron): Are there tools that I
> > didn't include, but you would strongly recommend for testing? Then I will
> > concentrate on them to finish.
>
> These tests are shaping up nicely; thanks again for putting them
> together.  Of the remaining tools, I would prioritize testing tbl2asn
> and perhaps asnmacro.  (Also, please fix the typo in the asn2gb test's
> leading echo statement.)
>

Sorry for the delay in continuing the work! Last two days I have been
figuring out how to test *tbl2asn* and *asnmacro*. Please, take a look at
the last commits
<https://salsa.debian.org/med-team/ncbi-tools6/commits/master>. I could not
understand where a macro file for *asnmacro* can be taken from. Is it
possible to generate such a file by any program? I have included one as an
example, containing only a simple action (it is generated during
*run-unit-test* script execution).

Спасибо!
>

Oops! I have not paid attention to the fact that the date and time
headlines are written on my native language. Fixed it! ;-)

Regards,
Liubov

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

Dear Andreas, dear Aaron,

ср, 28 мар. 2018 г. в 5:07, Aaron M. Ucko <u...@debian.org>:

> Liubov Chuprikova <chuprikov...@gmail.com> writes:
>
> > Thanks a lot for helping me out with this project! I saw your messages to
> > Aaron and it was a relief for me that there was a "real" problem to build
> > the package. I had it too, but thought, this was with updating package
> > dependencies on my computer..
>
> Thanks for adding these tests, and sorry you ran into dpkg errors along
> the way!  Please let me know if you have usage questions about any of
> this package's tools.


вт, 27 мар. 2018 г. в 16:01, Andreas Tille <andr...@an3as.eu>:

> On Tue, Mar 27, 2018 at 01:33:58PM +, Liubov Chuprikova wrote:
>
> > > I noticed that you pushed a commit featuring the copyright information
> > > of the test data.  Do you consider the package ready for upload now or
> > > are you busy to enhance the test?  From my point of view an upload with
> > > the current status would be fine but I'm waiting for your OK for the
> > > upload.  In any case I added a closes: #879619 (which should mark the
> > > bug "pending upload" if the hook on Salsa works properly which I hereby
> > > want to test).
> > >
> >
> > Sorry, but yes, I had no time to enhance the test by this evening. The
> > package has more commands to test and I need to figure out how. I will be
> > able to finish it no later than tomorrow's evening.  I will let you know
> > once it will be done.
>
> That's perfectly fine and I'll stay patient.  Feel free to take all time
> you need.
>

Thanks a lot for your attention to my work on the project! Frankly, I am
stunned with the huge amount of different file formats required or
generated! :-) Unfortunately, I could not add tests for all commands in the
package so far. It appears I need more time to recognise what their inputs
should look like and where to find them.

Please, have an eye on my last commits
<https://salsa.debian.org/med-team/ncbi-tools6/commits/master>! I'd like to
ask one question (most likely it is to Aaron): Are there tools that I
didn't include, but you would strongly recommend for testing? Then I will
concentrate on them to finish.

Kind regards,
Liubov

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

Dear Andreas,

вт, 27 мар. 2018 г. в 12:49, Andreas Tille <andr...@an3as.eu>:

> Dear Liubov,
>
> On Sat, Mar 24, 2018 at 06:45:42PM +, Liubov Chuprikova wrote:
> > > I once had the idea in the figtree package to use xvfb-run[1].  It was
> > > not really successful and most probably the answer is: No, there is no
> > > sensible way to test X applications right now.
> >
> > Thank you for the comprehensive answers and interesting example
> provided! I
> > have looked through it and I will return to this subject after completing
> > with *ncbi-tools-bin*.
>
> I can confirm that the test works for me (now since I'm able to build
> the package - thanks to Aaron for the quick response).
>

Thanks a lot for helping me out with this project! I saw your messages to
Aaron and it was a relief for me that there was a "real" problem to build
the package. I had it too, but thought, this was with updating package
dependencies on my computer..


>
> > > >From my personal point of view I would add a copyright notice right
> > > when injecting additional files that need to be mentioned.  Its just
> > > that the memory is fresh what was done to get the file.
> > >
> >
> > Yes, I haven't thought that it would be a better practice! I'll try to
> > follow your advice.
>
> I noticed that you pushed a commit featuring the copyright information
> of the test data.  Do you consider the package ready for upload now or
> are you busy to enhance the test?  From my point of view an upload with
> the current status would be fine but I'm waiting for your OK for the
> upload.  In any case I added a closes: #879619 (which should mark the
> bug "pending upload" if the hook on Salsa works properly which I hereby
> want to test).
>

Sorry, but yes, I had no time to enhance the test by this evening. The
package has more commands to test and I need to figure out how. I will be
able to finish it no later than tomorrow's evening.  I will let you know
once it will be done.

With regards,
Liubov

Bug#890783: Autopkgtest for prodigal (#890783)

[Liubov Chuprikova]

Dear Andreas,

пн, 19 мар. 2018 г. в 14:14, Andreas Tille <andr...@an3as.eu>:

> Dear Liubov,
>
> On Mon, Mar 19, 2018 at 12:47:38PM +, Liubov Chuprikova wrote:
>
> > I have tried to find the information that should be placed in
> d/copyright,
> > but unfortunately, I don't have any experience with this kind of stuff.
> So
> > this is what I have found so far:
> >
> >- I downloaded the test sequence from the Ensemble Bacteria, which is
> an
> >online database of EMBL-EBI. At the bottom of the sequence page
> ><
> http://bacteria.ensembl.org/Candidatus_carsonella_ruddii_dc/Info/Index>,
> >it is indicated "Ensembl Bacteria release 38 - January 2018 ©
> EMBL-EBI". I
> >couldn't find any license they may have for the data, except that
> Terms
> >of Use <https://www.ebi.ac.uk/about/terms-of-use> states: "EMBL-EBI
> >itself places no additional restrictions on the use or redistribution
> of
> >the data available via its online services other than those provided
> by the
> >original data owners."
> >- At first, the sequence was deposited in the GenBank database (as
> said
> >in this paper
> ><http://www.cell.com/current-biology/fulltext/S0960-9822(13)00752-5>).
> I
> >didn't find if the GenBank has copyright, but they say here
> ><https://www.ncbi.nlm.nih.gov/genbank/>: "NCBI places no
> restrictions on
> >the use or distribution of the GenBank data. However, some submitters
> >may claim patent, copyright, or other intellectual property rights in
> all
> >or a portion of the data they have submitted."
> >- Finally, I have found that the sequence itself has no patent (this
> had
> >to be indicated in the field LOCUS of the GenBank file
> ><https://www.ncbi.nlm.nih.gov/nuccore/CP003467?report=genbank> as
> PAT).
> >I suspect the sequence has no copyright as well, although I can't
> find a
> >confirmation.
> >
> > Could you, please, point me in the right direction. I feel like I'm
> getting
> > stuck.
>
> Thanks for this elaborate information.  I tried my best to condensate it
> into d/copyright.  The rule should be that we provide information to the
> best of our knowledge (but not more ;-) ).  Please review and add at
> least a line
>
>wget ...


>
(see FIXME) and may be other information you (as a scientist) might
> consider helpful which I might have missed.
>
>
Thank you for help! I have added wget link, but it is quite long. Is it ok
or it would be better to split it into several lines? Plus, I have replaced
the link to the journal article by the one containing DOI (which is more
stable).

If there is nothing additional to change, could you please check and upload
the package?

Regards,
Liubov

Bug#890783: Autopkgtest for prodigal (#890783)

[Liubov Chuprikova]

Hi Andreas,


> On Fri, Mar 16, 2018 at 05:48:35PM +0100, Andreas Tille wrote:
>
> > > I included a genome sequence from NCBI as test data. Should I indicate
> the
> > > source of this data somewhere in the package (e.g., in Readme.tests)?
> >
> > I think the best place would be debian/copyright since a data file
> > should come with a license.  I would say something like
> >
> >
> > Files: debian/tests/test-data
> > Copyright: - Copyright-Owner
> > License:
> > Comment:
> >   This file was obtained by
> > wget URL
>
> Please let us know here on the list if you spot any problem to fill
> in the details.


I have tried to find the information that should be placed in d/copyright,
but unfortunately, I don't have any experience with this kind of stuff. So
this is what I have found so far:

   - I downloaded the test sequence from the Ensemble Bacteria, which is an
   online database of EMBL-EBI. At the bottom of the sequence page
   ,
   it is indicated "Ensembl Bacteria release 38 - January 2018 © EMBL-EBI". I
   couldn't find any license they may have for the data, except that Terms
   of Use  states: "EMBL-EBI
   itself places no additional restrictions on the use or redistribution of
   the data available via its online services other than those provided by the
   original data owners."
   - At first, the sequence was deposited in the GenBank database (as said
   in this paper
   ). I
   didn't find if the GenBank has copyright, but they say here
   : "NCBI places no restrictions on
   the use or distribution of the GenBank data. However, some submitters
   may claim patent, copyright, or other intellectual property rights in all
   or a portion of the data they have submitted."
   - Finally, I have found that the sequence itself has no patent (this had
   to be indicated in the field LOCUS of the GenBank file
    as PAT).
   I suspect the sequence has no copyright as well, although I can't find a
   confirmation.

Could you, please, point me in the right direction. I feel like I'm getting
stuck.

Thank you,
Liubov

Bug#890786: Question about adding autopkgtest for coils (#890786)

[Liubov Chuprikova]

Sorry, I've just realized that I've forgotten to specify the subject.

вт, 13 мар. 2018 г. в 20:26, Liubov Chuprikova <chuprikov...@gmail.com>:

> Hi Andreas,
>
> I have just added an autopkgtest to *coils* (commit
> <https://salsa.debian.org/med-team/coils/commit/83773ecf79f48c10b59f6c81d5892b2478c3da2b>).
> Could you, please,  take a look at it and help me with a few questions I
> have about the process:
>
>1. I noticed that tests usually try to run a program using test data
>from a package and check for errors. There was one in *coils*
>available and I used it in my autopkgtest. Is it enough to check that
>the program runs without errors or it would be preferable to check if the
>output is correct (there is a sample output in *coil's* Readme)?
>2. Was I right by indicating "Team upload" in *debian/changelog* or it
>should be NMU?
>3. What would be my next step? Should I find a sponsor?
>
> I would really appreciate any feedback you can give me.
>
> Thank you,
> Liubov
>