Re: [galaxy-dev] planemo/toolshed error, assistance request
Cicada, It appears that the ctat_metagenomics repository does exist, so that's not causing the problem. To simplify debugging this error, could you send me your repository_dependencies.xml file or a link to a gist? - Dave Bouvier http://galaxyproject.org http://usegalaxy.org On 04/13/2018 06:27 AM, Dennis, H. E. Cicada Brokaw wrote: Hello, I am having a problem using planemo to upload a suite of tools into the testtoolshed. The tools at this point are all in the toolshed from using the shed_create and shed_update commands in the suite directory. However, along the way there were some errors in uploading some of the tools that I had to fix. Those are all fixed and all the tools show as up to date, except for the suite, which is returning the following error message, about which I have no idea what to do (and I have tried a lot of different things): The repository_dependencies.xml file contains an invalid tag. Invalid latest installable changeset_revision retrieved for repository ctat_metagenomics owned by trinity_ctat. Does anyone have an idea of what to do to fix this? Thanks, Cicada Dennis ___ 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/ ___ 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/
Re: [galaxy-dev] Conda dependency install problems for DESeq2 tool
Peter, We recently resolved a similar issue on usegalaxy.org, part of which involved rebuilding some of deseq2's dependencies for R version 3.3.1, which is the currently preferred version for bioconda R packages. You should be able to get the right versions and builds of deseq2 and its dependencies with the following command: conda_/bin/conda create --name __bioconductor-deseq2@1.14.1 --override-channels -c iuc -c bioconda -c conda-forge -c defaults -c r bioconductor-deseq2=1.14.1 r-base=3.3.1 This will force installation of R 3.3.1 bioconda builds of r-getopt and other dependencies, which were rebuilt with conda-build > 2.0 a few months ago. - Dave Bouvier http://galaxyproject.org http://usegalaxy.org On 08/23/2017 08:38 AM, Peter Briggs wrote: 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@1.14.2 and r-getopt@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@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. ___ 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/
Re: [galaxy-dev] Fwd: Mismatched Files
Changsu, It sounds very much like multiple distinct galaxy instances are running against the same database, is that the case here? What happens in those situations is that each galaxy instance associates a dataset ID with a specific file, and the contents of the file might be tool output from a different galaxy instance. - Dave Bouvier http://galaxyproject.org http://usegalaxy.org On 07/06/2017 04:25 PM, Changsu Dong wrote: Hello, I am a galaxy user at Hunter College in New York. Recently we have encountered mismatching files throughout various tools under the same history. We are running our RNAseq analysis on the Dockerized containers. I need the BAM files (accepted hits) which produced by Tophats for the MulticovBed to get the read count. Those BAM files should be the binary 'accepted hit' files but instead they are showing random output from other tools(see the image below). This not only happened to BAM files but for most of the tools and most of the datasets. For example, the output for Groomer is not actually from Groomer but rather from the Tophat 'deletion' or an output from Cufflinks. We are not sure if you are familiar with this issue whether it's a container or a Galaxy known issue. It would be great if you could point me to a right direction on how to resolve this issue. Inline image 1 Sincerely, Changsu ___ 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/ ___ 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/
Re: [galaxy-dev] Testtoolshed status
Steve, Thank you for reporting this issue, we've determined a potential cause and are working to correct it. - Dave Bouvier http://galaxyproject.org http://usegalaxy.org On 09/02/2016 03:29 AM, Steve Cassidy wrote: I’m getting a 500 response from the testtoolshed when I try to upload a tool via planemo: ➜ alveo-galaxy-tools git:(master) ✗ planemo shed_update --shed_target testtoolshed apitools cd '/Users/steve/projects/alveo-galaxy-tools/apitools' && git rev-parse HEAD cd '/Users/steve/projects/alveo-galaxy-tools/apitools' && git diff --quiet Could not update alveoimport Unexpected HTTP status code: 500: Internal Server Error Internal Server Error The server has either erred or is incapable of performing the requested operation. WSGI Server Repository metadata updated successfully for repository alveoimport. Failed to update a repository. In addition, I just got a “Tool Shed could not be reached” message via the web interface, so i’m wondering if something is up. Thanks, Steve — Department of Computing, Macquarie University http://web.science.mq.edu.au/~cassidy ___ 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/mailinglists/ ___ 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/mailinglists/
Re: [galaxy-dev] local toolshed not working
And thank you for making us aware of this issue, we've updated the
sample configs to include that option and its default value.
-
Dave Bouvier
http://galaxyproject.org
http://usegalaxy.org
On 04/28/2016 11:02 AM, Vincent Cahais wrote:
It's working, Thanks Dave.
Le 28/04/2016 16:40, Dave Bouvier a écrit :
Vincent,
Thanks, that looks like either a different bug, or the fix hasn't made
it to the master branch yet. One possible workaround you could try,
while I confirm which is the case, is to set the following option in
your tool_shed.ini somewhere after [app:main]
use_printdebug = False
-
Dave Bouvier
http://galaxyproject.org
http://usegalaxy.org
On 04/28/2016 09:54 AM, Vincent Cahais wrote:
>git show
commit b79474083b08860923f7f28fc1e7442b53f925db
Merge: 7c94ac8 5aefe1b
Author: Martin Cech <cech.mar...@gmail.com>
Date: Wed Apr 20 15:22:20 2016 -0400
Merge pull request #2206 from dannon/master
Sanity check of master update.
Le 28/04/2016 15:40, Dave Bouvier a écrit :
Vincent,
Could you provide the output of `git show` in your Galaxy root? This
error message looks like a bug that was fixed in
0d616af28a175bae8e193f429a18f97cd8b274ec.
-
Dave Bouvier
http://galaxyproject.org
http://usegalaxy.org
On 04/28/2016 09:26 AM, Vincent Cahais wrote:
Hi everyone,
I'm trying to set up a new local toolshed with a fresh install of
galaxy.
I can run the server, create repositories and upload files. But when I
try to install a tool in galaxy it fail with a server error.
In the tool_shed_webapp.log I have the following error :
Exception happened during processing of request from ('**.**.**.**',
41026)
Traceback (most recent call last):
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/httpserver.py",
line 1085, in process_request_in_thread
self.finish_request(request, client_address)
File "/usr/lib/python2.7/SocketServer.py", line 331, in
finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python2.7/SocketServer.py", line 652, in __init__
self.handle()
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/httpserver.py",
line 459, in handle
BaseHTTPRequestHandler.handle(self)
File "/usr/lib/python2.7/BaseHTTPServer.py", line 340, in handle
self.handle_one_request()
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/httpserver.py",
line 454, in handle_one_request
self.wsgi_execute()
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/httpserver.py",
line 304, in wsgi_execute
self.wsgi_start_response)
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/urlmap.py",
line 216, in __call__
return app(environ, start_response)
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/debug/prints.py",
line 107, in __call__
environ, self.app)
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/wsgilib.py",
line 547, in intercept_output
if data[0] is None:
IndexError: list index out of range
Removing PID file tool_shed_webapp.pid
Cheers,
___
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/mailinglists/
___
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/mailinglists/
Re: [galaxy-dev] local toolshed not working
Vincent,
Thanks, that looks like either a different bug, or the fix hasn't made
it to the master branch yet. One possible workaround you could try,
while I confirm which is the case, is to set the following option in
your tool_shed.ini somewhere after [app:main]
use_printdebug = False
-
Dave Bouvier
http://galaxyproject.org
http://usegalaxy.org
On 04/28/2016 09:54 AM, Vincent Cahais wrote:
>git show
commit b79474083b08860923f7f28fc1e7442b53f925db
Merge: 7c94ac8 5aefe1b
Author: Martin Cech <cech.mar...@gmail.com>
Date: Wed Apr 20 15:22:20 2016 -0400
Merge pull request #2206 from dannon/master
Sanity check of master update.
Le 28/04/2016 15:40, Dave Bouvier a écrit :
Vincent,
Could you provide the output of `git show` in your Galaxy root? This
error message looks like a bug that was fixed in
0d616af28a175bae8e193f429a18f97cd8b274ec.
-
Dave Bouvier
http://galaxyproject.org
http://usegalaxy.org
On 04/28/2016 09:26 AM, Vincent Cahais wrote:
Hi everyone,
I'm trying to set up a new local toolshed with a fresh install of
galaxy.
I can run the server, create repositories and upload files. But when I
try to install a tool in galaxy it fail with a server error.
In the tool_shed_webapp.log I have the following error :
Exception happened during processing of request from ('**.**.**.**',
41026)
Traceback (most recent call last):
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/httpserver.py",
line 1085, in process_request_in_thread
self.finish_request(request, client_address)
File "/usr/lib/python2.7/SocketServer.py", line 331, in
finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python2.7/SocketServer.py", line 652, in __init__
self.handle()
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/httpserver.py",
line 459, in handle
BaseHTTPRequestHandler.handle(self)
File "/usr/lib/python2.7/BaseHTTPServer.py", line 340, in handle
self.handle_one_request()
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/httpserver.py",
line 454, in handle_one_request
self.wsgi_execute()
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/httpserver.py",
line 304, in wsgi_execute
self.wsgi_start_response)
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/urlmap.py",
line 216, in __call__
return app(environ, start_response)
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/debug/prints.py",
line 107, in __call__
environ, self.app)
File
"/home/galaxy/galaxy/.venv/local/lib/python2.7/site-packages/paste/wsgilib.py",
line 547, in intercept_output
if data[0] is None:
IndexError: list index out of range
Removing PID file tool_shed_webapp.pid
Cheers,
___
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/mailinglists/
___
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/mailinglists/
Re: [galaxy-dev] installable revisions for repository suite definitions
Aaron, Repository suite definitions are designed to only allow the latest revision to be installable. My recommendation in this case would be to define two separate suites tagged in some descriptive way, so the individual use cases would have their appropriate suites. - Dave Bouvier http://galaxyproject.org http://usegalaxy.org On 10/29/2015 02:23 PM, Aaron Petkau wrote: Hello, I'm running into some issues with maintaining multiple installable revisions for a repository suite and I'm not sure if there's something I've missed. I have a local toolshed where I'm maintaining my tools, and I have a repository suite definition, defining a number of dependencies. So, I have: suite_X (mercurial revision 0): Dependency A Dependency B I updated "suite_X" and changed the dependencies: suite_X (mercurial revision 1): Dependency A Dependency B Dependency C I would like to have both mercurial revision 0 and 1 installable in Galaxy, but only revision 1 (the latest) is showing up as installable. I found documentation at https://wiki.galaxyproject.org/RepositoryRevisions but this seems to only cover a repository containing a single tool, not a suite of tools. Is there something I'm doing wrong or some setting I have to change here? My toolshed is running with Galaxy tag "v15.07". Thanks, Aaron ___ 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/mailinglists/ ___ 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/mailinglists/
Re: [galaxy-dev] Bismark installation dependencies error
Yes, this is definitely related to the issue I fixed part of, and (I think) Nicola fixed the rest of. - Dave Bouvier http://galaxyproject.org http://usegalaxy.org On 10/28/2015 11:46 AM, Nicola Soranzo wrote: Hi Jose, can you check that your release_15.07 is updated and contains git commit 197c7b21b209a7b6fbdb9a8a11c232a2b88523fc ( https://github.com/galaxyproject/galaxy/commit/197c7b21b209a7b6fbdb9a8a11c232a2b88523fc )? Cheers, Nicola On 28/10/15 14:53, Jose Juan Almagro Armenteros wrote: Hello Björn, I am using Galaxy 15.07, so everything should be updated. Regards, Jose 2015-10-28 15:43 GMT+01:00 Björn Grüning <bjoern.gruen...@gmail.com <mailto:bjoern.gruen...@gmail.com>>: Hi Jose, which version of Galaxy are you using? @Dave can this be one of the old un-compressing changes? Cheers, Bjoern Am 28.10.2015 um 15:31 schrieb Jose Juan Almagro Armenteros: > Hello, > > I have tried to install the last version of Bismark from the toolshed and I > got an error while installing. Basically it can't install bowtie and > bowtie2 because the folder name > is written twice in the download directory. Here is the error: > > File "/steno-internal/projects/galaxy/galaxy-dist/lib/tool_shed/galaxy_install/install_manager.py", > line 142, in install_and_build_package_via_fabric > tool_dependency = self.install_and_build_package( > tool_shed_repository, tool_dependency, actions_dict ) > File "/steno-internal/projects/galaxy/galaxy-dist/lib/tool_shed/galaxy_install/install_manager.py", > line 100, in install_and_build_package > initial_download=True ) > File "/steno-internal/projects/galaxy/galaxy-dist/lib/tool_shed/galaxy_install/tool_dependencies/recipe/recipe_manager.py", > line 32, in execute_step > initial_download=initial_download ) > File "/steno-internal/projects/galaxy/galaxy-dist/lib/tool_shed/galaxy_install/tool_dependencies/recipe/step_handler.py", > line 685, in execute_step > dir = self.url_download( work_dir, downloaded_filename, url, > extract=True, checksums=checksums ) > File "/steno-internal/projects/galaxy/galaxy-dist/lib/tool_shed/galaxy_install/tool_dependencies/recipe/step_handler.py", > line 223, in url_download > extraction_path = archive.extract( install_dir ) > File "/steno-internal/projects/galaxy/galaxy-dist/lib/tool_shed/galaxy_install/tool_dependencies/recipe/step_handler.py", > line 89, in extract > os.chmod( absolute_filepath, unix_permissions ) > > [Errno 2] No such file or directory: > './database/tmp/tmp-toolshed-mtdM4XBx_/bowtie-0.12.8/bowtie-0.12.8/' > > As you see "bowtie-0.12.8" is twice in the path and when I check the > directory, the last "bowtie-0.12.8" folder doesn't exists. > > Do you know what could go wrong or an alternative way of specifying the > correct path? > > > Best regards, > > Jose > > > > ___ > 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/mailinglists/ > ___ 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/mailinglists/ ___ 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/mailinglists/ ___ 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/mailinglists/
Re: [galaxy-dev] Samtools 1.1 Dependency
Hans, An actions tag with specified architecture and operating system will only be processed if both attributes match, so that one would not be executed on your OSX system. As regards the error in the sed command, I've created a pull request for the IUC's samtools 1.1 (and others with the same error) tool dependency definition, once that is accepted I'll be able to update the toolshed with the working code. Thank you for alerting me to that error. - Dave Bouvier http://galaxyproject.org http://usegalaxy.org On 07/09/2015 05:22 PM, Hans Vasquez-Gross wrote: Hi All, I have a galaxy installation on an OSX system that has been running fine with our custom tools. However, now we want to start using for some simple BAC mapping. When I go to the main toolshed to install bwa, it lists the following dependencies. Repository *package_bwa_0_7_10_039ea20639* revision *5b9aca1e1c07* owned by *devteam* Repository *package_samtools_1_1* revision *43f2fbec5d52* owned by *iuc* However, when running through this process, it fails at the package_samtools_1_1 stage with an Error. Looking at the INSTALLATION.LOG i see the following. # sed -i 's/-lcurses/-lncurses/' Makefile STDOUT # # sed -i 's/-lcurses/-lncurses/' Makefile STDERR sed: 1: Makefile: invalid command code M # However, looking at the tool_dependencies.xml for this particular package, I see the following. I've highlighted in yellow a key configuration. ?xml version=1.0? tool_dependency package name=samtools version=1.1 install version=1.0 actions_group actions architecture=x86_64 os=linux action type=download_by_urlhttp://depot.galaxyproject.org/package/linux/x86_64/samtools/samtools-1.1-Linux-x86_64.tgz/action action type=move_directory_files source_directory./source_directory destination_directory$INSTALL_DIR/destination_directory /action /actions actions package name=ncurses version=5.9 repository changeset_revision=5e1760c773ba name=package_ncurses_5_9 owner=iuc prior_installation_required=True toolshed=https://toolshed.g2.bx.psu.edu; / /package package name=zlib version=1.2.8 repository changeset_revision=63a4a902cda2 name=package_zlib_1_2_8 owner=iuc prior_installation_required=True toolshed=https://toolshed.g2.bx.psu.edu; / /package action type=download_by_urlhttp://downloads.sourceforge.net/project/samtools/samtools/1.1/samtools-1.1.tar.bz2/action action type=set_environment_for_install repository changeset_revision=5e1760c773ba name=package_ncurses_5_9 owner=iuc toolshed=https://toolshed.g2.bx.psu.edu; package name=ncurses version=5.9 / /repository repository changeset_revision=63a4a902cda2 name=package_zlib_1_2_8 owner=iuc toolshed=https://toolshed.g2.bx.psu.edu; package name=zlib version=1.2.8 / /repository /action action type=shell_commandsed -i 's/-lcurses/-lncurses/' Makefile/action action type=shell_commandsed -i -e s|CFLAGS=\s*-g\s*-Wall\s*-O2\s*|CFLAGS= -g -Wall -O2 -I$NCURSES_INCLUDE_PATH/ncurses/ -I$NCURSES_INCLUDE_PATH -L$NCURSES_LIB_PATH|g Makefile /action action type=shell_commandmake/action action type=move_file sourcesamtools/source destination$INSTALL_DIR/bin/destination /action /actions action type=set_environment environment_variable action=prepend_to name=PATH$INSTALL_DIR/bin/environment_variable environment_variable action=set_to name=SAMTOOLS_ROOT_PATH$INSTALL_DIR/environment_variable /action /actions_group /install So, to me, it sounds like this is trying to compile/install a distribution meant for linux, but I'm on OSX. I was able to successfully install samtools 1.2 with no errors. Is there anyway to update, or modify the code for the BWA installation recipe to use as a dependency samtools 1.2 rather then 1.1? Or does anyone have any suggestions on how to get samtools 1.1 to work? I tried making a bin/ directory and moving a precompiled samtools binary for 1.1 in the directory. But galaxy didn't seem to recognize that the dependency was satisfied manually. Any advice would be greatly appreciated. Thank you, -Hans
Re: [galaxy-dev] unable to install from toolshed. bounced e-mail
Alexey, In order to help track down the issue, I'd like to gather a bit more information on your setup: Which release of Galaxy are you running locally? Which toolshed are you attempting to install from? Additionally, there may be some more informative messages in the paster.log in the root of your galaxy installation. - Dave Bouvier http://galaxyproject.org http://usegalaxy.org On 06/01/2015 10:20 AM, Leontovich, Alexey A., Ph.D. wrote: Hello galaxy team, This e-mail was bounced, so I am sending it again. When I try to install tools (bismark, bisulfighter, bscall) to my local instance of Galaxy, I get an error message: Internal Server Error *Galaxy was unable to successfully complete your request* An error occurred. This may be an intermittent problem due to load or other unpredictable factors, reloading the page may address the problem. *The error has been logged to our team.* The first time I tried to install was Friday, May 31, 2015. I have installed many tools before, about 6 months ago and it worked just fine. Could you please help with current installation problems? Thank you. Alexey Leontovich *Alexey Leontovich, Ph.D.*| Assistant Professor of Medical Informatics | Biomedical Statistics and Informatics |Phone: 507-284-4850 | Fax: 507-538-0850 | leontovich.ale...@mayo.edu *Mayo Clinic* | 200 First Street SW | Rochester, MN 55905 | mayoclinic.org http://www.mayoclinic.org ___ 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/mailinglists/ ___ 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/mailinglists/
Re: [galaxy-dev] Tests not being run on toolsheds?
Gentlemen, The issue with the nightly testing was due to a stalled test run blocking subsequent tests. I've cleared out that blockage and a manual test run appears to have completed successfully, as should future automated test runs. As always, feel free to let us know if you encounter any additional inexplicable behavior. --Dave B. On 03/18/2015 07:00 AM, Peter Cock wrote: On Wed, Mar 18, 2015 at 10:13 AM, Peter Briggs peter.bri...@manchester.ac.uk wrote: Hello Peter C. Thanks for your comments and advice Ironically after I sent that email the tests for the next tool I looked at in the toolshed had been run in the past couple of days. That's good. I can also confirm that the Test Tool Shed example I gave was tested overnight, although it looks like a novel failure: https://testtoolshed.g2.bx.psu.edu/view/peterjc/sample_seqs I'm interested because I've got a couple of tools that seem to work okay when I run the tests locally, but are reported as failing on the toolshed, and I wanted to see if I'd addressed the issue for one of them by updating the tool dependencies. I suggest asking on this mailing list, posting the shareable Tool Shed URL and a copy of the error message. Hopefully it will be a simple issue (forgetting a test file is my most common mistake), or it may be that another tool author has seen the same error (which can happen due to problems in Galaxy itself). (As an aside I'd also assumed that passing tests is one of the conditions for the tool to be marked as verified, but maybe that's not the case?) I think there is still a human involved, but passing tests is expected for a verified tool. However as you say, more testing locally seems to be a good way to go - thanks for your suggestions. I looked at planemo briefly a while ago and it looked good. The other issue I've had with testing is actually testing tool installation (i.e. tool_dependencies.xml) - I recall that planemo didn't deal with that side of things, so I had to set up the environment for the tests manually. There is some work on tool_dependencies.xml ongoing within planemo, John Chilton would be the person to ask (CC'd directly). Thanks again for your advice and the links, I will investigate trying to set up a local solution (including some CI testing!). This is something where using planemo ought to be very useful - for now I still do my local testing with a test Galaxy instance via: $ ./run_tests.sh -id my_tool_id Peter ___ 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/mailinglists/ ___ 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/mailinglists/
