Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-05-24 Thread Liubov Chuprikova
Hi Aaron,

On Wed, 23 May 2018 at 20:36 Aaron M. Ucko  wrote:

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


Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-05-24 Thread Liubov Chuprikova
Hi Andreas,

Thank you for your detailed answer!

On Thu, 24 May 2018 at 07:44 Andreas Tille  wrote:

> On Wed, May 23, 2018 at 10:14:56PM +0200, Liubov Chuprikova wrote:
> > > 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.
>
> You should always install lintian from unstable.  To do so create two
> files:
>
> $ cat /etc/apt/sources.list.d/01-unstable.list
> deb http://httpredir.debian.org/debian unstable main
>
> $ cat /etc/apt/preferences.d/01-lintian.pref
> Package: lintian
> Pin: release a=unstable
> Pin-Priority: 601
>
> Package: debian-policy
> Pin: release a=unstable
> Pin-Priority: 601
>
>
> Try first
>
> $ apt-cache policy lintian
>
> which should show
>
>Candidate: 2.5.88
>
> and to make sure that your general preferences are set correctly
>
> $ apt-cache policy dpkg
>
> This should *not* have a candidate from unstable.  Otherwise add
>
> $ cat /etc/apt/preferences.d/01-unstable.pref
> Package: *
> Pin: release a=unstable
> Pin-Priority: 50
>
>
> to make sure you will not upgrade your whole system to unstable which is
> probably not what you want.  Than do
>
>sudo apt-get install lintian debian-policy
>
> (This also pulls debian-policy from unstable which is also what you
> want.)
>

I have updated lintian and debian-policy as you wrote. Now they are of
2.5.88 and 4.1.4.1 versions, respectively.


> > I tried it like
> > this:
> > lintian -i -I --show-overrides
> ncbi-tools6_6.1.20170106-3_amd64.changes
>

After that I've also noticed a mentioning of "ncbi-tools6 source" in the
warnings above and realised that I should use .dsc instead of .changes to
reproduce them.


>
> > 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?
>
> I admit I'm unsure myself.  Either it inherits the copyright of the
> original data file (which should be mentioned in trnascan-se) or you
> become the copyright owner.  Besides this I doubt that data are
> copyright-able at all.  So I would not see any problem to use
>
>   Copyright: Liubov Chuprikova
>   License: public_domain
>

Ok, I've decided to mention myself as a copyright owner. By the way,
trnascan-se_sample.output already has a mentioning about tRNAscan-SE
(including tRNAscan-SE's copyright and license info). But, as you wrote,
the data itself can hardly follow the same license as the program.

Thanks again!
Liubov


Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-05-23 Thread Andreas Tille
On Wed, May 23, 2018 at 10:14:56PM +0200, Liubov Chuprikova wrote:
> > 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.

You should always install lintian from unstable.  To do so create two
files:

$ cat /etc/apt/sources.list.d/01-unstable.list 
deb http://httpredir.debian.org/debian unstable main

$ cat /etc/apt/preferences.d/01-lintian.pref
Package: lintian
Pin: release a=unstable
Pin-Priority: 601

Package: debian-policy
Pin: release a=unstable
Pin-Priority: 601


Try first

$ apt-cache policy lintian

which should show

   Candidate: 2.5.88

and to make sure that your general preferences are set correctly

$ apt-cache policy dpkg

This should *not* have a candidate from unstable.  Otherwise add

$ cat /etc/apt/preferences.d/01-unstable.pref 
Package: *
Pin: release a=unstable
Pin-Priority: 50


to make sure you will not upgrade your whole system to unstable which is
probably not what you want.  Than do

   sudo apt-get install lintian debian-policy

(This also pulls debian-policy from unstable which is also what you
want.)

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

I admit I'm unsure myself.  Either it inherits the copyright of the
original data file (which should be mentioned in trnascan-se) or you
become the copyright owner.  Besides this I doubt that data are
copyright-able at all.  So I would not see any problem to use

  Copyright: Liubov Chuprikova
  License: public_domain

Kind regards

 Andreas.

-- 
http://fam-tille.de



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-05-23 Thread Liubov Chuprikova
On Wed, 23 May 2018 at 20:36 Aaron M. Ucko  wrote:

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


Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-05-21 Thread Andreas Tille
Hi Liubov,

On Tue, May 22, 2018 at 01:01:55AM +0200, Liubov Chuprikova wrote:
> 
> Aaron, thank you for the explanations! They helped me a lot!

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

Your work looks very fine grained but for the decision of "completed"
Aaron is the expert we both need to trust.  Aaron, let me know if you
want me to upload or if you want to do it yourself.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-05-21 Thread 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  wrote:

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


Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-04-16 Thread Aaron M. Ucko
Liubov Chuprikova  writes:

> Sorry for a delay, but I was planning to make one more effort on extending
> the set of tests.

No problem.

> 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.
- gbseqget is like insdseqget, but formally uses GenBank-specific
  notation; as such, it requires network access.
- 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.

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

>- *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).

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

