I have a question regarding the param tag. I would like to pass on the
user email to a external python script. I tried to use it like this:
<param name="email" type="hidden" value=$__user_email__ />
<param name="experiment" type="select" label="Experiment" help="select
This does not work. Ideally I would like to have something like this:
Has someone done this before?
Center for Information Sciences and Databases (C-ISD)
Department of Biosystems Science & Engineering (D-BSSE)
ETH Zurich, Maulbeerstrasse (1078, 1.02), CH-4058 Basel, +41 61 387 3132
In my local Galaxy,when I want to reset my Login password,some error occurre :"Mail is not configured for this Galaxy instance. Please contact an administrator. "Could anyone tell me some imformation about how to configure the mail for my Galaxy instance?
Thank you very much.
I have migrated Emboss tool from dist to tool-shed using the migration script and later updated it's revision. The tool was installed along with it's dependencies, but it's failing to find them during job run. It's logging following 'Failed to resolve dependency on 'emboss', ignoring' warning message in the log file. It seems like build_dependency_shell_commands method in '/lib/galaxy/tools/__init__.py' is unable to get installed_tool_dependencies. I am not sure why this would fail and how to resolve it. I have tried resetting tool metadata several times, but that didn't help. Appreciate any help on resolving this error. I am using Galaxy release_2013.06.03 revision.
Mercurial has recently started throwing errors:
galaxy@hitmsbhpc1:~/galaxy-dist> hg incoming
abort: error: _ssl.c:517: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
It has previously worked with issues has anyone seen this before?
I don't think anything has changed that would have caused this problem but googling error has proved to be unhelpful so far.
I can't seem to find any information on the Galaxy wiki website about the
procedure for updating a local Galaxy instance to the newest release. Is
there a tutorial for this somewhere?
This question is best directed to the galaxy-dev mailing list because it concerns developing around Galaxy, so I've moved it there.
> However, if I understand it right, the idea of the XML tool config is to provide a description of the galaxy graphical user interface rather then a general description of the actual tool's interface.
No, the XML config describes a tool in abstract/essence: inputs, parameters, and outputs. Rendering of a tool can be done any number of ways.
> - param tag: I havent really understood how you define a parameter to be mandatory or optional. I see when it is the child of the repeat element that there is (maybe) a minimum defined. But when this is not the case, how can I conclude that the parameter is optional vs. mandatory ?
Parameters have an 'optional' attribute. See here for details on tool and parameter config in general:
> - param tag's help attribute: can I assume any format, or is it simply the output of the tools help command ?
Format is simply text.
> - when do you update the tools and in turn the XML configs. (e.g. the gatk stuff is kind of outdated: 1.4 vs 2.6 )
The depends on a number of factors, including tool stability, dependencies, usage level, and ease of updating.
The tool shed makes it easy to follow tool updates for a local instance:
You might be able to reuse some of that code in a stand-alone script.
Hi Greg et al,
For the NCBI BLAST+ wrappers, Nicola has suggested we split
out the binaries themselves into a separate Tool Shed package,
e.g. package_blast_plus_2_2_26 and similar for the later releases.
I think this is a good idea.
I'd like to check if there are any complications foreseeable from
the fact that the NCBI BLAST+ wrappers were migrated out of
the Galaxy core and therefore have migration scripts we need
Potentially this could be held under the shared IUC account
as planned for other commonly used packages? Or would
the migration issues require it to also live under devteam?
Also, we may wish to add a dependency on BOOST, e.g.
once this is on the main Tool Shed.
The python scripts to clean histories, datasets, users etc.. are fine...
However, the records are not really removed from the postgresql database
and as a result, this one gets bigger and bigger with unused records. Ours
is above 1 To after 2 years of production.
Is there a safe way to clean the database from unused records and their
dependencies to reduce it size, without being a postgresql guru ?
Drosophila Genetics and Epigenetics
Laboratoire de Biolologie du Développement
9, Quai St Bernard, Boîte courrier 24
75252 Paris Cedex 05
Tel +33 1 44 27 34 39
Fax +33 1 44 27 34 45
Mobile +33 6 68 60 51 50
There may be permissions problems if just for these two links, but I am
not an expert on this. Moving post over to the galaxy-dev list, which
will give it better exposure to the development team and community.
You'll want to post here directly with any future local install
On 8/26/13 10:49 AM, Kucukural, Alper wrote:
> I have a problem in galaxy to get host/domain name in two different pages.
> First one is in the tool installation from toolshed, I got the error below,
> Not Found
> The requested URL /admin_toolshed/prepare_for_install was not found on this server.
> The second one is in the saved histories. When I click the buttons of the saved histories. I got the similar error like below.
> Not Found
> The requested URL /history/list was not found on this server.
> I haven't seen these any other pages yet.
> My installation is working on LDAP authentication with Proxy. So, I could not find a place to set the domain or host name in these two places that they can actually find the requested URLs.
> In the paster.log file. I don't get any error when I install a tool or go to another history. It doesn't report any error.
> Thanks for your help,
> Alper Kucukural
> The Galaxy User list should be used for the discussion of
> Galaxy analysis and other features on the public server
> at usegalaxy.org. Please keep all replies on the list by
> using "reply all" in your mail client. For discussion of
> local Galaxy instances and the Galaxy source code, please
> use the Galaxy Development list:
> To manage your subscriptions to this and other Galaxy lists,
> please use the interface at:
> To search Galaxy mailing lists use the unified search at: