Re: RFS: bowtie/1.2.1.1+dfsg-1

[Andreas Tille]

Hi Alex,

thanks a lot for your work on this.  I'd consider this quite important
but I would prefer if someone more educated than I who knows what the
test issues might mean would have another look.  Please ping me again
if nobody would step in (should there really nobody interested???) and
I'll sponsor as is.

Thanks again

  Andreas.

On Thu, Oct 19, 2017 at 06:16:39PM +0200, Alex Mestiashvili wrote:
> Hello,
> 
> I've worked a bit on bowtie in git [0] and think that it is ready for
> upload. It also presumably closes #864439. One of the issues I run
> during package building is that bowtie unit tests fail on example6 and
> exmaple9.
> Could somebody who uses bowtie please comment on this ? Not sure if this
> is something I should report upstream.
> 
> bowtie -a --best --strata -v 2 --suppress 1,5,6,7 e_coli -c
> ATGCATCATGCGCCAT > example6.out
> 
> bowtie 1.1.2-6
> 
> cat example6.out
> -   gi|110640213|ref|NC_008253.1|   2852852 8:T>A
> 
> bowtie 1.2.1.1+dfsg-1
> 
> cat example6.out
> -   gi|110640213|ref|NC_008253.1|   2852852 8:T>A
> -   gi|110640213|ref|NC_008253.1|   148810  10:A>G,13:C>G
> +   gi|110640213|ref|NC_008253.1|   1093035 2:T>G,15:A>T
> -   gi|110640213|ref|NC_008253.1|   905664  6:A>G,7:G>T
> -   gi|110640213|ref|NC_008253.1|   4930433 4:G>T,6:C>G
> 
> bowtie -a -m 3 --best --strata -v 2 e_coli --suppress 1,5,6,7 -c
> ATGCATCATGCGCCAT  > example9.out
> 
> bowtie 1.1.2-6
> 
> cat example9.out
> -   gi|110640213|ref|NC_008253.1|   2852852 8:T>A
> 
> bowtie 1.2.1.1+dfsg-1
> 
> produces empty example9.out
> 
> Thank you,
> Alex
> 
> [0] https://anonscm.debian.org/git/debian-med/bowtie.git
> 
> 

-- 
http://fam-tille.de

RFS: bowtie/1.2.1.1+dfsg-1

[Alex Mestiashvili]

Hello,

I've worked a bit on bowtie in git [0] and think that it is ready for
upload. It also presumably closes #864439. One of the issues I run
during package building is that bowtie unit tests fail on example6 and
exmaple9.
Could somebody who uses bowtie please comment on this ? Not sure if this
is something I should report upstream.

bowtie -a --best --strata -v 2 --suppress 1,5,6,7 e_coli -c
ATGCATCATGCGCCAT > example6.out

bowtie 1.1.2-6

cat example6.out
-   gi|110640213|ref|NC_008253.1|   2852852 8:T>A

bowtie 1.2.1.1+dfsg-1

cat example6.out
-   gi|110640213|ref|NC_008253.1|   2852852 8:T>A
-   gi|110640213|ref|NC_008253.1|   148810  10:A>G,13:C>G
+   gi|110640213|ref|NC_008253.1|   1093035 2:T>G,15:A>T
-   gi|110640213|ref|NC_008253.1|   905664  6:A>G,7:G>T
-   gi|110640213|ref|NC_008253.1|   4930433 4:G>T,6:C>G

bowtie -a -m 3 --best --strata -v 2 e_coli --suppress 1,5,6,7 -c
ATGCATCATGCGCCAT  > example9.out

bowtie 1.1.2-6

cat example9.out
-   gi|110640213|ref|NC_008253.1|   2852852 8:T>A

bowtie 1.2.1.1+dfsg-1

produces empty example9.out

Thank you,
Alex

[0] https://anonscm.debian.org/git/debian-med/bowtie.git

Role of acedb-other-belvu and acedb-other-dotter versus belvu & dotter from seqtools

[Andreas Tille]

Hi,

