Re: Import of debian med packages metadata to Tools Platform Ecosystem

[Steffen Möller]

On 25.07.20 22:49, Hervé Ménager wrote:
> Hi Steffen, Andreas,
>
> - Thanks for the clarification regarding the mirror. I thought there
> was a mirror because I read this in the edam.sh comment:
> "
> This script lives on
>
> https://salsa.debian.org/blends-team/website/commits/master/misc/sql/edam.sh
> 
>
>
This is where Andreas initially commited to.
>
> and a redundant copy is held on
>
> https://github.com/bio-tools/biotoolsConnect.git/DebianMed/edam.sh
> 
> "
This is where Matúš and I fiddled with it and the initial site got
everything back.
>
> - regarding the fact of reusing the output of edam.sh rather than a
> single python script, I wholeheartedly agree. I just focused at first
> on a minimal working workflow, but time permitting, I'd like to clean
> up a bit and have a single python tool
Yip. And at the 2019 Sprint we came up with an almost working web
service to translate between bio.tools and Debian med package names.
This should now depend on bio.tools directly, right?
>
> - regarding EDAM annotations, one source you could possibly use is
> bio.tools, for the packages which are already cross-linked between
> debian and bio.tools.

Ok - then I suggest to

 a) complete the mapping from Debian to bio.tools for the bioinformatics
packages on that Excel sheet (state "n" that I mention below)
 b) add d/u/edam files for these packages, maybe autogenerate them from
bio.tools if not already existing? We need to mention that in d/copyright.
 c) see how this can be fed back to bio.tools.

>
> Anyway, thanks a lot for your help, I am so very happy this is now up
> and running! We should set up a plan to continue this work!

m) I first looked on bio.tools for "blast", was unhappy with the result,
then "ncbi blast", still unhappy.

n) Ok, then "bowtie", which is what the debian/upstream/edam effort once
started with and found https://bio.tools/bowtie2 with a reference to the
Debian package on the lower-right. It is actually the first time I ever
saw that but you likely have that for a while already and I was just
unaware of it right?https://bio.tools/clustalo also worked. Nice.

o) Infernal is a bit broken on the bio.tools side since it only refers
to one of its executables.

p) hmmer3 (https://bio.tools/hmmer3) does not have a ref to Debian.

q) I then searched for "Debian" on bio.tools and found four entries.
https://bio.tools/DNCON2 hat Debian in its description. The other three
have a "DebianMed" collection tag. I was not aware of that.

My personal ambition for bio.tools is that it substitutes most of what
the Debian Med task pages are doing at the moment. But that is just what
keeps me going, let's ignore this for now, just for the back of our minds.

Concerning m-q - I happen to have stumbled across 5 very different
problems/challenges. Only for packages that have reached the state "n" I
think we shall proceed with edam annotation in Debian so we have a
feedback loop. What would be the right thing to do for a Debian package
maintainer / user who encounters a package in state m, o, p or q? This
is an issue on github, I presume, but maybe you could come up with a bit
more of an explicit instruction for the Debian folks how to report and
where to make it all as easy as possible for bio.tools?

Do you have opinions on a-c?

Best,

Steffen


> n Sat, Jul 25, 2020 at 5:15 PM Steffen Möller  > wrote:
>
> This is great news, thank you for this, Hervé.
>
> For now I think the most important bit is to have anything that is
> automated in some reasonable way. And then let's extend that over
> time.
> This should give edam annotation a particular boost, I tend to think.
>
> You may be aware of an earlier email in which I described the Google
> Spreadsheet
> 
> https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit?usp=sharing
> 
> 
> to provide an overview on what packages (rows) are important for which
> workflows (columns).
>
> Now imagine what EDAM could do for us along those lines. @Jon,Matúš,
> should we possibly do some bulk EDAM annotation just for the
> packages on
> this "virus" tab? I suggest several iterations, like Topics first to
> provide the summary scope and I/O+File formats second for the
> individual
> executables once we know more about it all.
>
> Best,
>
> Steffen
>
>
> On 25.07.20 16:33, Andreas Tille wrote:
> > Hi Hervé
> >
> > On Sat, Jul 25, 2020 at 12:43:08AM +0200, Hervé Ménager wrote:
> >> Hello Steffen, everyone,
> >> This is to let you know I am currently attending the BCC
> virtual hackathon (
> >> https://bcc2020.github.io/cofest/
> 

Re: quast - should this be uploaded?

[Andreas Tille]

On Sun, Jul 26, 2020 at 02:56:09PM +0200, Steffen Möller wrote:
> Ah - thanks! Seems like something is wrong with the busco package, then.

But busco does not feature busco.py (I checked this).
 
> d/changelog mentions a d/TODO - do you have this uncommitted on your
> end, possibly?

I was wondering about this as well.  No, I do not have such a file.  We
should either create one or delete the reference to it to avoid
confusion.

Kind regards

 Andreas.
 
> Best,
> 
> Steffen
> 
> On 25.07.20 23:54, Andreas Tille wrote:
> > dh clean --with python3 --buildsystem=pybuild
> >debian/rules override_dh_auto_clean
> > make[1]: Entering directory 
> > '/home/andreas/debian-maintain/salsa/med-team/0_prospective/build-area/quast-5.0.2+dfsg'
> > dh_auto_clean
> > I: pybuild base:217: python3.8 setup.py clean
> > Traceback (most recent call last):
> >   File "setup.py", line 37, in 
> > from quast_libs.run_busco import download_all_db
> >   File 
> > "/home/andreas/debian-maintain/salsa/med-team/0_prospective/build-area/quast-5.0.2+dfsg/quast_libs/run_busco.py",
> >  line 16, in 
> > import busco
> > ModuleNotFoundError: No module named 'busco'
> > E: pybuild pybuild:352: clean: plugin distutils failed with: exit code=1: 
> > python3.8 setup.py clean
> 

-- 
http://fam-tille.de

Attributions concern for aparapi (currently in NEW)

[Pierre Gruet]

Hi,

I just realized there was a strange paragraph in the ATTRIBUTIONS.md
file in libaparapi-java root folder :

https://salsa.debian.org/med-team/libaparapi-java/-/blob/master/ATTRIBUTIONS.md

It seems to be restrictive and perhaps annoying for us.

Afterwards I saw that Andreas had already raised and discussed the issue
on Debian lists, and that we were still waiting for an answer about
removing this clause :

https://github.com/aparapi/aparapi/issues/50

Yet I packaged libaparapi-java and we sent it in NEW, where it currently
lies. Sorry for not seeing it before.

Shoud we wait and see if it exits NEW or ask for its removal now?

Thanks for the advice,
Pierre

[RFS] prime-philo

[Nilesh Patra]

Hi,
I've fixed gcc-10 FTBFS for prime-philo as reported here in #957708.
builds with passing tests.
I've pushed my changes to the team-repo[1]
Please:

gbp clone --pristine-tar https://salsa.debian.org/med-team/prime-philo

OR

Grant DM access: PGP key fingerprint:
3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1

Thanks and regards
Nilesh

Re: Attributions concern for aparapi (currently in NEW)

[Andreas Tille]

Hi Pierre,

On Sun, Jul 26, 2020 at 04:13:41PM +0200, Pierre Gruet wrote:
> I just realized there was a strange paragraph in the ATTRIBUTIONS.md
> file in libaparapi-java root folder :
> 
> https://salsa.debian.org/med-team/libaparapi-java/-/blob/master/ATTRIBUTIONS.md
> 
> It seems to be restrictive and perhaps annoying for us.
> 
> Afterwards I saw that Andreas had already raised and discussed the issue
> on Debian lists, and that we were still waiting for an answer about
> removing this clause :
> 
> https://github.com/aparapi/aparapi/issues/50

I've pinged that issue.
 
> Yet I packaged libaparapi-java and we sent it in NEW, where it currently
> lies. Sorry for not seeing it before.

Well, its not only your fault - I should have seen it when sponsoring.
 
> Shoud we wait and see if it exits NEW or ask for its removal now?

May be some explicit hint to ftpmaster and asking for opinions is the
best way to go.

Kind regards

Andreas. 

-- 
http://fam-tille.de

Re: [RFS] prime-philo

[Steffen Möller]

Allowed.

On 26.07.20 16:41, Nilesh Patra wrote:
> Hi,
> I've fixed gcc-10 FTBFS for prime-philo as reported here in #957708.
> builds with passing tests.
> I've pushed my changes to the team-repo[1]
> Please:
>
> gbp clone --pristine-tar https://salsa.debian.org/med-team/prime-philo
> 
>
> OR
>
> Grant DM access: PGP key fingerprint:
> 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1
>
> Thanks and regards
> Nilesh

About Snpeff packaging (Was : Re: Attributions concern for aparapi (currently in NEW))

[Pierre Gruet]

Hi Andreas,

Le 26/07/2020 à 17:22, Andreas Tille a écrit :
> Hi Pierre,
> 
>>
>> https://github.com/aparapi/aparapi/issues/50
> 
> I've pinged that issue.
>

Thanks!

>  
>> Yet I packaged libaparapi-java and we sent it in NEW, where it currently
>> lies. Sorry for not seeing it before.
> 
> Well, its not only your fault - I should have seen it when sponsoring.
>

Well, I should have looked more carefully -- which I will do, in the future!

>  
>> Shoud we wait and see if it exits NEW or ask for its removal now?
> 
> May be some explicit hint to ftpmaster and asking for opinions is the
> best way to go.
> 

Thanks for the suggestion, I will thus do so, stating the issue explicitly.



While I am at it:
- if aparapi cannot enter Debian, I should be able to deactivate the
module of apfloat that uses it, as this module is not part of the main
code. I have got a similar issue for the module using jscience, as
important non backward-compatible ABI changes in a dependency of
jscience will prevent us from packaging it unless a new version comes
one day. Snpeff does not use any of those modules (aparapi and jscience
wrappers);
- charts4j is currently in NEW;
- distlib is in unstable and testing;
- I have some concerns about akko-actor, as the build of this software
seems to be relying on Scala Build Tool (sbt), which is packaged in
Debian but not in good shape currently. I will look for a workaround if
possible.


>
> Kind regards
> 
> Andreas. 
> 

Best regards,
Pierre

Re: About Snpeff packaging (Was : Re: Attributions concern for aparapi (currently in NEW))

[Andreas Tille]

Hi Pierre,

On Sun, Jul 26, 2020 at 10:07:24PM +0200, Pierre Gruet wrote:
> Le 26/07/2020 à 17:22, Andreas Tille a écrit :
> >> https://github.com/aparapi/aparapi/issues/50
> > 
> > I've pinged that issue.
> 
> Thanks!

You are more than welcome.  Its just supporting your attempt which is
helping the Debian Med team with an important package.
 
> While I am at it:
> - if aparapi cannot enter Debian, I should be able to deactivate the
> module of apfloat that uses it, as this module is not part of the main
> code. I have got a similar issue for the module using jscience, as
> important non backward-compatible ABI changes in a dependency of
> jscience will prevent us from packaging it unless a new version comes
> one day. Snpeff does not use any of those modules (aparapi and jscience
> wrappers);

Thanks a lot for your investigation.  While I'd prefer to provide a full
featured package but finally its very good news that we might be able to
leave out what is not possible to package due to licensing issues.

> - charts4j is currently in NEW;
> - distlib is in unstable and testing;

Finally. :-)

> - I have some concerns about akko-actor, as the build of this software
> seems to be relying on Scala Build Tool (sbt), which is packaged in
> Debian but not in good shape currently. I will look for a workaround if
> possible.

I remember we have some other package inside Debian which is Scala source
(I would need to check which package if it is of interest) and finally
we found a way to deal with this.
 
Thanks a lot for your work on this snpeff.  Its very appreciated

  Andreas. 

-- 
http://fam-tille.de

RF peer review: DYNAMIC

[Steffen Möller]

Heya,

This goes to Andreas in particular, upstream has addressed their test
issues - the problem was with the tests. They also kindly issued a
release tag for the first version, but not for the now fixed one, so we
now have 1.0~alpha.1+2020072524git5390b6c , which I find amusingly long.
And amusingly wrong - it should be 20200724.

DYNAMIC as a source package name I found a bit ambiguous so I went for
https://salsa.debian.org/med-team/xxsds-dynamic. This is kind of
important also since the vgteam maintains a fork and it is the one that
is referenced by mmmulti. Our Covid-19 hackathon synchronized the two
efforts. Happy.

Best,

Steffen