[galaxy-dev] Papers that cite Galaxy workflows

2016-07-21 Thread Steve Cassidy
Hi all,
 I’m writing a paper that will include some evangelism for Galaxy in language 
sciences and I’d like to be able to cite examples of papers in the Bio field 
that cite Galaxy workflows.  Even better would be the re-use of a Galaxy 
workflow cited in another paper.  Does anyone have any good example papers they 
could refer me to.

Thanks,

Steve
—
Department of Computing, Macquarie University
http://web.science.mq.edu.au/~cassidy

___
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:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] Galaxy, Docker Containers, and Installing tools not in Toolshed

2016-07-21 Thread Yip, Miu ki
Hi,

I apologize for all the questions, but would all of this work be done within 
the container after it is created by the Docker run command or are you 
referring to the local out of container area?

I am getting an error like:
DEBUG:galaxy.app:python path is: lib/, ., , 
/galaxy-central/eggs/PasteDeploy-1.5.0-py2.7.egg, 
/galaxy-central/.venv/lib/python2.7, 
/galaxy-central/.venv/lib/python2.7/plat-x86_64-linux-gnu, 
/galaxy-central/.venv/lib/python2.7/lib-tk, 
/galaxy-central/.venv/lib/python2.7/lib-old, 
/galaxy-central/.venv/lib/python2.7/lib-dynload, /usr/lib/python2.7, 
/usr/lib/python2.7/plat-x86_64-linux-gnu, /usr/lib/python2.7/lib-tk, 
/galaxy-central/.venv/local/lib/python2.7/site-packages
Traceback (most recent call last):
  File "lib/galaxy/webapps/galaxy/buildapp.py", line 63, in paste_app_factory
app = galaxy.app.UniverseApplication( global_conf=global_conf, **kwargs )
  File "lib/galaxy/app.py", line 44, in __init__
self.config.check()
  File "lib/galaxy/config.py", line 636, in check
raise ConfigurationError("Tool config file not found: %s" % path )
ConfigurationError: Tool config file not found: 
/root/../home/user/galaxy_storage/galaxy-central/config/tool_conf.xml.main

if I try to run when I am adding outside of the container, I've cat-ed the path 
and standard out displays the contents of the file. I am getting another error 
about files not being found also when I add to the container itself when I 
attach. 

Thanks so much,
Miuki

From: Björn Grüning [bjoern.gruen...@gmail.com]
Sent: Wednesday, July 20, 2016 2:05 PM
To: Yip, Miu ki; Björn Grüning; galaxy-dev@lists.galaxyproject.org
Subject: Re: [galaxy-dev] Galaxy, Docker Containers, and Installing tools not 
in Toolshed

Hi,

> Hello Bjoern,
>
> Thanks for the quick response, I appreciate that.
>
> Concerning the instructions, I am unclear of a couple of things.
>
> I have a folder with my tools, there is no preinstalled folder that
> these tools need to go in called my_tools_folder, right?

No, you can create such a folder wherever you want and name it like you
want :)

> Additionally, would I place this tool in the same directory level as
> Galaxy_Central or as the config directory? (My current set up is
> galaxy_storage -> galaxy-central -> config, I have my tools folder in
> the same level as galaxy-central.)

This does not matter, what matters is that the folder path is correct in
the env variable.

> Lastly, the environment variable, is there a specific file that all
> the environment variables are stored for docker Galaxy? I have tried
> looking for an env file, but could not find it.

There is no file. These are real environment variables that are created
by Docker during container start. You can change them during start with
(e.g): docker run -e MY_ENV_VAR=foo bgruening/galaxy-stable

If such a variable, beginning with GALAXY_CONFIG_XXX exists this will be
picked up by Galaxy. Have a look at the container there are a lot
GALAXY_CONFIG_ vars set.

Hope this helps,
Bjoern