I started to check the list of external packages of possibly interesting
packages and stumbled upon blixem which is part of seqtools[1].  The
source also contains dotter and belvu and seems to be actively
maintained.  However, the packages acedb-other-belvu and
acedb-other-dotter from source acedb (which is orphaned upstream)
contain the same executable names and it seems the programs are doing
the same.  My packaging attempt on seqtools[2] went quite smoothly but
surely needs some polishing - most probably also dynamic linking against
a common library.  Before I'll spent additional time cycles I'd like to
know your opinion whether we should simply replace the orphaned belvu
and dotter versions from the acedb package or if not how we should
proceed otherwise.

Kind regards

Andreas.

[1] http://www.sanger.ac.uk/science/tools/seqtools
[2] https://anonscm.debian.org/git/debian-med/seqtools.git

-- 
http://fam-tille.de

Re: [Outreachy] Hi all!

[ka lou]

Dear all,

I am sorry for the late answer!  This is just an update on my last tries to
get the source of tophat and run a test with sbuild ;)

As Diane suggested in the last email , i downloaded and installed (at least
tried too) the sbuild package on my linux mint machine. I followed the
instructions of the Debian wiki

and
i also installed the libsbuild-dev
. Things
seemed to work up until that point.

I then followed the commands  'apt source tophat' , 'apt build-dep
tophat',  'cd usr/source/tophat',  'dpkg-buildpackage', which went also
well.
However, when i tried 'sudo sbuild -d unstable' , after running for a while
i get an error : ​ 'E: Build failure (dpkg-buildpackage died)'.
I think the error connected to that (last lines of the log) is that :
'/usr/include/c++/7/bits/stl_pair.h:519:5: note:   template argument
deduction/substitution failed:
tophat_reports.cpp:2707:128: note:   cannot convert ‘junction_stat’ (type
‘JunctionStats’) to type ‘JunctionStats&&’
 gtf_junctions.insert(make_pair(Junction(ref_id, left_coord, right_coord, antisense),
junction_stat));'

I can also send you more details if you wish (e.g the summary) , i am sorry
i do not know very well how to report all these.

Finally , i would like to tell you that since my PhD thesis deadline is
postponed to the end of January , i will probably won't make it to apply to
the Outreach program for this round... which is really sad. However , with
your permission, i would like to keep on working on running tests and get
more familiar with the whole process. And hopefully i will be able to apply
for Outreach's next round!

Thank you all very much,
Katerina


On Sat, Oct 14, 2017 at 12:02 AM, ka lou  wrote:

> Dear Andreas and Diane and all, thank you for your help!!
>
> I'll keep you posted about the results - hopefully successful ones :)
>
> Thank you again so much!
>
> On Fri, Oct 13, 2017 at 10:10 PM, Diane Trout  wrote:
>
>>
>> I have one question : all the examples in the part of the tutorial for
>> setting up the development environment (i.e sudo apt-get install rerun
>> ruby-foreman apt-cacher-ng
>> |
>> moreutils lighttpd rabbitmq-server) are relative to the specific package
>> of 'rubby'? So when i want to set up the environment for running test in
>> another package i will have to change these commands accordingly?
>>
>>
>> I suspect apt-cacher-ng is in there as a performance enhancement.
>>
>> apt-cacher-ng can help speed frequent rebuilding of packages because it
>> can download and store locally packages.
>>
>> When you're first starting to test build an application you'd do:
>>
>> apt source 
>> apt build-dep 
>> cd 
>> dpkg-buildpackage
>>
>> (with the stretch release they added apt as an improvement to apt-get)
>>
>> Debian maintianers will usually build packages in a temporary environment
>> using tools like pbuilder or sbuild. Those tools automate extracting the
>> package, installing the dependencies, building, and running tests. It's
>> just a bit of work to get them setup.
>>
>> And it looks like autopkgtest expects to be running in a temporary build
>> environment so it can install things and change the system configuration.
>>
>> Hope that helps
>> Diane
>>
>
>

Re: Fwd: Lack of license for pal2nal

[Michael Crusoe]

Hello Mikita,

Thank you very much!


Pe 17 oct. 2017 1:59 p.m., "Mikita Suyama"  a
scris:

Hello Michael,

I put a sentence about the license to the script, so from now on, the
script (pal2nal.pl v14.1) is licensed under GPL v2.0.
At the moment, I don't have an access permission to the download site of
PAL2NAL on the web, so I attached a tar.gz file that contains the modified
script with the license declaration.

best regards,

Mikita



On 2017/10/10 18:48, Michael Crusoe wrote:

