Re: /usr/bin/picard Re: bcbio will need another while - needs gatk
Hi Andreas,
On 14.11.20 21:50, Andreas Tille wrote:
> Hi Steffen,
>
> On Sat, Nov 14, 2020 at 08:18:48PM +0100, Steffen Möller wrote:
>>> We have the workaround
>>>
>>> /usr/lib/debian-med/bin/
>>>
>>> see for instance in eigensoft[1] and lots of other packages. Simply
>>> provide this for picard-tools and make sure gatk users set the PATH
>>> accordingly.
>> Ah - that is good. Seems like I should read our policy document again.
> Not sure whether it is mentioned in policy. I introduced this 2 or 3
> sprints ago. Finally you are Uploader of at least one package using
> this technique. ;-P
;)
>> I just checked what my installation has in this directory ... and it
>> seems like I spotted a typo (or a creative fix of a typo elsewhere)
> ?
tranlate misses the "s"
>
>> $ ls -l /usr/lib/debian-med/bin/
>> total 0
>> lrwxrwxrwx 1 root root 26 Nov 12 16:57 tranlate ->
>> ../../../bin/fsa-translate
>>
>> $ apt-file search tranlate
>> fsa: /usr/lib/debian-med/bin/tranlate
>> $ apt-file search /usr/bin/translate
>> drslib: /usr/bin/translate_cmip3
>> openafs-client: /usr/bin/translate_et
>> translate: /usr/bin/translate
>>
>> I presume you would be happy for me to put there a link from cnvkit.py
>> (like bcbio expects it) to /usr/bin/cnvkit, right?
> Well, I think its orthogonal to my own happyness. If it works for
> you just do the same as in the given example package.
I added that symlink and then patched bcbio to not expect the .py since
bcbio ignored the $PATH on this one.
>>> Simply ping the authors about this. As far as I remember the last
>>> status was that sources are lost (?????) and a backup needs to be found.
>> And if we just go for a non-free binary package for those jars? Just to
>> get somewhere?
> I personally consider maintaining non-free packages a pure nuisance and
> I'm not motivated to maintain such a package. I think we should do
> *way* more effort to free *all* our non-free packages.
>
>> bcbio is in contrib anyway because of vienna-rna.
> Same here. I do not see any record of attempts to free vienna-rna.
https://github.com/ViennaRNA/ViennaRNA/issues/97
>> And I do not think
>> these .jar files
>> will find much future adoption without a source backing, so this problem
>> will eradicate
>> itself.
> I will not try to stop anybody to maintain non-free packages - just do
> not trust on me in doing so.
>
>> There is also
>> bcbio.pipeline.config_utils.CmdNotFound: '_get_program_cmd' 'snpEff'
>> {'dir': '/usr/local/share/java/snpeff', 'jvm_opts': ['-Xms750m',
>> '-Xmx3g']} None
> I think we are pretty close to snpEff due to Pierre's efforts.
Nice!
This may be worth a sidenote - bcbio to me is something metaphorical. We
have it in the distribution already. And now we work to get all the
runtime-dependencies in to make it functional. And snpEff is pretty high
up (it interprets the importance of nucleotide variations, you need to
have identified these variants for that, first). So, my comment on
"snpeff" being invoked was to be interpreted as "see, here we are already".
>> ... picard-tools stuff snipped - I have nothing to say here ...
Works now.
>> Somehow Debian does barely complete any of these tests. There is always
>> something missing. And if it is tophat that upstream had asked us not to
>> support any more.
> I asked *several* times whether we need tophat and consequently will do
> a Python3 port. Its perfectly fine for me to re-introduce tophat once
> it works with Python3.
Do other things first. I would not be completely surprised if this is
gone in one of the next updates to bcbio.
Steffen
Reply to: