Re: Bug#879619: Autopkgtest for ncbi-tools6

[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

[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: RRID update on salsa on packages starting with A+B

[Andreas Tille]

On Tue, Apr 03, 2018 at 12:27:08PM +0200, Steffen Möller wrote:
> > There is a daily cron job parsing Salsa directories.
> Fine. Somewhere there is (or should be :o) ) a documentation how this page
> is crafted. On our Wiki? Let us then have a link to that page.

May be this

   https://blends.debian.org/blends/apa.html#datagathering

(A.7.) could be a first shot on this problem.

> Could branches for your cron job's autodock checkout differ? The page was
> updated
> this morning but yet not references. Or is there a second directory
> "autodock" when
> the source package name is "autodocksuite" (because of the joint autogrid
> tool)?

That's not about branches.  As previously said:  Registry data are per
source package currently.  There is no means in the registry data table
to map an entry to a binary package.  Thus autodock *and* autogrid are
missing registry data both.
 
Kind regards

  Andreas. 

-- 
http://fam-tille.de

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

[Tony Travis]

On 03/04/18 11:27, Steffen Möller wrote:
> [...]
> This is a bit of a side-track from the core of this thread. Maybe we
> would have Tony describing our achievements one they are manifesting in
> Bio-Linux. And if we have a look at
> https://salsa.debian.org/dashboard/milestones ? Maybe we can use those
> as an anchor for achievements from which news could be generated in an
> easier way, not necessarily by us.

Hi, Steffen.

Yes, I would be happy to do that.

I'm now only doing minimal maintenance work on Bio-Linux 8, based on
Ubuntu 14.04 LTS (Trusty) while I start work on Bio-Linux 9, based on
Ubuntu-MATE 18.04 LTS (Bionic). I've got the 18.04 Ubuntu-MATE beta .iso
and I've started work remastering it for Bio-Linux using "customizer":

> https://github.com/kamilion/customizer

I plan to base Bio-Linux 9 on Debian-Med + Bioconda and would like to
start adding Ubuntu 18.04 (Bionic) versions of Debian-Med packages to
the Debian-Med PPA if nobody objects. I also want to drop ALL the 'bad'
NEBC packages (i.e. the binary-only packages that Bela and Tim used
initially to migrate from Debian testing (Sarge) to Ubuntu 6.06 LTS.

I've listened to Andreas: I intend to create a "bio-linux-desktop"
meta-package modelled on the Debian-Med/Bio* tasks that are now being
updated to include some 'missing' packages that were only in Bio-Linux.

Thanks again to all in the Debian-Med team for your help and support,

  Tony.

-- 
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK)
tel. +44(0)19755 63548http://minke-informatics.co.uk
mob. +44(0)7985 078324mailto:tony.tra...@minke-informatics.co.uk

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

[Steffen Möller]

On 4/3/18 10:30 AM, Andreas Tille wrote:

On Tue, Apr 03, 2018 at 12:14:57AM +0200, Steffen Möller wrote:

Registry:
   - Name: OMICtools
 Entry: NA
   - Name: RRID
 Entry: NA
   - Name: bio.tools
 Entry: NA

That is an interesting one. Please kindly check

https://salsa.debian.org/med-team/autodocksuite/blob/master/debian/upstream/metadata

which on my side shows

Registry:
  - Name: OMICtools
    Entry: OMICS_19997
  - Name: SciCrunch
    Entry: SCR_012746
  - Name: bio.tools
    Entry: AutoDock

May be you forgot to push.  I now received

commit e5292af2136df30df8ea2a0da0dbeba6b82b027b (HEAD -> master, origin/master)
Author: Steffen Möller 
Date:   Mon Mar 26 16:05:33 2018 +

 Added RRID to metadata

which has the values you are mentioning.  This was not available in the public
repository (at least until 1st of April).

Hm. No. Have not touched it again. May be some delay-thingy somewhere.

I remember it was not your prefered solution but for the moment 'NA'
values are not stored. [...]

How would you like Name and no fancy colouring?

The idea was to inform the world (and ourselves) that we have checked.

I admit I do not like this.  The thing is that the maintainers of the
repository could have updated their data.  Recent development shows that
this is a very probable action these days.  I do not think that the fact
that we have checked is no information which is valuable for a random
visitor of the tasks page and it might be simply wrong since the data
were updated.  So I keep on thinking that 'NA' is not anything
interesting for the page.  For us as developers we can easily do

 grep -w 'NA' */debian/upstream/metadata

if we want to find the information.


Right. If we developers have the whole of Debian Med checked out. I don't.
It is a side-issue. Don't worry.


The
problem is that we are unlikely to be informed about an entry being added to
the registry, so we would look bad. But since the advent of salsa.d.o I am
tempted to risk that.

Sorry, I do not understand this.


We have that mistake only for a few days upon notification.


  

bio-express (https://salsa.debian.org/med-team/express)

It is rather berkeley-express.  This works now[1].  The reason for the
problem was that the repository name is different from the source
package name.  The importer was simply wrong for these cases.  This is
fixed now (hopefully!) but we should definitely avoid this kind of
divergence and I'm tempted to adapt the repository name to the source
package name once we migrate anonscm.d.o to salsa.d.o (I've lost hope
for some sensible solution to keep anonscm working :-((().

Aaah. Yes. This sounds like a reasonable addition to the Debian Med policy.

We are intuitively doing it in close to all of our packages but
specifying it explicitly in policy makes sense, definitely.


gromacs

No Registry entries in d/upstream/metadata - so nothing to display here.

:o/ Because that is debichem and looked at my not-yet-merged own branch.

Why not asking for membership in Debichem and commit directly?


I was with debichem on alioth and eventually will ask for membership again.
However, I would loose the external view on how we present ourselves. And I
am much after attracting casual contributors to our cause, e.g. to improve
the description of our packages or ... registry entries in d/u/metadata. So,
debichem is a test-case to teach me how this feels on the other side.





This document is prepared every 24 hours for Debian packages selected in the
https://salsa.debian.org/blends-team/med/blob/master/tasks/bio;>Med
Bio Task Description withinformation in the Ultimate Debian Database (https://udd.debian.org;>UDD).

The bottom line has a creation date of the web page.  Currently it says:

  Last update: Mon, 02 Apr 2018 19:21:37 -

Excellent. I have missed that one.

It was last updated at [Date+Time].

This information is not available, sorry.

I am uncertain about what "this" refers to, but maybe you have some idea
about who the page can explain itself to the ones who want to contribute
code or content.

There is a daily cron job parsing Salsa directories.

Fine. Somewhere there is (or should be :o) ) a documentation how this page
is crafted. On our Wiki? Let us then have a link to that page. Casual 
contributors,
that is what I am primarily after. For everything else I happily ask you 
or Ole.

I do not keep
track on the information when this job is finished.  The UDD importer is
reading the result of this job later and I also do not keep track when
this job ends.  So we have two uncertain times - the only time that can
be safely displayed is when the web pages are displayed which is done on
the bottom line.  I admit that I'm not very motivated to make some
effort to keep track of the other times compared to other tasks on my
desk.


That is fine.

There could be a line like "Please allow 48 hours for your change to the
package selection or the package description to 

Re: pynast did not migrate to salsa?

[Sascha Steinbiss]

Hi Steffen and Andreas,

>> I cannot find the pynast repository on salsa. Any ideas? The entry on  the
>> med/bio task page points to its previous location on alioth and I cannot
>> find it on salsa.
> 
> I simply forgot to push after the local SVN to Git migration.  So the
> package never existed on git.debian.org (despite the Vcs fields said so
> after my upload.

Ah, I see. Good to see this is not an result of some error in the
automated migration. Please let me know if there are other unexplained
cases, I'd be happy to take a look.

Cheers
Sascha

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

[Andreas Tille]

On Tue, Apr 03, 2018 at 12:14:57AM +0200, Steffen Möller wrote:
> 
> > Registry:
> >   - Name: OMICtools
> > Entry: NA
> >   - Name: RRID
> > Entry: NA
> >   - Name: bio.tools
> > Entry: NA
> 
> That is an interesting one. Please kindly check
> 
> https://salsa.debian.org/med-team/autodocksuite/blob/master/debian/upstream/metadata
> 
> which on my side shows
> 
> Registry:
>  - Name: OMICtools
>    Entry: OMICS_19997
>  - Name: SciCrunch
>    Entry: SCR_012746
>  - Name: bio.tools
>    Entry: AutoDock

May be you forgot to push.  I now received

commit e5292af2136df30df8ea2a0da0dbeba6b82b027b (HEAD -> master, origin/master)
Author: Steffen Möller 
Date:   Mon Mar 26 16:05:33 2018 +

Added RRID to metadata

which has the values you are mentioning.  This was not available in the public
repository (at least until 1st of April).
 
> > I remember it was not your prefered solution but for the moment 'NA'
> > values are not stored. [...]
> How would you like Name and no fancy colouring?
> 
> The idea was to inform the world (and ourselves) that we have checked.

I admit I do not like this.  The thing is that the maintainers of the
repository could have updated their data.  Recent development shows that
this is a very probable action these days.  I do not think that the fact
that we have checked is no information which is valuable for a random
visitor of the tasks page and it might be simply wrong since the data
were updated.  So I keep on thinking that 'NA' is not anything
interesting for the page.  For us as developers we can easily do

grep -w 'NA' */debian/upstream/metadata

if we want to find the information.

> The
> problem is that we are unlikely to be informed about an entry being added to
> the registry, so we would look bad. But since the advent of salsa.d.o I am
> tempted to risk that.

Sorry, I do not understand this.
 
> > > bio-express (https://salsa.debian.org/med-team/express)
> > It is rather berkeley-express.  This works now[1].  The reason for the
> > problem was that the repository name is different from the source
> > package name.  The importer was simply wrong for these cases.  This is
> > fixed now (hopefully!) but we should definitely avoid this kind of
> > divergence and I'm tempted to adapt the repository name to the source
> > package name once we migrate anonscm.d.o to salsa.d.o (I've lost hope
> > for some sensible solution to keep anonscm working :-((().
> Aaah. Yes. This sounds like a reasonable addition to the Debian Med policy.

We are intuitively doing it in close to all of our packages but
specifying it explicitly in policy makes sense, definitely.

> > > gromacs
> > No Registry entries in d/upstream/metadata - so nothing to display here.
> :o/ Because that is debichem and looked at my not-yet-merged own branch.

Why not asking for membership in Debichem and commit directly?

> > > This document is prepared every 24 hours for Debian packages selected in 
> > > the
> > >  > > href="https://salsa.debian.org/blends-team/med/blob/master/tasks/bio;>Med
> > > Bio Task Description withinformation in the Ultimate Debian Database 
> > > ( > > href="https://udd.debian.org;>UDD).
> > The bottom line has a creation date of the web page.  Currently it says:
> > 
> >  Last update: Mon, 02 Apr 2018 19:21:37 -
> Excellent. I have missed that one.

> > > It was last updated at [Date+Time].
> > This information is not available, sorry.
> 
> I am uncertain about what "this" refers to, but maybe you have some idea
> about who the page can explain itself to the ones who want to contribute
> code or content.

There is a daily cron job parsing Salsa directories.  I do not keep
track on the information when this job is finished.  The UDD importer is
reading the result of this job later and I also do not keep track when
this job ends.  So we have two uncertain times - the only time that can
be safely displayed is when the web pages are displayed which is done on
the bottom line.  I admit that I'm not very motivated to make some
effort to keep track of the other times compared to other tasks on my
desk.
 
> > There is no difference between pushing from remote repository and a web
> > interface edit.
> 
> Good.
> 
> Curious about this autodock/autodocksuite thingy and maybe there is some
> chance to have this self-explaining bit at the end.

I have no idea how this can happen.  I do not use the web interface for
editing package data.
 
> I have added registry links to about all green entries in bio now. Let us
> review those over the next weeks a bit and then think about an announcing it
> with the Debian News or whatever the list finds appropriate.

I'd love if we could find some default channel for Debian Med news (and
a person who feels dedicated to feed this channel regularly). 

Kind regards

   Andreas.

-- 
http://fam-tille.de