> Thanks so much! Miuki  From:
> Björn Grüning [bjoern.gruen...@gmail.com] Sent: Wednesday, July 20,
> 2016 2:23 AM To: Yip, Miu ki; galaxy-dev@lists.galaxyproject.org
> Subject: Re: [galaxy-dev] Galaxy, Docker Containers, and Installing
> tools not in Toolshed
>
> Hi Miuki!
>
> Am 19.07.2016 um 22:36 schrieb Yip, Miu ki:
>> Hello Galaxy Team,
>>
>> We're from the Bioinformatics Shared Resources at Cold Spring
>> Harbor Lab and we're trying to create a new flavour of Galaxy for
>> local use in the lab using docker containers.
>>
>> We want to add tools that are specific for our lab, such as
>> importing files from our system, onto this flavour of Galaxy using
>> Docker containers. Is there a recommended way to do this?
>
> Can you try the following, assuming that all your tools are in
> my_tools_tolder.
>
> ADD ./my_tools_folder /inhouse_tools/
>
> Now we need a tool_conf.xml file. You can create an additional one,
> no need to modify the existing one. I would propose to include this
> config file also in ./my_tools_folder so it will end up in
> /inhouse_tools/tool_conf.xml With the following environment variable
> you tell Galaxy about the additional tool_conf file.
>
> ENV GALAXY_CONFIG_TOOL_CONFIG_FILE =
> config/tool_conf.xml,config/shed_tool_conf.xml,/inhouse_tools/tool_conf.xml
>
>  Please make sure that your new tools in
> /inhouse_tools/tool_conf.xml have as path "/inhouse_tools/.xml".
>
> Let me know if this works, we should add this to the readme.
>
> Thanks, Bjoern
>
>> I've taken a look at the README from:
>> https://github.com/bgruening/docker-galaxy-stable
>>
>> I have been able to successfully create an instance of Galaxy
>> where the homepage is different and tools are imported from the
>> Tool Shed. However, I cannot figure out how to install tools onto
>> Galaxy that are not from the Tool Shed. I have tried creating a
>> container, putting the

Re: [galaxy-dev] BLAST only using single core

2016-07-21 Thread Shane Sturrock
Thanks Peter, that was the hint I was needing. It looks like the solution for 
my LSF cluster was to use drmaa://-n 8/ in the universe_wsgi.ini and now I can 
see BLAST using 8 cores. It doesn’t scale perfectly so going higher isn't 
sensible but turnaround time for my test job has improved markedly.

Shane

Dr. Shane Sturrock
NZGL BioIT Admin
n...@biomatters.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:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] Galaxy, Docker Containers, and Installing tools not in Toolshed

2016-07-21 Thread Bjoern Gruening

Hi,

all this can be done in your Dockerfile if you create a Galaxy flavour 
or during startup.


For example you can start your container like this

docker run -v /home/miuki/tools/:/tools/ -e 
GALAXY_CONFIG_TOOL_CONFIG_FILE = 
config/tool_conf.xml,config/shed_tool_conf.xml,/tools/tool_conf.xml 
bgruening/galaxy-stable


This should work if inside of /home/miuki/tools/tool_conf.xml all tools 
have the path /tools/my_tool.xml


Ciao,
Bjoern





Hi,

I apologize for all the questions, but would all of this work be done within 
the container after it is created by the Docker run command or are you 
referring to the local out of container area?

I am getting an error like:
DEBUG:galaxy.app:python path is: lib/, ., , 
/galaxy-central/eggs/PasteDeploy-1.5.0-py2.7.egg, 
/galaxy-central/.venv/lib/python2.7, 
/galaxy-central/.venv/lib/python2.7/plat-x86_64-linux-gnu, 
/galaxy-central/.venv/lib/python2.7/lib-tk, 
/galaxy-central/.venv/lib/python2.7/lib-old, 
/galaxy-central/.venv/lib/python2.7/lib-dynload, /usr/lib/python2.7, 
/usr/lib/python2.7/plat-x86_64-linux-gnu, /usr/lib/python2.7/lib-tk, 
/galaxy-central/.venv/local/lib/python2.7/site-packages
Traceback (most recent call last):
   File "lib/galaxy/webapps/galaxy/buildapp.py", line 63, in paste_app_factory
 app = galaxy.app.UniverseApplication( global_conf=global_conf, **kwargs )
   File "lib/galaxy/app.py", line 44, in __init__
 self.config.check()
   File "lib/galaxy/config.py", line 636, in check
 raise ConfigurationError("Tool config file not found: %s" % path )