OK, thanks.  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 M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-04-16 Thread Liubov Chuprikova
Hi Aaron,

On Fri, 13 Apr 2018 at 02:04 Aaron M. Ucko  wrote:

> Liubov Chuprikova  writes:
>
> > 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!
>
> 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


Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-04-12 Thread Aaron M. Ucko
Liubov Chuprikova  writes:

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

Fix pushed, no problem.  I'd also be happy to sponsor the upload if
you'd like.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-04-12 Thread 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


Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-04-12 Thread Aaron M. Ucko
Liubov Chuprikova  writes:

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

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

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-04-12 Thread 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


Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-04-12 Thread Andreas Tille
Hi Liubov,

On Thu, Apr 12, 2018 at 02:24:12PM +, Liubov Chuprikova wrote:
> >
> > 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?

Just from reading the shell script it looks fine.  Requiring bash is
also OK.
 
> 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?

I hope Aaron will give a more authoritative answer but when I'm reading
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).

In some rules file this is somehow faked by using

  export http_proxy=http://127.0.0.1:9/

I'm absolutely not sure that this has any chance to work in the test
suite.  If the test needs network access to succeed than the only way is
to skip that test.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-04-12 Thread Liubov Chuprikova
Hi Aaron,

On Thu, 5 Apr 2018 at 23:30 Aaron M. Ucko  wrote:

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


Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-04-05 Thread Aaron M. Ucko
Liubov Chuprikova  writes:

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

Thanks!

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

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.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-04-05 Thread Liubov Chuprikova
Hi Aaron, Hi Andreas,

On Wed, 4 Apr 2018 at 01:41 Aaron M. Ucko  wrote:

> Liubov Chuprikova  writes:
>
> > Last two days I have been figuring out how to test *tbl2asn* and
> > *asnmacro*. Please, take a look at the last commits
> > .
>
> 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


Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-04-03 Thread Aaron M. Ucko
Liubov Chuprikova  writes:

> Sorry for the delay in continuing the work!

No problem.

> Last two days I have been figuring out how to test *tbl2asn* and
> *asnmacro*. Please, take a look at the last commits
> .

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.

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

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-04-03 Thread Liubov Chuprikova
Dear Andreas, dear Aaron,

On Thu, 29 Mar 2018 at 18:14 Andreas Tille  wrote:

> On Thu, Mar 29, 2018 at 02:35:01PM +, 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  wrote:

> Liubov Chuprikova  writes:
>
> > Please, have an eye on my last commits
> > ! 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
. 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


Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-03-29 Thread Aaron M. Ucko
Liubov Chuprikova  writes:

> Please, have an eye on my last commits
> ! 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.)

Спасибо!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-03-29 Thread Andreas Tille
On Thu, Mar 29, 2018 at 02:35:01PM +, 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. ;-)

> Please, have an eye on my last commits
> ! 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.

Definitely Aaron is the expert here.  I personally have no idea, sorry.

Kind regards

 Andreas.

