date:20130213

I got this error which executing tophat2 in Galaxy:

Error in tophat:

[2013-02-13 02:02:43] Beginning TopHat run (v2.0.7)
---
[2013-02-13 02:02:43] Checking for Bowtie
  Bowtie version:2.0.6.0
[2013-02-13 02:02:43] Checking for Samtools
Samtools version:0.1.18.0
[2013-02-13 02:02:43] Checking for Bowtie index files
Error: Could not find Bowtie 2 index files
(/data/bowtie2-2.0.6/hg19/Homo_sapiens/Homo_sapiens/UCSC/hg19/Sequence/Bowtie2Index/.*.bt2)

The tool produced the following additional output:

TopHat v2.0.7
tophat2 -p 4  
/data/bowtie2-2.0.6/hg19/Homo_sapiens/Homo_sapiens/UCSC/hg19/Sequence/Bowtie2Index/
/opt/galaxyprod/galaxy-dist/database/files/000/dataset_197.dat

I have these files under the Index directory:

genome.1.bt2  genome.2.bt2  genome.3.bt2  genome.4.bt2  genome.fa
genome.rev.1.bt2  genome.rev.2.bt2  tophat_out
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Error when trying to change the permissions in data libraries.

2013-02-13 Thread Christos Kannas

Hi,

The problem has been solved.
There was a corruption within a user's email address, there was a character
that could not be decoded so it caused errors with permissions and the
datasets the user had uploaded.

--
Chris


On Fri, Feb 8, 2013 at 3:59 PM, galaxy-dev-requ...@lists.bx.psu.edu wrote:

 From: Christos Kannas chriskan...@gmail.com
 To: galaxy-dev@lists.bx.psu.edu
 Cc:
 Date: Fri, 8 Feb 2013 14:35:25 +0200
 Subject: [galaxy-dev] Error when trying to change the permissions in data
 libraries.
 Hi,

 In our local Galaxy server an error came up today.
 When I try to edit the permissions of data librarles via the Admin panel I
 get the following error:
 (Also attached is an image of the following error)

 UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0:
 ordinal not in range(128)

 URL:
 http://lisis.cs.ucy.ac.cy/library_common/library_permissions?show_deleted=Falsecntrller=library_adminuse_panels=Falseid=0174dcff8bad94a7
 File
 '/home/galaxy/galaxy-dist/eggs/WebError-0.8a-py2.6.egg/weberror/evalexception/middleware.py',
 line 364 in respond
   app_iter = self.application(environ, detect_start_response)
 File
 '/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/debug/prints.py',
 line 98 in __call__
   environ, self.app)
 File '/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/wsgilib.py',
 line 539 in intercept_output
   app_iter = application(environ, replacement_start_response)
 File
 '/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/recursive.py',
 line 80 in __call__
   return self.application(environ, start_response)
 File
 '/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py',
 line 632 in __call__
   return self.application(environ, start_response)
 File '/home/galaxy/galaxy-dist/lib/galaxy/web/framework/base.py', line 160
 in __call__
   body = method( trans, **kwargs )
 File
 '/home/galaxy/galaxy-dist/lib/galaxy/webapps/galaxy/controllers/library_common.py',
 line 262 in library_permissions
   status=status )
 File '/home/galaxy/galaxy-dist/lib/galaxy/web/framework/__init__.py', line
 832 in fill_template
   return self.fill_template_mako( filename, **kwargs )
 File '/home/galaxy/galaxy-dist/lib/galaxy/web/framework/__init__.py', line
 843 in fill_template_mako
   return template.render( **data )
 File
 '/home/galaxy/galaxy-dist/eggs/Mako-0.4.1-py2.6.egg/mako/template.py', line
 296 in render
   return runtime._render(self, self.callable_, args, data)
 File '/home/galaxy/galaxy-dist/eggs/Mako-0.4.1-py2.6.egg/mako/runtime.py',
 line 660 in _render
   **_kwargs_for_callable(callable_, data))
 File '/home/galaxy/galaxy-dist/eggs/Mako-0.4.1-py2.6.egg/mako/runtime.py',
 line 692 in _render_context
   _exec_template(inherit, lclcontext, args=args, kwargs=kwargs)
 File '/home/galaxy/galaxy-dist/eggs/Mako-0.4.1-py2.6.egg/mako/runtime.py',
 line 718 in _exec_template
   callable_(context, *args, **kwargs)
 File '/home/galaxy/galaxy-dist/database/compiled_templates/base.mako.py',
 line 42 in render_body
   __M_writer(unicode(next.body()))
 File '/home/galaxy/galaxy-dist/database/compiled_templates/library/common/
 library_permissions.mako.py', line 76 in render_body
   __M_writer(unicode(render_permission_form( library, library.name,
 h.url_for( controller='library_common', action='library_permissions',
 cntrller=cntrller, id=trans.security.encode_id( library.id ),
 show_deleted=show_deleted ), roles, do_not_render=[], all_roles=all_roles
 )))
 File '/home/galaxy/galaxy-dist/database/compiled_templates/dataset/
 security_common.mako.py', line 108 in render_render_permission_form
   __M_writer(unicode(render_select( current_actions, k, v, all_roles )))
 File '/home/galaxy/galaxy-dist/database/compiled_templates/dataset/
 security_common.mako.py', line 34 in render_select
   return
 render_render_select(context,current_actions,action_key,action,roles)
 File '/home/galaxy/galaxy-dist/database/compiled_templates/dataset/
 security_common.mako.py', line 190 in render_render_select
   __M_writer(unicode(role.name))
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0:
 ordinal not in range(128)

 We are using a modified version of Galaxy.
 The info from hg (latest galaxy-dist we have pulled):

 changeset:   7828:b5bda7a5c345
 user:Nate Coraor n...@bx.psu.edu
 date:Fri Oct 05 15:49:26 2012 -0400
 summary: Fix the Compute tool to only allow for execution of a limited
 set of expressions.

 What we have to do to fix it?

 Thanks,
 Christos

 --

 Christos Kannas
 Researcher
 Ph.D Student

 e-Health Laboratory http://www.medinfo.cs.ucy.ac.cy/
 kannas.chris...@ucy.ac.cy
 kannas.chris...@cs.ucy.ac.cy
 chriskan...@gmail.com

 ...




-- 

Christos Kannas
Researcher
Ph.D Student

e-Health Laboratory http://www.medinfo.cs.ucy.ac.cy/
kannas.chris...@ucy.ac.cy
kannas.chris...@cs.ucy.ac.cy
chriskan...@gmail.com

Mob: (+357) 99530608
___
Please keep all replies

Re: [galaxy-dev] hg19 reference gnome for Tophat2

 Shall I replace:
 
 /orig/path/hg19hg19hg19
 /depot/data2/galaxy/bowtie2/hg19/hg19
 
 with
 
 hg19   hg19hg19   Homo_sapiens/UCSC/hg19/Sequence/Bowtie2Index

Yes, that's correct.

Finally, please email only galaxy-dev with questions about local installations; 
galaxy-user is for questions about how to use Galaxy.

Best,
J.


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] hg19 reference gnome for Tophat2


 Also, do I have make all the reference files executable? 

No, that's not necessary.

Best,
J.
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] hg19 reference gnome for Tophat2

Ok sorry. I did that, but the output of splice junctions is empty. The
other outputs looks fine. What might be the problem?

Thanks,

Sachit