ConfigurationError: Tool config file not found: 
/root/../home/user/galaxy_storage/galaxy-central/config/tool_conf.xml.main

if I try to run when I am adding outside of the container, I've cat-ed the path 
and standard out displays the contents of the file. I am getting another error 
about files not being found also when I add to the container itself when I 
attach.

Thanks so much,
Miuki

From: Björn Grüning [bjoern.gruen...@gmail.com]
Sent: Wednesday, July 20, 2016 2:05 PM
To: Yip, Miu ki; Björn Grüning; galaxy-dev@lists.galaxyproject.org
Subject: Re: [galaxy-dev] Galaxy, Docker Containers, and Installing tools not 
in Toolshed

Hi,


Hello Bjoern,

Thanks for the quick response, I appreciate that.

Concerning the instructions, I am unclear of a couple of things.

I have a folder with my tools, there is no preinstalled folder that
these tools need to go in called my_tools_folder, right?

No, you can create such a folder wherever you want and name it like you
want :)


Additionally, would I place this tool in the same directory level as
Galaxy_Central or as the config directory? (My current set up is
galaxy_storage -> galaxy-central -> config, I have my tools folder in
the same level as galaxy-central.)

This does not matter, what matters is that the folder path is correct in
the env variable.


Lastly, the environment variable, is there a specific file that all
the environment variables are stored for docker Galaxy? I have tried
looking for an env file, but could not find it.

There is no file. These are real environment variables that are created
by Docker during container start. You can change them during start with
(e.g): docker run -e MY_ENV_VAR=foo bgruening/galaxy-stable

If such a variable, beginning with GALAXY_CONFIG_XXX exists this will be
picked up by Galaxy. Have a look at the container there are a lot
GALAXY_CONFIG_ vars set.

Hope this helps,
Bjoern



Thanks so much! Miuki  From:
Björn Grüning [bjoern.gruen...@gmail.com] Sent: Wednesday, July 20,
2016 2:23 AM To: Yip, Miu ki; galaxy-dev@lists.galaxyproject.org
Subject: Re: [galaxy-dev] Galaxy, Docker Containers, and Installing
tools not in Toolshed

Hi Miuki!

Am 19.07.2016 um 22:36 schrieb Yip, Miu ki:

Hello Galaxy Team,

We're from the Bioinformatics Shared Resources at Cold Spring
Harbor Lab and we're trying to create a new flavour of Galaxy for
local use in the lab using docker containers.

We want to add tools that are specific for our lab, such as
importing files from our system, onto this flavour of Galaxy using
Docker containers. Is there a recommended way to do this?

Can you try the following, assuming that all your tools are in
my_tools_tolder.

ADD ./my_tools_folder /inhouse_tools/

Now we need a tool_conf.xml file. You can create an additional one,
no need to modify the existing one. I would propose to include this
config file also in ./my_tools_folder so it will end up in
/inhouse_tools/tool_conf.xml With the following environment variable
you tell Galaxy about the additional tool_conf file.

ENV GALAXY_CONFIG_TOOL_CONFIG_FILE =
config/tool_conf.xml,config/shed_tool_conf.xml,/inhouse_tools/tool_conf.xml

  Please make sure that your new tools in
/inhouse_tools/tool_conf.xml have as path "/inhouse_tools/.xml".

Let me know if this works, we should add this to the readme.

Thanks, Bjoern


I've taken a look at the README

Re: [galaxy-dev] errors when updating tools

2016-07-21 Thread Sarah DIEHL
Hi Nikolay,

I set it to 5 and the request goes through, but I still only see an empty 
list for "Monitoring installing tool shed repositories".

I suppose something is wrong with my existing version of cuffdiff, since I 
can't update or repair it also. I had issues with galaxy messing up entries in 
the tool install database before. Maybe the existing entry is screwing up the 
installation of the new version.

Best regards,
Sarah



Sarah Diehl
HPC System Administrator

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | Biotech II
6, avenue du Swing
L-4371 Belvaux
T +352 46 66 44 5360
sarah.di...@uni.lu 
http://lcsb.uni.lu
-
This message is confidential and may contain privileged information. It is 
intended for the named recipient only. If you receive it in error please notify 
me and permanently delete the original message and any copies.
-


