[galaxy-dev] New tool listed under Latest revision: failing tool tests yet not tested
Hi Dave et al, Yesterday I uploaded a new tool to the TestToolShed: http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast_rbh Development repository: https://github.com/peterjc/galaxy_blast/tree/master/tools/blast_rbh It is currently listed under Latest revision: failing tool tests, Name Latest Installable Revision Owner blast_rbh 1 (2014-05-15) peterjc On viewing the tool, there are no test results at all (yet). Is this a corner case false-positive, or was there really a failed test run which is not being shown? Thanks, Peter ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] New tool listed under Latest revision: failing tool tests yet not tested
Hi Peter, I doscovered an error in the query filters that are used for rendering these various Latest revision: lists. The problem was that the filters were not correctly determining whether the revisions had been tested yet by the install and test framework. This problem should be fixed in 13496:26b9fe985ee7, which is now running on the test tool shed. Thanks for reporting this problem, and please let us know if you discover any other problems related to this. Greg Von Kustet On May 16, 2014, at 7:22 AM, Peter Cock p.j.a.c...@googlemail.com wrote: Hi Dave et al, Yesterday I uploaded a new tool to the TestToolShed: http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast_rbh Development repository: https://github.com/peterjc/galaxy_blast/tree/master/tools/blast_rbh It is currently listed under Latest revision: failing tool tests, Name Latest Installable Revision Owner blast_rbh 1 (2014-05-15) peterjc On viewing the tool, there are no test results at all (yet). Is this a corner case false-positive, or was there really a failed test run which is not being shown? Thanks, Peter ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] New tool listed under Latest revision: failing tool tests yet not tested
Great - thanks Greg, Peter On Fri, May 16, 2014 at 2:59 PM, Greg Von Kuster g...@bx.psu.edu wrote: Hi Peter, I doscovered an error in the query filters that are used for rendering these various Latest revision: lists. The problem was that the filters were not correctly determining whether the revisions had been tested yet by the install and test framework. This problem should be fixed in 13496:26b9fe985ee7, which is now running on the test tool shed. Thanks for reporting this problem, and please let us know if you discover any other problems related to this. Greg Von Kustet On May 16, 2014, at 7:22 AM, Peter Cock p.j.a.c...@googlemail.com wrote: Hi Dave et al, Yesterday I uploaded a new tool to the TestToolShed: http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast_rbh Development repository: https://github.com/peterjc/galaxy_blast/tree/master/tools/blast_rbh It is currently listed under Latest revision: failing tool tests, Name Latest Installable Revision Owner blast_rbh 1 (2014-05-15) peterjc On viewing the tool, there are no test results at all (yet). Is this a corner case false-positive, or was there really a failed test run which is not being shown? Thanks, Peter ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] nginx configuration question
Hi All,
I have been trying to get the visualization through ucsc main working, thus
I installed the nginx on our ubuntu(the one comes with update), then I
configured it according to the wiki
https://wiki.galaxyproject.org/Admin/Config/nginxProxy
Here is the section in my nginx.conf
include /etc/nginx/conf.d/*.conf;
#include /etc/nginx/sites-enabled/*;
upstream galaxy_app {
server localhost:20020;
}
server {
client_max_body_size 10G;
# ... other server stuff ...
location / {
proxy_pass http://galaxy_app;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
}
}
server {
location /_x_accel_redirect/ {
internal;
alias /;
}
}
A couple notes:
1. I commented out
#include /etc/nginx/sites-enabled/*;
should I?
2. I have two sections of 'server', I am not sure if this is correct, but
the wiki does not talk about it.
I also have the following in universe_wsgi.ini:
nginx_x_accel_redirect_base = /_x_accel_redirect
Now, if I go to http://127.0.0.1, it will redirect to http://127.0.0.1:20020,
our galaxy instance, which is right.
However, when i choose 'display in UCSC main' on a bigwig file, it failed
to show and here is the log:
75.142.102.9 - - [16/May/2014:09:18:20 -0700] GET
/display_application/360b40e91c77a7e9/ucsc_bigwig/main HTTP/1.0 302 -
http://128.125.28.215/root; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36
128.114.119.135 - - [16/May/2014:09:18:20 -0700] GET
/display_application/360b40e91c77a7e9/ucsc_bigwig/main/6e1547da5bd290c9/param/track
HTTP/1.0 200 201 - genome.ucsc.edu/net.c
128.114.119.135 - - [16/May/2014:09:18:20 -0700] HEAD
/display_application/360b40e91c77a7e9/ucsc_bigwig/main/6e1547da5bd290c9/data/galaxy_360b40e91c77a7e9.bigwig
HTTP/1.0 200 92543742 - genome.ucsc.edu/net.c
128.114.119.135 - - [16/May/2014:09:18:20 -0700] HEAD
/_x_accel_redirect/home/bioinfoadmin/app/galaxy-dist/database/files/003/dataset_3353.dat
HTTP/1.0 404 - - genome.ucsc.edu/net.c
128.114.119.135 - - [16/May/2014:09:18:20 -0700] HEAD
/galaxy/display_application/360b40e91c77a7e9/ucsc_bigwig/main/6e1547da5bd290c9/data/galaxy_360b40e91c77a7e9.bigwig
HTTP/1.0 404 - - genome.ucsc.edu/net.c
I don't know how this works -- the dataset I clicked is in fact:
/home/bioinfoadmin/app/galaxy-dist/database/files/003/dataset_3353.dat
and it is on disk. However, it gave 404:
128.114.119.135 - - [16/May/2014:09:18:20 -0700] HEAD
/_x_accel_redirect/home/bioinfoadmin/app/galaxy-dist/database/files/003/dataset_3353.dat
HTTP/1.0 404 - - genome.ucsc.edu/net.c
seems '_x_accel_redirect' is not substituted by the redirect alias '/'? but
why?
I checked the permission and it is 775 for all the dir on path, and 664 for
dataset_3353.dat
so www-data user has the read access.
Also, where is this dir and file?
/display_application/360b40e91c77a7e9/ucsc_bigwig/main/6e1547da5bd290c9/data/galaxy_360b40e91c77a7e9.bigwig
I don't see them anywhere on the disk at all!
I'm very confused about this. Could anyone give me a hand? I'll really
appreciate!
Thanks,
Rui
___
Please keep all replies on the list by using reply all
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
[galaxy-dev] Fwd: InvalidVersionError: 103 is not 105
I have an empty posgresql database:
psql -c create database galaxy;
I'm trying to launch run.sh from the latest version of galaxy-dist.
Migration proceeds normally up to this point:
#
galaxy.model.migrate.check INFO 2014-05-16 19:11:17,121
galaxy.model.migrate.check INFO 2014-05-16 19:11:17,121 Migration
script to add the cleanup_event* tables.
galaxy.model.migrate.check INFO 2014-05-16 19:11:17,121
galaxy.model.migrate.check INFO 2014-05-16 19:11:17,121
galaxy.model.migrate.check INFO 2014-05-16 19:11:17,121 Migrating 105 - 106...
galaxy.model.migrate.check INFO 2014-05-16 19:11:17,121
Traceback (most recent call last):
File /opt/galaxy/web/lib/galaxy/webapps/galaxy/buildapp.py, line
39, in app_factory
app = UniverseApplication( global_conf = global_conf, **kwargs )
File /opt/galaxy/web/lib/galaxy/app.py, line 45, in __init__
self._configure_models( check_migrate_databases=True,
check_migrate_tools=check_migrate_tools, config_file=config_file )
File /opt/galaxy/web/lib/galaxy/config.py, line 629, in _configure_models
create_or_verify_database( db_url, config_file,
self.config.database_engine_options, app=self )
File /opt/galaxy/web/lib/galaxy/model/migrate/check.py, line 73,
in create_or_verify_database
migrate()
File /opt/galaxy/web/lib/galaxy/model/migrate/check.py, line 57, in migrate
migrate_to_current_version( engine, db_schema )
File /opt/galaxy/web/lib/galaxy/model/migrate/check.py, line 131,
in migrate_to_current_version
schema.runchange( ver, change, changeset.step )
File
/opt/galaxy/web/eggs/sqlalchemy_migrate-0.7.2-py2.7.egg/migrate/versioning/schema.py,
line 89, in runchange
(self.version, startver))
InvalidVersionError: 103 is not 105
#
I re-run run.sh and get:
#
migrate.versioning.repository DEBUG 2014-05-16 19:12:22,132 Repository
lib/galaxy/model/migrate loaded successfully
migrate.versioning.repository DEBUG 2014-05-16 19:12:22,132 Config:
OrderedDict([('db_settings', OrderedDict([('__name__', 'db_settings'),
('repository_id', 'Galaxy'), ('version_table', 'migrate_version'),
('required_dbs', '[]')]))])
galaxy.model.migrate.check DEBUG 2014-05-16 19:12:22,136 psycopg2 egg
successfully loaded for postgres dialect
/opt/galaxy/web/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/engine/url.py:105:
SADeprecationWarning: The SQLAlchemy PostgreSQL dialect has been
renamed from 'postgres' to 'postgresql'. The new URL format is
postgresql[+driver]://user:pass@host/dbname
Traceback (most recent call last):
File /opt/galaxy/web/lib/galaxy/webapps/galaxy/buildapp.py, line
39, in app_factory
app = UniverseApplication( global_conf = global_conf, **kwargs )
File /opt/galaxy/web/lib/galaxy/app.py, line 45, in __init__
self._configure_models( check_migrate_databases=True,
check_migrate_tools=check_migrate_tools, config_file=config_file )
File /opt/galaxy/web/lib/galaxy/config.py, line 629, in _configure_models
create_or_verify_database( db_url, config_file,
self.config.database_engine_options, app=self )
File /opt/galaxy/web/lib/galaxy/model/migrate/check.py, line 111,
in create_or_verify_database
% ( db_schema.version, migrate_repository.versions.latest, config_arg ) )
Exception: Your database has version '103' but this code expects
version '120'. Please backup your database and then migrate the
schema by running 'sh manage_db.sh upgrade'.
#
I manually run manage_db.sh upgrade. This step passes, and then I run
run.sh a third time and galaxy finally starts properly.
My question is: why can't the manage_db.sh upgrade step be included
automatically when the initial DB build fails?
This is the first time a DB is being built, so it should be dead simple
Cheers,
-Evan Bollig
Research Associate | Application Developer | User Support Consultant
Minnesota Supercomputing Institute
599 Walter Library
612 624 1447
e...@msi.umn.edu
boll0...@umn.edu
___
Please keep all replies on the list by using reply all
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Fwd: InvalidVersionError: 103 is not 105
On Fri, May 16, 2014 at 3:33 PM, Evan Bollig boll0...@umn.edu wrote: InvalidVersionError: 103 is not 105 This would indicate to me that migration script 104 failed. My question is: why can't the manage_db.sh upgrade step be included automatically when the initial DB build fails? It is, in a sense, hence all the other migration steps. Can you provide more details about your configuration? Postgres version, whether you're using a virtualenv (or not), or anything else you think seems relevant? -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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