On Wed, Feb 13, 2013 at 1:20 PM, Jeremy Goecks jeremy.goe...@emory.eduwrote:

  Shall I replace:
 
  /orig/path/hg19hg19hg19
  /depot/data2/galaxy/bowtie2/hg19/hg19
 
  with
 
  hg19   hg19hg19   Homo_sapiens/UCSC/hg19/Sequence/Bowtie2Index

 Yes, that's correct.

 Finally, please email only galaxy-dev with questions about local
 installations; galaxy-user is for questions about how to use Galaxy.

 Best,
 J.


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Error executing tophat2

 Error in tophat:
 
 [2013-02-13 02:02:43] Beginning TopHat run (v2.0.7)
 ---
 [2013-02-13 02:02:43] Checking for Bowtie
 Bowtie version:2.0.6.0
 [2013-02-13 02:02:43] Checking for Samtools
   Samtools version:0.1.18.0
 [2013-02-13 02:02:43] Checking for Bowtie index files
 Error: Could not find Bowtie 2 index files 
 (/data/bowtie2-2.0.6/hg19/Homo_sapiens/Homo_sapiens/UCSC/hg19/Sequence/Bowtie2Index/.*.bt2)
 The tool produced the following additional output:
 TopHat v2.0.7
 tophat2 -p 4  
 /data/bowtie2-2.0.6/hg19/Homo_sapiens/Homo_sapiens/UCSC/hg19/Sequence/Bowtie2Index/
  /opt/galaxyprod/galaxy-dist/database/files/000/dataset_197.dat
 I have these files under the Index directory:
 genome.1.bt2  genome.2.bt2  genome.3.bt2  genome.4.bt2  genome.fa  
 genome.rev.1.bt2  genome.rev.2.bt2  tophat_out

Your path to your indices should like like this:

/data/bowtie2-2.0.6/hg19/Homo_sapiens/Homo_sapiens/UCSC/hg19/Sequence/Bowtie2Index/genome

Best,
J.

___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] hg19 reference gnome for Tophat2

If the other outputs are fine, then the problem is likely with your data and/or 
your Tophat settings.

Good luck,
J.

On Feb 13, 2013, at 8:22 AM, Sachit Adhikari wrote:

 Ok sorry. I did that, but the output of splice junctions is empty. The other 
 outputs looks fine. What might be the problem?
 
 Thanks,
 
 Sachit
 
 On Wed, Feb 13, 2013 at 1:20 PM, Jeremy Goecks jeremy.goe...@emory.edu 
 wrote:
  Shall I replace:
 
  /orig/path/hg19hg19hg19
  /depot/data2/galaxy/bowtie2/hg19/hg19
 
  with
 
  hg19   hg19hg19   Homo_sapiens/UCSC/hg19/Sequence/Bowtie2Index
 
 Yes, that's correct.
 
 Finally, please email only galaxy-dev with questions about local 
 installations; galaxy-user is for questions about how to use Galaxy.
 
 Best,
 J.
 
 

___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] hg clone link on news brief incorrect

On Feb 12, 2013, at 11:23 PM, Anthonius deBoer wrote:

 I think the hg clone link on the news brief is incorrect:
 
 it states:  hg clone https://bitbucket.org/galaxy-dist#stable
 
 Probably should be hg clone https://bitbucket.org/galaxy/galaxy-dist#stable

Thanks for catching that, Thon.  It's been fixed.

--nate

 
 Thon
 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:
 
  http://lists.bx.psu.edu/

___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Circster save just hangs

I will try to reproduce. In the meantime, can you please check the JavaScript 
console and forward along any errors that you see?

Thanks,
J.

On Feb 12, 2013, at 11:15 PM, Anthonius deBoer wrote:

 Hi,
 
 I had created a trackster vizualization that had not finished indexing yet, 
 and I decided to change it into a circster visualization.
 I then added a few more BAM files and tried to save the visualization and now 
 it just hangs there...
 
 no errors in the logs so far, but no saving of the visualization either...
 
 Thon
 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:
 
  http://lists.bx.psu.edu/


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Error executing tophat2

Thanks, that's what I was missing.

On Wed, Feb 13, 2013 at 7:09 PM, Jeremy Goecks jeremy.goe...@emory.eduwrote:

 Error in tophat:

 [2013-02-13 02:02:43] Beginning TopHat run (v2.0.7)
 ---
 [2013-02-13 02:02:43] Checking for Bowtie
 Bowtie version:2.0.6.0
 [2013-02-13 02:02:43] Checking for Samtools
   Samtools version:0.1.18.0
 [2013-02-13 02:02:43] Checking for Bowtie index files
 Error: Could not find Bowtie 2 index files 
 (/data/bowtie2-2.0.6/hg19/Homo_sapiens/Homo_sapiens/UCSC/hg19/Sequence/Bowtie2Index/.*.bt2)

 The tool produced the following additional output:

 TopHat v2.0.7
 tophat2 -p 4  
 /data/bowtie2-2.0.6/hg19/Homo_sapiens/Homo_sapiens/UCSC/hg19/Sequence/Bowtie2Index/
  /opt/galaxyprod/galaxy-dist/database/files/000/dataset_197.dat

 I have these files under the Index directory:

 genome.1.bt2  genome.2.bt2  genome.3.bt2  genome.4.bt2  genome.fa  
 genome.rev.1.bt2  genome.rev.2.bt2  tophat_out


 Your path to your indices should like like this:


 /data/bowtie2-2.0.6/hg19/Homo_sapiens/Homo_sapiens/UCSC/hg19/Sequence/Bowtie2Index/
 *genome*
 *
 *
 Best,
 J.


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Still seeing this CRITICAL message in the logs when its trying to delete the working directories

On Jan 30, 2013, at 2:51 PM, Anthonius deBoer wrote:

 Hi,
 
 I continue to see this error in the logs, every time a jobs finishes:
 
 galaxy.objectstore CRITICAL 2013-01-30 11:42:14,161 
 /mnt/ngs/analysis/svcgalaxy/DATA/job_working_directory/000/327 delete
 error [Errno 39] Directory not empty: 
 '/mnt/ngs/analysis/svcgalaxy/DATA/job_working_directory/000/327'
 
 When I check the directory, it is of course empty:
 
 $ls -la /mnt/ngs/analysis/svcgalaxy/DATA/job_working_directory/000/327
 total 68
 drwxrwsr-x   2 svcgalaxy Domain Linux Users0 Jan 30 11:42 .
 drwxrwsr-x 283 svcgalaxy Domain Linux Users 5793 Jan 30 11:45 .. 
 
 Any ideas why this keeps happening?
 I end up with thousands of directories in the working directories which I 
 need to clean out manually now...

Hi Thon,

You'll probably need to add a debug statement to the code that outputs the 
contents of that directory at the time of attempted deletion.   The call to 
delete() is in the cleanup() method in lib/galaxy/jobs/__init__.py.

--nate

 
 Thanks
 
 Thon
 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:
 
  http://lists.bx.psu.edu/


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Changing job command line.

On Feb 4, 2013, at 6:03 PM, James Boocock wrote:

 Hi All,
 
 I am currently working on a clustering interface for galaxy that will
 hopefully enable users to pick the grid
 in the tool form.
 
 With tools that need access to files within the galaxy directory, I
 have an idea to create a symlinked
 fake galaxy root with all the files the tools needs for galaxy. This
 is done currently in my own xml format
 for each grid.
 
 Problem is when parsing a tool_wrapper variable I need to prepare the
 job and add my additional commands
 to the command line so that the fake galaxy dir is created with the
 symlinked databases.
 
 Is it bad practice to disable preparation in each tool runner if the
 job has come from my clustering module
 or is there a better way to do this. Will the job runners
 wrapper.prepare() overwrite any of my changes to the command-line
 when the job makes its way to the runner say local.py.

Hi James,

You'll probably need to make the changes to the command line after the command 
line has been assembled in prepare().  Can you do this later in prepare()?

--nate

 
 
 Cheers James.
 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:
 
  http://lists.bx.psu.edu/


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Problem to upload files to Galaxy

2013-02-13 Thread Carl Eberhard

Hello, Roy
There was a recent fix for this. Is this problem still occurring for you?

Thanks,
Carl


On Thu, Jan 31, 2013 at 10:17 PM, Blum, Roy roy.b...@nyumc.org wrote:

   Dear Galaxy support,

  In the last 24 hours we are unable to load files to the Galaxy server.
 We tried doing so as guest and by login as users but failed.
 We try to load a small file (about 1M) but so far no success.
 Has the Galaxy server been experienced problems recently?

  Thanks a lot,
 Roy
  *___*
 *Roy Blum, Ph.D. *
 New York University School of Medicine,
 Cancer Institute, Smilow Research Building,
 11th Floor, Room 1106
 552 First Ave.
 New York, NY, 10016
 Mob:   +1 (646) 716-2875
 Lab:+1 (212) 263-6169
 *http://blumroy.googlepages.com*

 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:

   http://lists.bx.psu.edu/