Hello Mikita,

This is wonderful news -- thank you very much! We really appreciate it.

Have a safe trip,

2017-10-10 11:46 GMT+02:00 Mikita Suyama :

> Hi Peer,
>
> Thank you for forwarding the message.
>
>
> Hello Michael,
>
> I will set GPL license to PAL2NAL to make the things clear.
>
> I'll modify the header of the code to clarify this license, and
> put it to the download site, and also send a copy to you.
> But, unfortunately, now I'm on my business trip and have little time
> to access the code. So, I'll do this as soon as I come back to the
> office, which will be on next Tuesday (Oct 17th).
>
> Best regards,
>
> Mikita
>
> --
> Mikita Suyama
> Medical Institute of Bioregulation
> Kyushu University
> mik...@bioreg.kyushu-u.ac.jp
>
>
> On 2017/10/09 22:56, Peer Bork wrote:
>
> Hi Mikita,
>
> I never thought about licenses, but having a gnu etc thingy might be
> better than having it open source. Up to you
> Best Wishes
> P
>
> From the Road...
>
> Begin forwarded message:
>
> *From:* "Michael R. Crusoe" 
> *Date:* 9. October 2017 at 15:34:49 GMT+2
> *To:* mik...@genome.med.kyoto-u.ac.jp, b...@embl.de
> *Cc:* "moel...@debian.org" ,  Debian Med Project List
> , Pjotr Prins 
> *Subject:* *Lack of license for pal2nal*
>
> Hello,
>
> I'm writing you on behalf of the Debian Med team which is a subgroup
> inside Debian with the objective to package free software in the field
> of biology and medicine for official Debian releases. We have packaged
> pal2nal but we can not distribute it as it has no license.
>
> Since Debian only distributes free software (for instance licensed under
> GPL, BSD or so) we are wondering whether you might consider to publish
> the source code of this software under a free license.
>
> The advantage would be that users of Debian / Ubuntu and its derivatives
> systems which are quite frequently used in bioinformatics could easily
> install your software.  You also get some additional quality assurance
> and I can confirm that all authors who decided to open source their
> software to enable the Debian Med packaging team were happy about this
> step since it contributed to a wider distribution of their software and
> a better user response.
>
> Kind regards and thanks for considering,
>
> --
> Michael R. Crusoe
> Co-founder & Lead,
> Common Workflow Language project 
> https://impactstory.org/u/-0002-2961-9670
> m...@commonwl.org
>
>
>


-- 
Michael R. Crusoe
Co-founder & Lead,
Common Workflow Language project 
https://impactstory.org/u/-0002-2961-9670
m...@commonwl.org
+1 480 627 9108 <(480)%20627-9108>

Help with cmake / Qt5 migration needed

[Andreas Tille]

Hi,

I'd like to package beads[1] which is Qt4 but since Qt4 will be droped
soon my goal is to port it to Qt5.  With my current packaging attempt[1]
I get:

CMake Error at src/CMakeLists.txt:4 (FIND_PACKAGE):
  Found package configuration file:

/usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake

  but it set Qt5_FOUND to FALSE so package "Qt5" is considered to be NOT
  FOUND.  Reason given by package:

  The Qt5 package requires at least one component


The FIND_PACKAGE line was patched by me where I naively did

   s/Qt4 REQUIRED/Qt5 REQUIRED/

Any hint how to get this build is welcome.

Kind regards

  Andreas.

[1] https://anonscm.debian.org/git/debian-med/beads.git

-- 
http://fam-tille.de

[MoM] Re: gatb-core packaging

[Andreas Tille]

Hi Nadiya,

after the longish explanation about your packaging attempt of gatb-core
I wonder whether this former hint of Olivier might get some relevance to
get things done more easily.  May be you can discuss removing third
party code with upstream authors.

Kind regards

  Andreas.