From: Nikolay Aleksandrov Vazov 
mailto:n.a.va...@usit.uio.no>>
Date: Thursday 21 July 2016 13:36
To: Sarah DIEHL mailto:sarah.di...@uni.lu>>
Subject: Re: errors when updating tools


I am not very familiar with ToolShed and I don't know what 
"encoded_repo_info_dicts" actually does. Do you remember what your previous 
values were?

The apache option worked for me. Try to set 5 instead.


Nikolay

===
Nikolay Vazov, PhD
Department for Research Computing, University of Oslo

From: Sarah DIEHL mailto:sarah.di...@uni.lu>>
Sent: 21 July 2016 13:05
To: Nikolay Aleksandrov Vazov; 
galaxy-dev@lists.galaxyproject.org
Subject: Re: errors when updating tools

Hi Nikolay,

thanks a lot for the hint. I looked up the apache option and everywhere it says 
that something is wrong if you have to change that ;-). I did it anyway and I 
can see in the logs that a very long request appears that doesn't look right 
(see attached file) and afterwards I just get an empty page.


___
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:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] errors when updating tools

2016-07-21 Thread Sarah DIEHL
Hi Nikolay,

thanks a lot for the hint. I looked up the apache option and everywhere it says 
that something is wrong if you have to change that ;-). I did it anyway and I 
can see in the logs that a very long request appears that doesn't look right 
(see attached file) and afterwards I just get an empty page.

Best regards,
Sarah



Sarah Diehl
HPC System Administrator

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | Biotech II
6, avenue du Swing
L-4371 Belvaux
T +352 46 66 44 5360
sarah.di...@uni.lu 
http://lcsb.uni.lu
-
This message is confidential and may contain privileged information. It is 
intended for the named recipient only. If you receive it in error please notify 
me and permanently delete the original message and any copies.
-


From: Nikolay Aleksandrov Vazov 
mailto:n.a.va...@usit.uio.no>>
Date: Thursday 21 July 2016 09:36
To: Sarah DIEHL mailto:sarah.di...@uni.lu>>, 
"galaxy-dev@lists.galaxyproject.org" 
mailto:galaxy-dev@lists.galaxyproject.org>>
Subject: Re: errors when updating tools


​Hi, Sarah,


I can't be of much help on the tools issue but the "Request-URI Too Large" 
error can be fixed by adding a line like :


LimitRequestFieldSize 12392


(the size is a number of bytes which reflects the length of the uri eventually. 
For my setup, the above number does the job)


This line shall be added into your httpd.conf of ssl.conf in case you are using 
https connection. It shall be placed within



​here




Cheers


Nikolay

===
Nikolay Vazov, PhD
Department for Research Computing, University of Oslo

From: galaxy-dev 
mailto:galaxy-dev-boun...@lists.galaxyproject.org>>
 on behalf of Sarah DIEHL mailto:sarah.di...@uni.lu>>
Sent: 20 July 2016 09:51
To: 
galaxy-dev@lists.galaxyproject.org
Subject: [galaxy-dev] errors when updating tools

Hi,

I just updated our Galaxy from 15.10 to 16.04. I also wanted to update the 
tools installed, but I'm (again) getting a whole bunch of different errors.


Some of the updated tools rely on package_cairo_1_12_14, which fails, because 
it cannot find some of it's dependencies (see package_cairo_errors.jpg):

> Error installing tool dependency fontconfig version 2.11.1: Unable to locate 
> required tool shed repository named package_fontconfig_2_11_1 owned by iuc 
> with revision 2ce32675340e.
> Error installing tool dependency freetype version 2.5.2: Unable to locate 
> required tool shed repository named package_freetype_2_5_2 owned by iuc with 
> revision 3b09e7916896.

In the main overview of the repository I also see the message "Dependency was 
not resolved by any resolver module."  (see package_cairo_resolver.jpg). Is 
this related and something I should worry about? I did not touch the resolver 
configuration, I left the line in galaxy.ini commented.
I also don't understand why it tries to install a different revision of a 
package repo that's already installed. I'm having similar errors for some other 
packages.


