Hey Eric, The connection string dialect is as follows for TCP/IP connections: dialect+driver://username:password@host:port/database
So, the host=/tmp is not necessary when are specifying a hostname (resolves to the IP) and a port because that is referring to UNIX sockets. If you were using SQL Alchemy with a unix socket to connect to the postgres server, then it would look something like this. "postgresql+psycopg2://user:password@/dbname?host=/var/lib/postgresql" Note that there's no hostname and port. Just the socket is specified. See http://docs.sqlalchemy.org/en/rel_0_9/core/engines.html for more info. Iyad Kandalaft Bioinformatics Programmer Microbial Biodiversity Bioinformatics Science & Technology Branch Agriculture & Agri-Food Canada iyad.kandal...@agr.gc.ca | (613) 759-1228 ________________________________________ From: galaxy-dev-boun...@lists.bx.psu.edu [galaxy-dev-boun...@lists.bx.psu.edu] on behalf of galaxy-dev-requ...@lists.bx.psu.edu [galaxy-dev-requ...@lists.bx.psu.edu] Sent: May 27, 2014 12:00 PM To: galaxy-dev@lists.bx.psu.edu Subject: galaxy-dev Digest, Vol 95, Issue 25 Send galaxy-dev mailing list submissions to galaxy-dev@lists.bx.psu.edu To subscribe or unsubscribe via the World Wide Web, visit http://lists.bx.psu.edu/listinfo/galaxy-dev or, via email, send a message with subject or body 'help' to galaxy-dev-requ...@lists.bx.psu.edu You can reach the person managing the list at galaxy-dev-ow...@lists.bx.psu.edu When replying, please edit your Subject line so it is more specific than "Re: Contents of galaxy-dev digest..." HEY! This is important! If you reply to a thread in a digest, please 1. Change the subject of your response from "Galaxy-dev Digest Vol ..." to the original subject for the thread. 2. Strip out everything else in the digest that is not part of the thread you are responding to. Why? 1. This will keep the subject meaningful. People will have some idea from the subject line if they should read it or not. 2. Not doing this greatly increases the number of emails that match search queries, but that aren't actually informative. Today's Topics: 1. Re: Problem using Galaxy with a PostgreSQL database on a remote host (Dannon Baker) 2. Changes in admin menu - Upload files (Julien Daligault) 3. Re: Changes in admin menu - Upload files (Dannon Baker) 4. Re: New tool on TestToolShed still not tested (Greg Von Kuster) 5. Re: New tool on TestToolShed still not tested (Peter Cock) 6. Re: Main ToolShed wrong report: Repository does not have a test-data directory. (Greg Von Kuster) 7. Re: Installation failure on Test Tool Shed (Greg Von Kuster) 8. Re: Old Tool Shed URL http://community.g2.bx.psu.edu/ dead (Greg Von Kuster) 9. Re: ToolShed: Uploaded archives can only include regular directories and files (Greg Von Kuster) 10. Re: Old Tool Shed URL http://community.g2.bx.psu.edu/ dead (Peter Cock) 11. Re: ToolShed: Uploaded archives can only include regular directories and files (Peter Cock) 12. Re: Old Tool Shed URL http://community.g2.bx.psu.edu/ dead (Greg Von Kuster) 13. Re: Problem using Galaxy with a PostgreSQL database on a remote host (Paniagua, Eric) 14. Uploading files to galaxy from a folder (Kandalaft, Iyad) 15. complex help for conditional param (Jun Fan) 16. Re: complex help for conditional param (Peter Cock) 17. Re: Problem using Galaxy with a PostgreSQL database on a remote host (Dannon Baker) 18. Re: Problem using Galaxy with a PostgreSQL database on a remote host (Paniagua, Eric) 19. Re: Problem using Galaxy with a PostgreSQL database on a remote host (Dannon Baker) ---------------------------------------------------------------------- Message: 1 Date: Tue, 27 May 2014 07:40:13 -0400 From: Dannon Baker <dannon.ba...@gmail.com> To: "Paniagua, Eric" <epani...@cshl.edu> Cc: "galaxy-dev@lists.bx.psu.edu" <galaxy-dev@lists.bx.psu.edu> Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host Message-ID: <cagn_wzn7wkihvyidhlovl0j4cbu_xeem02n1fkggo8bcnyc...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hey Eric, It looks like you have connection info for both tcp/ip connections and unix sockets in the connection strings. If you're logging in using "psql -h wigserv5.cshl.edu <snip>", then you only want the tcp/ip connection info. Drop the ?host=tmp off the third option you listed and I think you'll be up and running, so: postgresql://glxeric:xx...@wigserv5.cshl.edu:5432/glxeric -Dannon On Sat, May 24, 2014 at 1:49 AM, Paniagua, Eric <epani...@cshl.edu> wrote: > Dear Galaxy Developers, > > I've been banging my head against this one for a few days now. > > I have two Galaxy instances. One resides on a server called "genomics", > which also hosts the corresponding PostgreSQL installation. The second > also resides on "genomics", but its database is hosted on "wigserv5". > > Based on the tests I just ran and code I just read, sqlalchemy (not > Galaxy) is ignoring the hostname/port part of the database_connection > string. For reference, the connection strings I've tried are: > > postgresql://glxeric:XXXXX@/glxeric?host=/tmp > postgresql://glxeric:xx...@wigserv5.cshl.edu/glxeric?host=/tmp > postgresql://glxeric:xx...@wigserv5.cshl.edu:5432/glxeric?host=/tmp > postgresql://glxeric:XXXXX@adgdgdfdflkhjfdhfkl/glxeric?host=/tmp > > All of these appear to result in Galaxy connecting to the PostgreSQL > installation on genomics, as determined by Galaxy schema version > discrepancies and other constraints. With each connection string, Galaxy > starts up normally. I force database activity by browsing saved histories. > It works every time. By all appearances, the second Galaxy instance is > using the PostgreSQL database hosted on "genomics", not on "wigserv5". > > All databases and roles exist, and the databases are populated. > > When I comment out the "database_connection" line in universe_wsgi.ini, I > get errors arising from the later configuration of PostgreSQL-specific > Galaxy options, as expected. > > I can connect to the database server on "wigserv5" using "psql -h > wigserv5.cshl.edu -d glxeric -U glxeric" from the server "genomics". > > Have you ever observed this behavior from Galaxy or sqlalchemy? > > Thanks, > Eric > > ___________________________________________________________ > 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/ > > To search Galaxy mailing lists use the unified search at: > http://galaxyproject.org/search/mailinglists/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.bx.psu.edu/pipermail/galaxy-dev/attachments/20140527/d1888e84/attachment-0001.html> ------------------------------ Message: 2 Date: Mon, 26 May 2014 12:47:06 +0200 From: Julien Daligault <daliga...@ijm.univ-paris-diderot.fr> To: galaxy-dev@lists.bx.psu.edu Subject: [galaxy-dev] Changes in admin menu - Upload files Message-ID: <53831baa.1040...@ijm.univ-paris-diderot.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, I manage a galaxy instance on a local server and I want that users use only the "filesystem paths" to create a link to their data by the Admin Menu. Where can I find the source file to modify the web page in order to appear directly this option in first in the drop-down menu ? It will avoid to load directly big data on our computing machine. Thanks Julien -- Julien Daligault Plateforme G?nomique-Transcriptomique (583B) INSTITUT JACQUES MONOD CNRS-Universit? Paris Diderot B?t. Buffon - 15 rue H?l?ne Brion 75205 Paris Cedex 13 - France tel : +33 1 57 27 81 31 daliga...@ijm.univ-paris-diderot.fr ------------------------------ Message: 3 Date: Tue, 27 May 2014 09:29:36 -0400 From: Dannon Baker <dannon.ba...@gmail.com> To: Julien Daligault <daliga...@ijm.univ-paris-diderot.fr> Cc: Galaxy Dev <galaxy-dev@lists.bx.psu.edu> Subject: Re: [galaxy-dev] Changes in admin menu - Upload files Message-ID: <CAGn_WZkU=3cwvhb5vx8tyws8-pzkx2whbanzjejb1vgcehm...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Cross-post from biostar, answered there: https://biostar.usegalaxy.org/p/7747/#7760 On Mon, May 26, 2014 at 6:47 AM, Julien Daligault < daliga...@ijm.univ-paris-diderot.fr> wrote: > Hi, > > I manage a galaxy instance on a local server and I want that users use > only the "filesystem paths" to create a link to their data by the Admin > Menu. Where can I find the source file to modify the web page in order to > appear directly this option in first in the drop-down menu ? > It will avoid to load directly big data on our computing machine. > Thanks > > Julien > > -- > Julien Daligault > Plateforme G?nomique-Transcriptomique (583B) > INSTITUT JACQUES MONOD > CNRS-Universit? Paris Diderot > B?t. Buffon - 15 rue H?l?ne Brion > 75205 Paris Cedex 13 - France > tel : +33 1 57 27 81 31 > daliga...@ijm.univ-paris-diderot.fr > > ___________________________________________________________ > 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/ > > To search Galaxy mailing lists use the unified search at: > http://galaxyproject.org/search/mailinglists/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.bx.psu.edu/pipermail/galaxy-dev/attachments/20140527/4f383442/attachment-0001.html> ------------------------------ Message: 4 Date: Tue, 27 May 2014 10:05:16 -0400 From: Greg Von Kuster <g...@bx.psu.edu> To: Peter Cock <p.j.a.c...@googlemail.com> Cc: Galaxy Dev <galaxy-...@bx.psu.edu> Subject: Re: [galaxy-dev] New tool on TestToolShed still not tested Message-ID: <eb7f9ee7-ad8f-4d22-9258-150965d01...@bx.psu.edu> Content-Type: text/plain; charset=us-ascii Hello peter, I've looked inot this and discovered what I suspect is a problem with the buildbot configuration for the Tool Shed's install and test framework. The framework is executed in 2 stages where stage 1 installs and tests repositories that contain tool dependency packages, and stage 2 installs and test repositories that contain tools the require them. For the past few test runs, only stage 1 executes, so no repositories that contain tools are tested (this affects all stage 2 repositories, not just yours). The buildbot environment is Dave B's realm (I've not been involved in setting it up), so he'll have to take a look to see what may be the problem. Unfortunately, Dave is out of the lab this week, so we'll have to wait until next week to get this resolved. Sorry for the inconvenience on this, and the unfortunate timing with Dave being out. I've added the following Trello card for this issue: https://trello.com/c/YElEsCWl/208-install-and-test-framework-stage-2-does-not-run Greg Von Kuster On May 26, 2014, at 6:46 AM, Peter Cock <p.j.a.c...@googlemail.com> wrote: > Hi guys, > > I updated this new tool on Wednesday last week, but it still > has no functional test results: > > http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast_rbh > > Has it been excluded for some reason? If so, could some > indicator be shown (at least to the tool authors)? > > I looked over some of my other tools and the test dates > are quite variable. I thought you had gone from nightly > tests to every second night - but is the scheme now more > complex, or have there been technical difficulties? > > Thanks, > > 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/ > > To search Galaxy mailing lists use the unified search at: > http://galaxyproject.org/search/mailinglists/ ------------------------------ Message: 5 Date: Tue, 27 May 2014 15:23:15 +0100 From: Peter Cock <p.j.a.c...@googlemail.com> To: Greg Von Kuster <g...@bx.psu.edu> Cc: Galaxy Dev <galaxy-...@bx.psu.edu> Subject: Re: [galaxy-dev] New tool on TestToolShed still not tested Message-ID: <CAKVJ-_7pzvJ8C_wXjmh8k_VciXvrZbUjkKXNA-N84j=w2cm...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Thanks - I'll leave this until next week then. Peter On Tue, May 27, 2014 at 3:05 PM, Greg Von Kuster <g...@bx.psu.edu> wrote: > Hello peter, > > I've looked inot this and discovered what I suspect is a problem with > the buildbot configuration for the Tool Shed's install and test framework. > The framework is executed in 2 stages where stage 1 installs and tests > repositories that contain tool dependency packages, and stage 2 installs > and test repositories that contain tools the require them. For the past > few test runs, only stage 1 executes, so no repositories that contain > tools are tested (this affects all stage 2 repositories, not just yours). > The buildbot environment is Dave B's realm (I've not been involved in > setting it up), so he'll have to take a look to see what may be the problem. > Unfortunately, Dave is out of the lab this week, so we'll have to wait until > next week to get this resolved. > > Sorry for the inconvenience on this, and the unfortunate timing with Dave > being out. > > I've added the following Trello card for this issue: > > https://trello.com/c/YElEsCWl/208-install-and-test-framework-stage-2-does-not-run > > Greg Von Kuster > > > On May 26, 2014, at 6:46 AM, Peter Cock <p.j.a.c...@googlemail.com> wrote: > >> Hi guys, >> >> I updated this new tool on Wednesday last week, but it still >> has no functional test results: >> >> http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast_rbh >> >> Has it been excluded for some reason? If so, could some >> indicator be shown (at least to the tool authors)? >> >> I looked over some of my other tools and the test dates >> are quite variable. I thought you had gone from nightly >> tests to every second night - but is the scheme now more >> complex, or have there been technical difficulties? >> >> Thanks, >> >> 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/ >> >> To search Galaxy mailing lists use the unified search at: >> http://galaxyproject.org/search/mailinglists/ > ------------------------------ Message: 6 Date: Tue, 27 May 2014 10:31:50 -0400 From: Greg Von Kuster <g...@bx.psu.edu> To: Peter Cock <p.j.a.c...@googlemail.com> Cc: Galaxy Dev <galaxy-...@bx.psu.edu> Subject: Re: [galaxy-dev] Main ToolShed wrong report: Repository does not have a test-data directory. Message-ID: <baa62d61-2e21-4c9a-b61f-12848b957...@bx.psu.edu> Content-Type: text/plain; charset=us-ascii Hi Peter, I've looked into this as well and again believe it is caused by a problem in the buildbot configuration for the main Tool Shed's Install and Test framework. I've created the following Trello card for this, and we'll get it resolved when Dave B returns next week. https://trello.com/c/9mLrFhTJ/209-install-and-test-framework-does-not-locate-test-data-directory-for-repositories-on-main-tool-shed Greg Von Kuster On May 26, 2014, at 6:54 AM, Peter Cock <p.j.a.c...@googlemail.com> wrote: > Hi guys, > > I just noticed two of my tools on the main ToolShed were listed under > "Latest revision: missing tool tests" unexpectedly. > > http://toolshed.g2.bx.psu.edu/view/peterjc/sample_seqs > > Test runs > 2014-05-25 15:12:04 > Automated test environment > Tools missing tests or test data > Tool id: sample_seqs > Tool version: 0.0.1 > Tool guid: > toolshed.g2.bx.psu.edu/repos/peterjc/sample_seqs/sample_seqs/0.0.1 > Missing components: > Repository does not have a test-data directory. > 2014-05-13 01:43:51 > Automated test environment > Tests that passed successfully > Successful installations > 2014-05-11 01:38:18 > Automated test environment > Tests that passed successfully > Successful installations > 2014-05-09 01:43:58 > Automated test environment > Tests that passed successfully > Successful installations > 2014-05-07 01:55:08 > Automated test environment > Tests that passed successfully > Successful installations > > And, http://toolshed.g2.bx.psu.edu/view/peterjc/get_orfs_or_cdss > > Test runs > 2014-05-25 15:10:53 > Automated test environment > Tools missing tests or test data > Tool id: get_orfs_or_cdss > Tool version: 0.0.5 > Tool guid: > toolshed.g2.bx.psu.edu/repos/peterjc/get_orfs_or_cdss/get_orfs_or_cdss/0.0.5 > Missing components: > Repository does not have a test-data directory. > 2014-05-13 05:11:12 > Automated test environment > Tests that passed successfully > Successful installations > 2014-05-11 05:06:15 > Automated test environment > Tests that passed successfully > Successful installations > 2014-05-09 05:17:53 > Automated test environment > Tests that passed successfully > Successful installations > 2014-05-07 05:52:29 > Automated test environment > Tests that passed successfully > Successful installations > > In both cases the most recent test run (2014-05-25) has failed in some > way, and the ToolShed *wrongly* reports the repository does not have > a test-data directory. > > Regards, > > 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/ > > To search Galaxy mailing lists use the unified search at: > http://galaxyproject.org/search/mailinglists/ ------------------------------ Message: 7 Date: Tue, 27 May 2014 10:37:32 -0400 From: Greg Von Kuster <g...@bx.psu.edu> To: Peter Cock <p.j.a.c...@googlemail.com> Cc: "galaxy-dev@lists.bx.psu.edu" <galaxy-dev@lists.bx.psu.edu> Subject: Re: [galaxy-dev] Installation failure on Test Tool Shed Message-ID: <cddf73d8-4d64-4965-aa8c-6cfb9aa91...@bx.psu.edu> Content-Type: text/plain; charset=us-ascii Hi Peter, I've created the following Trello card for this - we'll take a look and get this resolved as soon as possible. https://trello.com/c/G5hZEajv/210-tool-dependency-installation-may-not-be-properly-handling-broken-package-urls Thanks for reporting this! Greg Von Kuster On May 21, 2014, at 7:00 AM, Peter Cock <p.j.a.c...@googlemail.com> wrote: > On Mon, May 12, 2014 at 11:40 AM, Peter Cock <p.j.a.c...@googlemail.com> > wrote: >> On Wed, May 7, 2014 at 3:01 PM, Peter Cock <p.j.a.c...@googlemail.com> wrote: >>> Hi Dave, >>> >>> Can you tell me any more about this failed tool dependency error: >>> http://testtoolshed.g2.bx.psu.edu/view/peterjc/mira4_assembler >>> >>> Installation errors >>> Tool dependencies >>> TypeNameVersion >>> MIRA package 4.0 >>> Error >>> File >>> "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/install_util.py", >>> line 345, in install_and_build_package_via_fabric tool_dependency = >>> fabric_util.install_and_build_package( app, tool_shed_repository, >>> tool_dependency, actions_dict ) File >>> "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/fabric_util.py", >>> line 93, in install_and_build_package initial_download=False ) File >>> "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/recipe/recipe_manager.py", >>> line 418, in execute_step initial_download=initial_download ) File >>> "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/recipe/step_handler.py", >>> line 1312, in execute_step return_output=False ) File >>> "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/recipe/recipe_manager.py", >>> line 247, in handle_command output = self.handle_complex_command( >>> command ) File >>> "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/recipe/recipe_manager.py", >>> line 287, in handle_complex_command cwd=state.env[ 'lcwd' ] ) File >>> "/usr/lib/python2.7/subprocess.py", line 711, in __init__ errread, >>> errwrite) File "/usr/lib/python2.7/subprocess.py", line 1308, in >>> _execute_child raise child_exception [Errno 2] No such file or >>> directory: >>> '/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/install_and_test_tool_shed_repositories/repositories_with_tools/tmp/tmpxFCguW/tmp-toolshed-mtdt0b857/MIRA' >>> >>> I presume this was a Python stack trace but the whitespace >>> has been lost when rendered as HTML. However, I don't quite >>> see what is going wrong here... >> >> Still failing. This is presumably something in my tool_dependencies.xml >> which is breaking... that defines <package name="MIRA" version="4.0"> >> >> I've recently been changing the download URL - is it possible that >> the ToolShed didn't catch a failed download? >> >> Thanks, >> >> Peter > > I'm pretty sure the above failure is down to a broken URL - due to > a change on the project files for MIRA, see: > http://www.freelists.org/post/mira_talk/Stable-download-URLs-on-sourceforge > > If I am right, then the ToolShed is not handling the failed download nicely? > > I've just updated this to download MIRA v4.0.2, so fingers crossed... > http://testtoolshed.g2.bx.psu.edu/view/peterjc/mira4_assembler > > 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/ > > To search Galaxy mailing lists use the unified search at: > http://galaxyproject.org/search/mailinglists/ ------------------------------ Message: 8 Date: Tue, 27 May 2014 10:39:59 -0400 From: Greg Von Kuster <g...@bx.psu.edu> To: Peter Cock <p.j.a.c...@googlemail.com> Cc: Galaxy Dev <galaxy-...@bx.psu.edu> Subject: Re: [galaxy-dev] Old Tool Shed URL http://community.g2.bx.psu.edu/ dead Message-ID: <5a622011-a841-4091-92bf-292a9de9b...@bx.psu.edu> Content-Type: text/plain; charset="us-ascii" Hi peter, It seems that we have stopped redirecting the old Tool Shed URL http://community.g2.bx.psu.edu/ to the new Tool Shed URL http://toolshed.g2.bx.psu.edu/ . I'm not sure when this happened. Sorry for the inconvenience. Greg Von Kuster On May 21, 2014, at 9:37 AM, Peter Cock <p.j.a.c...@googlemail.com> wrote: > Hi Greg, > > That Trello card link doesn't work for me, but the old domain is > currently not redirecting to the ToolShed. > > Regards, > > Peter > > > On Wed, Mar 6, 2013 at 12:32 PM, Greg Von Kuster <g...@bx.psu.edu> wrote: >> Hi Peter, >> >> I've added this to the same Trello card. These URL redirects lie outside of >> my control, so I'll bug the right person to get them set up. >> >> https://trello.com/card/toolshed-galaxyproject-org-url-redirects/506338ce32ae458f6d15e4b3/697 >> >> Thanks! >> >> >> On Mar 6, 2013, at 6:52 AM, Peter Cock wrote: >> >>> Hello all, >>> >>> Either I made a typo in some old README files, or the old >>> URL for the Tool Shed http://community.g2.bx.psu.edu/ has >>> stopped working. Could this redirect to the current Tool Shed >>> address http://toolshed.g2.bx.psu.edu/ please? >>> >>> Thanks, >>> >>> 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/ >> > ___________________________________________________________ > 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/ > > To search Galaxy mailing lists use the unified search at: > http://galaxyproject.org/search/mailinglists/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.bx.psu.edu/pipermail/galaxy-dev/attachments/20140527/ed0a92e5/attachment-0001.html> ------------------------------ Message: 9 Date: Tue, 27 May 2014 11:15:38 -0400 From: Greg Von Kuster <g...@bx.psu.edu> To: Peter Cock <p.j.a.c...@googlemail.com> Cc: Galaxy Dev <galaxy-...@bx.psu.edu> Subject: Re: [galaxy-dev] ToolShed: Uploaded archives can only include regular directories and files Message-ID: <da409cde-3d5d-4e5d-84d9-d97d6c9ce...@bx.psu.edu> Content-Type: text/plain; charset=us-ascii Hello Peter, This issue should be resolved in 13630:33b1ff4b9985, which is now running on the test Tool Shed. Thanks for reporting this! Greg Von Kuster On May 19, 2014, at 1:41 PM, Peter Cock <p.j.a.c...@googlemail.com> wrote: > Hi Greg, Dave, > > I just tried to upload an updated tar-ball to the Test ToolShed and > got a red error message: > > <quote> > Uploaded archives can only include regular directories and files (no > symbolic links, devices, etc). Offender: > </quote> > > Note no offending files were listed. When I double checked I had prepared > my tar-ball from the wrong source directory and it did contain symlinks, but > the Tool Shed error message failed to list these. > > Regards, > > 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/ > > To search Galaxy mailing lists use the unified search at: > http://galaxyproject.org/search/mailinglists/ ------------------------------ Message: 10 Date: Tue, 27 May 2014 16:16:45 +0100 From: Peter Cock <p.j.a.c...@googlemail.com> To: Greg Von Kuster <g...@bx.psu.edu> Cc: Galaxy Dev <galaxy-...@bx.psu.edu> Subject: Re: [galaxy-dev] Old Tool Shed URL http://community.g2.bx.psu.edu/ dead Message-ID: <cakvj-_49yt5f_n_bwqdq3cjb2kprgwerh88zpzxh2srjvcm...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 3:39 PM, Greg Von Kuster <g...@bx.psu.edu> wrote: > Hi peter, > > It seems that we have stopped redirecting the old Tool Shed URL > http://community.g2.bx.psu.edu/ to the new Tool Shed URL > http://toolshed.g2.bx.psu.edu/ . I'm not sure when this happened. > > Sorry for the inconvenience. > > Greg Von Kuster Can the old domain be restored to fix pre-existing 3rd party links? There could be some in published papers, certainly there are on the mailing list archives. Peter ------------------------------ Message: 11 Date: Tue, 27 May 2014 16:19:13 +0100 From: Peter Cock <p.j.a.c...@googlemail.com> To: Greg Von Kuster <g...@bx.psu.edu> Cc: Galaxy Dev <galaxy-...@bx.psu.edu> Subject: Re: [galaxy-dev] ToolShed: Uploaded archives can only include regular directories and files Message-ID: <CAKVJ-_6pLYtMXe1Eg1Y88YUFaAKssU8z=mjjtrwbmlzo4lo...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 4:15 PM, Greg Von Kuster <g...@bx.psu.edu> wrote: > Hello Peter, > > This issue should be resolved in 13630:33b1ff4b9985, which is now running on > the test Tool Shed. Thanks for reporting this! > > Greg Von Kuster Thanks - clearer error messages are a good thing :) Peter ------------------------------ Message: 12 Date: Tue, 27 May 2014 11:19:41 -0400 From: Greg Von Kuster <g...@bx.psu.edu> To: Peter Cock <p.j.a.c...@googlemail.com>, Nate Coraor <n...@bx.psu.edu> Cc: Galaxy Dev <galaxy-...@bx.psu.edu> Subject: Re: [galaxy-dev] Old Tool Shed URL http://community.g2.bx.psu.edu/ dead Message-ID: <3416eadd-41c9-429b-b888-6271c4459...@bx.psu.edu> Content-Type: text/plain; charset=us-ascii Peter, sorry, this one is "out of my hands". I'm hoping Nate can answer this when he gets a chance. Greg Von Kuster On May 27, 2014, at 11:16 AM, Peter Cock <p.j.a.c...@googlemail.com> wrote: > On Tue, May 27, 2014 at 3:39 PM, Greg Von Kuster <g...@bx.psu.edu> wrote: >> Hi peter, >> >> It seems that we have stopped redirecting the old Tool Shed URL >> http://community.g2.bx.psu.edu/ to the new Tool Shed URL >> http://toolshed.g2.bx.psu.edu/ . I'm not sure when this happened. >> >> Sorry for the inconvenience. >> >> Greg Von Kuster > > Can the old domain be restored to fix pre-existing 3rd party links? > There could be some in published papers, certainly there are on > the mailing list archives. > > Peter ------------------------------ Message: 13 Date: Tue, 27 May 2014 15:26:51 +0000 From: "Paniagua, Eric" <epani...@cshl.edu> To: Dannon Baker <dannon.ba...@gmail.com> Cc: "galaxy-dev@lists.bx.psu.edu" <galaxy-dev@lists.bx.psu.edu> Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host Message-ID: <759e5be3a1277b48adee4096e39269cbb222c...@ex-hs-mbx05.cshl.edu> Content-Type: text/plain; charset="iso-8859-1" Hey Dannon, Thanks for pointing that out! I missed it. I am now connecting to the remote database. I ran "sh manage_db.sh upgrade" and it upgraded from schema 114 to 118 without error messages. I then ran "sh ./scripts/migrate_tools/0010_tools.sh install_dependencies" and received the following error: Traceback (most recent call last): File "./scripts/migrate_tools/migrate_tools.py", line 21, in app = MigrateToolsApplication( sys.argv[ 1 ] ) File "/localdata1/galaxy/glxmaint/src/lib/tool_shed/galaxy_install/migrate/common.py", line 59, in __init__ install_dependencies=install_dependencies ) File "/localdata1/galaxy/glxmaint/src/lib/tool_shed/galaxy_install/install_manager.py", line 122, in __init__ is_repository_dependency=is_repository_dependency ) File "/localdata1/galaxy/glxmaint/src/lib/tool_shed/galaxy_install/install_manager.py", line 506, in install_repository is_repository_dependency=is_repository_dependency ) File "/localdata1/galaxy/glxmaint/src/lib/tool_shed/galaxy_install/install_manager.py", line 345, in handle_repository_contents guid = self.get_guid( repository_clone_url, relative_install_dir, tool_config ) File "/localdata1/galaxy/glxmaint/src/lib/tool_shed/galaxy_install/install_manager.py", line 253, in get_guid tool = self.toolbox.load_tool( full_path )! File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py", line 671, in load_tool return ToolClass( config_file, root, self.app, guid=guid, repository_id=repository_id, **kwds ) File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py", line 1045, in __init__ self.parse( root, guid=guid ) File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py", line 1260, in parse self.parse_inputs( root ) File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py", line 1351, in parse_inputs display, inputs = self.parse_input_page( page, enctypes ) File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py", line 1655, in parse_input_page inputs = self.parse_input_elem( input_elem, enctypes ) File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py", line 1723, in parse_input_elem case.inputs = self.parse_input_elem( case_elem, enctypes, context ) File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py", line 1679, in pa! rse_input_elem group.inputs = self.parse_input_elem( elem, enc! types, c ontext ) File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py", line 1751, in parse_input_elem param = self.parse_param_elem( elem, enctypes, context ) File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py", line 1764, in parse_param_elem param = ToolParameter.build( self, input_elem ) File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/parameters/basic.py", line 215, in build return parameter_types[param_type]( tool, param ) File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/parameters/basic.py", line 1566, in __init__ ToolParameter.__init__( self, tool, elem ) File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/parameters/basic.py", line 54, in __init__ self.validators.append( validation.Validator.from_element( self, elem ) ) File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/parameters/validation.py", line 23, in from_element return validator_types[type].from_element( param, elem ) File "/localdata1/galaxy/glxmaint/src/lib/galaxy/t! ools/parameters/validation.py", line 283, in from_element tool_data_table = param.tool.app.tool_data_tables[ table_name ] File "/localdata1/galaxy/glxmaint/src/lib/galaxy/tools/data/__init__.py", line 35, in __getitem__ return self.data_tables.__getitem__( key ) KeyError: 'gatk_picard_indexes' I fixed this by adding the appropriate entries to tool_data_table_conf.xml. I then reran the migrate_tools command successfully. However, now my "history_dataset_association" table in the database was blown away at some point. The table is now completely empty. Have you ever seen this before? Thanks, Eric ________________________________ From: Dannon Baker [dannon.ba...@gmail.com] Sent: Tuesday, May 27, 2014 7:40 AM To: Paniagua, Eric Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host Hey Eric, It looks like you have connection info for both tcp/ip connections and unix sockets in the connection strings. If you're logging in using "psql -h wigserv5.cshl.edu<http://wigserv5.cshl.edu> <snip>", then you only want the tcp/ip connection info. Drop the ?host=tmp off the third option you listed and I think you'll be up and running, so: postgresql://glxeric:xx...@wigserv5.cshl.edu:5432/glxeric<http://glxeric:xx...@wigserv5.cshl.edu:5432/glxeric> -Dannon On Sat, May 24, 2014 at 1:49 AM, Paniagua, Eric <epani...@cshl.edu<mailto:epani...@cshl.edu>> wrote: Dear Galaxy Developers, I've been banging my head against this one for a few days now. I have two Galaxy instances. One resides on a server called "genomics", which also hosts the corresponding PostgreSQL installation. The second also resides on "genomics", but its database is hosted on "wigserv5". Based on the tests I just ran and code I just read, sqlalchemy (not Galaxy) is ignoring the hostname/port part of the database_connection string. For reference, the connection strings I've tried are: postgresql://glxeric:XXXXX@/glxeric?host=/tmp postgresql://glxeric:xx...@wigserv5.cshl.edu/glxeric?host=/tmp<http://glxeric:xx...@wigserv5.cshl.edu/glxeric?host=/tmp> postgresql://glxeric:xx...@wigserv5.cshl.edu:5432/glxeric?host=/tmp<http://glxeric:xx...@wigserv5.cshl.edu:5432/glxeric?host=/tmp> postgresql://glxeric:XXXXX@adgdgdfdflkhjfdhfkl/glxeric?host=/tmp All of these appear to result in Galaxy connecting to the PostgreSQL installation on genomics, as determined by Galaxy schema version discrepancies and other constraints. With each connection string, Galaxy starts up normally. I force database activity by browsing saved histories. It works every time. By all appearances, the second Galaxy instance is using the PostgreSQL database hosted on "genomics", not on "wigserv5". All databases and roles exist, and the databases are populated. When I comment out the "database_connection" line in universe_wsgi.ini, I get errors arising from the later configuration of PostgreSQL-specific Galaxy options, as expected. I can connect to the database server on "wigserv5" using "psql -h wigserv5.cshl.edu<http://wigserv5.cshl.edu> -d glxeric -U glxeric" from the server "genomics". Have you ever observed this behavior from Galaxy or sqlalchemy? Thanks, Eric ___________________________________________________________ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ------------------------------ Message: 14 Date: Tue, 27 May 2014 15:28:36 +0000 From: "Kandalaft, Iyad" <iyad.kandal...@agr.gc.ca> To: "galaxy-dev@lists.bx.psu.edu" <galaxy-dev@lists.bx.psu.edu> Subject: [galaxy-dev] Uploading files to galaxy from a folder Message-ID: <ca1994d763c7444cb37efc823d43c3823ec8c...@onottaxes1.agr.gc.ca> Content-Type: text/plain; charset="iso-8859-1" Hi Everyone I'm throwing this out there for some feedback and recommendations. Objective: Facilitate transferring large files (> 2GB) from an HPC cluster (and its associated fast tier storage) to galaxy for my clients. I enabled the FTP upload option in galaxy but it involves users learning to copy files over FTP. So, I created a galaxy folder in each users' home directory on the HPC Cluster that symbolically links to the FTP upload folder for galaxy. Hence, users can use either FTP to upload files (drag and drop in windows) or simply copy files into this folder from an ssh session on the cluster. The problem with that strategy was that galaxy had to be the owner of the file (similar to the ProFTPd configuration that sets the UID and GID of uploads files to galaxy's UID/GID). Otherwise, galaxy threw errors when it tried deleting the original file from the FTP upload folder. I could have added the galaxy user to the same group as all user but this meant that users would have to ensure the correct permissions are set on files so that galaxy can read and delete the file thereafter. The alternative involved modifying the upload.py tool to chown/chmod files that were being uploaded. Upload.py now sudo executes an external script that sets ownership to the galaxy user and corrects the! permissions if required (see attachment for code modification). The galaxy user has sudo rights on this script and the script restricts chown/chmod to the ftp folder path for security reasons. I was planning to clean up the code and make it production ready by adding an option in universe_wsgi.ini for this "feature", but I thought I would check with the galaxy devs first. Am I taking the wrong approach? Is there a better alternative? As an alternative, I thought about locating the handler code for dataset.type == file and possibly making it support the SETGID sticky bits on folders. In that case, the FTP upload folder would have the sticky bit set for UID and can assume the role of the user to upload that file. Your input is much appreciated. Iyad Kandalaft Bioinformatics Application Developer Agriculture and Agri-Food Canada | Agriculture et Agroalimentaire Canada KW Neatby Bldg | ?d. KW Neatby 960 Carling Ave| 960, avenue Carling Ottawa, ON | Ottawa (ON) K1A 0C6 E-mail Address / Adresse courriel: iyad.kandal...@agr.gc.ca<mailto:iyad.kandal...@agr.gc.ca> Telephone | T?l?phone 613- 759-1228 Facsimile | T?l?copieur 613-759-1701 Government of Canada | Gouvernement du Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.bx.psu.edu/pipermail/galaxy-dev/attachments/20140527/e769f2fd/attachment-0001.html> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: upload diff.txt.txt URL: <http://lists.bx.psu.edu/pipermail/galaxy-dev/attachments/20140527/e769f2fd/attachment-0001.txt> ------------------------------ Message: 15 Date: Tue, 27 May 2014 15:32:00 +0000 From: Jun Fan <j....@qmul.ac.uk> To: "galaxy-dev@lists.bx.psu.edu" <galaxy-dev@lists.bx.psu.edu> Subject: [galaxy-dev] complex help for conditional param Message-ID: <480ed8fc2641416fb705ea56e7d47...@dbxpr07mb286.eurprd07.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Hi all, In the conditional param, when sub-element allows you to write specific parameters for a particular value selected. I am wondering how to write the help context according to the value selection. For example, if there is a conditional param called blast_type, when "blastn" is selected, the help context will be "blast dna against dna" and when "blastp" is selected, the help context will be "blast protein against protein". Basically this selection-based help text provides a general description of the selection, which could help to set up the corresponding parameters. By the way, is there any document about formatting text in the help element? Best regards! Jun -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.bx.psu.edu/pipermail/galaxy-dev/attachments/20140527/3edf0e28/attachment-0001.html> ------------------------------ Message: 16 Date: Tue, 27 May 2014 16:39:49 +0100 From: Peter Cock <p.j.a.c...@googlemail.com> To: Jun Fan <j....@qmul.ac.uk> Cc: "galaxy-dev@lists.bx.psu.edu" <galaxy-dev@lists.bx.psu.edu> Subject: Re: [galaxy-dev] complex help for conditional param Message-ID: <CAKVJ-_5et8XCaHmmM4K2=bxyrrtsjqkewbjsw+anvrehpf2...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Tue, May 27, 2014 at 4:32 PM, Jun Fan <j....@qmul.ac.uk> wrote: > Hi all, > > > > In the conditional param, when sub-element allows you to write > specific parameters for a particular value selected. I am wondering how to > write the help context according to the value selection. For example, if > there is a conditional param called blast_type, when ?blastn? is selected, > the help context will be ?blast dna against dna? and when ?blastp? is > selected, the help context will be ?blast protein against protein?. > Basically this selection-based help text provides a general description of > the selection, which could help to set up the corresponding parameters. > > By the way, is there any document about formatting text in the help > element? > > Best regards! > > Jun You can do this kind of thing with one-line Cheetah syntax within the output XML tag, but it quickly gets very complicated. e.g. https://github.com/peterjc/pico_galaxy/commit/3991893c6ee2cc69c33aaa391bbed412c85fa9db Peter ------------------------------ Message: 17 Date: Tue, 27 May 2014 11:43:45 -0400 From: Dannon Baker <dannon.ba...@gmail.com> To: "Paniagua, Eric" <epani...@cshl.edu> Cc: "galaxy-dev@lists.bx.psu.edu" <galaxy-dev@lists.bx.psu.edu> Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host Message-ID: <CAGn_WZkeCwQt7q1S=EcP-mDKKmj8UrU_XWatKDHzGL=np_xh=w...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Tue, May 27, 2014 at 11:26 AM, Paniagua, Eric <epani...@cshl.edu> wrote: > Thanks for pointing that out! I missed it. I am now connecting to the > remote database. I ran "sh manage_db.sh upgrade" and it upgraded from > schema 114 to 118 without error messages. I then ran "sh > ./scripts/migrate_tools/0010_tools.sh install_dependencies" and received > the following error: > > line 35, in __getitem__ return self.data_tables.__getitem__( key ) > KeyError: 'gatk_picard_indexes' > > I fixed this by adding the appropriate entries to > tool_data_table_conf.xml. I then reran the migrate_tools command > successfully. However, now my "history_dataset_association" table in the > database was blown away at some point. The table is now completely empty. > Have you ever seen this before? > I have not seen the tool migration issue before, but it seems harmless. The fact that your history_dataset_association table is empty is concerning if there was ever anything in it. Can you verify that there are datasets in the same database that *should* be associated to a history? It sounds like this galaxy instance has been used with different databases, and my hope is that the wires are crossed up here and there actually should not be any. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.bx.psu.edu/pipermail/galaxy-dev/attachments/20140527/f528387d/attachment-0001.html> ------------------------------ Message: 18 Date: Tue, 27 May 2014 15:48:19 +0000 From: "Paniagua, Eric" <epani...@cshl.edu> To: Dannon Baker <dannon.ba...@gmail.com> Cc: "galaxy-dev@lists.bx.psu.edu" <galaxy-dev@lists.bx.psu.edu> Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host Message-ID: <759e5be3a1277b48adee4096e39269cbb222c...@ex-hs-mbx05.cshl.edu> Content-Type: text/plain; charset="iso-8859-1" The "dataset" table is populated. I looked at the SQL dump file I used to copy the database, and it has create table and copy into statements for history_dataset_association, but it looks like there may have been an error while executing them. Trying to figure out how to get my data in... ________________________________ From: Dannon Baker [dannon.ba...@gmail.com] Sent: Tuesday, May 27, 2014 11:43 AM To: Paniagua, Eric Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host On Tue, May 27, 2014 at 11:26 AM, Paniagua, Eric <epani...@cshl.edu<mailto:epani...@cshl.edu>> wrote: Thanks for pointing that out! I missed it. I am now connecting to the remote database. I ran "sh manage_db.sh upgrade" and it upgraded from schema 114 to 118 without error messages. I then ran "sh ./scripts/migrate_tools/0010_tools.sh install_dependencies" and received the following error: line 35, in __getitem__ return self.data_tables.__getitem__( key ) KeyError: 'gatk_picard_indexes' I fixed this by adding the appropriate entries to tool_data_table_conf.xml. I then reran the migrate_tools command successfully. However, now my "history_dataset_association" table in the database was blown away at some point. The table is now completely empty. Have you ever seen this before? I have not seen the tool migration issue before, but it seems harmless. The fact that your history_dataset_association table is empty is concerning if there was ever anything in it. Can you verify that there are datasets in the same database that *should* be associated to a history? It sounds like this galaxy instance has been used with different databases, and my hope is that the wires are crossed up here and there actually should not be any. ------------------------------ Message: 19 Date: Tue, 27 May 2014 11:58:30 -0400 From: Dannon Baker <dannon.ba...@gmail.com> To: "Paniagua, Eric" <epani...@cshl.edu> Cc: "galaxy-dev@lists.bx.psu.edu" <galaxy-dev@lists.bx.psu.edu> Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host Message-ID: <cagn_wznm3zxmvfvd0fktuq-bss-xmq-px5mxpdm-je2r44o...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Since the database has lost consistency, I'd really try a fresh pg_dump / import if that's possible. If there's an error this time around, note it and send it on over and we can figure out where to go from there. On Tue, May 27, 2014 at 11:48 AM, Paniagua, Eric <epani...@cshl.edu> wrote: > The "dataset" table is populated. I looked at the SQL dump file I used to > copy the database, and it has create table and copy into statements for > history_dataset_association, but it looks like there may have been an error > while executing them. Trying to figure out how to get my data in... > ________________________________ > From: Dannon Baker [dannon.ba...@gmail.com] > Sent: Tuesday, May 27, 2014 11:43 AM > To: Paniagua, Eric > Cc: galaxy-dev@lists.bx.psu.edu > Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database > on a remote host > > On Tue, May 27, 2014 at 11:26 AM, Paniagua, Eric <epani...@cshl.edu > <mailto:epani...@cshl.edu>> wrote: > Thanks for pointing that out! I missed it. I am now connecting to the > remote database. I ran "sh manage_db.sh upgrade" and it upgraded from > schema 114 to 118 without error messages. I then ran "sh > ./scripts/migrate_tools/0010_tools.sh install_dependencies" and received > the following error: > > line 35, in __getitem__ return self.data_tables.__getitem__( key ) > KeyError: 'gatk_picard_indexes' > > I fixed this by adding the appropriate entries to > tool_data_table_conf.xml. I then reran the migrate_tools command > successfully. However, now my "history_dataset_association" table in the > database was blown away at some point. The table is now completely empty. > Have you ever seen this before? > > I have not seen the tool migration issue before, but it seems harmless. > The fact that your history_dataset_association table is empty is > concerning if there was ever anything in it. Can you verify that there are > datasets in the same database that *should* be associated to a history? It > sounds like this galaxy instance has been used with different databases, > and my hope is that the wires are crossed up here and there actually should > not be any. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.bx.psu.edu/pipermail/galaxy-dev/attachments/20140527/789f64f0/attachment-0001.html> ------------------------------ _______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ End of galaxy-dev Digest, Vol 95, Issue 25 ****************************************** ___________________________________________________________ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