___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Error with local toolshed and remote user authentication: HTTPError: HTTP Error 401: Authorization Required

On Feb 5, 2013, at 4:29 PM, Carlos Borroto wrote:

 Hi,
 
 I would like to use Apache LDAP to authenticate a local toolshed.
 Configuring community_wsgi.ini wasn't a problem and I can now login
 into the local toolshed with my institution active directory
 credentials. The same way I do for the local Galaxy. I did have to add
 remote_user_maildomain as it wasn't there and I needed it. Maybe this
 is something that could be added in the next release.
 
 The problem is when I try to install a tool from this toolshed I get:
 
 URL: 
 http://galaxy-bfx.brel.local/admin_toolshed/prepare_for_install?tool_shed_url=http://toolshed-bfx.brel.local/repository_ids=ee9b707789bf4714changeset_revisions=3cc82d4e406c
 File 
 '/local/opt/galaxy/galaxy-dist/eggs/WebError-0.8a-py2.6.egg/weberror/evalexception/middleware.py',
 line 364 in respond
  app_iter = self.application(environ, detect_start_response)
 File 
 '/local/opt/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/debug/prints.py',
 line 98 in __call__
  environ, self.app)
 File 
 '/local/opt/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/wsgilib.py',
 line 539 in intercept_output
  app_iter = application(environ, replacement_start_response)
 File 
 '/local/opt/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/recursive.py',
 line 80 in __call__
  return self.application(environ, start_response)
 File 
 '/local/opt/galaxy/galaxy-dist/lib/galaxy/web/framework/middleware/remoteuser.py',
 line 91 in __call__
  return self.app( environ, start_response )
 File 
 '/local/opt/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py',
 line 632 in __call__
  return self.application(environ, start_response)
 File '/local/opt/galaxy/galaxy-dist/lib/galaxy/web/framework/base.py',
 line 160 in __call__
  body = method( trans, **kwargs )
 File '/local/opt/galaxy/galaxy-dist/lib/galaxy/web/framework/__init__.py',
 line 208 in decorator
  return func( self, trans, *args, **kwargs )
 File 
 '/local/opt/galaxy/galaxy-dist/lib/galaxy/webapps/galaxy/controllers/admin_toolshed.py',
 line 1177 in prepare_for_install
  response = urllib2.urlopen( url )
 File '/usr/lib64/python2.6/urllib2.py', line 126 in urlopen
  return _opener.open(url, data, timeout)
 File '/usr/lib64/python2.6/urllib2.py', line 397 in open
  response = meth(req, response)
 File '/usr/lib64/python2.6/urllib2.py', line 510 in http_response
  'http', request, response, code, msg, hdrs)
 File '/usr/lib64/python2.6/urllib2.py', line 435 in error
  return self._call_chain(*args)
 File '/usr/lib64/python2.6/urllib2.py', line 369 in _call_chain
  result = func(*args)
 File '/usr/lib64/python2.6/urllib2.py', line 518 in http_error_default
  raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
 HTTPError: HTTP Error 401: Authorization Required
 
 
 Is there any trick I could do with Apache to let this go through?
 
 
 This is my current Apache configuration:
 
 VirtualHost *:80
ServerAdmin carlos.borr...@gmail.com
ServerName toolshed-bfx.brel.local:80
 
Proxy http://localhost:9009
Order deny,allow
Allow from all
/Proxy
RewriteEngine on
Location /
AuthName Galaxy Toolshed BFX
AuthType Basic
AuthBasicAuthoritative off
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthLDAPURL
 ldap://ad.brel.local/OU=BREL,DC=brel,DC=local?sAMAccountName?sub;
AuthLDAPBindDN MASKED
AuthLDAPBindPassword MASKED

Hi Carlos,

You'll need something here like:

Satisfy Any
Order deny,allow
Deny from all
Allow from your.galaxy.server

--nate

Require valid-user
# Set the REMOTE_USER header to the contents of the LDAP query
 response's uid attribute
RequestHeader set REMOTE_USER %{AUTHENTICATE_sAMAccountName}e
 
XSendFile on
XSendFilePath /
/Location
RewriteRule ^/static/style/(.*)
 /local/opt/galaxy/galaxy-dist/static/june_2007_style/blue/$1 [L]
RewriteRule ^/static/scripts/(.*)
 /local/opt/galaxy/galaxy-dist/static/scripts/packed/$1 [L]
RewriteRule ^/static/(.*) /local/opt/galaxy/galaxy-dist/static/$1 [L]
RewriteRule ^/favicon.ico
 /local/opt/galaxy/galaxy-dist/static/favicon.ico [L]
RewriteRule ^/robots.txt /local/opt/galaxy/galaxy-dist/static/robots.txt 
 [L]
RewriteRule ^(.*) http://localhost:9009$1 [P]
 
ErrorLog logs/toolshed-bfx.brel.local-error_log
CustomLog logs/toolshed-bfx.brel.local-access_log common
 /VirtualHost
 
 As always any help will be highly appreciated,
 Thanks,
 Carlos
 ___
 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

Re: [galaxy-dev] Uploading a Directory of Files - IOError: [Errno 28] No space left on device

On Feb 7, 2013, at 2:29 PM, greg wrote:

 I think I found the problem.  The TMPDIR environment variable was set
 to /tmp/5393732.1.f03.q for jobs galaxy was running. (I guess the
 admins do this?)

SGE does this to create a job-specific temporary directory that it can clean up 
after each job terminates.

 I updated /usr/local/galaxy/job_environment_setup_file and also
 /home/galaxy/.bashrc to set TMPDIR to /scratch/galaxy and it seems to
 work now.

Great, thanks for letting us know.

--nate

 
 Thanks for the help.
 
 -Greg
 
 On Thu, Feb 7, 2013 at 1:19 PM, greg margeem...@gmail.com wrote:
 Could I modify /misc/local/galaxy/galaxy-dist/lib/galaxy/datatypes/sniff.py
 to print out debug information like host, os.environ,
 tempfile.gettempdir(), etc?
 
 Would I be able to see its stdout from galaxy or the log, or is there
 something special I need to do to retrieve the information?
 
 On Thu, Feb 7, 2013 at 1:12 PM, greg margeem...@gmail.com wrote:
 Update:
 
 When I run as the Galaxy user, Python does have the right temp directory:
 
 tempfile.gettempdir()
 '/scratch/galaxy'
 
 So does that mean this upload job isn't running as galaxy, or is
 skipping the job_environment_setup_file?  Or could something else be
 going on?
 
 Any ideas, now I'm really stuck.
 
 Thanks,
 
 Greg
 
 
 
 On Wed, Feb 6, 2013 at 3:35 PM, greg margeem...@gmail.com wrote:
 Ok, when I ran Python in my last two emails I was running as myself,
 not the galaxy user, and only the galaxy user has write permission to
 /scratch/galaxy
 
 So that's why Python was ignoring /scratch/galaxy for me.  If it
 doesn't have write access it tries the next temp directory in its
 list.
 
 I'm going to try debugging as the galaxy user next.
 
 -Greg
 
 On Wed, Feb 6, 2013 at 3:21 PM, greg margeem...@gmail.com wrote:
 Hi Nate,
 
 I don't see $TMPDIR being set on the cluster, in addition to my
 previous email I ran:
 
 print os.environ.keys()
 ['KDE_IS_PRELINKED', 'FACTERLIB', 'LESSOPEN', 'SGE_CELL', 'LOGNAME',
 'USER', 'INPUTRC', 'QTDIR', 'PATH', 'PS1', 'LANG', 'KDEDIR', 'TERM',
 'SHELL', 'TEMP', 'QTINC', 'G_BROKEN_FILENAMES', 'SGE_EXECD_PORT',
 'HISTSIZE', 'KDE_NO_IPV6', 'MANPATH', 'HOME', 'SGE_ROOT', 'QTLIB',
 'VIRTUAL_ENV', 'SGE_CLUSTER_NAME', '_', 'SSH_CONNECTION', 'SSH_TTY',
 'HOSTNAME', 'SSH_CLIENT', 'SHLVL', 'PWD', 'MAIL', 'LS_COLORS',
 'SGE_QMASTER_PORT']
 
 But I think we've narrowed it down to something interfering with
 Python deciding the temp file location.  I just can't figure out what.
 
 
 
 On Wed, Feb 6, 2013 at 3:18 PM, Nate Coraor n...@bx.psu.edu wrote:
 On Feb 6, 2013, at 3:00 PM, greg wrote:
 
 Thanks Nate,
 
 It turns out I already had this as the first line of my job setup file:
 
 export TEMP=/scratch/galaxy
 
 But when I look in that directory, there's plenty of free space, and I
 also don't see any recent files there.  So I'm wondering if the upload
 jobs aren't seeing that for some reason.
 
 Any ideas on how I could diagnose this more?
 
 Hi Greg,
 
 The first place to look would be in lib/galaxy/datatypes/sniff.py, line 
 96:
 