Furthermore, when I try to "Get Updates" for cuffdiff, I get an internal server 
error (see cuffdiff_update_error.txt). The same for macs2 (see 
macs2_update_error.jpg).

When I try to install the newest version of cuffdiff from the toolshed, after I 
click "Install to Galaxy", I get a "Request-URI Too Large" error (from apache I 
guess). The last message before it fails in the Galaxy log is "Building 
repository dependency relationships...".


I'm a bit reluctant to update any package repositories I have installed, since 
in the past this lead to dependencies breaking. Also uninstalling and 
reinstalling usually doesn't help, since the database keeps the records and 
once it's messed up it stays messed up. I checked on the galaxy-stable docker 
image and there everything works fine, so I guess it's related to my Galaxy 
instance, not the package/tool repositories.

Any help on how to solve this is greatly appreciated!

Best regards,
Sarah



Sarah Diehl
HPC System Administrator

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | Biotech II
6, avenue du Swing
L-4371 Belvaux
T +352 46 66 44 5360
sarah.di...@uni.lu 
http://lcsb.uni.lu
-
This message is confidential and may contain privileged information. It is 
intended for the named recipient only. If you receive it in error please notify 
me and permanently delete the original message and any copies.
-

10.184.148.20 - - [21/Jul/2016:11:38:18 +0200] "GET 
/admin_toolshed/prepare_for_install?changeset_revisions=0f32ad418df8&repository_ids=497bb1cd1c72a204&tool_shed_url=https%3A%2F%2Ftoolshed.g2.bx.psu.edu%2F
 HTTP/1.1" 200 - 
"https://toolshed.g2.bx.psu.edu/repository/preview_tools_in_changeset?repository_id=497bb1cd1c72a204&changeset_revision=0f32ad418df8"

Re: [galaxy-dev] BLAST only using single core

2016-07-21 Thread Peter Cock
On Thu, Jul 21, 2016 at 10:35 AM, Shane Sturrock  wrote:
>
> I’m just using the drmaa plugin so I’m guessing I need to either specify a
> job runner for BLAST which sets GALAXY_SLOTS. The documentation isn’t
> entirely clear although it seems I need to create a job_conf.xml which sets
> local_slots to a value for runner drmaa unless there’s a way to set that in
> the galaxy.ini file instead.

There is a legacy job setting via galaxy.ini aka universe_wsgi.ini where
we used to use this:

[galaxy:tool_runners]
ncbi_blastp_wrapper  = drmaa://-V -pe smp 4/
ncbi_blastn_wrapper  = drmaa://-V -pe smp 4/
ncbi_blastx_wrapper  = drmaa://-V -pe smp 4/
ncbi_tblastn_wrapper = drmaa://-V -pe smp 4/
ncbi_tblastx_wrapper = drmaa://-V -pe smp 4/
blast_reciprocal_best_hits = drmaa://-V -pe smp 4/

The -V was an SGE switch to copy the environment variables,
and -pe smp 4 is for a 4 core job.

For job_conf.xml I am trying something similar with less repetition:

...


-pe smp 4


...








...


i.e. I've set the computationally heavy BLAST+ tools to use a
destination configured to use just four cores. Because this is
SGE, we do this via the native syntax of -pe smp 4, i.e.
just like at the command line we'd do:

$ qsub -pe smp 4 ...

This detail will be different for your LSF cluster.

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:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] BLAST only using single core

2016-07-21 Thread Shane Sturrock
Hi Peter,

> On 21/07/2016, at 8:50 PM, Peter Cock  wrote:
> 
> Hi Shane,
> 
> We've not touched anything on the BLAST+ wrapper here for
> a while - the command line is always built using:
> 
> -num_threads "\${GALAXY_SLOTS:-8}"
> 
> That means use the environment variable $GALAXY_SLOTS
> if set, defaulting to 8 threads if not. See:
> 
> https://github.com/peterjc/galaxy_blast/blob/master/tools/ncbi_blast_plus/ncbi_macros.xml#L352
> 
> Galaxy itself should be setting $GALAXY_SLOTS via your
> cluster configuration - and from your description this seems
> to be set to 1 thread/slot only.