-- 
http://fam-tille.de



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-03-29 Thread Liubov Chuprikova
Dear Andreas, dear Aaron,

ср, 28 мар. 2018 г. в 5:07, Aaron M. Ucko :

> Liubov Chuprikova  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 :

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


Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-03-27 Thread Aaron M. Ucko
Liubov Chuprikova  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.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-03-27 Thread Andreas Tille
Dear Liubov,

On Tue, Mar 27, 2018 at 01:33:58PM +, Liubov Chuprikova wrote:
> > 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..

:-)  I'd recommend you *always* ask if something is different than you
expect it to be.  It *might* be that it is just your computer but than
we would like to help you fixing the issue on your computer.  There is
no point in wasting your time to hunt down problems that might be easy
to solve here.
 
> > 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 for your solid work on this package

Andreas.

-- 
http://fam-tille.de



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-03-27 Thread Liubov Chuprikova
Dear Andreas,

вт, 27 мар. 2018 г. в 12:49, Andreas Tille :

> 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


Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-03-27 Thread Andreas Tille
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).
 
> > >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).

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-03-24 Thread Liubov Chuprikova
Dear Andreas,

сб, 24 мар. 2018 г. в 17:33, Andreas Tille :

On Sat, Mar 24, 2018 at 02:35:41PM +, Liubov Chuprikova wrote:
> > Is there a way to test graphical applications in *ncbi-tools-x11?
>
> 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 сomprehensive answers and interesting example provided! I
have looked through it and I will return to this subject after completing
with *ncbi-tools-bin*.


> > I haven't changed the copyright yet because I am likely to add more
> > additional test files later.
>
> >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.

Kind regards,
Liubov


Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-03-24 Thread Andreas Tille
Dear Liubov,

On Sat, Mar 24, 2018 at 02:35:41PM +, Liubov Chuprikova wrote:
> 
> I have started to work on writing tests for *ncbi-tools6*, which is the
> source for multiple binary packages.

Yes.  Its tough that you want to tackle this more complex package which
is definitely very valuable since its a frequently used package.

> Some of them contain shared libraries,
> others are with data files and only two contain executables (
> *ncbi-tools-bin* and *ncbi-**tools-x11*). Is there a way to test graphical
> applications in *ncbi-tools-x11?

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.

> *Should I ignore non-executable binary packages?

Yes.  Even if the wording is not fully correct.  When autopkgtests are
run all binary packages are installed besides the source package on the
testing machine.  Thus the test is working on all binary packages in
principle - but we are running the command line executables in the test
suite.  The special way I prefer to provide the test script also as
user installable example in /usr/share/doc//run-unit-test
is strictly speaking not what autopkgtest is doing - it runs any
script that is specified in PKGSOURCE/debian/tests/control (= in the
unpackaged source package).

But if we stick to the user executable example this should be installed
into the package containig the command line executables binary package.
 
> Meanwhile, I have pushed my first efforts to check some of the
> functionality inside *ncbi-tools-**bin *(commit
> ).
> At the moment, the commands in the test run one by one and the test exits
> on the first fail. I thought it would be better if the test gathers exit
> statuses of each command and returns only global exit status instead and
> maybe some summary of which commands fail? I could implement this idea if
> you don't think it is too much.

Well, I'm fine if you think this is better.  But we need to look for
errors whereever it happens and I do not consider it very important to
do the sophisticated design you are proposing.  So it does not harm but
I think it is more important to add the way you obtained the data to
d/control (as in the previous example).
 
> I haven't changed the copyright yet because I am likely to add more
> additional test files later.

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

> However, I always doubt that I don't see
> something else that I need to pay attention to. I'll be happy to receive
> any recommendations from you!

Without having built the package and tested the script it looks sensible
to me as it is.  I'll start a build and will give further remarks if
needed.

Thanks for your work on this

  Andreas.


[1] 
https://salsa.debian.org/med-team/figtree/blob/master/debian/tests/run-unit-test
 

-- 
http://fam-tille.de