Re: [Bio-linux-devel] phoenix clinical trial management system integration

2018-05-21 Thread Andreas Tille
Hi,

@Tony: Thanks a lot for forwarding this. :-)

On Sat, May 19, 2018 at 02:56:18PM +0100, Tony Travis wrote:
> On 18/05/18 23:19, Rene Krenn wrote:
> > hello,
> >
> >
> >
> > would like to probe if there is an interest to include
> > https://github.com/phoenixctms ?
> >
> > it’s the most powerful EDC system we know.
> >
> >
> >
> > pls let me know if it makes sense and someone can/wants to help with
> > packaging.

For sure we would love to help you in packaging.  We have quite some
record in teaching upstream how to package.  We have formalised this
process in so called "Mentoring of the Month" (MoM)[1].  You are more
than welcome to add yourself to the list of students (or simply confirm
here on this list[2] if you are scared by just another random Wiki login
in the web.  However, you should subscribe in any case this list since
the mentoring is done in public.)
 
> Hi, Rene.
> 
> Bio-Linux is a platform for bioinformatics, rather than collecting and
> analysing clinical trials data.

It looks like a good target for the task "Research"[3] which has no
existing package yet which is a real shame - but may be you consider
other of our tasks[4] fitting better / in addition.

> However, many packages from Debian-Med
> are included in Bio-Linux and the two projects work together to avoid
> duplication of effort packaging the same bioinformatics software.
> 
> The Debian-Med project is much broader than Bio-Linux and specifically
> includes biomedical applications like your clinical trials management
> software. I've CC'ed your message to the Debian-Med mailing list so we
> can discuss the possibility of packaging your software there.
> 
> Please post a message to the Debian-Med list explaining clearly what the
> licence is for your software and what, exactly, you want to package.

Nothing to add to Tony's kid explanation.

Kind regards

Andreas.

[1] https://wiki.debian.org/DebianMed/MoM
[2] https://lists.debian.org/debian-med
[3] https://blends.debian.org/med/tasks/research
[4] https://blends.debian.org/med/tasks

-- 
http://fam-tille.de



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