I suspect since I’m running an old configuration that my cluster setup isn’t 
optimal. I didn’t really want my users going nuts since our cluster is small (6 
nodes, 16 cores each) so I wasn’t keen to give them too much power because and 
was happy that tools would only run on single cores although I’ve set things up 
as per the docs way back when so it uses multiple handlers and so on and with 
default_cluster_job_runner = drmaa:/// all in the galaxy.ini (universe_wsgi.ini 
actually)

> 
> Can you tell us more about how your Galaxy LSF is setup?
> Have you got BLAST specific cluster job settings?

Nothing specific, but it would seem that the GALAXY_SLOTS variable has gone 
from being unset to set with the install I’ve got now and that would explain 
why BLAST has slowed down a lot.
> 
> (I don't use LSF so don't have the details to hand)

I’m just using the drmaa plugin so I’m guessing I need to either specify a job 
runner for BLAST which sets GALAXY_SLOTS. The documentation isn’t entirely 
clear although it seems I need to create a job_conf.xml which sets local_slots 
to a value for runner drmaa unless there’s a way to set that in the galaxy.ini 
file instead.

Shane

> 
> Peter
> 
> On Wed, Jul 20, 2016 at 10:03 PM, Shane Sturrock  wrote:
>> Previously, the BLAST wrapper was able to use multiple cores but recently
>> users have started complaining it has got really slow and when I look at the
>> cluster a job is only using a single core. I don’t want jobs split across
>> multiple cluster nodes, but each node has 16 cores so it would be good if
>> they could be used. I’m still using the older 16.01 release and this has
>> been upgraded repeatedly over the last few years so I’m still using the
>> universe_wsg.ini file (sym linked to config/galaxy.ini) and I don’t have a
>> job_conf.xml set up. I’m using drmaa to drive an LSF cluster. BLAST is the
>> main issue here so I was wondering if there’s a way to pass the -num_threads
>> flag without breaking everything until I can build up a new server?
>> 
>> Dr. Shane Sturrock
>> NZGL BioIT Admin
>> n...@biomatters.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:
>>  https://lists.galaxyproject.org/
>> 
>> To search Galaxy mailing lists use the unified search at:
>>  http://galaxyproject.org/search/mailinglists/


Dr. Shane Sturrock
NZGL BioIT Admin
n...@biomatters.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:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

[galaxy-dev] Fwd: Uploads not working in local Galaxy installation

2016-07-21 Thread Adrià Cereto i Massagué
Hello,

I've been trying to get working a local galaxy installation, using nginx
with the upload module as a proxy.

It all seems to work, except uploading files to Galaxy, where I get a "GET
/_upload/ HTTP/1.1" 404 and nothing else Ic an find in the logs.

There must be some misconfiguration somewhere, but I can't sport it. Could
you help me?

Here's my nginx.conf:

user galaxy;
> worker_processes 10;
> pid /run/nginx.pid;
>
> events {
>worker_connections 768;
> }
> http {
>gzip  on;
>gzip_http_version 1.1;
>gzip_vary on;
>gzip_comp_level 4;
>gzip_proxied any;
>gzip_types text/plain text/css application/x-javascript text/xml
> application/xml text/javascript application/json;
>gzip_buffers 16 8k;
>gzip_disable "MSIE [1-6].(?!.*SV1)";
>upstream galaxy_app {
>server localhost:8080;
>}
>server {
>client_max_body_size 10G;
>location / {
>proxy_pass   http://galaxy_app;
>proxy_set_header   X-Forwarded-Host $host;
>proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
>}
>location /_x_accel_redirect/ {
>internal;
>alias /;
>}
>location ~
> ^/plugins/visualizations/(?.+?)/static/(?.*?)$ {
>alias
> /home/galaxy/galaxy/config/plugins/visualizations/$vis_name/static/$static_file;
>
>expires 24h;
>}
>location /static {
>alias /home/galaxy/galaxy/static;
>expires 24h;
>}
>location /static/style {
>alias /home/galaxy/galaxy/static/june_2007_style/blue;
>expires 24h;
>}
>location /static/scripts {
>alias /home/galaxy/galaxy/static/scripts/packed;
>expires 24h;
>}
>location /favicon.ico {
>alias /home/galaxy/galaxy/static/favicon.ico;
>expires 24h;
>}
>location /robots.txt {
>alias /home/galaxy/galaxy/static/robots.txt;
>expires 24h;
>}
>location /_upload {
>upload_store /home/galaxy/galaxy/database/tmp/upload_store;
>upload_pass_form_field "";
>upload_set_form_field "__${upload_field_name}__is_composite"
> "true";
>upload_set_form_field "__${upload_field_name}__keys" "name
> path";
>upload_set_form_field "${upload_field_name}_name"
> "$upload_file_name";
>upload_set_form_field "${upload_field_name}_path"
> "$upload_tmp_path";
>upload_pass_args on;
>upload_pass /_upload_done;
>}
>location /_upload_done {
>set $dst /api/tools;
>if ($args ~ nginx_redir=([^&]+)) {
>set $dst $1;
>}
>rewrite "" $dst;
>}
>location /plugins {
>alias /home/galaxy/galaxy-dist/config/plugins;
>}
>}
> }
>


