Hello Marius

Thanks for the prompt reply & explanation of the channel ordering.

Checking galaxy.ini, the ordering isn't explicitly set for our instance. I'm guessing that in this case the ordering is taken from whatever Galaxy's default ordering is for that version. Is it better to explicitly set the ordering in future?

Also thanks for the tip-off re updating conda, doing that now.

Thanks for your help,

Best wishes

Peter

-- 
Peter Briggs peter.briggs@manchester.ac.uk
Bioinformatics Core Facility University of Manchester
B.1083 Michael Smith Bldg Tel: (0161) 2751482

From: Marius van den Beek [m.vandenbeek@gmail.com]
Sent: Thursday, August 17, 2017 5:47 PM
To: Peter Briggs
Cc: Galaxy Dev List
Subject: Re: [galaxy-dev] htseq-count/deseq2 conda dependency issues

Hi Peter,

indeed the defaults channel should now be the lowest priority of all conda channels.
This recommended setting in galaxy.ini is now

conda_ensure_channels = iuc,bioconda,conda-forge,defaults,r

Unfortunately these changes appear as changes are made within bioconda, which usually
do not coincide with galaxy releases. That means that these settings may need to be adjusted occasionally.
On a slightly unrelated note, if you have upgraded to galaxy 17.05 you should also upgrade conda to 4.2.13 if you haven't done so (conda install conda=4.2.13), for best experience.

Hope that helps,
Marius


On 17 August 2017 at 17:12, Peter Briggs <peter.briggs@manchester.ac.uk> wrote:
Dear devs

I've recently encountered some strange issues when running the htseq-count and deseq2 tools installed from the toolshed onto our production instance. In both cases there have been problems with a couple of the conda dependency installations.

Specifically:

- For htseq-count, runs failed with an error message about a missing libbz2.so.1.0.

- For deseq2, runs failed silently first with the same "missing libbz2.so.1.0" message, then when this was fixed, with a new message about an undefined symbol in libreadline.so.6.

In both cases I seemed to be able to fix the problems manually by activating the appropriate conda environments (under .../tool_dependencies/_conda/envs) and reinstalling the affected packages from different sources:

- htseq-count: in __samtools@1.3.1, reinstalled bzip2 1.0.2 from 'conda-forge' rather than 'defaults'

- deseq2: in __r-getopt@1.20.0, did the same for bzip2 and also got readline 6.3 from 'conda-forge' rather than 6.2 from 'defaults'

However: deseq2 installed into a local Galaxy instance doesn't seem to have this problem, so I'm guessing it's something peculiar to the setup of the production instance.

Can anyone suggest what might be happening here (e.g. some issue with the conda config for the production instance?), and how it might be avoided in future?

Thanks for your help,

Best wishes

Peter

(PS if it helps: the production instance is running Scientific Linux 6.8, and has recently been updated from v16.07 to v17.05. Both the tools were installed prior to the upgrade.)

--
Peter Briggs peter.briggs@manchester.ac.uk
Bioinformatics Core Facility University of Manchester
B.1083 Michael Smith Bldg Tel: (0161) 2751482
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
 https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
 http://galaxyproject.org/search/