On Thu, Aug 24, 2017 at 08:40:27AM +0200, Olivier Sallou wrote:
> - Mail original -
> 
> > De: "Nadiya Sitdykova" 
> > À: "Debian Med Project List" 
> > Envoyé: Jeudi 24 Août 2017 04:30:20
> > Objet: gatb-core packaging
> 
> > Hello Andreas,
> 
> > I decided at least to try to package gatb-core.
> > The Debian Med Group Policy suggests to add the package to the "task" file,
> > so I
> > did
> 
> > debcheckout -a debian-med
> 
> > then added info about gatb-core to the tasks/bio-dev and then tried to push
> > the changes.
> 
> Hi, just for info I personally know some guys behind gatb-core, so if you 
> face issues needing upstream info, you can CC me in your mails with them, I 
> will check they consider your questions/comments ;-) 
> 
> Olivier 
> 
> > But it seems that I don't have writing rights. Here is what I got:
> 
> > nadiya@debian:~/tasks/debian-med$ git push
> > Enter passphrase for key '/home/nadiya/.ssh/id_rsa':
> > Counting objects: 4, done.
> > Compressing objects: 100% (4/4), done.
> > Writing objects: 100% (4/4), 732 bytes | 183.00 KiB/s, done.
> > Total 4 (delta 3), reused 0 (delta 0)
> > remote: error: insufficient permission for adding an object to repository
> > database ./objects
> > remote: fatal: failed to write object
> > error: remote unpack failed: unpack-objects abnormal exit
> > To git+ssh:// git.debian.org/git/blends/projects/med.git
> > ! [remote rejected] master -> master (unpacker error)
> > error: failed to push some refs to 'git+ssh://
> > git.debian.org/git/blends/projects/med.git '
> 
> > I checked my git configuration and both name and mail seems right:
> > user.name =Nadiya Sitdykova
> > user.email= rovensk...@gmail.com
> 
> > Any ideas what I'm doing wrong?

-- 
http://fam-tille.de

Re: debian/upstream/metadata: registry item for the Blends' task pages?

[Andreas Tille]

On Tue, Aug 15, 2017 at 09:44:48AM +0200, Steffen Möller wrote:
> 
> @Andreas, I am mostly concerned about getting the references to
> registries as quickly as possible to our task pages. What do you
> suggest? Continue for now with debian/upstream/metadata and move to
> appstream as soon as we know how this all relates to upstream/metadata
> and have made respective holistic decisions?

For the moment I can not find any data in appstream metadata files.
Once this is decided and there are some data I see no problem to import
it into UDD. 

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: debian/upstream/metadata: registry item for the Blends' task pages?

[Andreas Tille]

Hi Dylan,

On Tue, Aug 15, 2017 at 12:17:29AM +0200, Dylan Aïssi wrote:
> > fully grasp how to get it in and - is not everything in
> > upstream/metadata something for appstream? Also, from what I got, this
> > shoud all be redistributed with the upstream source tree and not be kept
> > within Debian to the degree I got this right.
> >
> 
> I agree that could be pushed in the appstream file instead the
> metadata file. By this way, it will be easier reused by other
> distributions.

I fully agree but this has not happened so far.  If somebody intends
to feed this metadata into appstream files please let me know and
I'll extend the UDD importer.

> Indeed, appstream and upstream/metadata seems to be redundant. We
> should probably propose new fields in the specification [1].

You have a point here.  It seems somebody needs to do the work to sort
this out.  I'm fine with adapting things in UDD.

> We can distribute the appstream file in the deb package until upstream
> redistribute it. It was what I have done with the galileo package.

In the file debian/debian/galileo.metainfo.xml I can not find the type
of information we currently maintain in debian/upstream/metadata.  Can
you provide a better example?

Kind regards

   Andreas.

> [1] https://github.com/ximion/appstream/issues

-- 
http://fam-tille.de

Please check implementation (Was: Proposal for Registry-display on task pages)

[Andreas Tille]

Hi,

I've posted a set of questions today to this list and they are remaining
**open**.  So those who feel able to answer the questions please check
out this thread.

Despite the open questions I tried an example implementation:

   https://blends.debian.org/med/tasks/bio

