Re: ncbi-tools6 does not simply build via gbp due to changed files

[Aaron M. Ucko]

Andreas Tille  writes:

> I admit that there is probably no right or wrong in the choice of a
> workflow but if it comes to team maintenance commented patches are more
> obvious for your team mates.

Fair enough.

> That's fine.  Some patches look as if you have forwarded these upstream
> and we can create more sensible patches with next upstream version.

FWIW, I don't anticipate any more upstream releases, as upstream is
really trying to phase this code base out.  Already, the latest release
occurred only because a government-wide HTTPS mandate was going to break
previous releases' ability to communicate with NCBI servers.

>> how do you feel about gbp-pq(1) as a compromise between our preferred
>> approaches?
>
> I admit I have never dealt with this.  I think I can live with it if gbp
> would work out of the box.  If there are some specific hints needed
> please frop these in debian/README.source.

OK, thanks.  I'll look into switching over when I get a chance.

> In short: If you want to change Vcs URLs manually now you do not need
> to do it later.

Got it.  My approach has been to switch the fields as part of preparing
to make an upload, but redirection does certainly still work for now.  I
do share your frustration that the anonscm alias didn't offer as much
permanance as promised.

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

[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: RFS: bioSyntax -- Syntax highlighting for computational biology

[Andreas Tille]

Hi Dylan,

On Tue, Mar 27, 2018 at 10:17:57PM +0200, Dylan Aïssi wrote:
> 2018-03-24 17:46 GMT+01:00 Andreas Tille :
> > Uploaded.  Could you please make some suggestion in what task
> > (=metapackage) we should put what binary package?  I'm undecided between
> > med-bio and med-bio-dev and which binary package should be mentioned in
> > that task(s).
> 
> Thanks for the upload.
> 
> I did a pull request (I don't have enough rights to push directly):

Merged and added to the team to give you commit permission for the next
time.

> I
> put biosyntax-gedit into the med-bio task. I selected med-bio and not
> med-bio-dev because this package is to help to visualize sequences and
> not to help in development of bioinformatics applications. I chose to
> mention only biosyntax-gedit and not the others almost randomly,
> probably because I use gedit more frequently than others. But this
> should not be a big problem, because next time that biosyntax will
> need to go in the new queue (probably quickly because upstream is
> working on a plugin for nano), I will create a meta package (=
> biosyntax-all), so we will be able to mention only this meta-package
> in our tasks (right approach?).

Sounds OK for me.  We can also add the other packages as Suggests.  I
admit I'm unsure what might be the most sensible solution.  I think
there is no right or wrong in this question. 

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: RFS: bioSyntax -- Syntax highlighting for computational biology

[Dylan Aïssi]

Hi Andreas,

2018-03-24 17:46 GMT+01:00 Andreas Tille :
> Uploaded.  Could you please make some suggestion in what task
> (=metapackage) we should put what binary package?  I'm undecided between
> med-bio and med-bio-dev and which binary package should be mentioned in
> that task(s).

Thanks for the upload.

I did a pull request (I don't have enough rights to push directly): I
put biosyntax-gedit into the med-bio task. I selected med-bio and not
med-bio-dev because this package is to help to visualize sequences and
not to help in development of bioinformatics applications. I chose to
mention only biosyntax-gedit and not the others almost randomly,
probably because I use gedit more frequently than others. But this
should not be a big problem, because next time that biosyntax will
need to go in the new queue (probably quickly because upstream is
working on a plugin for nano), I will create a meta package (=
biosyntax-all), so we will be able to mention only this meta-package
in our tasks (right approach?).

Best,
Dylan

Re: Bug#879619: Autopkgtest for ncbi-tools6

[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

[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

[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: Debian has RRID SCR_006638

[Stian Soiland-Reyes]

Great!

For linking/annotation we should probably use permalink 
http://identifiers.org/rrid/RRID:SCR_006638 rather than the 
more fragile scicrunch search URLs.
--
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
http://orcid.org/-0001-9842-9718



From: Andreas Tille [andr...@an3as.eu]
Sent: 27 March 2018 08:08
To: debian-med@lists.debian.org
Subject: Re: Debian has RRID SCR_006638

Hi Steffen,

On Mon, Mar 26, 2018 at 11:49:19PM +0200, Steffen Möller wrote:
> I just tripped over
> https://scicrunch.org/scicrunch/Resources/search?q=SCR_006638=SCR_006638
> and, well, we should probably start adding that reference on our web site
> and papers.

Cool!  Thanks for the pointer.

For me this once more makes it evident that we need somebody who will
care somehow for "public relations" spreading these nice things to the
world (outside the limited circle of the readers of this list).
Informations like this, our Sprint, may be new packages we added last
month or so should be made public more visibly.   And no, I'm NOT that
person who is doing this.  I have lots of technical stuff on my desk
but obviously we urgently need somebody who does this.  Volunteers?

Kind regards

Andreas.

--
http://fam-tille.de

Re: Debian has RRID SCR_006638

[Andreas Tille]

Hi Steffen,

On Mon, Mar 26, 2018 at 11:49:19PM +0200, Steffen Möller wrote:
> I just tripped over
> https://scicrunch.org/scicrunch/Resources/search?q=SCR_006638=SCR_006638
> and, well, we should probably start adding that reference on our web site
> and papers.

Cool!  Thanks for the pointer.

For me this once more makes it evident that we need somebody who will
care somehow for "public relations" spreading these nice things to the
world (outside the limited circle of the readers of this list).
Informations like this, our Sprint, may be new packages we added last
month or so should be made public more visibly.   And no, I'm NOT that
person who is doing this.  I have lots of technical stuff on my desk
but obviously we urgently need somebody who does this.  Volunteers?

Kind regards

Andreas.

-- 
http://fam-tille.de

Re: RRID update on salsa on packages starting with A+B

[Andreas Tille]

Hi Steffen,

On Mon, Mar 26, 2018 at 07:23:24PM +0200, Steffen Möller wrote:
> 
> I just procrastinated a bit into using the comfort of salsa to update
> debian/upstream/metadata and here the references to SciCrunch, OMICtools and
> bio.tools registries. All three registries have improved their coverage
> enormously over the past few months. I am deeply impressed.

Thanks a lot for the large update.
 
> Anyway. I came across
> 
>  * one or two entries

Which ones?

> that had perfect RRID descriptions on salsa but not on
> our task page - does the package need to be re-uploaded for the change to
> become visible?

Re-uploading is *not* needed.  The data come from Salsa Git repositories
(since about two weeks the machine-readable gatherer was pointed from
Alioth to Salsa).  However, there is an about 24 hour delay between
commits and visibility of the data on the web sentinel since at least
two cron jobs are involved (one that gathers the data and one that
creates the pages).

>  * belvu and blixem that are from the same source package but have different
> task entries and also separate catalog entries in all three registries. This
> breaks the current UDD schema. I have annotated it now as ['belvu','blixem']
> (for bio.tools, the others analogously).
> 
> Ideas for improvements anyone? Or is this how it should be for now?

I'm not sure.  In any case the current gatherer code will do nothing (at
best) or fail.  It seems that we are lucky and it does not break.  The
thing is that if we change our data model somebody (currently only me)
needs to adapt the code.  Currently there is no chance to resolve

 - Name: OMICtools
   Entry: ['OMICS_23183', 'OMICS_23184', 'OMICS_15828']

or

 - Name: SciCrunch
   Entry: ['SCR_015989','SCR_015994', 'NA']

How should the gatherer magically guess what binary package to choose?
The entry

 - Name: bio.tools
   Entry: ['belvu', 'blixem', 'dotter']

looks helpfull - but it is just pure luck that bio.tools has choosen IDs
matching our package names.  So I think your data model is not helpful
since there is no chance to define a sequence of the binary packages
build from one source package.  Thus we somehow need to define the
binary package name explicitly.

For citations we are using the field Debian-package[1] which is for
instance used for meme package[2] (just to have another example since
in seqtools also the dotter publication is marked like this).  However,
this is because I once added an additional field "package" to the bibref
table which looks for instance like this:


udd=# select * from bibref where (source = 'meme' or source = 'seqtools' ) and 
key = 'title';
  source  |  key  |  value  
 | package | rank 
--+---+--+-+--
 meme | title | MEME: discovering and analyzing DNA and protein sequence 
motifs  | |0
 meme | title | Discovering Sequence Motifs with Arbitrary Insertions and 
Deletions  | glam2   |0
 seqtools | title | SeqTools: visual tools for manual analysis of sequence 
alignments| |0
 seqtools | title | Scoredist: A simple and robust protein sequence distance 
estimator   | |1
 seqtools | title | A dot-matrix program with dynamic threshold control suited 
for genomic DNA and protein sequence analysis | dotter  |0
 seqtools | title | A workbench for large-scale sequence homology analysis  
 | |2


You see, packages with different names than the source packages got an
additional value in the package column since it was defined in our data
model first and implemented in the code afterwards.  However, the
registry table looks like this:


udd=# select * from registry where source = 'seqtools';
  source  |   name|   entry   
--+---+---
 seqtools | OMICtools | {OMICS_23183,OMICS_23184}
 seqtools | bio.tools | {belvu,blixem}
 seqtools | SciCrunch | {SCR_015989,SCR_015994}


That's the status before your last commit since the machine-readable
gatherer cron job was not run yet.  The gatherer takes what it gets and
injects it into the database.  Its not magic - its code that needs to be
adapted to a data model.  Changing the data model and hoping that
something sensible will happen is not working.

What we should clarify in advance is:  Does the source column in the
registry table make sense at all or should it rather be a package column
refering to binary packages?  The web sentinel is working on binary
packages so may be we should not keep source package names but rather
binary package names inside this table.  Alternatively