[galaxy-dev] uploads stuck in history
Dear list, I have stumbled on some strange behaviour when uploading files to galaxy via the upload.py tool. At times, the upload seems to be stalled in history and is never actually performed, followed by a seemingly infinite history update (see log below). My system is Ubuntu 11.10 and runs Python 2.7.2. I find the behaviour in both my own modified galaxy install (based on galaxy-dist), and in a fresh clone from galaxy-central. I have tried to upload different files, and all seem to sometimes trigger the behaviour, but not all the time. A restart of galaxy sometimes sorts things out. Common for the debug messages is that it seems there is never a job id generated as in galaxy.tools.actions.upload_common INFO 2012-02-22 10:06:36,186 tool upload1 created job id 2. Has anyone seen similar things or can it be a problem with my system? cheers, jorrit --Debug messa: galaxy.web.framework DEBUG 2012-02-22 09:47:43,730 Error: this request returned None from get_history(): http://localhost:8080/ 127.0.0.1 - - [22/Feb/2012:09:47:43 +0200] GET / HTTP/1.1 200 - - Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:44 +0200] GET /root/tool_menu HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:44 +0200] GET /history HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:44 +0200] POST /root/user_get_usage HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:50 +0200] GET /tool_runner?tool_id=upload1 HTTP/1.1 200 - http://localhost:8080/root/tool_menu; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] POST /tool_runner/upload_async_create HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] GET /tool_runner/upload_async_message HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] GET /history HTTP/1.1 200 - http://localhost:8080/tool_runner/upload_async_message; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] POST /root/user_get_usage HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:13 +0200] GET /tool_runner?tool_id=upload1 HTTP/1.1 200 - http://localhost:8080/root/tool_menu; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:15 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:19 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:23 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:27 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:31 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:35 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:39 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:43 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:47 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 ___ Please keep all replies on the list by using reply all in your mail client. To manage your
[galaxy-dev] Timeout and Galaxy - Cluster could not complete job
Hello everybody :) Today, I have a question related to timeout management in Galaxy. More particularly, I'm searching for a way to set (in a configuration file if possible) all timeouts related to DRMAA and timeouts related to communication between Galaxy and SGE. My goal is to increase current timeouts to avoid the Cluster could not complete job error on successful jobs when there is a temporary problem of job status checking (due to heavy write load on the hard drive or whatever). Is this possible ? Thank you in advance, Have a nice day A. Bernard -- Aurélien Bernard IE Bioprogrammeur - CNRS Université des sciences Montpellier II Institut des Sciences de l'Evolution France ___ 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] uploads stuck in history
Hi I guess we see similar things: a new history item is created, it turns purple, stays like this apparently forever while no job id is created (ie I don't see the job in any of the report tools). To be honest we ignore them, because: a) it only (as far as I can tell) happens with big data files (we try to avoid this anyway by using 'Data libraries') while there is heavy load on the storage system b) ...eventually, unless the user has deleted the history item, it does turn green and the job is listed as 'ok'. Do you experience this problem with all files, even small ones? Regards, Hans On 02/22/2012 10:14 AM, Jorrit Boekel wrote: Dear list, I have stumbled on some strange behaviour when uploading files to galaxy via the upload.py tool. At times, the upload seems to be stalled in history and is never actually performed, followed by a seemingly infinite history update (see log below). My system is Ubuntu 11.10 and runs Python 2.7.2. I find the behaviour in both my own modified galaxy install (based on galaxy-dist), and in a fresh clone from galaxy-central. I have tried to upload different files, and all seem to sometimes trigger the behaviour, but not all the time. A restart of galaxy sometimes sorts things out. Common for the debug messages is that it seems there is never a job id generated as in galaxy.tools.actions.upload_common INFO 2012-02-22 10:06:36,186 tool upload1 created job id 2. Has anyone seen similar things or can it be a problem with my system? cheers, jorrit --Debug messa: galaxy.web.framework DEBUG 2012-02-22 09:47:43,730 Error: this request returned None from get_history(): http://localhost:8080/ 127.0.0.1 - - [22/Feb/2012:09:47:43 +0200] GET / HTTP/1.1 200 - - Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:44 +0200] GET /root/tool_menu HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:44 +0200] GET /history HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:44 +0200] POST /root/user_get_usage HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:50 +0200] GET /tool_runner?tool_id=upload1 HTTP/1.1 200 - http://localhost:8080/root/tool_menu; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] POST /tool_runner/upload_async_create HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] GET /tool_runner/upload_async_message HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] GET /history HTTP/1.1 200 - http://localhost:8080/tool_runner/upload_async_message; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] POST /root/user_get_usage HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:13 +0200] GET /tool_runner?tool_id=upload1 HTTP/1.1 200 - http://localhost:8080/root/tool_menu; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:15 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:19 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:23 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:27 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:31 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:35 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:39 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2)
Re: [galaxy-dev] uploads stuck in history
Hi all, We get the behavior mentioned some times too, its not reproducible just like you mentioned. Some times it happens with small files, some times with large files and again as you said it doesn't happen all the time. Now I haven't seen this yet on our Galaxy dev server which is the latest galaxy-dist, only see this on our Galaxy production which is an older version of galaxy-dist from last winter. regards, Leandro On Wed, Feb 22, 2012 at 3:59 PM, Hans-Rudolf Hotz h...@fmi.ch wrote: Hi I guess we see similar things: a new history item is created, it turns purple, stays like this apparently forever while no job id is created (ie I don't see the job in any of the report tools). To be honest we ignore them, because: a) it only (as far as I can tell) happens with big data files (we try to avoid this anyway by using 'Data libraries') while there is heavy load on the storage system b) ...eventually, unless the user has deleted the history item, it does turn green and the job is listed as 'ok'. Do you experience this problem with all files, even small ones? Regards, Hans On 02/22/2012 10:14 AM, Jorrit Boekel wrote: Dear list, I have stumbled on some strange behaviour when uploading files to galaxy via the upload.py tool. At times, the upload seems to be stalled in history and is never actually performed, followed by a seemingly infinite history update (see log below). My system is Ubuntu 11.10 and runs Python 2.7.2. I find the behaviour in both my own modified galaxy install (based on galaxy-dist), and in a fresh clone from galaxy-central. I have tried to upload different files, and all seem to sometimes trigger the behaviour, but not all the time. A restart of galaxy sometimes sorts things out. Common for the debug messages is that it seems there is never a job id generated as in galaxy.tools.actions.upload_common INFO 2012-02-22 10:06:36,186 tool upload1 created job id 2. Has anyone seen similar things or can it be a problem with my system? cheers, jorrit --Debug messa: galaxy.web.framework DEBUG 2012-02-22 09:47:43,730 Error: this request returned None from get_history(): http://localhost:8080/ 127.0.0.1 - - [22/Feb/2012:09:47:43 +0200] GET / HTTP/1.1 200 - - Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:44 +0200] GET /root/tool_menu HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:44 +0200] GET /history HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:44 +0200] POST /root/user_get_usage HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:50 +0200] GET /tool_runner?tool_id=upload1 HTTP/1.1 200 - http://localhost:8080/root/tool_menu; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] POST /tool_runner/upload_async_create HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] GET /tool_runner/upload_async_message HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] GET /history HTTP/1.1 200 - http://localhost:8080/tool_runner/upload_async_message; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] POST /root/user_get_usage HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:13 +0200] GET /tool_runner?tool_id=upload1 HTTP/1.1 200 - http://localhost:8080/root/tool_menu; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:15 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:19 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:23 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:27 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Re: [galaxy-dev] uploads stuck in history
Hi, I haven't been patient enough to wait really long, but I can give that a try. As Leandro mentioned, I've also seen it in kilobyte to megabyte sized files. My Galaxy is forked from the latest galaxy-dist. cheers, jorrit On 02/22/2012 04:47 PM, Leandro Hermida wrote: Hi all, We get the behavior mentioned some times too, its not reproducible just like you mentioned. Some times it happens with small files, some times with large files and again as you said it doesn't happen all the time. Now I haven't seen this yet on our Galaxy dev server which is the latest galaxy-dist, only see this on our Galaxy production which is an older version of galaxy-dist from last winter. regards, Leandro On Wed, Feb 22, 2012 at 3:59 PM, Hans-Rudolf Hotzh...@fmi.ch wrote: Hi I guess we see similar things: a new history item is created, it turns purple, stays like this apparently forever while no job id is created (ie I don't see the job in any of the report tools). To be honest we ignore them, because: a) it only (as far as I can tell) happens with big data files (we try to avoid this anyway by using 'Data libraries') while there is heavy load on the storage system b) ...eventually, unless the user has deleted the history item, it does turn green and the job is listed as 'ok'. Do you experience this problem with all files, even small ones? Regards, Hans On 02/22/2012 10:14 AM, Jorrit Boekel wrote: Dear list, I have stumbled on some strange behaviour when uploading files to galaxy via the upload.py tool. At times, the upload seems to be stalled in history and is never actually performed, followed by a seemingly infinite history update (see log below). My system is Ubuntu 11.10 and runs Python 2.7.2. I find the behaviour in both my own modified galaxy install (based on galaxy-dist), and in a fresh clone from galaxy-central. I have tried to upload different files, and all seem to sometimes trigger the behaviour, but not all the time. A restart of galaxy sometimes sorts things out. Common for the debug messages is that it seems there is never a job id generated as in galaxy.tools.actions.upload_common INFO 2012-02-22 10:06:36,186 tool upload1 created job id 2. Has anyone seen similar things or can it be a problem with my system? cheers, jorrit --Debug messa: galaxy.web.framework DEBUG 2012-02-22 09:47:43,730 Error: this request returned None from get_history(): http://localhost:8080/ 127.0.0.1 - - [22/Feb/2012:09:47:43 +0200] GET / HTTP/1.1 200 - - Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:44 +0200] GET /root/tool_menu HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:44 +0200] GET /history HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:44 +0200] POST /root/user_get_usage HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:47:50 +0200] GET /tool_runner?tool_id=upload1 HTTP/1.1 200 - http://localhost:8080/root/tool_menu; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] POST /tool_runner/upload_async_create HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] GET /tool_runner/upload_async_message HTTP/1.1 200 - http://localhost:8080/; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] GET /history HTTP/1.1 200 - http://localhost:8080/tool_runner/upload_async_message; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:11 +0200] POST /root/user_get_usage HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:13 +0200] GET /tool_runner?tool_id=upload1 HTTP/1.1 200 - http://localhost:8080/root/tool_menu; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:15 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:19 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 - - [22/Feb/2012:09:48:23 +0200] POST /root/history_item_updates HTTP/1.1 200 - http://localhost:8080/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 127.0.0.1 -
Re: [galaxy-dev] Error 500 when trying to execute a workflow with the API
Huh? I have many string inputs to some particular workflow steps...Those are parameters etc that need to be entered or chosen from a dropdown..How would we deal with those kinds of entries into a workflow in the API? Or do all of them have to be pre-set?ThanksThonOn Feb 21, 2012, at 04:21 PM, Dannon Baker dannonba...@me.com wrote:There is no string input. If the string you're looking for is, say, the name of a dataset what you'd do is make separate calls to the history and workflow API. For example, if you had a history "My important history", and a dataset "My input dataset", and no knowledge of the id's (as you shouldn't' have to have, externally), it'd be three separate calls. One to list histories, then you would programmatically grab the one you want ("My important history") and the ID associated with it. Then you'd make a call to grab the contents of that history, from which you could extract the id of the dataset you had the name of. And from there you know how to execute a workflow with that id (hda, in this case). -Dannon On Feb 21, 2012, at 7:13 PM, thondeb...@me.com wrote: One more question... How do I pass a string value to one of the workflow input steps? Is there an equivalent of ldda and hda, maybe "str"..So 38=str="Some value"Where could I find a list of the expected dataset sources?ThanksThonOn Feb 21, 2012, at 03:46 PM, Dannon Baker dannonba...@me.com wrote:Hi Thon,You have the right idea about what's going wrong here. Galaxy is trying to pull up a library dataset with the ID you specify, but it doesn't exist.In this context, src refers to the 'type' of dataset input id, more specifically whether it's from a history or library. 'hda' indicates that the dataset is from a history, and 'ldda' is what you'll most likely use in the case of a library dataset. If you browse the history and library API functionality, you'll see other methods for explicitly grabbing these ids.My hunch is that you have an id from a history and that you should swap ldda to hda and give it another shot. Definitely let me know if you run into more issues, though, and I'll help figure out what's going on.-DannonOn Feb 21, 2012, at 6:22 PM, thondeb...@me.com wrote: Hi, I tried to run a workflow with the API, but get an Error 500 when I try to run the WF...The paster.log shows the following error... $ workflow_execute.py 92cc01ed93dc0f0fc91e3ded35497c0a http://srp106:8080/api/workflows ebfb8f50c6abde6d 'TEST the API' '1=ldda=7c5ebce002fc9d5c' Paster.log galaxy.web.framework ERROR 2012-02-21 14:36:33,067 Uncaught exception in exposed API method: Traceback (most recent call last): File "/home/tdeboer/code/galaxy-central/lib/galaxy/web/framework/__init__.py", line 145, in decorator return simplejson.dumps( func( self, trans, *args, **kwargs ), indent=4, sort_keys=True ) File "/home/tdeboer/code/galaxy-central/lib/galaxy/web/api/workflows.py", line 123, in create hda = ldda.to_history_dataset_association(history, add_to_history=add_to_history) AttributeError: 'NoneType' object has no attribute 'to_history_dataset_association' 172.16.108.6 - - [21/Feb/2012:14:36:32 -0700] "POST /api/workflows?key=92cc01ed93dc0f0fc91e3ded35497c0a HTTP/1.1" 500 - "-" "Python-urllib/2.6" Any ideas? Also...I had a hard time finding out what I should use for the dataset source parameter "src" in "step=src="" and just tried ldda, but would hope there is a little info on what this hda and ldda is? 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/One ___
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] Error 500 when trying to execute a workflow with the API
Ahh, I see what you're asking. I thought you were referring to providing dataset inputs by name, my mistake.Currently running workflows through the API doesn't support defining inputs other than datasets, that is, it expects workflows to be fully pre-defined with nothing 'set at runtime' other than the input datasets.That said, this is something that's definitely on my plate to add, unless the community gets to it first, in which case I'll happily accept a pull request :)-DannonOn Feb 22, 2012, at 10:11 AM, Anthonius deBoer thondeb...@me.com wrote:Huh? I have many string inputs to some particular workflow steps...Those are parameters etc that need to be entered or chosen from a dropdown..How would we deal with those kinds of entries into a workflow in the API? Or do all of them have to be pre-set?ThanksThonOn Feb 21, 2012, at 04:21 PM, Dannon Baker dannonba...@me.com wrote:There is no string input. If the string you're looking for is, say, the name of a dataset what you'd do is make separate calls to the history and workflow API. For example, if you had a history "My important history", and a dataset "My input dataset", and no knowledge of the id's (as you shouldn't' have to have, externally), it'd be three separate calls. One to list histories, then you would programmatically grab the one you want ("My important history") and the ID associated with it. Then you'd make a call to grab the contents of that history, from which you could extract the id of the dataset you had the name of. And from there you know how to execute a workflow with that id (hda, in this case). -Dannon On Feb 21, 2012, at 7:13 PM, thondeb...@me.com wrote: One more question... How do I pass a string value to one of the workflow input steps? Is there an equivalent of ldda and hda, maybe "str"..So 38=str="Some value"Where could I find a list of the expected dataset sources?ThanksThonOn Feb 21, 2012, at 03:46 PM, Dannon Baker dannonba...@me.com wrote:Hi Thon,You have the right idea about what's going wrong here. Galaxy is trying to pull up a library dataset with the ID you specify, but it doesn't exist.In this context, src refers to the 'type' of dataset input id, more specifically whether it's from a history or library. 'hda' indicates that the dataset is from a history, and 'ldda' is what you'll most likely use in the case of a library dataset. If you browse the history and library API functionality, you'll see other methods for explicitly grabbing these ids.My hunch is that you have an id from a history and that you should swap ldda to hda and give it another shot. Definitely let me know if you run into more issues, though, and I'll help figure out what's going on.-DannonOn Feb 21, 2012, at 6:22 PM, thondeb...@me.com wrote: Hi, I tried to run a workflow with the API, but get an Error 500 when I try to run the WF...The paster.log shows the following error... $ workflow_execute.py 92cc01ed93dc0f0fc91e3ded35497c0a http://srp106:8080/api/workflows ebfb8f50c6abde6d 'TEST the API' '1=ldda=7c5ebce002fc9d5c' Paster.log galaxy.web.framework ERROR 2012-02-21 14:36:33,067 Uncaught exception in exposed API method: Traceback (most recent call last): File "/home/tdeboer/code/galaxy-central/lib/galaxy/web/framework/__init__.py", line 145, in decorator return simplejson.dumps( func( self, trans, *args, **kwargs ), indent=4, sort_keys=True ) File "/home/tdeboer/code/galaxy-central/lib/galaxy/web/api/workflows.py", line 123, in create hda = ldda.to_history_dataset_association(history, add_to_history=add_to_history) AttributeError: 'NoneType' object has no attribute 'to_history_dataset_association' 172.16.108.6 - - [21/Feb/2012:14:36:32 -0700] "POST /api/workflows?key=92cc01ed93dc0f0fc91e3ded35497c0a HTTP/1.1" 500 - "-" "Python-urllib/2.6" Any ideas? Also...I had a hard time finding out what I should use for the dataset source parameter "src" in "step=src="" and just tried ldda, but would hope there is a little info on what this hda and ldda is? 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/One ___
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] Splitting large jobs over multiple nodes/CPUs?
On Thu, Feb 16, 2012 at 9:02 PM, Peter wrote: On Thu, Feb 16, 2012 at 6:42 PM, Chris wrote: On Feb 16, 2012, at 12:24 PM, Peter wrote: I also need to look at merging multiple BLAST XML outputs, but this is looking promising. Yep, that's definitely one where a simple concatenation wouldn't work (though NCBI used to think so, years ago…) Well, given the NCBI's historic practise of producing 'XML' output which was the concatenation of several XML files, some tools will tolerate this out of practicality - the Biopython BLAST XML parser for example. But yes, some care is needed over the header/footer to ensure a valid XML output is created by the merge. This may also require renumbering queries... I will check. Basic BLAST XML merging implemented and apparently working: https://bitbucket.org/peterjc/galaxy-central/changeset/ebf65c0b1e26 This does not currently attempt to remap the iteration numbers or automatically assigned query names, e.g. you can have this kind of thing in the middle of the XML at a merge point: Iteration_iter-num1/Iteration_iter-num Iteration_query-IDQuery_1/Iteration_query-ID That isn't a problem for some tools, e.g. my code in Galaxy to convert BLAST XML to tabular, but I suspect it could cause trouble elsewhere. If anyone has specific suggestions for what to test, that would be great. If this is an issue, then the merge code needs a little more work to edit these values. I think the FASTA split code could be reviewed for inclusion though. Dan - do you want to look at that? Would a clean branch help? 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Splitting large jobs over multiple nodes/CPUs?
Awesome, I'll take a look. And, if you're able to pull it together easily enough, clean branches are always nice.-DannonOn Feb 22, 2012, at 10:59 AM, Peter Cock p.j.a.c...@googlemail.com wrote: Basic BLAST XML merging implemented and apparently working: https://bitbucket.org/peterjc/galaxy-central/changeset/ebf65c0b1e26 This does not currently attempt to remap the iteration numbers or automatically assigned query names, e.g. you can have this kind of thing in the middle of the XML at a merge point: Iteration_iter-num1/Iteration_iter-num Iteration_query-IDQuery_1/Iteration_query-ID That isn't a problem for some tools, e.g. my code in Galaxy to convert BLAST XML to tabular, but I suspect it could cause trouble elsewhere. If anyone has specific suggestions for what to test, that would be great. If this is an issue, then the merge code needs a little more work to edit these values. I think the FASTA split code could be reviewed for inclusion though. Dan - do you want to look at that? Would a clean branch help? 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: http://lists.bx.psu.edu/
[galaxy-dev] snpEff: html report is not displaying after update
Hello Raj, This tool is from the Tool Shed and is maintained by the tool author. To contact them about functionality or problems, go to the Tool Shed at http://toolshed.g2.bx.psu.edu/, locate the repository (search by 'snpEff'), click on the name, in the the top far right corner locate the pull down menu Repository Actions. Select Contact repository owner to send them a message. There have been many updates to Galaxy recently and it is possible that one of these had an impact on this tool. I am going to send your email to galaxy-...@bx.psu.edu, to see if anyone else has had problems with this tool since the last distribution update. You may be asked to provide more information (be as specific as you can): the hg pull #, any customizations, python version, etc. Regards, Jen Galaxy team On 2/14/12 8:28 PM, Praveen Raj Somarajan wrote: Hi All, I updated galaxy recently to the latest version. Everything looks fine, except snpEff report html view. It was displaying properly (all tables and summary values) before the update, but the summary values are not displaying after the update. A sample screen-shot is attached for your reference. Could you please figure out this issue? When I ran the same on command line, the reports were generated correctly. I assume, something (datatypes or preview) has changed by the update. Please let me know the work around on this? Secondly, as we know, snpEff also generates a gene-wise annotation file along with other results, but somehow we cannot access this file through Galaxy. Though we see the link in the html report, but it seems the path is broken. Let me know your suggestions. Best, Raj This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions that are unlawful. This e-mail may contain viruses. Ocimum Biosolutions has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. OCIMUMBIO SOLUTIONS (P) LTD ___ 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: http://lists.bx.psu.edu/listinfo/galaxy-dev To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ -- Jennifer Jackson http://usegalaxy.org http://galaxyproject.org/wiki/Support ___ 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] R scripts for DESeq
Hi Lisa, I am going to send your question over to the galaxy-...@bx.psu.edu mailing list so that the development community can offer feedback. http://wiki.g2.bx.psu.edu/Support#Starting_a_technical.2C_local.2BAC8-cloud_instance.2C_or_development_thread Th galaxy-user list is primarily for tool/data usage on the Galaxy public server. http://wiki.g2.bx.psu.edu/Mailing%20Lists Thanks, Jen Galaxy team Original Message Subject: [galaxy-user] R scripts for DESeq Date: Tue, 21 Feb 2012 23:25:35 -0500 From: Liusong Yang liusongyang2...@gmail.com To: galaxy-u...@lists.bx.psu.edu Hello, I am planning to put DESeq into galaxy. I am a newcomer for both Galaxy and R. I have already read all of the related discussion in this group. I also noticed that there are r_wrapper.sh and DESeq.xml added into galaxy recently under the path of tools. These lines are from r_wrapper.sh. ### Run R providing the R script in $1 as standard input and passing ### the remaining arguments on the command line I guess this means we need to give the DESeq R script to the wrapper as standard input. My question is where or what is the DESeq R scripts? I installed R and DESeq package, but I can not fund anything like DESeq.R or something similar? I feel so confusing now. Any comments or suggestions would be absolutely appreciated! Thanks Lisa ___ 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: http://lists.bx.psu.edu/listinfo/galaxy-dev 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] limited tool shed browse
When I click on Admin-'Search and browse tool sheds'-'Galaxy main tool shed', it shows the first page of Valid repositories. However, clicking '2', '3', '4', or 'Show All' has no effect. I can only display the first page of repositories. However, if I search for valid tools using the menu under 'Galaxy main tool shed', I can get to any of the repositories listed at the Galaxy main toolshed. Is this a bug or a feature? David Hoover Helix Systems Staff ___ 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] FastX tools
On Tue, Feb 21, 2012 at 5:49 PM, Borrone, James james.w.borr...@okstate.edu wrote: hello, I am trying to use the FastX tools on the Main server to trim and manipulate FASTQ files extracted directly from an sff file (again using the main galaxy web server). In using Clip and the Reverse compliment tools, I get the following error: An error occurred running this job: fastx_reverse_complement: (or fastx_clip) found invalid nucleotide sequence (gactGCGACTCACGTACAGCAATGCACATACTATATTATATC) on line 2 When you turn the SFF into FASTQ, ask for the trimmed reads. That will remove the lower case nucleotides. 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: http://lists.bx.psu.edu/
Re: [galaxy-dev] limited tool shed browse
Hi David, I cannot reproduce this behavior from my local Galaxy instance, but clicking '2', '3', '4' or 'Show All does take a second or more to display the response. Can you provide more information about the environment you have or what you are doing to reproduce this? Thanks Greg Von Kuster On Feb 22, 2012, at 4:02 PM, David Hoover wrote: When I click on Admin-'Search and browse tool sheds'-'Galaxy main tool shed', it shows the first page of Valid repositories. However, clicking '2', '3', '4', or 'Show All' has no effect. I can only display the first page of repositories. However, if I search for valid tools using the menu under 'Galaxy main tool shed', I can get to any of the repositories listed at the Galaxy main toolshed. Is this a bug or a feature? David Hoover Helix Systems Staff ___ 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] limited tool shed browse
What browser / version are you using? On Feb 22, 2012, at 4:18 PM, David Hoover wrote: It's a local install, hg summary gives 6621:26920e20157f. I'm using MySQL as a backend database and have the following options set to non-default: port = 8081 host = 0.0.0.0 tool_config_file = tool_conf.xml,shed_tool_conf.xml install_tool_config_file = shed_tool_conf.xml brand = Galaxy1 use_interactive = False enable_whoosh_library_search = True use_remote_user = True allow_user_deletion = True allow_user_impersonation = True allow_user_dataset_purge = True new_user_dataset_access_role_default_private = True enable_quotas = True retry_job_output_collection = 10 output_size_limit = 10737418240 start_job_runners = drmaa On Feb 22, 2012, at 4:07 PM, Greg Von Kuster wrote: Hi David, I cannot reproduce this behavior from my local Galaxy instance, but clicking '2', '3', '4' or 'Show All does take a second or more to display the response. Can you provide more information about the environment you have or what you are doing to reproduce this? Thanks Greg Von Kuster On Feb 22, 2012, at 4:02 PM, David Hoover wrote: When I click on Admin-'Search and browse tool sheds'-'Galaxy main tool shed', it shows the first page of Valid repositories. However, clicking '2', '3', '4', or 'Show All' has no effect. I can only display the first page of repositories. However, if I search for valid tools using the menu under 'Galaxy main tool shed', I can get to any of the repositories listed at the Galaxy main toolshed. Is this a bug or a feature? David Hoover Helix Systems Staff ___ 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] How to learn about new tools in the official Tool Shed
Hi Sarah, Bjoern is correct. A few other choices are: We send out a tweet when new tools are added. This isn't automatic, or necessarily for all tools, but something we plan on continuing. If interested, you could follow us on twitter or track the Twitter wiki: http://wiki.g2.bx.psu.edu/Galaxy%20on%20Twitter The getgalaxy search will find items in the Tool Shed, as well as other Galaxy areas of developer interest (like the galaxy-dev list threads): http://wiki.g2.bx.psu.edu/News/Custom%20Galaxy%20Search Best, Jen Galaxy team On 2/20/12 1:01 AM, Sarah Diehl wrote: Hello, one quick question: is there a way to get news about new tools in the Tool Shed? I saw that I can subscribe to get news about already existing tools, but how about newly created ones? I would also be fine with some subscription to any changes in the Tool Shed in general. Best regards, Sarah ___ 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://usegalaxy.org http://galaxyproject.org/wiki/Support ___ 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] R scripts for DESeq
Lisa, In case you aren't aware, you can set your user preferences for your account in the tool shed to receive an email message when a new repository's first upload occurs. This would keep you from having to check the tool shed. Go to User - Preferences - Manage your email alerts and you'll see the following setting. inline: email_alert.tiff On Feb 22, 2012, at 8:50 PM, Liusong Yang wrote: Hi Vipin, That is a wonderful news and I am eager to see it in tool shed. I am going to check tool shed frequently these days to get it asap. Thanks Lisa On Wed, Feb 22, 2012 at 4:07 PM, Vipin TS vipin...@gmail.com wrote: Hi, We have the recent release version of DESeq at our Galaxy instance, http://galaxy.tuebingen.mpg.de/tool_runner?tool_id=deseq I will add the Galaxy wrapper for DESeq in community tool shed in few days. regards, --Vipin Hi Lisa, I am going to send your question over to the galaxy-...@bx.psu.edu mailing list so that the development community can offer feedback. http://wiki.g2.bx.psu.edu/Support#Starting_a_technical.2C_local.2BAC8-cloud_instance.2C_or_development_thread Th galaxy-user list is primarily for tool/data usage on the Galaxy public server. http://wiki.g2.bx.psu.edu/Mailing%20Lists Thanks, Jen Galaxy team Original Message Subject: [galaxy-user] R scripts for DESeq Date: Tue, 21 Feb 2012 23:25:35 -0500 From: Liusong Yang liusongyang2...@gmail.com To: galaxy-u...@lists.bx.psu.edu Hello, I am planning to put DESeq into galaxy. I am a newcomer for both Galaxy and R. I have already read all of the related discussion in this group. I also noticed that there are r_wrapper.sh and DESeq.xml added into galaxy recently under the path of tools. These lines are from r_wrapper.sh. ### Run R providing the R script in $1 as standard input and passing ### the remaining arguments on the command line I guess this means we need to give the DESeq R script to the wrapper as standard input. My question is where or what is the DESeq R scripts? I installed R and DESeq package, but I can not fund anything like DESeq.R or something similar? I feel so confusing now. Any comments or suggestions would be absolutely appreciated! Thanks Lisa ___ 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: http://lists.bx.psu.edu/listinfo/galaxy-dev 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/ ___ 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/
