Thanks, works like a charm.
Could it be that this is not documented? Where can I find those options?
(perhaps in the code?) Then I can perhaps add it to the wiki.
Kind regards,
Joachim Jacob, PhD
Rijvisschestraat 120, 9052 Zwijnaarde
Tel: +32 9 244.66.34
Bioinformatics Training and
Hi all,
The last few days I have been experimenting with a local Galaxy installation.
Via the tool shed, emboss and emboss_datatypes were installed. Next, a custom
tool was added for which a rich sequence is needed as input.
I was hoping to achieve this as such:
param name=input type=data
Hi Batsal,
I have the exact same problem, on 2 different instances of Galaxy, on two
different servers. I can replicate this problem on a cloned instance with no
modification, and one using multiple galaxay server, nginx proxy and
postgresql, both instances being on different machines (one on
From: galaxy-dev-boun...@lists.bx.psu.edu
[mailto:galaxy-dev-boun...@lists.bx.psu.edu] On Behalf Of Marc Logghe
Sent: Friday, August 03, 2012 9:22 AM
To: galaxy-dev@lists.bx.psu.edu
Subject: [galaxy-dev] genbank data type
Hi all,
The last few days I have been experimenting with a local Galaxy
It's implied, although not clearly stated in the wiki. The User component is
the same code for both applications, so User component features that are
available in Galaxy are generally available in the tool shed as well. I'm soon
going to be making some major changes to the tool shed wiki, so
Hello Nikhil,
On Aug 2, 2012, at 9:32 PM, Nikhil Joshi wrote:
Hi all,
We just upgraded our local galaxy to the latest version and now I am
trying to get automatic tool installation to work properly. I changed
the universe_wsgi.ini file to enable the toolshed xml file,
Regarding this, do
Hi David and Bastal,
We have been able to reproduce this behavior under certain conditions and are
working on a fix. Until this fix is available, you can disable ajax uploads,
which should allow the upload tool to work properly.
In tools/data_source/upload.xml change
param name=file_data
Hi again,
Emboss_datatypes is installad via tool shed. The 'View datatypes registry' in
the Adminstration page, shows all registered data types, including the emboss
ones, like e.g. genbank.
However, the 'Upload File' tool does not show genbank in the 'File Format'
dropdown. How can one
Hi Dan,
It works like a charm! Thanks a lot! I have been looking for a workaround for
this issue for almost a month!
Once again, thanks you so much!
David
Subject: Re: [galaxy-dev] Upload issue in local installation
From: d...@bx.psu.edu
Date: Fri, 3 Aug 2012 09:24:43 -0400
CC:
Hi Marc,
please have a look at the datatypes_conf.xml file in your galaxy
directory.
There should be something like that:
datatype extension=wsf type=galaxy.datatypes.wsf:SnpFile
display_in_upload=true/
Try to add 'display_in_upload=true' to the genbank datatype.
The 'good' solution would be
Dear Galaxy community,
I have noticed on forums that some users are experiencing this problem too, but
no clues on how to fix it. When I set debug = false in universe.wsgi.ini, I get
a server error in the history frame (history works perfectly when debug =
true). Trying to create a new
Hi Björn,
I think the issue is that the genbank datatype is coming in via the tool shed
and is not taken into account by the upload tool. The genbank datatype is
defined in
shed_tools/toolshed.g2.bx.psu.edu/repos/devteam/emboss_datatypes/a89163f31369/emboss_datatypes/datatypes_conf.xml
I have
Hi Marc,
You'll need to add the display_in_upload attribute to your local version of the
datatypes_conf.xml file installed with your emboss_datatypes repository from
the tool shed.
This may result in a merge at some point if the contents of the
datatypes_conf.xml file changes in the
Hi Greg,
You'll need to add the display_in_upload attribute to your local version of
the datatypes_conf.xml file installed with your emboss_datatypes repository
from the tool shed.
I'am afraid this does not work. At least not in my hands. Like I indicated
before, it seems like the upload
Hi Greg,
So I looked at the the URL from the log file and it was trying to
write to a tmp directory owned by root, so that was a problem. I
traced the problem to a python function (make_tmp_directory) where it
was using the environment variable TMPDIR, which was not defined.
So in our launch
To get the repositories out of the limbo state, you'll have to get into your
database and run the following sql command. Doing this will allow you to
install those repositories that were in limbo. After they are installed, you
can uninstall them if you want to. The case on the Strings is
16 matches
Mail list logo