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

[Pierre Gruet <pgtdebian@free.fr>]

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