August 2017 - galaxy-dev - lists.galaxyproject.org

toolshed and testtoolshed
by Matthias Bernt 23 Aug '17

23 Aug '17

Dear dev-list, Bjoern Gruening was so nice to provide a fix for one of the galaxy tools (openms_metaprosip). It seems that the fix found its way into the testtoolshed, but not the toolshed. So I was curious how the connection between these two tool sources works. - Is there a regular sync interval? Or does someone need to push a button to get a new version to the toolshed? - Are the versions (and the hashes) of the tools that find their way to the main toolshed identical? Then I could just switch the tool_shed_url in my tool_list.yml file when the desired version or a newer one appears in the main toolshed. - I guess its not a good idea (in general) to provide tools from the testtoolshed in a prodiction instance? Best, Matthias -- ------------------------------------------- Matthias Bernt Bioinformatics Service Molekulare Systembiologie (MOLSYB) Helmholtz-Zentrum für Umweltforschung GmbH - UFZ/ Helmholtz Centre for Environmental Research GmbH - UFZ Permoserstraße 15, 04318 Leipzig, Germany Phone +49 341 235 482296, m.bernt(a)ufz.de, www.ufz.de Sitz der Gesellschaft/Registered Office: Leipzig Registergericht/Registration Office: Amtsgericht Leipzig Handelsregister Nr./Trade Register Nr.: B 4703 Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: MinDirig Wilfried Kraus Wissenschaftlicher Geschäftsführer/Scientific Managing Director: Prof. Dr. Dr. h.c. Georg Teutsch Administrative Geschäftsführerin/ Administrative Managing Director: Prof. Dr. Heike Graßmann -------------------------------------------

3 2

Conda dependency install problems for DESeq2 tool
by Peter Briggs 23 Aug '17

23 Aug '17

Dear devs I'm experiencing problems with the conda dependencies for the DESeq2 tool (https://toolshed.g2.bx.psu.edu/repository?repository_id=1f158f7565dc70f9) installed into our production instance. When this tool is run the only output is: /PATH/TO/job_working_directory/025/25029/conda-env/lib/R/bin/exec/R: symbol lookup error: /PATH/TO/job_working_directory/025/25029/conda-env/lib/R/bin /exec/../../lib/../../libreadline.so.6: undefined symbol: PC I've tried manually reinstalling the two dependencies (bioconductor-deseq2(a)1.14.2 and r-getopt(a)1.20.0) by moving the relevant directories from 'tool_dependencies/_conda/envs' and then doing e.g. conda_/bin/conda create -n __r-getopt(a)1.20.0 --override-channels -c iuc -c bioconda -c conda-forge -c defaults -c r r-getopt=1.20.0 to see if this fixes the problem. However while it completes okay for the bioconductor-deseq2 package, for r-getopt I get the following failure: PaddingError: Placeholder of length '80' too short in package r::r-base-3.2.2-0. The package must be rebuilt with conda-build > 2.0. I've tried doing 'conda_/bin/conda clean -pt' and retrying but I get the same error. Any help to fix this is greatly appreciated, many thanks Best wishes Peter Ps conda version is 4.2.13 and Galaxy is release_17.05; I'm trying to rebuild the conda environments manually because I couldn't see anything within the Galaxy UI which would let me do it there. -- Peter Briggs peter.briggs(a)manchester.ac.uk Bioinformatics Core Facility University of Manchester B.1083 Michael Smith Bldg Tel: (0161) 2751482

2 2

Groovy tool for galaxy
by Anshul Tak 22 Aug '17

22 Aug '17

Hi, I have a question regarding galaxy. Can I execute groovy scipts using galaxy? I installed groovy in galaxy docker image and all the dependencies. However, when I try to execute a tool which require groovy engine it says "/export/galaxy-central/database/job_working_directory/000/2/tool_script.sh: line 9: groovy: command not found" So I understood the error that galaxy is not able to find groovy but ideally it should take the groovy engine as it is installed. Can you give me some pointers to solve this issue? -- With Regards, Anshul Tak