To mark different repositories visibly I went to their homepage and
picked the "main color" there to use it as background for the according
link (but used transparency level 75% to make the page not to
varicoloured.

I did **not** implemented the 'NA' feature suggested by Steffen since I
was not convinced that users will really follow any link to do something
- my experience to provide screenshots, debtags and translations is
quite bad (BTW, have you provided any screenshot today?)

Please test, comment and find bugs in the implementation - and answer
the open questions in this thread.

Kind regards

   Andreas.

On Mon, Oct 09, 2017 at 04:10:59PM +0200, Steffen Möller wrote:
> Hi Andreas,
> here some R/Python/PHP-mix pseudocode idea for getting
> the registry links displayed on the task page:
> 
> registry_prefix={
>   "bio.tools"=>"https://bio.tools/;,
>   "RRID" => "http://identifiers.org/rrid/RRID:;,
>   "SciCrunch" => "http://identifiers.org/rrid/RRID:;,
>   "OMICtools" => "https://duckduckgo.com/?q=\\; (a single backslash at the 
> end is what I want)
> }
> 
> print "Registries: "
> for (registry_name,registry_id) %in% registry_assignments {
>   prefix=registry_prefix[[registry_name]]
>   if (empty(prefix) or "NA"==registry_id) {
> print "%s:%s" % ($registry_name,$registry_id)
>   } else {
> print "%s:%s" % 
> (registry_name,prefix,registry_id,registry_id)
>   }
> }
> 
> The situation with OMICtools is not yet ideal, but from what
> I understood this will soon get better. The single backslash
> at the end induces some "You feel lucky!"-like immediate
> forward to the top hit. Funnily enough, SciCrunch also needs
> a bit of bridge, albeit a more deterministic one.
> 
> Best,
> 
> Steffen
> 
> 

-- 
http://fam-tille.de

Re: Proposal for Registry-display on task pages

[Andreas Tille]

Hi Dylan,

On Thu, Oct 19, 2017 at 12:26:44PM +0200, Dylan Aïssi wrote:
> Hi Andreas,
> 
> 2017-10-19 8:29 GMT+02:00 Andreas Tille :
> > On Mon, Oct 09, 2017 at 04:10:59PM +0200, Steffen Möller wrote:
> >>   "OMICtools" => "https://duckduckgo.com/?q=\\; (a single backslash at the 
> >> end is what I want)
> >
> > The link
> >
> > https://duckduckgo.com/?q=\OMIC_6
> >
> > should lead to something related to abyss but it does not. :-(
> 
> It's normal, the OMICtools ID here is incorrect, the correct ID is
> OMICS_6 with a "S". We started to correct these ID but some still
> need to be corrected.

Well, it might be that we have some typos in our data but this
duckduckgo.com detour seems very suspicious to me and I would love to
avoid this.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Proposal for Registry-display on task pages

[Dylan Aïssi]

Hi Andreas,

2017-10-19 8:29 GMT+02:00 Andreas Tille :
> On Mon, Oct 09, 2017 at 04:10:59PM +0200, Steffen Möller wrote:
>>   "OMICtools" => "https://duckduckgo.com/?q=\\; (a single backslash at the 
>> end is what I want)
>
> The link
>
> https://duckduckgo.com/?q=\OMIC_6
>
> should lead to something related to abyss but it does not. :-(
>

It's normal, the OMICtools ID here is incorrect, the correct ID is
OMICS_6 with a "S". We started to correct these ID but some still
need to be corrected.

Best,
Dylan

Re: Proposal for Registry-display on task pages

[Andreas Tille]

On Thu, Oct 19, 2017 at 08:22:34AM +0200, Andreas Tille wrote:
> On Mon, Oct 09, 2017 at 04:10:59PM +0200, Steffen Möller wrote:
> > 
> > registry_prefix={
> >   "bio.tools"=>"https://bio.tools/;,
> >   "RRID" => "http://identifiers.org/rrid/RRID:;,
> >   "SciCrunch" => "http://identifiers.org/rrid/RRID:;,
> >   "OMICtools" => "https://duckduckgo.com/?q=\\; (a single backslash at the 
> > end is what I want)
> > }
> 
> What about SEQwiki ?

udd=# select * from registry where name = 'SEQwiki';
source |  name   |   entry
---+-+
 snpomatic | SEQwiki | SNP-o-matic
 ssake | SEQwiki | http://seqanswers.com/wiki/SSAKE
 ampliconnoise | SEQwiki | PyroNoise
 trinityrnaseq | SEQwiki | http://seqanswers.com/wiki/Trinity
 bowtie2   | SEQwiki | Bowtie
 bwa   | SEQwiki | http://seqanswers.com/wiki/BWA
 bowtie| SEQwiki | http://seqanswers.com/wiki/Bowtie
 fastqc| SEQwiki | FastQC
(8 rows)

