Missing libicui18n.so.64 in conda installation

[Tomnl]

When trying to install the latest 1.12.0+galaxy0 into the Bham Galaxy instances we have been getting the following error

Fatal error: Exit code 1 ()
Loading required package: Rcpp
Error: package or namespace load failed for ‘msPurity’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/rds/bear-apps/handbuilt/software/galaxy/viantm-dev/galaxy/tool_dependencies/_conda/envs/mulled-v1-fea1f401d21bb11acce24f16c73c7884d1638bb0e8333e16578be52546dc19c3/lib/R/library/stringi/libs/stringi.so':
  libicui18n.so.64: cannot open shared object file: No such file or directory
In addition: Warning messages:
1: package ‘msPurity’ was built under R version 3.6.1 
2: package ‘Rcpp’ was built under R version 3.6.1 
Execution halted

However the same error is not reproduced on travis or locally on Ubuntu.

@jsaintvanne - have you had this problem when you have been testing?

@bgruening - have you seen anything similar to this before?

[Tomnl]

This seems to be related

https://github.com/conda-forge/r-stringi-feedstock/issues/20

Most recent post about it 15 hours ago

Thanks @RJMW

[bgruening]

Yes, looks lie conda has installed a wrong dependency. This can happen if you have the wrong channel order. Wired, try to remove the env and let Galaxy build it again. Alternatively, change into this env and install icu in version 64.

[bgruening]

https://github.com/conda-forge/r-stringi-feedstock/pull/17 ;)

[Tomnl]

Thanks @bgruening.

What Conda channel order is currently recommended. Is it [iuc, bioconda, r, defaults, conda-forge]?

[Tomnl]

Sorry that was an old reference. I was getting the error with the following order:

'iuc, conda-forge, bioconda, defaults'

[bgruening]

I guess this a broken package somewhere, try to install the package manually in this env for now.

[skbly7]

You can install it from r channel specifically, pinning worked for us. r::r-stringi in your environment.yml

[Tomnl]

OK - thanks for the help all. I am just installing r::r-stringi in the env at the moment as a temp solution

[hechth]

Seems like there is something similar happening again - anyone else having the same issues?

[Tomnl]

@hechth - could I check how you were installing? (e.g. was it via the toolshed/planemo/manually)

[hechth]

@Tomnl no worries it wasn't on this tool. It w was on other conda environments on some of the tools we develop

[Tomnl]

Ah OK, Were the tools using either bioconductor-mspurity or bioconductor-xcms?

[hechth]

I think neither of those actually.

[Tomnl]

I think fixed externally