fd, temp_name = tempfile.mkstemp()
 
 If you print temp_name, that will tell you what file the upload tool is 
 writing to.  You may also want to take a look at:
 
http://docs.python.org/2/library/tempfile.html#tempfile.tempdir
 
 Some cluster environments set $TMPDIR, and if that is set, $TEMP will 
 not be used.
 
 --nate
 
 
 -Greg
 
 
 Relevant info?
 
 
 grep env galaxy-dist/universe_wsgi.ini
 environment_setup_file = /usr/local/galaxy/job_environment_setup_file
 
 cat /usr/local/galaxy/job_environment_setup_file
 export TEMP=/scratch/galaxy
 #active Python virtual env just for galaxy
 source /usr/local/galaxy/galaxy_python/bin/activate
 ... path setup lines ...
 
 
 
 
 
 
 
 
 
 
 On Wed, Feb 6, 2013 at 2:37 PM, Nate Coraor n...@bx.psu.edu wrote:
 On Feb 6, 2013, at 2:32 PM, greg wrote:
 
 Hi guys,
 
 When I try to upload a directory of files from a server directory I'm
 seeing the error below.
 
 It appears to be trying to write to a temp directory somewhere that
 I'm guessing doesn't have enough space?  Is there a way I can direct
 where it writes to for temporary files like this?
 
 Hi Greg,
 
 There are a few ways.  For some parts of Galaxy, you will want to set 
 new_file_path in universe_wsgi.ini to a suitable temp space.  However, 
 this is not the case for the upload tool.
 
 Am I understanding right, that these upload jobs are running on our
 cluster?  I think it would be a problem if its trying to use the
 default temp directory on each cluster node since they aren't
 provisioned with much space.
 
 This is correct.  On the cluster, add something to your user's shell 
 startup files (or see the environment_setup_file option in 
 universe_wsgi.ini) that will set the $TEMP or $TMPDIR environment 
 variable to a suitable temp space.
 
 --nate
 
 
 Please advise.
 
 Thanks,
 
 Greg
 
 
 
 Miscellaneous information:Traceback (most recent call last): File

Re: [galaxy-dev] Reloading a tools configuration does not seem to actually work

On Feb 7, 2013, at 2:43 PM, Anthonius deBoer wrote:

 That's very unfortunate...
 I have a ton of tools and I guess now I have to create a package for them in 
 a local toolshed to update them in a running galaxy server?
 
 In any case...The toolshed installation also does not work for me...I still 
 have to restart galaxy, even after using the toolshed approach to install a 
 tool...It either does not show up at all or give a bunch of errors, about not 
 being able to find the tool...
 
 Is this also related to the fact I have two webservers and am behind a proxy 
 server as well?

Hi Thon,

Essentially yes, there is no way for one web process to communicate with others 
that it has installed a tool.  We'd like to allow for this sort of notification 
via a message queue, but we don't have a proper message queue in Galaxy right 
now.

--nate

 
 Thon
 
 On Feb 07, 2013, at 05:29 AM, Dannon Baker dannonba...@me.com wrote:
 
 Unfortunately not, and with the migration of tools to the toolshed 
 installation mechanism I don't imagine this will be addressed (at least by 
 the team) anytime soon. If you wanted you could probably write a script that 
 would reload a specified tool in each of the separate web processes, or just 
 implement a complete rolling restart of your web processes to avoid service 
 disruption while still loading the tool updates.
 
 -Dannon
 
 
 On Feb 6, 2013, at 8:40 PM, Anthonius deBoer thondeb...@me.com wrote:
 
  I am indeed using multiple web processes and I guess I am talking about 
  the old admine tool reloader...
  Is there any other way to do this for your own tools that you just 
  manually place in tools etc.?
  
  Thon
  
  On Feb 05, 2013, at 06:22 PM, Dannon Baker dannonba...@me.com wrote:
  
  Are you using multiple web processes, and are you referring to the old 
  admin tool reloader or the toolshed reloading interface?
  
  -Dannon
  
  On Feb 5, 2013, at 9:13 PM, Anthonius deBoer thondeb...@me.com wrote:
  
   Hi,
   
   I find that reloading a tool's configuration file does not really work.
   First, you have to click the reload buttow twice to actually have it 
   update the VERSION number (so it does read something)...
   But when I try to run my tool, the old bug is still there...
   
   I am using proxy server so something may still be cached, but I have to 
   restart my server for it actually to pick up the changes...
   
   Any ideas?
   
   Thon
   ___
   Please keep all replies on the list by using reply all
   in your mail client. To manage your subscriptions to this
   and other Galaxy lists, please use the interface at:
   
   http://lists.bx.psu.edu/
  
 
 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:
 
  http://lists.bx.psu.edu/


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Environment variables reset after manually restarting Galaxy

On Feb 11, 2013, at 7:48 AM, Joachim Jacob |VIB| wrote:

 Hello all,
 
 
 After a *reboot* of our Galaxy server, the environment variables are set 
 correctly.
 
 However, after *restarting* the Galaxy process on a running server, by 
 logging in as Galaxy and running the init script on CentOS as service 
 galaxyd restart, the environment variables seems to be messed up

Hi Joachim,

It seems odd you'd be logging in as Galaxy to restart the process.  Since the 
system is going to run the init script as root, you should do this as well when 
you restart it.  Presumably whatever init script you are using is properly 
switching to the galaxy user to start the server process(es).

--nate

 
 After this manual Galaxy restart, some tools are not found, apparently caused 
 by a modification of the environment variable PATH. Can somebody provide me 
 perhaps with insight on what is causing this, and how to avoid this?
 
 My environment variables are set in /etc/profile.d/galaxy_environment_setup 
 (which is a symbolic link to   - /home/galaxy/environment_setup )
 
 
 Thanks,
 Joachim
 
 -- 
 Joachim Jacob
 
 Rijvisschestraat 120, 9052 Zwijnaarde
 Tel: +32 9 244.66.34
 Bioinformatics Training and Services (BITS)
 http://www.bits.vib.be
 @bitsatvib
 
 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:
 
 http://lists.bx.psu.edu/


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Error with local toolshed and remote user authentication: HTTPError: HTTP Error 401: Authorization Required

2013-02-13 Thread Carlos Borroto

On Wed, Feb 13, 2013 at 10:38 AM, Nate Coraor n...@bx.psu.edu wrote:
 You'll need something here like:

 Satisfy Any
 Order deny,allow
 Deny from all
 Allow from your.galaxy.server

Thanks Nate!, this worked flawlessly. My work around was to point
galaxy to the toolshed paster server at localhost:9009 instead of
apache in tool_sheds_conf.xml. This is a much better solution thou.

Thanks again,
Carlos
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Datasets linked into Galaxy do not work

On Feb 12, 2013, at 11:17 AM, Sarah Diehl wrote:

Hi all,

I have problems with datasets that were linked into Galaxy data libraries (as
Admin: Add datasets, select Upload files from filesystem paths and Link
to files without copying to Galaxy). Those files cannot be looked at,
downloaded or viewed in a genome browser.

Errors in the browser are:
The requested URL /datasets/126e6c4f4c2d468e/display/ was not found on this
server.
The requested URL /library_common/download_dataset_from_folder was not found
on this server.
An error occurred while accessing:
http://galaxy.immunbio.mpg.de/display_application/7108f175b5be4900/igv_bam/local_default/d85d47a3ee6ecd54/data/galaxy_7108f175b5be4900.bam
Read error; BinaryCodec in readmode; streamed file (filename not available)

I don't see any errors in the log files.

We do this kind of linking a lot and everything worked fine in the past. I
need to use this feature and need it to work, due to hard disk space and data
duplication.

Hi Sarah,

Do display applications work correctly for datasets that were uploaded to a
library and copied in to Galaxy rather than linked? Do you run Galaxy from the
server root (http://galaxy.immunbio.mpg.de/) or some path underneath the root?

Thanks,
--nate

Any help is appreciated.

Best regards,
Sarah
___
Please keep all replies on the list by using reply all
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/

___
Please keep all replies on the list by using reply all
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/

Re: [galaxy-dev] Problems linking Data inside Galaxy

On Feb 12, 2013, at 10:49 AM, Gaueko Erge wrote:

 Hi,
 
 I have followed, carefully, the instructions posted 
 in:http://wiki.galaxyproject.org/Admin/Data%20Integration
 
 Yet, despite my best efforts when I get, say all exons from hg19 build and 
 try to their fetch sequences, galaxy tells me that the sequences for hg19 are 
 not there
 
 I find this surprising because I have downloaded:
 
 rsync://datacache.g2.bx.psu.edu/indexes/
 rsync://hgdownload.cse.ucsc.edu/gbdb/
 rsync://hgdownload.cse.ucsc.edu/goldenPath/vicPac1/bigZips
 
 databases and added the correct paths to the 'alignseq.loc' file

Hi Gaueko,

It'd be helpful if you could provide us with the entry from your alignseq.loc 
file.  Also, you may want to verify that your alignseq.loc contains only tabs 
between the fields, not spaces.

--nate

 
 Any ideas will be appreciated
 
 Thanks
 
 --G
 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:
 
  http://lists.bx.psu.edu/


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Error with local toolshed and remote user authentication: HTTPError: HTTP Error 401: Authorization Required

2013-02-13 Thread Carlos Borroto

On Wed, Feb 13, 2013 at 2:11 PM, Carlos Borroto
carlos.borr...@gmail.com wrote:
 On Wed, Feb 13, 2013 at 10:38 AM, Nate Coraor n...@bx.psu.edu wrote:
 You'll need something here like:

 Satisfy Any
 Order deny,allow
 Deny from all
 Allow from your.galaxy.server

 Thanks Nate!, this worked flawlessly. My work around was to point
 galaxy to the toolshed paster server at localhost:9009 instead of
 apache in tool_sheds_conf.xml. This is a much better solution thou.


Oops, I spoke to soon. This does solve the access issue from the
apache side, but then the toolshed is expecting a remote user and will
answer with a message in a red box and a HTTP/1.1 403. This is the
red box message:

Access to this Galaxy tool shed is denied

This Galaxy tool shed is configured to authenticate users via an
external method (such as HTTP authentication in Apache), but a
username was not provided by the upstream (proxy) server. This is
generally due to a misconfiguration in the upstream server.

Contact your local Galaxy tool shed administrator.

It took me a while to realize this was the problem. I though I was
doing something wrong with the apache configuration. I confirmed it by
manually trying to access the URL I saw in the logs getting a
HTTP/1.1 403 from a host I had in Allow from 

BTW the work around I mentioned will fail as well. I though I was
using it but in reality I had use_remote_user turned off. Testing too
many combinations got me a little confuse on what works and what
doesn't.

In summary, I'm missing something here or I don't think there is
currently a functional way of turning on remote user with the
toolshed.

Thanks,
Carlos
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Error with local toolshed and remote user authentication: HTTPError: HTTP Error 401: Authorization Required

2013-02-13 Thread Greg Von Kuster

Carlos,

Sorry you're having difficulty here.  I'm not able to help very much here 
because I'm not familiar with the Galaxy remote user authentication process and 
I don't have an environment in which to mess with it.  

In case it helps, however, the Tool Shed uses the same code for remote user 
authentication as Galaxy does, so if you have gotten this to work for a Galaxy 
instance, you should be able to use the same configuration for the Tool Shed.

Greg Von Kuster

On Feb 13, 2013, at 3:00 PM, Carlos Borroto wrote:

 On Wed, Feb 13, 2013 at 2:11 PM, Carlos Borroto
 carlos.borr...@gmail.com wrote:
 On Wed, Feb 13, 2013 at 10:38 AM, Nate Coraor n...@bx.psu.edu wrote:
 You'll need something here like:
 
Satisfy Any
Order deny,allow
Deny from all
Allow from your.galaxy.server
 
 Thanks Nate!, this worked flawlessly. My work around was to point
 galaxy to the toolshed paster server at localhost:9009 instead of
 apache in tool_sheds_conf.xml. This is a much better solution thou.
 
 
 Oops, I spoke to soon. This does solve the access issue from the
 apache side, but then the toolshed is expecting a remote user and will
 answer with a message in a red box and a HTTP/1.1 403. This is the
 red box message:
 
 Access to this Galaxy tool shed is denied
 
 This Galaxy tool shed is configured to authenticate users via an
 external method (such as HTTP authentication in Apache), but a
 username was not provided by the upstream (proxy) server. This is
 generally due to a misconfiguration in the upstream server.
 
 Contact your local Galaxy tool shed administrator.
 
 It took me a while to realize this was the problem. I though I was
 doing something wrong with the apache configuration. I confirmed it by
 manually trying to access the URL I saw in the logs getting a
 HTTP/1.1 403 from a host I had in Allow from 
 
 BTW the work around I mentioned will fail as well. I though I was
 using it but in reality I had use_remote_user turned off. Testing too
 many combinations got me a little confuse on what works and what
 doesn't.
 
 In summary, I'm missing something here or I don't think there is
 currently a functional way of turning on remote user with the
 toolshed.
 
 Thanks,
 Carlos
 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:
 
  http://lists.bx.psu.edu/


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

[galaxy-dev] jobs don't get killed when histories deleted?

Hi,I am continue to struggle with the proccess of killing jobs that run on the SGE cluster when deleting histories.I would assume that jobs get removed from the queue when a history they are part of is deleted but in most cases, the jobs stay on the cluster and are not killedI also never have been able to get the kill jobs in the admin section to work (using the 8-Feb version)...It just sites there, returns and the jobs are still there on the cluster and still there in the databaseIs there anything in the database I can do to really kick out those jobs?ThanksThon
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Circster save just hangs

I'm getting this in the console...SharedContentScript::onBackgroundPageMessage: init {"oktaDomain":{},"settings":{"pluginFormFillCaptureEnabled":false},"matchedFullCredSitesNoPw":[]} log.js:1Uncaught TypeError: Cannot call method 'get' of undefined circster:6Uncaught TypeError: Cannot call method 'set' of undefined circster:25Failed to load resource: the server responded with a status of 500 (Internal Server Error) http://srv151/api/datasets/251653b1722255b8?data_type=genome_dataFailed to load resource: the server responded with a status of 500 (Internal Server Error) http://srv151/api/datasets/0ee5c74dd2bafd2c?data_type=genome_dataFailed to load resource: the server responded with a status of 500 (Internal Server Error) http://srv151/api/datasets/afa56ed7242d6156?data_type=genome_dataUncaught ReferenceError: view is not defined On Feb 13, 2013, at 06:00 AM, Jeremy Goecks jeremy.goe...@emory.edu wrote:I will try to reproduce. In the meantime, can you please check the _javascript_ console and forward along any errors that you see?  Thanks, J.  On Feb 12, 2013, at 11:15 PM, Anthonius deBoer wrote:   Hi,I had created a trackster vizualization that had not finished indexing yet, and I decided to change it into a circster visualization.  I then added a few more BAM files and tried to save the visualization and now it just hangs there...no errors in the logs so far, but no saving of the visualization either...Thon  ___  Please keep all replies on the list by using "reply all"  in your mail client. To manage your subscriptions to this  and other Galaxy lists, please use the interface at:http://lists.bx.psu.edu/ ___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Error with local toolshed and remote user authentication: HTTPError: HTTP Error 401: Authorization Required

2013-02-13 Thread Carlos Borroto

On Wed, Feb 13, 2013 at 3:10 PM, Greg Von Kuster g...@bx.psu.edu wrote:
 Carlos,

 Sorry you're having difficulty here.  I'm not able to help very much here 
 because I'm not familiar with the Galaxy remote user authentication process 
 and I don't have an environment in which to mess with it.

 In case it helps, however, the Tool Shed uses the same code for remote user 
 authentication as Galaxy does, so if you have gotten this to work for a 
 Galaxy instance, you should be able to use the same configuration for the 
 Tool Shed.


Hi Greg,

Maybe I should explain myself better here and also create a trello
card to check progress on this issue.

When you activate use_remote_user in the Tool Shed and correctly
configure your web server(ex. Apache), everything will work as in
Galaxy. You will get presented with an Apache basic authentication box
and you will get access Tool Shed as expected. Every single feature in
the Tool Shed works perfectly as far as I can tell.

Where is the problem them?. Well, it is when you try to install a tool
from the Tool Shed in a Galaxy instance. When Galaxy tries to clone
the mercurial repository from the Tool Shed it gets a HTTP/1.1 403.
Even so if you made sure Apache will allow unrestricted access from
the Galaxy host. You still get HTTP/1.1 403 from the Tool Shed, as
the Tools Shed is expecting a remote user header the Galaxy instance
is not providing.

I'm not so sure what is the best way to approach this issue. I see two
possibilities thou. Galaxy will have to provide a remote user header,
maybe assume the Galaxy user is the same as the Tool Shed, a good
guess I think, or the Tool Shed would have to allow access to
/repositories/ even if there is no a remote user in the header.
Again, I don't know if either of these options are technically
possible or safe to use.

Thanks for looking into this,
Carlos
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Error with local toolshed and remote user authentication: HTTPError: HTTP Error 401: Authorization Required

2013-02-13 Thread Greg Von Kuster

Thanks Carlos,

I've added the following Trello card for this:

https://trello.com/card/toolshed-problems-installing-a-repository-from-the-tool-shed-into-galaxy-if-using-remote-user-authentication/506338ce32ae458f6d15e4b3/622

Greg Von Kuster

On Feb 13, 2013, at 3:25 PM, Carlos Borroto wrote:

On Wed, Feb 13, 2013 at 3:10 PM, Greg Von Kuster g...@bx.psu.edu wrote:
Carlos,

Sorry you're having difficulty here. I'm not able to help very much here
because I'm not familiar with the Galaxy remote user authentication process
and I don't have an environment in which to mess with it.

In case it helps, however, the Tool Shed uses the same code for remote user
authentication as Galaxy does, so if you have gotten this to work for a
Galaxy instance, you should be able to use the same configuration for the
Tool Shed.

Hi Greg,

Maybe I should explain myself better here and also create a trello
card to check progress on this issue.

When you activate use_remote_user in the Tool Shed and correctly
configure your web server(ex. Apache), everything will work as in
Galaxy. You will get presented with an Apache basic authentication box
and you will get access Tool Shed as expected. Every single feature in
the Tool Shed works perfectly as far as I can tell.

Where is the problem them?. Well, it is when you try to install a tool
from the Tool Shed in a Galaxy instance. When Galaxy tries to clone
the mercurial repository from the Tool Shed it gets a HTTP/1.1 403.
Even so if you made sure Apache will allow unrestricted access from
the Galaxy host. You still get HTTP/1.1 403 from the Tool Shed, as
the Tools Shed is expecting a remote user header the Galaxy instance
is not providing.

I'm not so sure what is the best way to approach this issue. I see two
possibilities thou. Galaxy will have to provide a remote user header,
maybe assume the Galaxy user is the same as the Tool Shed, a good
guess I think, or the Tool Shed would have to allow access to
/repositories/ even if there is no a remote user in the header.
Again, I don't know if either of these options are technically
possible or safe to use.

Thanks for looking into this,
Carlos

___
Please keep all replies on the list by using reply all
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/

Re: [galaxy-dev] Reloading a tools configuration does not seem to actually work

Would this problem go away if I only used ONE webserver in my proxy setting and not use a balancer?I may not need it and if it means I could not use the toolshed effectively, it may be worth it not to use balancing..What i really need is the manager being balanced, since submitting a workflow with 100's of BAM files can take hours just to get started...ANy change we can run multiple managers?ThanksOn Feb 13, 2013, at 07:59 AM, Nate Coraor n...@bx.psu.edu wrote:On Feb 7, 2013, at 2:43 PM, Anthonius deBoer wrote:   That's very unfortunate...  I have a ton of tools and I guess now I have to create a package for them in a local toolshed to update them in a running galaxy server?In any case...The toolshed installation also does not work for me...I still have to restart galaxy, even after using the toolshed approach to install a tool...It either does not show up at all or give a bunch of errors, about not being able to find the tool...Is this also related to the fact I have two webservers and am behind a proxy server as well?  Hi Thon,  Essentially yes, there is no way for one web process to communicate with others that it has installed a tool. We'd like to allow for this sort of notification via a message queue, but we don't have a proper message queue in Galaxy right now.  --nate ThonOn Feb 07, 2013, at 05:29 AM, Dannon Baker dannonba...@me.com wrote:Unfortunately not, and with the migration of tools to the toolshed installation mechanism I don't imagine this will be addressed (at least by the team) anytime soon. If you wanted you could probably write a script that would reload a specified tool in each of the separate web processes, or just implement a complete rolling restart of your web processes to avoid service disruption while still loading the tool updates.-Dannon  On Feb 6, 2013, at 8:40 PM, Anthonius deBoer thondeb...@me.com wrote: I am indeed using multiple web processes and I guess I am talking about the "old" admine tool reloader...   Is there any other way to do this for your own tools that you just manually place in tools etc.?  Thon  On Feb 05, 2013, at 06:22 PM, Dannon Baker dannonba...@me.com wrote:  Are you using multiple web processes, and are you referring to the old admin tool reloader or the toolshed reloading interface?  -Dannon  On Feb 5, 2013, at 9:13 PM, Anthonius deBoer thondeb...@me.com wrote:   Hi,I find that reloading a tool's configuration file does not really work.First, you have to click the reload buttow twice to actually have it update the VERSION number (so it does read something)...But when I try to run my tool, the old bug is still there...I am using proxy server so something may still be cached, but I have to restart my server for it actually to pick up the changes...Any ideas?Thon___Please keep all replies on the list by using "reply all"in your mail client. To manage your subscriptions to thisand other Galaxy lists, please use the interface at:http://lists.bx.psu.edu/   ___  Please keep all replies on the list by using "reply all"  in your mail client. To manage your subscriptions to this  and other Galaxy lists, please use the interface at:http://lists.bx.psu.edu/ ___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

[galaxy-dev] Exception seen in update_manager.py; global name 'suc' is not defined

Hi,I see this in the log file...this really "suc"ks :)ThonException in thread Thread-1:Traceback (most recent call last): File "/usr/lib64/python2.6/threading.py", line 532, in __bootstrap_inner  self.run() File "/usr/lib64/python2.6/threading.py", line 484, in run  self.__target(*self.__args, **self.__kwargs) File "/mnt/ngs/analysis/svcgalaxy/galaxy-dist/lib/galaxy/tool_shed/update_manager.py", line 28, in __restarter  if self.check_for_update( repository ): File "/mnt/ngs/analysis/svcgalaxy/galaxy-dist/lib/galaxy/tool_shed/update_manager.py", line 37, in check_for_update  tool_shed_url = suc.get_url_from_repository_tool_shed( self.app, repository )NameError: global name 'suc' is not defined___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Exception seen in update_manager.py; global name 'suc' is not defined