And here's my galaxy.ini:

[server:handler0]
> port = 8090
> host = 127.0.0.1
> use_threadpool = true
> threadpool_workers = 10
>


> [server:handler1]
> port = 8091
> host = 127.0.0.1
> use_threadpool = true
> threadpool_workers = 10
>


> [server:handler2]
> port = 8092
> host = 127.0.0.1
> use_threadpool = true
> threadpool_workers = 10
>


> [server:handler3]
> port = 8093
> host = 127.0.0.1
> use_threadpool = true
> threadpool_workers = 10
>


> [server:main]
> port = 8080
> host = 0.0.0.0
> use_threadpool = True
> threadpool_workers = 30
> threadpool_kill_thread_limit = 10800
>


> [filter:gzip]
>


> [filter:proxy-prefix]
> prefix = /galaxy
>


> [app:main]
> paste.app_factory = galaxy.web.buildapp:app_factory
> database_connection = postgresql://galaxy:not_the_actual_password@localhost
> /galaxy?host=/var/run/postgresql
> nginx_x_accel_redirect_base = /_x_accel_redirect
> nginx_upload_store = database/tmp/upload_store
> nginx_upload_path = /_upload
> tool_dependency_dir = dep_dir
> use_nglims = False
> nglims_config_file = tool-data/nglims.yaml
> static_enabled = True
> debug = False
> use_interactive = False
> id_secret = ValarDohaerys
> admin_users = adria.cer...@ctns.cat, galac...@galaxy.gal
> allow_user_impersonation = True
> allow_user_dataset_purge = True
> new_user_dataset_access_role_default_private = True
> expose_user_name = True
> master_api_key = heavysplatling
> track_jobs_in_database = True
> enable_job_recovery = True
>


> [galaxy_amqp]
>


> [uwsgi]
> processes = 44
> stats = 127.0.0.1:9191
> socket = 127.0.0.1:4001
> pythonpath = lib
> threads = 12
> logto = /home/galaxy/uwsgi.log
> master = True



Thank you in advance,

Adrià

-- 
*Adrià Cereto i Massagué*
Centre for Omic Sciences (COS)
www.omicscentre.com
Servei de Recursos Científics i Tècnics (SRCiT)
Universitat Rovira i Virgili
Av. Universitat, 1.
43204 Reus (Catalonia)
Tel: +34 977 77 69 32 <%2B34%20977%2077%2014%2009>
Extensió URV: 4838

Languages: Català, Español, English, Français, Deutsch, Português

Important Notice 

Re: [galaxy-dev] BLAST only using single core

2016-07-21 Thread Peter Cock
Hi Shane,

We've not touched anything on the BLAST+ wrapper here for
a while - the command line is always built using:

-num_threads "\${GALAXY_SLOTS:-8}"

That means use the environment variable $GALAXY_SLOTS
if set, defaulting to 8 threads if not. See:

https://github.com/peterjc/galaxy_blast/blob/master/tools/ncbi_blast_plus/ncbi_macros.xml#L352

Galaxy itself should be setting $GALAXY_SLOTS via your
cluster configuration - and from your description this seems
to be set to 1 thread/slot only.

