[galaxy-dev] javascript
Hi all, I just now tried visiting Galaxy main with my browser's javascript turned off. Formerly the left Tools panel would appear with all of the sections expanded, however now it is empty except for Workflows. Also, some of the top menu bar items work without scripting, but others (including Help and User) do not. Ideally Galaxy would be usable without scripting, but if that is not feasible then I suggest checking whether javascript is available (as many other sites do) and displaying a prominent explanatory message if it is not. This would be much more helpful than an inexplicably near-empty tool panel and broken menus. In case it is relevant, I'm running Firefox 3.6.23 with the NoScript extension (2.4.7), on CentOS Linux with kernel 2.6.18-238.12.1.el5. Thanks, -Cathy ___ 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: http://lists.bx.psu.edu/
[galaxy-dev] Job doesn't runnig
Dear Galaxy Dev Team- I try to run a job with Tophat for Illumina (version 1.5.0) but in my history job always stay at Job is waiting to run. I use the following parameters : RNA-Seq FASTQ file: FASTQ Groomer on upload dataset Reference Genome : build-in index : Chicken (Gallus gallus): galGal3 Full Mate-paired : Single-end TopHat settings : Defaults How should i do to make this job running ? Thanks in advance. Amandin Talbot ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] javascript
I just now tried visiting Galaxy main with my browser's javascript turned off. Formerly the left Tools panel would appear with all of the sections expanded, however now it is empty except for Workflows. Also, some of the top menu bar items work without scripting, but others (including Help and User) do not. This is expected behavior. In order to create a more dynamic, flexible, and interactive UI, we're increasingly using JavaScript in Galaxy. We believe that the JavaScript requirement is a reasonable tradeoff for what can be done using client-side scripting. Ideally Galaxy would be usable without scripting, but if that is not feasible then I suggest checking whether javascript is available (as many other sites do) and displaying a prominent explanatory message if it is not. This would be much more helpful than an inexplicably near-empty tool panel and broken menus. Good idea; we plan to implement this soon. Best, J. ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] pbs_python issues
I was successful in getting the bps_python egg to load finally. However,
there is an issue that remains. When I submit a job it is sent to the
local runner and not to pbs. Where should I start looking to change this
work?
Thanks,
Iry
On 7/10/12 12:00 PM, galaxy-dev-requ...@lists.bx.psu.edu
galaxy-dev-requ...@lists.bx.psu.edu wrote:
Message: 3
Date: Mon, 9 Jul 2012 17:24:25 +
From: Iry Witham iry.wit...@jax.org
To: Dorset, Daniel C daniel.dor...@vanderbilt.edu
Cc: galaxy-dev@lists.bx.psu.edu galaxy-dev@lists.bx.psu.edu
Subject: Re: [galaxy-dev] galaxy-dev Digest, Vol 73, Issue 10
Message-ID: cc207dde.8f49%iry.wit...@jax.org
Content-Type: text/plain; charset=us-ascii
Hi Daniel,
I did use -e previously. The ?e was a typo in my post. I ran it again
and it tries, but fails to generate the file(s) as shown:
:galaxy@jaxgalaxydev01:/hpcdata/galaxy-dev/galaxy-setup/galaxy-dist
LIBTORQUE_DIR=/usr/local/lib/ python scripts/scramble.py -e pbs_python
fetch_one(): Trying to fetch:
http://eggs.g2.bx.psu.edu/pbs_python/pbs_python-4.1.0.tar.gz
fetch_one(): Fetched to:
/hpcdata/galaxy-dev/galaxy-setup/galaxy-dist/scripts/scramble/archives/pbs
_
python-4.1.0.tar.gz
unpack_source(): Unpacked to:
/hpcdata/galaxy-dev/galaxy-setup/galaxy-dist/scripts/scramble/build/py2.6-
l
inux-x86_64-ucs4/pbs_python
copy_build_script(): Using build script
/hpcdata/galaxy-dev/galaxy-setup/galaxy-dist/scripts/scramble/scripts/pbs_
p
ython.py
run_scramble_script(): Beginning build
run_scramble_script(): Executing in
/hpcdata/galaxy-dev/galaxy-setup/galaxy-dist/scripts/scramble/build/py2.6-
l
inux-x86_64-ucs4/pbs_python:
/usr/bin/python scramble.py
--
-
This script requires setuptools version 0.6c11 to run (even to display
help). I will attempt to download it for you (from
http://pypi.python.org/packages/2.6/s/setuptools/), but
you may need to enable firewall access for this script first.
I will start the download in 8 seconds.
(Note: if this machine does not have network access, please obtain the
file
http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.e
g
g
and place it in this directory before rerunning this script.)
--
-
Downloading
http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.e
g
g
checking for pbs-config... /usr/local/lib//../bin/pbs-config
Found torque version: 2.5.8
checking for python... /usr/bin/python
checking for python version... 2.6
checking for python platform... linux2
checking for python script directory...
${prefix}/lib64/python2.6/site-packages
checking for python extension module directory...
${exec_prefix}/lib64/python2.6/site-packages
configure: creating ./config.status
config.status: creating Makefile
config.status: creating setup.py
scramble(): Patching setup.py
running egg_info
creating src/pbs_python.egg-info
writing src/pbs_python.egg-info/PKG-INFO
writing top-level names to src/pbs_python.egg-info/top_level.txt
writing dependency_links to src/pbs_python.egg-info/dependency_links.txt
writing manifest file 'src/pbs_python.egg-info/SOURCES.txt'
reading manifest file 'src/pbs_python.egg-info/SOURCES.txt'
writing manifest file 'src/pbs_python.egg-info/SOURCES.txt'
running bdist_egg
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
creating build
creating build/lib.linux-x86_64-2.6
copying src/pbs.py - build/lib.linux-x86_64-2.6
copying src/PBSQuery.py - build/lib.linux-x86_64-2.6
running build_ext
building '_pbs' extension
creating build/temp.linux-x86_64-2.6
creating build/temp.linux-x86_64-2.6/src
gcc -pthread -fno-strict-aliasing -DNDEBUG -fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -g -fwrapv -fPIC -DTORQUE_2_4
-I/usr/include/python2.6 -c src/pbs_wrap.c -o
build/temp.linux-x86_64-2.6/src/pbs_wrap.o
gcc -pthread -shared build/temp.linux-x86_64-2.6/src/pbs_wrap.o
-L/usr/local/lib -L/usr/lib64 -ltorque -lpython2.6 -o
build/lib.linux-x86_64-2.6/_pbs.so
creating build/bdist.linux-x86_64
creating build/bdist.linux-x86_64/egg
copying build/lib.linux-x86_64-2.6/PBSQuery.py -
build/bdist.linux-x86_64/egg
copying build/lib.linux-x86_64-2.6/pbs.py - build/bdist.linux-x86_64/egg
copying build/lib.linux-x86_64-2.6/_pbs.so - build/bdist.linux-x86_64/egg
byte-compiling build/bdist.linux-x86_64/egg/PBSQuery.py to PBSQuery.pyc
byte-compiling build/bdist.linux-x86_64/egg/pbs.py to pbs.pyc
creating stub loader for _pbs.so
byte-compiling build/bdist.linux-x86_64/egg/_pbs.py to _pbs.pyc
creating build/bdist.linux-x86_64/egg/EGG-INFO
copying src/pbs_python.egg-info/PKG-INFO -
build/bdist.linux-x86_64/egg/EGG-INFO
copying src/pbs_python.egg-info/SOURCES.txt -
build/bdist.linux-x86_64/egg/EGG-INFO
copying src/pbs_python.egg-info/dependency_links.txt -
build/bdist.linux-x86_64/egg/EGG-INFO
copying
Re: [galaxy-dev] Sample tracking data transfer hangs in queue forever
Hello Luobin,
I'm on my way to ISMB for a week, and then will be at the Galaxy Community
Conference the following week, so I won't have time to help you track this
problem down until some time in August unless you will be at either of these 2
conferences. Sorry for the inconvenience on this, but my schedule over the
next few weeks is very hectic. If you'll be at either ISMB or the GCC, we can
certainly get together to look at this.
Greg Von Kuster
On Jul 9, 2012, at 1:24 PM, Luobin Yang wrote:
Hi, Greg,
I've still got issues after I downloaded the latest version from the dist
repository. So after I selected the datasets that I would like to transfer
from the sequencer and click the Transfer button, Galaxy generates an error
message : Invalid sample id (None)... I tried to delete this dataset using
the manage datasets menu, and Galaxy generates the same error message:
Invalid sample id (None). It seems galaxy system generates the sample id
automatically (the first one is sample_1), not sure why this happens...
Luobin
On Fri, Mar 30, 2012 at 8:30 AM, Greg Von Kuster g...@bx.psu.edu wrote:
Hello Emily,
This issue should be resolved in change set 6924:12b14f3e78e9, which is
currently only available from our central repository. It will not be
available in the dist repository fro some time, so you'll have to pull it
from Galaxy central (https://bitbucket.org/galaxy/galaxy-central) if you want
it now.
Thanks very much for reporting this problem, and we apologize for the
inconvenience it caused.
Greg Von Kuster
On Mar 29, 2012, at 1:49 PM, TerAvest, Emily wrote:
Hi Leandro,
I am also experiencing the same problem with the latest version of galaxy.
I just attempted to connect our sequencer for the first time yesterday. I
do not have an older version of galaxy to test and compare to see if it
works in earlier versions. I am able to transfer data from the sequence to
the import directory, however it is not moved to the data library. My
data_transfer.log also has the same error.
The server could not comply with the request since it is either malformed
or otherwise incorrect.
Does anyone have a solution for this?
Thanks
Emily
--
Message: 17
Date: Wed, 28 Mar 2012 13:15:47 +0200
From: Leandro Hermida soft...@leandrohermida.com
To: Luobin Yang yangl...@isu.edu
Cc: Galaxy Dev galaxy-...@bx.psu.edu
Subject: Re: [galaxy-dev] Sample tracking data transfer hangs in
queue forever
Message-ID:
caohzmpj67udrqbhfchgyxnrxsm3qcy1c7jna1kr0ajbnkek...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Dear Galaxy Dev,
Ok I have gotten further found out what was going on, in my
data_transfer.log I was getting HTTP 404 Not Authorized when the data
transfer was trying to access Galaxy API URLs
http://galaxyserver/api/... This is because we are using external user
authentication as documented in
http://wiki.g2.bx.psu.edu/Admin/Config/Apache%20Proxy and this puts
all of Galaxy behind this authentication. Since the Galaxy API uses
API keys to essentially authenticate you have to change you Location
/ ... /Location container to not match URLs starting with /api. To
do this you have to change it to LocationMatch ^/(?!api)
/LocationMatch.
best,
leandro
On Mon, Mar 26, 2012 at 6:10 PM, Luobin Yang yangl...@isu.edu wrote:
I've got the same problem and when I looked at the data_transfer.log, I saw
the following message:
2012-03-01 15:12:27,338 - datatx_13870 -
(u'9c17d84742cd2acb63d88b5bd41d968f',
u'http://xxx.xxx.xxx.xxx/api/samples/2d9035b3fc152403',
{'sample_dataset_ids': ['a799d38679e985db', '33b43b4e7093c91f'],
'error_msg': '', 'update_type': 'sample_dataset_transfer_status',
'new_status': 'Adding to data library'})
2012-03-01 15:12:27,342 - datatx_13870 - Error. !DOCTYPE HTML PUBLIC
-//IETF//DTD HTML 2.0//EN
htmlhead
title405 Method Not Allowed/title
/headbody
h1Method Not Allowed/h1
pThe requested method PUT is not allowed for the URL
/api/samples/2d9035b3fc152403./p
hr
Using Galaxy instead of Apache as the web server changed the sample status
from in queue to complete but didn't add the downloaded files to the data
library.
Luobin
On Mon, Mar 26, 2012 at 9:54 AM, Leandro Hermida
soft...@leandrohermida.com wrote:
Dear Galaxy Dev,
I've set up the Galaxy sample tracking system data transfer
functionality exactly as specified here
https://main.g2.bx.psu.edu/u/rkchak/p/data-transfer, but when I
attempt to transfer datasets it puts them into the queue and then
never seems to transfer anything.
The galaxy_listener.log shows:
2012-03-26 17:16:24,515 - GalaxyAMQP - GALAXY LISTENER PID: 8738 -
{'config_file': 'universe_wsgi.ini', 'http_server_section':
'server:main'}
2012-03-26 17:16:24,518 - GalaxyAMQP - {'exchange': 'galaxy_exchange',
Re: [galaxy-dev] Sample tracking data transfer hangs in queue forever
Hi Greg,
I will be at the galaxy conference and am experiencing the same problem. I
would love to meet with you to look at this together.
Emily
From: Greg Von Kuster [mailto:g...@bx.psu.edu]
Sent: Wednesday, July 11, 2012 7:55 AM
To: Luobin Yang
Cc: TerAvest, Emily; galaxy-...@bx.psu.edu
Subject: Re: [galaxy-dev] Sample tracking data transfer hangs in queue forever
Hello Luobin,
I'm on my way to ISMB for a week, and then will be at the Galaxy Community
Conference the following week, so I won't have time to help you track this
problem down until some time in August unless you will be at either of these 2
conferences. Sorry for the inconvenience on this, but my schedule over the
next few weeks is very hectic. If you'll be at either ISMB or the GCC, we can
certainly get together to look at this.
Greg Von Kuster
On Jul 9, 2012, at 1:24 PM, Luobin Yang wrote:
Hi, Greg,
I've still got issues after I downloaded the latest version from the dist
repository. So after I selected the datasets that I would like to transfer from
the sequencer and click the Transfer button, Galaxy generates an error
message : Invalid sample id (None)... I tried to delete this dataset using
the manage datasets menu, and Galaxy generates the same error message:
Invalid sample id (None). It seems galaxy system generates the sample id
automatically (the first one is sample_1), not sure why this happens...
Luobin
On Fri, Mar 30, 2012 at 8:30 AM, Greg Von Kuster
g...@bx.psu.edumailto:g...@bx.psu.edu wrote:
Hello Emily,
This issue should be resolved in change set 6924:12b14f3e78e9, which is
currently only available from our central repository. It will not be available
in the dist repository fro some time, so you'll have to pull it from Galaxy
central (https://bitbucket.org/galaxy/galaxy-central) if you want it now.
Thanks very much for reporting this problem, and we apologize for the
inconvenience it caused.
Greg Von Kuster
On Mar 29, 2012, at 1:49 PM, TerAvest, Emily wrote:
Hi Leandro,
I am also experiencing the same problem with the latest version of galaxy. I
just attempted to connect our sequencer for the first time yesterday. I do
not have an older version of galaxy to test and compare to see if it works in
earlier versions. I am able to transfer data from the sequence to the import
directory, however it is not moved to the data library. My data_transfer.log
also has the same error.
The server could not comply with the request since it is either malformed or
otherwise incorrect.
Does anyone have a solution for this?
Thanks
Emily
--
Message: 17
Date: Wed, 28 Mar 2012 13:15:47 +0200
From: Leandro Hermida
soft...@leandrohermida.commailto:soft...@leandrohermida.com
To: Luobin Yang yangl...@isu.edumailto:yangl...@isu.edu
Cc: Galaxy Dev galaxy-...@bx.psu.edumailto:galaxy-...@bx.psu.edu
Subject: Re: [galaxy-dev] Sample tracking data transfer hangs in
queue forever
Message-ID:
caohzmpj67udrqbhfchgyxnrxsm3qcy1c7jna1kr0ajbnkek...@mail.gmail.commailto:caohzmpj67udrqbhfchgyxnrxsm3qcy1c7jna1kr0ajbnkek...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Dear Galaxy Dev,
Ok I have gotten further found out what was going on, in my
data_transfer.log I was getting HTTP 404 Not Authorized when the data
transfer was trying to access Galaxy API URLs
http://galaxyserver/api/.http://galaxyserver/api/.. This is because we are
using external user
authentication as documented in
http://wiki.g2.bx.psu.edu/Admin/Config/Apache%20Proxy and this puts
all of Galaxy behind this authentication. Since the Galaxy API uses
API keys to essentially authenticate you have to change you Location
/ ... /Location container to not match URLs starting with /api. To
do this you have to change it to LocationMatch ^/(?!api)
/LocationMatch.
best,
leandro
On Mon, Mar 26, 2012 at 6:10 PM, Luobin Yang
yangl...@isu.edumailto:yangl...@isu.edu wrote:
I've got the same problem and when I looked at the data_transfer.log, I saw
the following message:
2012-03-01 15:12:27,338 - datatx_13870 -
(u'9c17d84742cd2acb63d88b5bd41d968f',
u'http://xxx.xxx.xxx.xxx/api/samples/2d9035b3fc152403',
{'sample_dataset_ids': ['a799d38679e985db', '33b43b4e7093c91f'],
'error_msg': '', 'update_type': 'sample_dataset_transfer_status',
'new_status': 'Adding to data library'})
2012-03-01 15:12:27,342 - datatx_13870 - Error. !DOCTYPE HTML PUBLIC
-//IETF//DTD HTML 2.0//EN
htmlhead
title405 Method Not Allowed/title
/headbody
h1Method Not Allowed/h1
pThe requested method PUT is not allowed for the URL
/api/samples/2d9035b3fc152403./p
hr
Using Galaxy instead of Apache as the web server changed the sample status
from in queue to complete but didn't add the downloaded files to the data
library.
Luobin
On Mon, Mar 26, 2012 at 9:54 AM, Leandro Hermida
soft...@leandrohermida.commailto:soft...@leandrohermida.com wrote:
Dear Galaxy Dev,
I've set
Re: [galaxy-dev] Byte-range support for IGV ?
On Jul 4, 2012, at 7:57 AM, Chebbi Mohamed Amine wrote: HI Geert ! I did well : Location / XSendFile on XSendFilePath / /Location and Location / # Compress all uncompressed content. SetOutputFilter DEFLATE SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary SetEnvIfNoCase Request_URI \.(?:t?gz|zip|bz2)$ no-gzip dont-vary /Location But it dosen't fix it. Hi Amine, Did you also set use_sendfile = True in universe_wsgi.ini and restart the Galaxy server process? --nate I think that il is may be a problem of server byte-range accepting? Thanks Amine 2012/7/4 Geert Vandeweyer geert.vandewey...@ua.ac.be Hi, If I remember correctly, I solved this issue by enabling the xsendfile module in apache and setting galaxy to use the proxy for file downloading. best regards, Geert On 07/04/2012 11:15 AM, Chebbi Mohamed Amine wrote: HELLO ! I just updated our local galaxy instance and just wanted to try the new IGV display application. When I try to display a BAM file whith the local IGV, I encounter the following message : HTTP and FTP access to BAM files require byte-range support Has anyone encountred the same probleme? Thanks in advances Regards Amine ___ 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: http://lists.bx.psu.edu/ -- Geert Vandeweyer, Ph.D. Department of Medical Genetics University of Antwerp Prins Boudewijnlaan 43 2650 Edegem Belgium Tel: +32 (0)3 275 97 56 E-mail: geert.vandewe...@ua.ac.be http://ua.ac.be/cognitivegenetics http://www.linkedin.com/pub/geert-vandeweyer/26/457/726 ___ 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: http://lists.bx.psu.edu/ ___ 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: http://lists.bx.psu.edu/
[galaxy-dev] is there a way too automatically select references based on the genome of the dataset?
I would like the reference list to be automatically selected based on the dbkey of the selected input... I think I've seen this, but I can'f seem to find an example. Anybody know? Should be some easy jquery i guess. Brad -- Brad Langhorst langho...@neb.commailto:langho...@neb.com 978-380-7564 ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Galaxy cleaning up after it self after jobs fail
On Jul 5, 2012, at 8:02 PM, Anthonius deBoer wrote: I am running galaxy on a system that normally runs all jobs on the cluster, but some jobs need to be run locally... But when I restart galaxy when these jobs are running, those jobs fail (and I am fine with that)... But then when I check the logs, I see a lot of this kind of errors and the word CRITICAL scares me a little... It complains about certain directories not being empty (although they look empty to me when I look at them) But if it needs to clean up should it not expect stuff to be in those working directories? And why is this a critical error and why don't those directories get removed anyway...It clutters my database and I fear this was the reason for weird behaviour I saw earlier, since it may re-use some of these directories after a while ? galaxy.objectstore CRITICAL 2012-07-05 16:57:24,964 /mnt/ngs/analysis/tdeboer/galaxy-data/database2/job_working_directory/003/3350 delete error [Errno 39] Directory not empty: '/mnt/ngs/analysis/tdeboer/galaxy-data/database2/job_working_directory/003/3350' Hi Thon, This is the job's working directory. It's possible that the sequence of removal steps is out of order, or that removing files from the directory in the previous steps takes too long. It could also be hanging filehandles (like .nfs* files) for a shared filesystem. If you want to see what's in there, I'd suggest logging the contents of the directory right before the call that attempts to remove the directory in lib/galaxy/jobs/__init__.py. Otherwise, this is harmless and you can simply use any method you prefer to clean up extra job working directories at a later time. --nate Thanks Thon ___ 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: http://lists.bx.psu.edu/ ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Output file permissions different pbs:/// VS local:/// job runners
On Jul 5, 2012, at 9:21 PM, Rob Syme wrote: Hi all. When I run the FastQC tool using the default local job runner, it produces a folder of files with permission 664: snip -rw-rw-r-- 1 galaxy galaxy 17K Jul 5 17:29 duplication_levels.png -rw-rw-r-- 1 galaxy galaxy 1.6K Jul 5 17:29 error.png -rw-rw-r-- 1 galaxy galaxy 7.5K Jul 5 17:29 fastqc_data.txt snip When I switch to using the(local) pbs queue, it produces a folder with permissions 600: snip -rw--- 1 galaxy galaxy 15K Jul 6 09:10 duplication_levels.png -rw--- 1 galaxy galaxy 1.6K Jul 6 09:10 error.png -rw--- 1 galaxy galaxy 8.8K Jul 6 09:10 fastqc_data.txt snip The final dat file (in database/files/000/dataset_xx.dat) is fine, it's just the files in the corresponding folder (database/files/000/dataset_xx_files/*) that have the incorrect permissions. These more restrictive permissions mean that the files cannot be read by apache, resulting a bunch of broken links when viewing the tool's output. Does anybody know why this might be happening or how to resolve it? Hi Rob, In your cluster user's .bash_profile, try setting `umask 022` to cause new files to be created with world-readable permissions. --nate Many thanks. -r ___ 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: http://lists.bx.psu.edu/ ___ 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: http://lists.bx.psu.edu/
[galaxy-dev] Tool migration errors
I'm getting this error when I try to run the tool migration:sh ./scripts/migrate_tools/0003_tools.sh install_dependenciesNo handlers could be found for logger "docutils"Repositories will be installed into configured tool_path location ../shed_toolsAdding new row (or updating an existing row) for repository 'freebayes' in the tool_shed_repository table.Traceback (most recent call last): File "./scripts/migrate_tools/migrate_tools.py", line 21, in module app = MigrateToolsApplication( sys.argv[ 1 ] ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/migrate/common.py", line 150, in __init__ install_dependencies=install_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py", line 37, in __init__ self.install_repository( repository_elem, install_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py", line 258, in install_repository install_dependencies=install_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py", line 174, in handle_repository_contents tool_dependencies=tool_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/util/shed_util.py", line 1231, in handle_tool_dependencies tool_dependency = install_package( app, elem, tool_shed_repository, tool_dependencies=tool_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/tool_dependencies/install_util.py", line 52, in install_package install_dir = get_tool_dependency_install_dir( app, tool_shed_repository, package_name, package_version ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/tool_dependencies/install_util.py", line 42, in get_tool_dependency_install_dir repository.installed_changeset_revision ) ) File "/home/tdeboer/code/galaxy_env/lib/python2.6/posixpath.py", line 67, in join elif path == '' or path.endswith('/'):AttributeError: 'NoneType' object has no attribute 'endswith'Any ideas?ThanksThon___
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:
http://lists.bx.psu.edu/
Re: [galaxy-dev] Tool migration errors
Hi Thon,
What revision of Galaxy are you running? Have you made multiple attempts at
the migration? Are you running a postgres database? How many records do you
have in your tool_dependency table in your database, and what is the status of
each record? Have you made any changes to the Galaxy code base in your
environment? Any additional information that you can send will help track down
the problem in your environment.
Thanks!
Greg Von Kuster
On Jul 11, 2012, at 2:46 PM, Anthonius deBoer wrote:
I'm getting this error when I try to run the tool migration:
sh ./scripts/migrate_tools/0003_tools.sh install_dependencies
No handlers could be found for logger docutils
Repositories will be installed into configured tool_path location
../shed_tools
Adding new row (or updating an existing row) for repository 'freebayes' in
the tool_shed_repository table.
Traceback (most recent call last):
File ./scripts/migrate_tools/migrate_tools.py, line 21, in module
app = MigrateToolsApplication( sys.argv[ 1 ] )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/migrate/common.py, line
150, in __init__
install_dependencies=install_dependencies )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py,
line 37, in __init__
self.install_repository( repository_elem, install_dependencies )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py,
line 258, in install_repository
install_dependencies=install_dependencies )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py,
line 174, in handle_repository_contents
tool_dependencies=tool_dependencies )
File /home/tdeboer/code/galaxy-copy/lib/galaxy/util/shed_util.py, line
1231, in handle_tool_dependencies
tool_dependency = install_package( app, elem, tool_shed_repository,
tool_dependencies=tool_dependencies )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/tool_dependencies/install_util.py,
line 52, in install_package
install_dir = get_tool_dependency_install_dir( app, tool_shed_repository,
package_name, package_version )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/tool_dependencies/install_util.py,
line 42, in get_tool_dependency_install_dir
repository.installed_changeset_revision ) )
File /home/tdeboer/code/galaxy_env/lib/python2.6/posixpath.py, line 67,
in join
elif path == '' or path.endswith('/'):
AttributeError: 'NoneType' object has no attribute 'endswith'
Any ideas?
Thanks
Thon
___
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:
http://lists.bx.psu.edu/
___
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:
http://lists.bx.psu.edu/
Re: [galaxy-dev] Tool migration errors
My Galaxy version is the most recent, but I had cloned this from an earlier version and have made lots of changes over the months...I'm a little confused by the fact that the tool_shed tools seem to be defined BOTH by the various XML files AND the databaseI have on occasions manually edited the XML file which I guess screws up the database...it is bad practice to have two different places that can easily get out of sync I would think...Either stick with the XML paradigm OR move everything into a database...Doing both is bound to get out of syncI don't really want to dive into the database since I don't know the schema and not that good at SQL to begin with, but maybe a script that would sync stuff would be an idea...ThanksOn Jul 11, 2012, at 12:29 PM, Greg Von Kuster g...@bx.psu.edu wrote:Hi Thon, What revision of Galaxy are you running? Have you made multiple attempts at the migration? Are you running a postgres database? How many records do you have in your tool_dependency table in your database, and what is the status of each record? Have you made any changes to the Galaxy code base in your environment? Any additional information that you can send will help track down the problem in your environment. Thanks! Greg Von Kuster On Jul 11, 2012, at 2:46 PM, Anthonius deBoer wrote: I'm getting this error when I try to run the tool migration:sh ./scripts/migrate_tools/0003_tools.sh install_dependencies No handlers could be found for logger "docutils" Repositories will be installed into configured tool_path location ../shed_tools Adding new row (or updating an existing row) for repository 'freebayes' in the tool_shed_repository table. Traceback (most recent call last): File "./scripts/migrate_tools/migrate_tools.py", line 21, in module app = MigrateToolsApplication( sys.argv[ 1 ] ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/migrate/common.py", line 150, in __init__ install_dependencies=install_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py", line 37, in __init__ self.install_repository( repository_elem, install_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py", line 258, in install_repository install_dependencies=install_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py", line 174, in handle_repository_contents tool_dependencies=tool_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/util/shed_util.py", line 1231, in handle_tool_dependencies tool_dependency = install_package( app, elem, tool_shed_repository, tool_dependencies=tool_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/tool_dependencies/install_util.py", line 52, in install_package install_dir = get_tool_dependency_install_dir( app, tool_shed_repository, package_name, package_version ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/tool_dependencies/install_util.py", line 42, in get_tool_dependency_install_dir repository.installed_changeset_revision ) ) File "/home/tdeboer/code/galaxy_env/lib/python2.6/posixpath.py", line 67, in join elif path == '' or path.endswith('/'): AttributeError: 'NoneType' object has no attribute 'endswith'Any ideas?ThanksThon ___ 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:http://lists.bx.psu.edu/ ___
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:
http://lists.bx.psu.edu/
Re: [galaxy-dev] Tool migration errors
If I drop the following two tables, would those be reconstructed again correctly if I had the XML files in order?tool_version_associationandtool_versionThanksThonOn Jul 11, 2012, at 12:29 PM, Greg Von Kuster g...@bx.psu.edu wrote:Hi Thon, What revision of Galaxy are you running? Have you made multiple attempts at the migration? Are you running a postgres database? How many records do you have in your tool_dependency table in your database, and what is the status of each record? Have you made any changes to the Galaxy code base in your environment? Any additional information that you can send will help track down the problem in your environment. Thanks! Greg Von Kuster On Jul 11, 2012, at 2:46 PM, Anthonius deBoer wrote: I'm getting this error when I try to run the tool migration:sh ./scripts/migrate_tools/0003_tools.sh install_dependencies No handlers could be found for logger "docutils" Repositories will be installed into configured tool_path location ../shed_tools Adding new row (or updating an existing row) for repository 'freebayes' in the tool_shed_repository table. Traceback (most recent call last): File "./scripts/migrate_tools/migrate_tools.py", line 21, in module app = MigrateToolsApplication( sys.argv[ 1 ] ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/migrate/common.py", line 150, in __init__ install_dependencies=install_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py", line 37, in __init__ self.install_repository( repository_elem, install_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py", line 258, in install_repository install_dependencies=install_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py", line 174, in handle_repository_contents tool_dependencies=tool_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/util/shed_util.py", line 1231, in handle_tool_dependencies tool_dependency = install_package( app, elem, tool_shed_repository, tool_dependencies=tool_dependencies ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/tool_dependencies/install_util.py", line 52, in install_package install_dir = get_tool_dependency_install_dir( app, tool_shed_repository, package_name, package_version ) File "/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/tool_dependencies/install_util.py", line 42, in get_tool_dependency_install_dir repository.installed_changeset_revision ) ) File "/home/tdeboer/code/galaxy_env/lib/python2.6/posixpath.py", line 67, in join elif path == '' or path.endswith('/'): AttributeError: 'NoneType' object has no attribute 'endswith'Any ideas?ThanksThon ___ 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:http://lists.bx.psu.edu/ ___
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:
http://lists.bx.psu.edu/
Re: [galaxy-dev] Tool migration errors
Hi Thon,
On Jul 11, 2012, at 3:38 PM, Anthonius deBoer wrote:
My Galaxy version is the most recent, but I had cloned this from an earlier
version and have made lots of changes over the months...
This could pose problems unless you are sure that your code is in a functional
state after you pull the latest revision from Galaxy central.
I'm a little confused by the fact that the tool_shed tools seem to be defined
BOTH by the various XML files AND the database
The tools themselves are not defined by the database, but metadata about the
tools id stored in the database. For each repository you install from the tool
shed, you will have 1 row in the tol_shed_repository table in your database.
This table has a column named metadata that stores this information about the
repository, including its contents (tools, datatypes, workflows, etc).
I have on occasions manually edited the XML file which I guess screws up the
database...
Possibly. If you install a repository from the tool shed that includes a tool
config, changing your local version of the tool config could pose problems if
you get updates for your installed repository from the tool shed. If you don't
do this, however, there should be no problem caused by changing your local
version of the tool config.
it is bad practice to have two different places that can easily get out of
sync I would think...Either stick with the XML paradigm OR move everything
into a database...Doing both is bound to get out of sync
The way the tool shed components are architected do not result in this syncing
issues. You do not have to use the tool shed at all. Based on your
statements that you like to change your versions of the tool configs and Galaxy
code, you can protect your version of things by not running the tool migration
scripts at all. Your Galaxy instance will still work as you expect.
I don't really want to dive into the database since I don't know the schema
and not that good at SQL to begin with, but maybe a script that would sync
stuff would be an idea...
Thanks
On Jul 11, 2012, at 12:29 PM, Greg Von Kuster g...@bx.psu.edu wrote:
Hi Thon,
What revision of Galaxy are you running? Have you made multiple attempts at
the migration? Are you running a postgres database? How many records do you
have in your tool_dependency table in your database, and what is the status
of each record? Have you made any changes to the Galaxy code base in your
environment? Any additional information that you can send will help track
down the problem in your environment.
Thanks!
Greg Von Kuster
On Jul 11, 2012, at 2:46 PM, Anthonius deBoer wrote:
I'm getting this error when I try to run the tool migration:
sh ./scripts/migrate_tools/0003_tools.sh install_dependencies
No handlers could be found for logger docutils
Repositories will be installed into configured tool_path location
../shed_tools
Adding new row (or updating an existing row) for repository 'freebayes' in
the tool_shed_repository table.
Traceback (most recent call last):
File ./scripts/migrate_tools/migrate_tools.py, line 21, in module
app = MigrateToolsApplication( sys.argv[ 1 ] )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/migrate/common.py,
line 150, in __init__
install_dependencies=install_dependencies )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py,
line 37, in __init__
self.install_repository( repository_elem, install_dependencies )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py,
line 258, in install_repository
install_dependencies=install_dependencies )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py,
line 174, in handle_repository_contents
tool_dependencies=tool_dependencies )
File /home/tdeboer/code/galaxy-copy/lib/galaxy/util/shed_util.py, line
1231, in handle_tool_dependencies
tool_dependency = install_package( app, elem, tool_shed_repository,
tool_dependencies=tool_dependencies )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/tool_dependencies/install_util.py,
line 52, in install_package
install_dir = get_tool_dependency_install_dir( app, tool_shed_repository,
package_name, package_version )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/tool_dependencies/install_util.py,
line 42, in get_tool_dependency_install_dir
repository.installed_changeset_revision ) )
File /home/tdeboer/code/galaxy_env/lib/python2.6/posixpath.py, line 67,
in join
elif path == '' or path.endswith('/'):
AttributeError: 'NoneType' object has no attribute 'endswith'
Any ideas?
Thanks
Thon
___
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
Re: [galaxy-dev] Tool migration errors
I would not advise doing this. Based on your environment, I recommend that you
do not attempt to install tools from the tool shed as doing so may pose
problems for the same tools that you have altered in your environment and that
you do not want to get out of sync.
On Jul 11, 2012, at 4:09 PM, Anthonius deBoer wrote:
If I drop the following two tables, would those be reconstructed again
correctly if I had the XML files in order?
tool_version_association
and
tool_version
Thanks
Thon
On Jul 11, 2012, at 12:29 PM, Greg Von Kuster g...@bx.psu.edu wrote:
Hi Thon,
What revision of Galaxy are you running? Have you made multiple attempts at
the migration? Are you running a postgres database? How many records do you
have in your tool_dependency table in your database, and what is the status
of each record? Have you made any changes to the Galaxy code base in your
environment? Any additional information that you can send will help track
down the problem in your environment.
Thanks!
Greg Von Kuster
On Jul 11, 2012, at 2:46 PM, Anthonius deBoer wrote:
I'm getting this error when I try to run the tool migration:
sh ./scripts/migrate_tools/0003_tools.sh install_dependencies
No handlers could be found for logger docutils
Repositories will be installed into configured tool_path location
../shed_tools
Adding new row (or updating an existing row) for repository 'freebayes' in
the tool_shed_repository table.
Traceback (most recent call last):
File ./scripts/migrate_tools/migrate_tools.py, line 21, in module
app = MigrateToolsApplication( sys.argv[ 1 ] )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/migrate/common.py,
line 150, in __init__
install_dependencies=install_dependencies )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py,
line 37, in __init__
self.install_repository( repository_elem, install_dependencies )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py,
line 258, in install_repository
install_dependencies=install_dependencies )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py,
line 174, in handle_repository_contents
tool_dependencies=tool_dependencies )
File /home/tdeboer/code/galaxy-copy/lib/galaxy/util/shed_util.py, line
1231, in handle_tool_dependencies
tool_dependency = install_package( app, elem, tool_shed_repository,
tool_dependencies=tool_dependencies )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/tool_dependencies/install_util.py,
line 52, in install_package
install_dir = get_tool_dependency_install_dir( app, tool_shed_repository,
package_name, package_version )
File
/home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/tool_dependencies/install_util.py,
line 42, in get_tool_dependency_install_dir
repository.installed_changeset_revision ) )
File /home/tdeboer/code/galaxy_env/lib/python2.6/posixpath.py, line 67,
in join
elif path == '' or path.endswith('/'):
AttributeError: 'NoneType' object has no attribute 'endswith'
Any ideas?
Thanks
Thon
___
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:
http://lists.bx.psu.edu/
___
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:
http://lists.bx.psu.edu/
Re: [galaxy-dev] Tool migration errors
On Wed, Jul 11, 2012 at 3:25 PM, Greg Von Kuster g...@bx.psu.edu wrote: Hi Thon, On Jul 11, 2012, at 3:38 PM, Anthonius deBoer wrote: My Galaxy version is the most recent, but I had cloned this from an earlier version and have made lots of changes over the months... This could pose problems unless you are sure that your code is in a functional state after you pull the latest revision from Galaxy central. I'm a little confused by the fact that the tool_shed tools seem to be defined BOTH by the various XML files AND the database The tools themselves are not defined by the database, but metadata about the tools id stored in the database. For each repository you install from the tool shed, you will have 1 row in the tol_shed_repository table in your database. This table has a column named metadata that stores this information about the repository, including its contents (tools, datatypes, workflows, etc). I have on occasions manually edited the XML file which I guess screws up the database... Possibly. If you install a repository from the tool shed that includes a tool config, changing your local version of the tool config could pose problems if you get updates for your installed repository from the tool shed. If you don't do this, however, there should be no problem caused by changing your local version of the tool config. it is bad practice to have two different places that can easily get out of sync I would think...Either stick with the XML paradigm OR move everything into a database...Doing both is bound to get out of sync The way the tool shed components are architected do not result in this syncing issues. You do not have to use the tool shed at all. Based on your statements that you like to change your versions of the tool configs and Galaxy code, you can protect your version of things by not running the tool migration scripts at all. Your Galaxy instance will still work as you expect. That is not accurate, right? You are removing the files from the repository, if we merge with you they will disappear also. You are also removing lines from tool_conf.xml.sample so if people have hg cp'd that file it will also cause the tools to be lost on auto merges. The periodic merges local instances have to do with galaxy-dist is already a complicated process. It usually takes me an hour or two. So I don't think you should advocate people diverging even more from galaxy's core code base. Especially, considering during your exchange with me last month, you had advocated pulling changes right from the public bitbucket repository directly into a production code base. -John I don't really want to dive into the database since I don't know the schema and not that good at SQL to begin with, but maybe a script that would sync stuff would be an idea... Thanks On Jul 11, 2012, at 12:29 PM, Greg Von Kuster g...@bx.psu.edu wrote: Hi Thon, What revision of Galaxy are you running? Have you made multiple attempts at the migration? Are you running a postgres database? How many records do you have in your tool_dependency table in your database, and what is the status of each record? Have you made any changes to the Galaxy code base in your environment? Any additional information that you can send will help track down the problem in your environment. Thanks! Greg Von Kuster On Jul 11, 2012, at 2:46 PM, Anthonius deBoer wrote: I'm getting this error when I try to run the tool migration: sh ./scripts/migrate_tools/0003_tools.sh install_dependencies No handlers could be found for logger docutils Repositories will be installed into configured tool_path location ../shed_tools Adding new row (or updating an existing row) for repository 'freebayes' in the tool_shed_repository table. Traceback (most recent call last): File ./scripts/migrate_tools/migrate_tools.py, line 21, in module app = MigrateToolsApplication( sys.argv[ 1 ] ) File /home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/migrate/common.py, line 150, in __init__ install_dependencies=install_dependencies ) File /home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py, line 37, in __init__ self.install_repository( repository_elem, install_dependencies ) File /home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py, line 258, in install_repository install_dependencies=install_dependencies ) File /home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py, line 174, in handle_repository_contents tool_dependencies=tool_dependencies ) File /home/tdeboer/code/galaxy-copy/lib/galaxy/util/shed_util.py, line 1231, in handle_tool_dependencies tool_dependency = install_package( app, elem, tool_shed_repository, tool_dependencies=tool_dependencies ) File /home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/tool_dependencies/install_util.py, line 52, in install_package install_dir = get_tool_dependency_install_dir( app,
[galaxy-dev] Where are the datatype associations stored?
Hi,I had some more bad luck trying to install the GMAP stuff from the TOOLSHEd but revision 10 is broken since it does not allow you to select a section and just stores the programs in the main tree...But when I tried to remove the tool I got the following error for every run, since the sniffers where still looking for a module called GMAP...Which table should I nuke to get rid of this association? Where are the datatype associations stored?There does not seem to be an XML file for this, so I hope i can just remove some lines from the postgres database table but there are no obvious table names I can find...WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:IntervalAnnotation' to sniff_order: No module named g! map WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:SpliceSiteAnnotation' to sniff_order: No module named gmap WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:IntronAnnotation' to sniff_order: No module named gmap WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:SNPAnnotation' to sniff_order: No module named gmap WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:IntervalAnnotation' to sniff_order: No module named gmap WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:SpliceSiteAnnotation' to sniff_order: No module named gmap WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:IntronAnnotation' to sniff_order: No module named gmapWARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:SNPAnnotation' to sniff_order: No module named gmapThanks ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Where are the datatype associations stored?
How did you try to remove the tool? Do you mean that you used the Galaxy Admin UI to Uninstall the repository? The datatypes are defined in a file named datatypes_conf.xml in the installed gmap repository. Assuming you can uninstall this repository, doing so will eliminate this problem. I do not recommend nuking tables. If you manually deleted rows from your database tables, you may have caused problems with your environment that could render it un-useable. On Jul 11, 2012, at 6:46 PM, Anthonius deBoer wrote: Hi, I had some more bad luck trying to install the GMAP stuff from the TOOLSHEd but revision 10 is broken since it does not allow you to select a section and just stores the programs in the main tree... But when I tried to remove the tool I got the following error for every run, since the sniffers where still looking for a module called GMAP... Which table should I nuke to get rid of this association? Where are the datatype associations stored? There does not seem to be an XML file for this, so I hope i can just remove some lines from the postgres database table but there are no obvious table names I can find... WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:IntervalAnnotation' to sniff_order: No module named g! map WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:SpliceSiteAnnotation' to sniff_order: No module named gmap WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:IntronAnnotation' to sniff_order: No module named gmap WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:SNPAnnotation' to sniff_order: No module named gmap WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:IntervalAnnotation' to sniff_order: No module named gmap WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:SpliceSiteAnnotation' to sniff_order: No module named gmap WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:IntronAnnotation' to sniff_order: No module named gmap WARNING:galaxy.datatypes.registry:Error appending sniffer for datatype 'galaxy.datatypes.gmap:SNPAnnotation' to sniff_order: No module named gmap Thanks ___ 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: http://lists.bx.psu.edu/ ___ 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Tool migration errors
Hi John, On Jul 11, 2012, at 4:53 PM, John Chilton wrote: On Wed, Jul 11, 2012 at 3:25 PM, Greg Von Kuster g...@bx.psu.edu wrote: The way the tool shed components are architected do not result in this syncing issues. You do not have to use the tool shed at all. Based on your statements that you like to change your versions of the tool configs and Galaxy code, you can protect your version of things by not running the tool migration scripts at all. Your Galaxy instance will still work as you expect. That is not accurate, right? This is, in fact, accurate. You are removing the files from the repository, if we merge with you they will disappear also. That is correct, but my point was that you are not required to use the migration scripts that automatically install the tools that have been migrated out of the Galaxy code base and into the tool shed. These scripts state that you can skip the installation process and simply make a second attempt to start your Galaxy server. Galaxy will start up with the second attempt. If you have made proprietary changes to the tool files, mercurial will ask you if you want to delete the altered file (since it was deleted in the update) or keep the version with your changes. You get to make the choice. If you did not make any proprietary changes to the file, it will get removed automatically with the update. However, you can download the tool from the tool shed as a compressed tarball, uncompress it and store it in the same place that you had it before it was removed from the distribution. Using this approach will not create any database tables, and you will not have to use the migration scripts to install the repository to get access to the migrated tools. You are also removing lines from tool_conf.xml.sample so if people have hg cp'd that file it will also cause the tools to be lost on auto merges. You should not hg cp sample files as they can always change with updates. You should simply cp them so you'll have control over your own version of the file. The periodic merges local instances have to do with galaxy-dist is already a complicated process. It usually takes me an hour or two. So I don't think you should advocate people diverging even more from galaxy's core code base. I'm certainly not advocating that policy. I think you simply misunderstood my recommendations to Thon. Especially, considering during your exchange with me last month, you had advocated pulling changes right from the public bitbucket repository directly into a production code base. I guess you misunderstood what I was saying as an option for you. I just felt that since you have a test environment and a production environment, you could go through the update process to your test environment, pulling directly from bitbucket. After any issues are resolved, you could use the same process to update your production environment. In stating this, I was not advocating anything - I was simply relaying to you the process we use here at Penn State for our public Galaxy environment, and letting you know that this approach has worked well for us for years. If it doesn't work in your environment, that ok... -John I don't really want to dive into the database since I don't know the schema and not that good at SQL to begin with, but maybe a script that would sync stuff would be an idea... Thanks On Jul 11, 2012, at 12:29 PM, Greg Von Kuster g...@bx.psu.edu wrote: Hi Thon, What revision of Galaxy are you running? Have you made multiple attempts at the migration? Are you running a postgres database? How many records do you have in your tool_dependency table in your database, and what is the status of each record? Have you made any changes to the Galaxy code base in your environment? Any additional information that you can send will help track down the problem in your environment. Thanks! Greg Von Kuster On Jul 11, 2012, at 2:46 PM, Anthonius deBoer wrote: I'm getting this error when I try to run the tool migration: sh ./scripts/migrate_tools/0003_tools.sh install_dependencies No handlers could be found for logger docutils Repositories will be installed into configured tool_path location ../shed_tools Adding new row (or updating an existing row) for repository 'freebayes' in the tool_shed_repository table. Traceback (most recent call last): File ./scripts/migrate_tools/migrate_tools.py, line 21, in module app = MigrateToolsApplication( sys.argv[ 1 ] ) File /home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/migrate/common.py, line 150, in __init__ install_dependencies=install_dependencies ) File /home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py, line 37, in __init__ self.install_repository( repository_elem, install_dependencies ) File /home/tdeboer/code/galaxy-copy/lib/galaxy/tool_shed/install_manager.py, line 258, in install_repository
Re: [galaxy-dev] Job doesn't runnig
Hello Amandin, The job queue for NGS jobs on the public main Galaxy instance has been very busy since last Friday. We have been tracking the queue carefully all week and this afternoon took additional action to ensure fair access to the public resource. I didn't find any of your jobs in the queue - which likely means that you have already benefited from the changes and your jobs have processed. Thank you for your patience. Just so you know (Galaxy does get busy at times), a job that is in a grey waiting-to-run state is in the active queue. You always want to leave these jobs alone and not stop and restart them - or you will lose your place in the order and be moved back to the end of the queue. Also, queue wait times can vary, from a few minutes up to a day if there is a very large usage demand. But, if you intend to run the job on the public instance, leaving the job as-is is the best strategy. If your work is urgent, a local or cloud instance is always another option: http://getgalaxy.org Next time, you may want to send usage questions about the main public instance (like this one) to the galaxy-u...@bx.psu.edu mailing list instead: http://wiki.g2.bx.psu.edu/Support#Mailing_Lists Best, Jen Galaxy team On 7/11/12 2:42 AM, Amandin Talbot wrote: Dear Galaxy Dev Team- I try to run a job with Tophat for Illumina (version 1.5.0) but in my history job always stay at Job is waiting to run. I use the following parameters : RNA-Seq FASTQ file: FASTQ Groomer on upload dataset Reference Genome : build-in index : Chicken (Gallus gallus): galGal3 Full Mate-paired : Single-end TopHat settings : Defaults How should i do to make this job running ? Thanks in advance. Amandin Talbot ___ 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: http://lists.bx.psu.edu/ -- Jennifer Jackson http://galaxyproject.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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Tophat and bowtie jobs failed!
Hello Avazeh, Your jobs were effected by two issues: 1 - This specific error was due to a problem on our side with the data processing around the time that you submitted this email. Next time, submitting a bug report (green bug icon) for failed jobs that are clearly processing related will ensure that you are included in the first round of notifications when the issue is resolved. http://wiki.g2.bx.psu.edu/Support#Reporting_tool_errors 2 - The job queue for NGS jobs on the public main Galaxy instance has been very busy since last Friday. We have been tracking the queue carefully all week and this afternoon took additional action to ensure fair access to the public resource. You will likely notice significant improvement in job processing wait times (shorter!). Please resubmit this job and all other jobs that have failed with this same type of error. Very sorry for the inconvenience, Jen Galaxy team On 7/10/12 2:28 AM, A Ghanbarian wrote: Hi, I have submitted tophat to run on two datasets yesterday morning. The jobs waited in the queue whole yesterday and the statues now show the output files being deleted. Not knowing the architecture that these services are running on, we also tried to submit couple of alignments for smaller datasets which both had the same faith. Now thinking there might be something wrong on the server. My user name is Avazeh and tophat jobs are still visible in the history, 52-55 and 60-63. Thanks for all the help, Avazeh ___ 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: http://lists.bx.psu.edu/ -- Jennifer Jackson http://galaxyproject.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: http://lists.bx.psu.edu/
[galaxy-dev] Is the galaxy main toolshed compatible with local installs of galaxy-dist?
I was wondering whether the general policy is to keep the toolshed at toolshed.g2.bx.psu.edu compatible with galaxy-dist or galaxy-central. The reason I ask is that I went to install a tool from a production server I'm trying to setup based on galaxy-dist ... but got an error; The resource could not be found. No action for /admin_toolshed/prepare_for_install Searching for this in the source code, I found that it exists in galaxy-central ... but not in galaxy-dist Am I right in guessing that this error is due to toolshed.g2.bx.psu.edu being powered by a recent toolshed version that is incompatible with galaxy-dist? If so, it would be great to get clarification as to whether this is to be expected in future. My personal feeling is that the main toolshed would be much more useful if kept compatible with galaxy-dist. Cheers Ira ___ 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: http://lists.bx.psu.edu/