2013-02-13 Thread Greg Von Kuster

Hello Thon,

This has been fixed in change set 8840:dde899d789b6.

Greg Von Kuster

On Feb 13, 2013, at 4:24 PM, Anthonius deBoer wrote:

 Hi,
 
 I see this in the log file...
 
 this really sucks :)
 
 Thon
 
 Exception in thread Thread-1:
 Traceback (most recent call last):
   File /usr/lib64/python2.6/threading.py, line 532, in __bootstrap_inner
 self.run()
   File /usr/lib64/python2.6/threading.py, line 484, in run
 self.__target(*self.__args, **self.__kwargs)
   File 
 /mnt/ngs/analysis/svcgalaxy/galaxy-dist/lib/galaxy/tool_shed/update_manager.py,
  line 28, in __restarter
 if self.check_for_update( repository ):
   File 
 /mnt/ngs/analysis/svcgalaxy/galaxy-dist/lib/galaxy/tool_shed/update_manager.py,
  line 37, in check_for_u
 pdate
 tool_shed_url = suc.get_url_from_repository_tool_shed( self.app, 
 repository )
 NameError: global name 'suc' is not defined
 
 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:
 
  http://lists.bx.psu.edu/


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Reloading a tools configuration does not seem to actually work

On Feb 13, 2013, at 4:12 PM, Anthonius deBoer wrote:

 Would this problem go away if I only used ONE webserver in my proxy setting 
 and not use a balancer?
 I may not need it and if it means I could not use the toolshed effectively, 
 it may be worth it not to use balancing..

