Thank you for the reference!

That does indeed solve the problem.

Thanks,
Eric


-------- Original message --------
From: "Kandalaft, Iyad"
Date:2014/05/28 08:48 (GMT-05:00)
To: galaxy-dev@lists.bx.psu.edu,"Paniagua, Eric"
Subject: Re: Problem using Galaxy with a PostgreSQL database on a remote host 
(Dannon Baker)

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/

Reply via email to