4 4

Image in tool XML "help" section only renders when installed from toolshed?
by Peter Briggs 22 Aug '17

22 Aug '17

Dear devs I've been updating the <help> section for a locally developed tool and want to include some images, but I've had some issues trying to see them when testing locally. I've followed the instructions outlined here: https://github.com/galaxy-iuc/standards/blob/master/docs/best_practices/too… (i.e. put the images files into a 'static/images/' subdir of the tool directory and reference them using ".. image:: picture.png") However when I load the tool into a Galaxy using "planemo serve ..." the images fail to render: I just get a line of text with the image filename. The same thing happens when I add the tool manually on our local server (i.e. by adding a <tool file=...> reference to the tool XML in the appropriate conf.xml file). If I upload the same tool files to a toolshed and then install from there, I do see the images rendered correctly. I'm a bit baffled as to why there should be a difference. Is there an option or setting I've missed to turn on the image rendering for non-shed-installed tools? Or have I made some other mistake? Thanks for your help, Best wishes Peter -- Peter Briggs peter.briggs(a)manchester.ac.uk Bioinformatics Core Facility University of Manchester B.1083 Michael Smith Bldg Tel: (0161) 2751482

3 6

User Preferences not rendering view, insetting galaxy UI
by evan clark 21 Aug '17

21 Aug '17

I have been testing our new galaxy instance and came across an odd issue. When a user is logged in and attempts to set their preferences the view does not render and the galaxy UI is inset in the center section. This also occurs when clicking public name. No errors are shown in the log. See image in link https://www.dropbox.com/s/769f3nmot113205/Screen%20Shot%202017-08-21%20at%2…

2 2

Python Communication
by evan clark 21 Aug '17

21 Aug '17

When attempting to start the galaxy communication server with all dependencies installed we receive the error below. (.venv)[galaxy@galaxy galaxy]$ python ./scripts/communication/communication_server.py --port 7070 --host 127.0.0.1 Traceback (most recent call last): File "./scripts/communication/communication_server.py", line 35, in <module> from flask import Flask, request, make_response, current_app, send_file ImportError: No module named flask

3 2

Gateways 2017: Early-bird registration open until Sept. 1; register by Th., Oct. 12
by Katherine Lawrence 21 Aug '17

21 Aug '17

GATEWAYS 2017: The 12th Gateway Computing Environments Conference Monday through Wednesday, October 23–25, 2017 Hosted at the University of Michigan, Ann Arbor https://sciencegateways.org/gateways2017 Science gateways allow science & engineering communities to access shared data, software, computing services, instruments, educational materials, and other resources specific to their disciplines. They are typically a web portal or a suite of desktop applications. Gateway developers and users — regardless of their domain area — have a lot in common but have had few venues for exchanging experiences. The expanded Gateways annual conference is an opportunity for gateway creators and enthusiasts to learn, share, connect, and shape the future of gateways. Early-bird REGISTRATION is now open through Friday, September 1. (Regular registration closes Thursday, October 12.) Book now for the best rates: https://sciencegateways.org/web/gateways2017/attend/register. The conference PROGRAM https://sciencegateways.org/web/gateways2017/program is already brimming with exciting keynotes, tutorials, and sessions (including a CloudLaunch demo http://sched.co/Bl3d) Anyone is welcome to participate in the POSTER SESSION. Submit an abstract for your poster by Friday, Sept. 8: https://sciencegateways.org/web/gateways2017/program/cfp#poster. Do you or a colleague offer resources or services that would be of interest to the science gateways community? Consider reserving a space at the RESOURCE EXPO: https://sciencegateways.org/web/gateways2017/program/resource-expo. Questions? Email help(a)sciencegateways.org

1 0

Galaxy Copying New Files
by evan clark 19 Aug '17

19 Aug '17