No, because your manager/handlers will still need to be restarted to pick up 
the new tools.  The only way you can have it work without restarting is to have 
everything in a single process.

 What i really need is the manager being balanced, since submitting a workflow 
 with 100's of BAM files can take hours just to get started...ANy change we 
 can run multiple managers?

I'm surprised the manager is the holdup here since all it does is assign a 
handler.  Regardless, in the development branch (which will be the next 
stable/release branch), the manager has been killed, and handlers are assigned 
directly by the web processes.

--nate

 
 Thanks
 
 On Feb 13, 2013, at 07:59 AM, Nate Coraor n...@bx.psu.edu wrote:
 
 On Feb 7, 2013, at 2:43 PM, Anthonius deBoer wrote:
 
  That's very unfortunate...
  I have a ton of tools and I guess now I have to create a package for them 
  in a local toolshed to update them in a running galaxy server?
  
  In any case...The toolshed installation also does not work for me...I 
  still have to restart galaxy, even after using the toolshed approach to 
  install a tool...It either does not show up at all or give a bunch of 
  errors, about not being able to find the tool...
  
  Is this also related to the fact I have two webservers and am behind a 
  proxy server as well?
 
 Hi Thon,
 
 Essentially yes, there is no way for one web process to communicate with 
 others that it has installed a tool. We'd like to allow for this sort of 
 notification via a message queue, but we don't have a proper message queue 
 in Galaxy right now.
 
 --nate
 
  
  Thon
  
  On Feb 07, 2013, at 05:29 AM, Dannon Baker dannonba...@me.com wrote:
  
  Unfortunately not, and with the migration of tools to the toolshed 
  installation mechanism I don't imagine this will be addressed (at least 
  by the team) anytime soon. If you wanted you could probably write a 
  script that would reload a specified tool in each of the separate web 
  processes, or just implement a complete rolling restart of your web 
  processes to avoid service disruption while still loading the tool 
  updates.
  
  -Dannon
  
  
  On Feb 6, 2013, at 8:40 PM, Anthonius deBoer thondeb...@me.com wrote:
  
   I am indeed using multiple web processes and I guess I am talking about 
   the old admine tool reloader...
   Is there any other way to do this for your own tools that you just 
   manually place in tools etc.?
   
   Thon
   
   On Feb 05, 2013, at 06:22 PM, Dannon Baker dannonba...@me.com wrote:
   
   Are you using multiple web processes, and are you referring to the old 
   admin tool reloader or the toolshed reloading interface?
   
   -Dannon
   
   On Feb 5, 2013, at 9:13 PM, Anthonius deBoer thondeb...@me.com wrote:
   
Hi,

I find that reloading a tool's configuration file does not really 
work.
First, you have to click the reload buttow twice to actually have it 
update the VERSION number (so it does read something)...
But when I try to run my tool, the old bug is still there...

I am using proxy server so something may still be cached, but I have 
to restart my server for it actually to pick up the changes...

Any ideas?

Thon
___
Please keep all replies on the list by using reply all
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/
   
  
  ___
  Please keep all replies on the list by using reply all
  in your mail client. To manage your subscriptions to this
  and other Galaxy lists, please use the interface at:
  
  http://lists.bx.psu.edu/
 


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Reloading a tools configuration does not seem to actually work

Interesting!But maybe it is not the manager that is the bottleneck, but which process is the one that takes the inputs from the webpage (or in the API) and prepares all the files that are produced by the workflows?I guess it is the MAIN server?THAT is the one that is the bottleneck I think then...Are there any plans to make that process parallel?What I am facing, is that I have 100 FASTQ pairs or so, for a single flowcell, I can start the analysis of that set from the UI, but it will just crank through them and takes about 2-4 minutues for each pair to be processed, so with 100 pairs or so, you are looking 3-4 hours of an hourglass before control is given back to the user...It would be ideal if we would farm out the parsing of the web input to the cluster, so the creation of the histories and datasets is no longer the bottleneckHow do others deal with large sequencing projects on this list?Are there any groups that routinely do 100-200 pairs of FASTQ files from within galaxy?I would like to hear their experience...ThanksThonOn Feb 13, 2013, at 01:44 PM, Nate Coraor n...@bx.psu.edu wrote:On Feb 13, 2013, at 4:12 PM, Anthonius deBoer wrote:   Would this problem go away if I only used ONE webserver in my proxy setting and not use a balancer?  I may not need it and if it means I could not use the toolshed effectively, it may be worth it not to use balancing..  No, because your manager/handlers will still need to be restarted to pick up the new tools. The only way you can have it work without restarting is to have everything in a single process.   What i really need is the manager being balanced, since submitting a workflow with 100's of BAM files can take hours just to get started...ANy change we can run multiple managers?  I'm surprised the manager is the holdup here since all it does is assign a handler. Regardless, in the development branch (which will be the next stable/release branch), the manager has been killed, and handlers are assigned directly by the web processes.  --nate ThanksOn Feb 13, 2013, at 07:59 AM, Nate Coraor n...@bx.psu.edu wrote:On Feb 7, 2013, at 2:43 PM, Anthonius deBoer wrote: That's very unfortunate...   I have a ton of tools and I guess now I have to create a package for them in a local toolshed to update them in a running galaxy server?  In any case...The toolshed installation also does not work for me...I still have to restart galaxy, even after using the toolshed approach to install a tool...It either does not show up at all or give a bunch of errors, about not being able to find the tool...  Is this also related to the fact I have two webservers and am behind a proxy server as well?Hi Thon,Essentially yes, there is no way for one web process to communicate with others that it has installed a tool. We'd like to allow for this sort of notification via a message queue, but we don't have a proper message queue in Galaxy right now.--nateThon  On Feb 07, 2013, at 05:29 AM, Dannon Baker dannonba...@me.com wrote:  Unfortunately not, and with the migration of tools to the toolshed installation mechanism I don't imagine this will be addressed (at least by the team) anytime soon. If you wanted you could probably write a script that would reload a specified tool in each of the separate web processes, or just implement a complete rolling restart of your web processes to avoid service disruption while still loading the tool updates.  -Dannon On Feb 6, 2013, at 8:40 PM, Anthonius deBoer thondeb...@me.com wrote:   I am indeed using multiple web processes and I guess I am talking about the "old" admine tool reloader...Is there any other way to do this for your own tools that you just manually place in tools etc.?ThonOn Feb 05, 2013, at 06:22 PM, Dannon Baker dannonba...@me.com wrote:Are you using multiple web processes, and are you referring to the old admin tool reloader or the toolshed reloading interface?-DannonOn Feb 5, 2013, at 9:13 PM, Anthonius deBoer thondeb...@me.com wrote: Hi,  I find that reloading a tool's configuration file does not really work. First, you have to click the reload buttow twice to actually have it update the VERSION number (so it does read something)... But when I try to run my tool, the old bug is still there...  I am using proxy server so something may still be cached, but I have to restart my server for it actually to pick up the changes...  Any ideas?  Thon ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at:  http://lists.bx.psu.edu/  ___   Please keep all replies on the list by using "reply all"   in your mail client. To manage your

Re: [galaxy-dev] Overwriting tools directory?

2013-02-13 Thread Amanda Zuzolo