The registry entries for SEQwiki are a mix from kind of IDish entries
and URLs.  I checked two of the URLs and I searched for SEQwiki which
leaded to

 https://www.bioinformatics.org/wiki/SEQwiki

The local search for the IDish entries did not lead to anything
sensible.

Please clarify.

Thanks

  Andreas.
 

-- 
http://fam-tille.de

Re: Proposal for Registry-display on task pages

[Andreas Tille]

On Mon, Oct 09, 2017 at 04:10:59PM +0200, Steffen Möller wrote:
> registry_prefix={
>   "bio.tools"=>"https://bio.tools/;,

This entry does not work with your algorithm:

   bowtie| bio.tools | http://bio.tools/tool/DebianMed/bowtie/1.1.1

I've removed this entry from debian/upstream/metadata.

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Re: Proposal for Registry-display on task pages

[Andreas Tille]

Hi again,

On Thu, Oct 19, 2017 at 08:32:23AM +0200, Andreas Tille wrote:
> On Thu, Oct 19, 2017 at 08:29:15AM +0200, Andreas Tille wrote:
> > On Mon, Oct 09, 2017 at 04:10:59PM +0200, Steffen Möller wrote:
> > >   "OMICtools" => "https://duckduckgo.com/?q=\\; (a single backslash at 
> > > the end is what I want)
> > 
> > The link
> > 
> > https://duckduckgo.com/?q=\OMIC_6
> > 
> > should lead to something related to abyss but it does not. :-(
> 
> Wouldn't it be more sensible to register the OMICtools name "abyss-tool"
> in our registry which can be used to refer to
> 
>   https://omictools.com/abyss-tool
> 
> instead of maintaining some "random" key we can not easily use?

I've somehow saved the hackish workaround by linking to

https://duckduckgo.com/?q=\site%3Aomictools.com+OMIC_6

(in the abyss example) but my question above remains. 

Kind regards

Andreas.

-- 
http://fam-tille.de

Re: Proposal for Registry-display on task pages

[Andreas Tille]

On Thu, Oct 19, 2017 at 08:29:15AM +0200, Andreas Tille wrote:
> On Mon, Oct 09, 2017 at 04:10:59PM +0200, Steffen Möller wrote:
> >   "OMICtools" => "https://duckduckgo.com/?q=\\; (a single backslash at the 
> > end is what I want)
> 
> The link
> 
> https://duckduckgo.com/?q=\OMIC_6
> 
> should lead to something related to abyss but it does not. :-(

Wouldn't it be more sensible to register the OMICtools name "abyss-tool"
in our registry which can be used to refer to

  https://omictools.com/abyss-tool

instead of maintaining some "random" key we can not easily use?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Proposal for Registry-display on task pages

[Andreas Tille]

On Mon, Oct 09, 2017 at 04:10:59PM +0200, Steffen Möller wrote:
>   "OMICtools" => "https://duckduckgo.com/?q=\\; (a single backslash at the 
> end is what I want)

The link

https://duckduckgo.com/?q=\OMIC_6

should lead to something related to abyss but it does not. :-(

Kind regards

   Andreas. 

-- 
http://fam-tille.de

Re: Proposal for Registry-display on task pages

[Andreas Tille]

On Mon, Oct 09, 2017 at 04:10:59PM +0200, Steffen Möller wrote:
> 
> registry_prefix={
>   "bio.tools"=>"https://bio.tools/;,
>   "RRID" => "http://identifiers.org/rrid/RRID:;,
>   "SciCrunch" => "http://identifiers.org/rrid/RRID:;,
>   "OMICtools" => "https://duckduckgo.com/?q=\\; (a single backslash at the 
> end is what I want)
> }

What about SEQwiki ?

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Proposal for Registry-display on task pages

[Andreas Tille]

Hi Steffen,

I'm working on some test implementation

On Mon, Oct 09, 2017 at 04:10:59PM +0200, Steffen Möller wrote:
> 
> registry_prefix={
>   "bio.tools"=>"https://bio.tools/;,
>   "RRID" => "http://identifiers.org/rrid/RRID:;,
>   "SciCrunch" => "http://identifiers.org/rrid/RRID:;,

How comes that this is the same URL?  Is it a typo?

Kind regards

  Andreas. 

-- 
http://fam-tille.de