Can you tell us more about how your Galaxy LSF is setup?
Have you got BLAST specific cluster job settings?

(I don't use LSF so don't have the details to hand)

Peter

On Wed, Jul 20, 2016 at 10:03 PM, Shane Sturrock  wrote:
> Previously, the BLAST wrapper was able to use multiple cores but recently
> users have started complaining it has got really slow and when I look at the
> cluster a job is only using a single core. I don’t want jobs split across
> multiple cluster nodes, but each node has 16 cores so it would be good if
> they could be used. I’m still using the older 16.01 release and this has
> been upgraded repeatedly over the last few years so I’m still using the
> universe_wsg.ini file (sym linked to config/galaxy.ini) and I don’t have a
> job_conf.xml set up. I’m using drmaa to drive an LSF cluster. BLAST is the
> main issue here so I was wondering if there’s a way to pass the -num_threads
> flag without breaking everything until I can build up a new server?
>
> Dr. Shane Sturrock
> NZGL BioIT Admin
> n...@biomatters.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:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/
___
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:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] errors when updating tools

2016-07-21 Thread Nikolay Aleksandrov Vazov
?Hi, Sarah,


I can't be of much help on the tools issue but the "Request-URI Too Large" 
error can be fixed by adding a line like :


LimitRequestFieldSize 12392


(the size is a number of bytes which reflects the length of the uri eventually. 
For my setup, the above number does the job)


This line shall be added into your httpd.conf of ssl.conf in case you are using 
https connection. It shall be placed within



?here




Cheers


Nikolay

===
Nikolay Vazov, PhD
Department for Research Computing, University of Oslo

From: galaxy-dev  on behalf of 
Sarah DIEHL 
Sent: 20 July 2016 09:51
To: galaxy-dev@lists.galaxyproject.org
Subject: [galaxy-dev] errors when updating tools

Hi,

I just updated our Galaxy from 15.10 to 16.04. I also wanted to update the 
tools installed, but I'm (again) getting a whole bunch of different errors.


Some of the updated tools rely on package_cairo_1_12_14, which fails, because 
it cannot find some of it's dependencies (see package_cairo_errors.jpg):

> Error installing tool dependency fontconfig version 2.11.1: Unable to locate 
> required tool shed repository named package_fontconfig_2_11_1 owned by iuc 
> with revision 2ce32675340e.
> Error installing tool dependency freetype version 2.5.2: Unable to locate 
> required tool shed repository named package_freetype_2_5_2 owned by iuc with 
> revision 3b09e7916896.

In the main overview of the repository I also see the message "Dependency was 
not resolved by any resolver module."  (see package_cairo_resolver.jpg). Is 
this related and something I should worry about? I did not touch the resolver 
configuration, I left the line in galaxy.ini commented.
I also don't understand why it tries to install a different revision of a 
package repo that's already installed. I'm having similar errors for some other 
packages.


Furthermore, when I try to "Get Updates" for cuffdiff, I get an internal server 
error (see cuffdiff_update_error.txt). The same for macs2 (see 
macs2_update_error.jpg).

When I try to install the newest version of cuffdiff from the toolshed, after I 
click "Install to Galaxy", I get a "Request-URI Too Large" error (from apache I 
guess). The last message before it fails in the Galaxy log is "Building 
repository dependency relationships...".


I'm a bit reluctant to update any package repositories I have installed, since 
in the past this lead to dependencies breaking. Also uninstalling and 
reinstalling usually doesn't help, since the database keeps the records and 
once it's messed up it stays messed up. I checked on the galaxy-stable docker 
image and there everything works fine, so I guess it's related to my Galaxy 
instance, not the package/tool repositories.

Any help on how to solve this is greatly appreciated!

Best regards,
Sarah



Sarah Diehl
HPC System Administrator

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | Biotech II
6, avenue du Swing
L-4371 Belvaux
T +352 46 66 44 5360
sarah.di...@uni.lu 
http://lcsb.uni.lu
-
This message is confidential and may contain privileged information. It is 
intended for the named recipient only. If you receive it in error please notify 
me and permanently delete the original message and any copies.
-

___
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:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/