We are setting up galaxy with the new files directory option enabled so that our instance will run jobs from our scratch. We are curious to know if galaxy itself copies the final output files directly to our files directory or if this occurs within the scope of a cluster node running a job. The primary issue we have is that our galaxy server cannot mount the scratch but jobs can be submitted to our cluster referencing the scratch directory and run fine.

1 0

Re: [galaxy-dev] Galaxy Conda resolver install Issue
by Matthias Bernt 18 Aug '17

18 Aug '17

Hi Evan, just for completeness Marius is referring to these changes: https://github.com/galaxyproject/galaxy/pull/4049 For testing you could also integrate these changes in your instance, but upgrading to an up-to-date version is a good idea anyways. Best, Matthias > Hello Evan, > > this looks suspiciously like a bug that Matthias Bernt has fixed on the > development branch a while back. > I have backported this to Galaxy release 17.01 and release 17.05. > > If you update your galaxy branch to the latest commit it should work (or > you should receive a more instructive error message). > > Hope that helps, > Marius > > On 17 August 2017 at 18:32, evan clark <eclark28(a)fau.edu> wrote: > >> I just ran across an issue when attempting to load galaxy. I am not sure >> how to fix this issue or what could be causing it. Conda is installed >> properly. >> >> File "/var/web_services/galaxy/lib/galaxy/webapps/galaxy/buildapp.py", >> line 58, in paste_app_factory >> app = galaxy.app.UniverseApplication( global_conf=global_conf, >> **kwargs ) >> File "/var/web_services/galaxy/lib/galaxy/app.py", line 113, in __init__ >> self._configure_toolbox() >> File "/var/web_services/galaxy/lib/galaxy/config.py", line 935, in >> _configure_toolbox >> self.toolbox = tools.ToolBox( tool_configs, self.config.tool_path, >> self ) >> File "/var/web_services/galaxy/lib/galaxy/tools/__init__.py", line 205, >> in __init__ >> app=app, >> File "/var/web_services/galaxy/lib/galaxy/tools/toolbox/base.py", line >> 1044, in __init__ >> self._init_dependency_manager() >> File "/var/web_services/galaxy/lib/galaxy/tools/toolbox/base.py", line >> 1057, in _init_dependency_manager >> self.dependency_manager = build_dependency_manager( self.app.config ) >> File "/var/web_services/galaxy/lib/galaxy/tools/deps/__init__.py", line >> 41, in build_dependency_manager >> dependency_manager = DependencyManager( **dependency_manager_kwds ) >> File "/var/web_services/galaxy/lib/galaxy/tools/deps/__init__.py", line >> 84, in __init__ >> self.dependency_resolvers = self.__build_dependency_resolvers( >> conf_file ) >> File "/var/web_services/galaxy/lib/galaxy/tools/deps/__init__.py", line >> 193, in __build_dependency_resolvers >> return self.__default_dependency_resolvers() >> File "/var/web_services/galaxy/lib/galaxy/tools/deps/__init__.py", line >> 201, in __default_dependency_resolvers >> CondaDependencyResolver(self), >> File "/var/web_services/galaxy/lib/galaxy/tools/deps/resolvers/conda.py", >> line 134, in __init__ >> self.disabled = not galaxy.tools.deps.installable. >> ensure_installed(conda_context, install_conda, self.auto_init) >> File "/var/web_services/galaxy/lib/galaxy/tools/deps/installable.py", >> line 77, in ensure_installed >> return ensure_installed(installable_context, auto_init) >> TypeError: ensure_installed() takes exactly 3 arguments (2 given) >>

1 0

htseq-count/deseq2 conda dependency issues
by Peter Briggs 18 Aug '17

18 Aug '17

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(a)1.3.1, reinstalled bzip2 1.0.2 from 'conda-forge' rather than 'defaults' - deseq2: in __r-getopt(a)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(a)manchester.ac.uk Bioinformatics Core Facility University of Manchester B.1083 Michael Smith Bldg Tel: (0161) 2751482

2 2