Thanks for the help, Björn. I will keep an eye on it when I go to merge.

Il giorno martedì 12 febbraio 2013, Björn Grüning ha scritto:

 Hi Amanda,

 the tools directory is also tracked and updated in mercurial. But only
 the tools that are shipped with galaxy. If you have inserted your own
 tools, they want be affected. If you modified galaxy tools that are part
 of main galaxy, than you will probably get a merge conflict. But
 mercurial will tell you that.

 Kind regards,
 Bjoern

  Since I can't find this on any of the wikis: when updating Galaxy
  through mercurial, is the tools directory affected? Our instance has
  backups of the directory, but I want to know whether I will have to
  take care of them when I pull down the latest release.
 
  Thanks in advance.
 




-- 
Amanda Zuzolo
Bioengineering Major, George Mason University
Metabiome Informatics Group, Environmental Biocomplexity
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

[galaxy-dev] New release : display problem

2013-02-13 Thread Mathieu Bahin

Hi there, 

I am using my own Galaxy instance and since I updated, I can't see file of 
several datatypes (for example the 'tabular' ) clicking on the eye icon. 

Is that a problem linked to the new release ? 

Cheers, 
Mathieu Bahin 
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] [galaxy-user] Installing new tools from the tool shed

2013-02-13 Thread Dannon Baker

On Feb 13, 2013, at 6:16 PM, David Joly idj...@gmail.com wrote:

 Hi!
 
 Ok, I know many people had the same issue, but I just can't figure what's 
 going on. I'm quite new about using a local instance of Galaxy and I'm trying 
 to figure how to install a tool from the tool shed. Reading the tutorial  
 (Installing Galaxy tool shed repository tools into a local Galaxy instance) 
 looked pretty simple, but maybe I missed something.
 
 First, I modified the universe_wsgi.ini file by removing the # before the 
 tool_config_file and tool_path lines.

This one step should really be all you need to do (any other files get created 
automatically with reasonable defaults if missing) as far as configuration 
goes.  Did you restart your galaxy instance after editing universe_wsgi.ini?

-Dannon
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] [galaxy-user] Installing new tools from the tool shed

2013-02-13 Thread Dannon Baker

How old is the galaxy you're running?  To use the main toolshed you'll need to 
use a galaxy-dist release from December or later.  After this point in time the 
interface was standardized and is backwards compatible.

To update, you should be able to simply navigate to your galaxy-dist directory, 
'hg pull -u', and you'll be off and running.

Also, since this deals with a local install, please do keep replies on the 
'galaxy-dev' list that I transitioned this thread to instead of galaxy-user.

Thanks!

-Dannon

On Feb 13, 2013, at 6:43 PM, David Joly idj...@gmail.com wrote:

 Ok, one more step closer (I thought closing the browser would be enough to 
 restart galaxy, but obviously, I had to reboot the computer).
 
 But now it says: ValueError: too many values to unpack
 
 
 2013/2/13 Dannon Baker dannon.ba...@gmail.com
 On Feb 13, 2013, at 6:16 PM, David Joly idj...@gmail.com wrote:
 
  Hi!
 
  Ok, I know many people had the same issue, but I just can't figure what's 
  going on. I'm quite new about using a local instance of Galaxy and I'm 
  trying to figure how to install a tool from the tool shed. Reading the 
  tutorial  (Installing Galaxy tool shed repository tools into a local Galaxy 
  instance) looked pretty simple, but maybe I missed something.
 
  First, I modified the universe_wsgi.ini file by removing the # before the 
  tool_config_file and tool_path lines.
 
 This one step should really be all you need to do (any other files get 
 created automatically with reasonable defaults if missing) as far as 
 configuration goes.  Did you restart your galaxy instance after editing 
 universe_wsgi.ini?
 
 -Dannon
 


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] New release : display problem

2013-02-13 Thread Dannon Baker

Mathieu,

To clarify -- is this after the new galaxy-dist release, or new code in
galaxy-central?  And, is this *any* tabular file?  Or just ones of a
particular size?  (Files of  50 columns are handled as a special case, for
instance)

-Dannon

On Wed, Feb 13, 2013 at 11:29 AM, Mathieu Bahin mathieu.ba...@irisa.frwrote:

 Hi there,

 I am using my own Galaxy instance and since I updated, I can't see file of
 several datatypes (for example the 'tabular') clicking on the eye icon.

 Is that a problem linked to the new release ?

 Cheers,
 Mathieu Bahin

 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:

   http://lists.bx.psu.edu/

___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

[galaxy-dev] Why are the search options in datasets no longer using AND logic?

Hi,One very cool feature was to be able to search quickly for datasets using the search feature.You could continue to add terms until your search results in the correct set...It was basically doing an AND search for the terms you entered.This feature has seem to have disappeared?Now a search term replaces your previous term so you can no longer pair your search down and there does not seem to be any support for using AND or Is this a bug or a new feature?ThanksThon
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] [galaxy-user] Installing new tools from the tool shed

2013-02-13 Thread David Joly

Ok, one more step closer (I thought closing the browser would be enough to
restart galaxy, but obviously, I had to reboot the computer).

But now it says: ValueError: too many values to unpack


2013/2/13 Dannon Baker dannon.ba...@gmail.com

 On Feb 13, 2013, at 6:16 PM, David Joly idj...@gmail.com wrote:

  Hi!
 
  Ok, I know many people had the same issue, but I just can't figure
 what's going on. I'm quite new about using a local instance of Galaxy and
 I'm trying to figure how to install a tool from the tool shed. Reading the
 tutorial  (Installing Galaxy tool shed repository tools into a local Galaxy
 instance) looked pretty simple, but maybe I missed something.
 
  First, I modified the universe_wsgi.ini file by removing the # before
 the tool_config_file and tool_path lines.

 This one step should really be all you need to do (any other files get
 created automatically with reasonable defaults if missing) as far as
 configuration goes.  Did you restart your galaxy instance after editing
 universe_wsgi.ini?

 -Dannon
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] [galaxy-user] Installing new tools from the tool shed

2013-02-13 Thread David Joly

This could be the problem, I just installed BioLinux 7 on my computer with
Galaxy running out-of-the-box...

However, it looks like they changed a few things, there is no .hg file and
no galaxy-dist folder. Can I update outside of mercurial?


2013/2/13 Dannon Baker dannon.ba...@gmail.com

 How old is the galaxy you're running?  To use the main toolshed you'll
 need to use a galaxy-dist release from December or later.  After this point
 in time the interface was standardized and is backwards compatible.

 To update, you should be able to simply navigate to your galaxy-dist
 directory, 'hg pull -u', and you'll be off and running.

 Also, since this deals with a local install, please do keep replies on the
 'galaxy-dev' list that I transitioned this thread to instead of galaxy-user.

 Thanks!

 -Dannon

 On Feb 13, 2013, at 6:43 PM, David Joly idj...@gmail.com wrote:

  Ok, one more step closer (I thought closing the browser would be enough
 to restart galaxy, but obviously, I had to reboot the computer).
 
  But now it says: ValueError: too many values to unpack
 
 
  2013/2/13 Dannon Baker dannon.ba...@gmail.com
  On Feb 13, 2013, at 6:16 PM, David Joly idj...@gmail.com wrote:
 
   Hi!
  
   Ok, I know many people had the same issue, but I just can't figure
 what's going on. I'm quite new about using a local instance of Galaxy and
 I'm trying to figure how to install a tool from the tool shed. Reading the
 tutorial  (Installing Galaxy tool shed repository tools into a local Galaxy
 instance) looked pretty simple, but maybe I missed something.
  
   First, I modified the universe_wsgi.ini file by removing the #
 before the tool_config_file and tool_path lines.
 
  This one step should really be all you need to do (any other files get
 created automatically with reasonable defaults if missing) as far as
 configuration goes.  Did you restart your galaxy instance after editing
 universe_wsgi.ini?
 
  -Dannon
 


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

[galaxy-dev] How to redirect output of all the galaxy tools to another directory?

I want to redirect all the output of Galaxy to another directory(actually a
external hard drive with full write access). How can I do that? Thanks
___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

[galaxy-dev] Incomplete tophat2 output