[galaxy-dev] Job manager crashes at start of Galaxy
Hi all, The jobmanager crashes when Galaxy starts. Starting server in PID 28704. Traceback (most recent call last): File "./scripts/paster.py", line 34, in command.run() File "/home/galaxy/galaxy-dist/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/command.py", line 84, in run invoke(command, command_name, options, args[1:]) File "/home/galaxy/galaxy-dist/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/command.py", line 123, in invoke exit_code = runner.run(args) File "/home/galaxy/galaxy-dist/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/command.py", line 218, in run result = self.command() File "/home/galaxy/galaxy-dist/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/serve.py", line 303, in command serve() File "/home/galaxy/galaxy-dist/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/serve.py", line 287, in serve server(app) File "/home/galaxy/galaxy-dist/eggs/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py", line 151, in server_wrapper **context.local_conf) File "/home/galaxy/galaxy-dist/eggs/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/util/fixtypeerror.py", line 57, in fix_call val = callable(*args, **kw) File "/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpserver.py", line 1314, in server_runner serve(wsgi_app, **kwargs) File "/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpserver.py", line 1264, in serve threadpool_options=threadpool_options) File "/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpserver.py", line 1114, in __init__ RequestHandlerClass, ssl_context) File "/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpserver.py", line 1094, in __init__ RequestHandlerClass, ssl_context) File "/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpserver.py", line 358, in __init__ HTTPServer.__init__(self, server_address, RequestHandlerClass) File "/usr/lib64/python2.6/SocketServer.py", line 402, in __init__ self.server_bind() File "/usr/lib64/python2.6/BaseHTTPServer.py", line 108, in server_bind SocketServer.TCPServer.server_bind(self) File "/usr/lib64/python2.6/SocketServer.py", line 413, in server_bind self.socket.bind(self.server_address) File "", line 1, in bind socket.gaierror: [Errno -2] Name or service not known galaxy.jobs.manager INFO 2013-01-24 14:05:22,524 sending stop signal to worker thread galaxy.jobs.manager INFO 2013-01-24 14:05:22,524 job manager queue stopped galaxy.jobs.manager INFO 2013-01-24 14:05:22,524 sending stop signal to worker thread galaxy.jobs.manager INFO 2013-01-24 14:05:22,524 job manager stop queue stopped Removing PID file manager.pid After searching a bit on that error (socket.gaierror: [Errno -2] Name or service not known), it might be rooted in my fiddling with the hostname (/etc/hosts). However, I cannot seems to resolve it... Any hints? Thanks, Joachim PS: sorry for the repost, but previous message had an inappropriate Subject line -- 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/
Re: [galaxy-dev] Blank history panel / Error in history API at listing contents
On Tue, Jan 22, 2013 at 4:43 PM, Carl Eberhard wrote: >>> Short form: >>> Both the API and client side should handle single datasets error-ing more >>> gracefully than they did and the history panel should be more resilient and >>> useful during and after a server error (at least of this kind). >>> >>> Please let me know if you see more problems, >>> C I'm seeing some (apparently harmless) errors in the output during the 'upload' step when running Galaxy unit tests - in this case for one of my tools: functional_tests.py INFO 2013-01-25 10:37:19,810 Functional tests will be run against localhost:9500 nose.plugins.manager DEBUG 2013-01-25 10:37:19,865 DefaultPluginManager load plugin sqlalchemy = sqlalchemy.test.noseplugin:NoseSQLAlchemy nose.plugins.manager DEBUG 2013-01-25 10:37:19,986 DefaultPluginManager load plugin nosetestdiff = nosetestdiff.plugin:NoseTestDiff nose.plugins.manager DEBUG 2013-01-25 10:37:19,989 DefaultPluginManager load plugin nosehtml = nosehtml.plugin:NoseHTML TMHMM 2.0 ( tmhmm2 ) > Test-1 ... galaxy.web.framework DEBUG 2013-01-25 10:37:20,366 Error: this request returned None from get_history(): http://localhost:9500/ galaxy.web.framework DEBUG 2013-01-25 10:37:20,425 Error: this request returned None from get_history(): http://localhost:9500/ galaxy.web.framework DEBUG 2013-01-25 10:37:20,676 Error: this request returned None from get_history(): http://localhost:9500/user/logout galaxy.web.framework DEBUG 2013-01-25 10:37:20,731 Error: this request returned None from get_history(): http://localhost:9500/ galaxy.tools.actions.upload_common INFO 2013-01-25 10:37:24,312 tool upload1 created job id 1 galaxy.jobs.manager DEBUG 2013-01-25 10:37:27,460 (1) Job assigned to handler 'main' galaxy.jobs DEBUG 2013-01-25 10:37:32,755 (1) Working directory for job is: /mnt/galaxy/galaxy-central/database/job_working_directory/000/1 galaxy.jobs.handler DEBUG 2013-01-25 10:37:32,755 dispatching job 1 to local runner galaxy.jobs.handler INFO 2013-01-25 10:37:33,041 (1) Job dispatched galaxy.jobs.runners.local DEBUG 2013-01-25 10:37:33,153 Local runner: starting job 1 galaxy.jobs.runners.local DEBUG 2013-01-25 10:37:33,712 executing: ... Are these lines just false positives? Error: this request returned None from get_history(): http://localhost:9500/ Error: this request returned None from get_history(): http://localhost:9500/user/logout Error: this request returned None from get_history(): http://localhost:9500/ 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/
[galaxy-dev] Error opening galaxy.json file
Hi all, Could someone explain to me what the "Error opening galaxy.json file" logging means (set at DEBUG level so perhaps not really an error). I've seen this when my development Galaxy is running normally (here I have the logging set to show the DEBUG output) but also for the Galaxy unit tests. e.g. galaxy.jobs.manager DEBUG 2013-01-25 10:37:45,645 (2) Job assigned to handler 'main' galaxy.jobs DEBUG 2013-01-25 10:37:50,899 (2) Working directory for job is: /mnt/galaxy/galaxy-central/database/job_working_directory/000/2 galaxy.jobs.handler DEBUG 2013-01-25 10:37:50,900 dispatching job 2 to local runner galaxy.jobs.handler INFO 2013-01-25 10:37:51,175 (2) Job dispatched galaxy.jobs.runners.local DEBUG 2013-01-25 10:37:51,286 Local runner: starting job 2 galaxy.jobs.runners.local DEBUG 2013-01-25 10:37:51,820 executing: python /mnt/galaxy/galaxy-central/tools/protein_analysis/tmhmm2.py "$NSLOTS" /tmp/tmp6hm9Td/database/files/000/dataset_1.dat /tmp/tmp6hm9Td/database/files/000/dataset_2.dat galaxy.jobs.runners.local DEBUG 2013-01-25 10:38:11,967 execution finished: python /mnt/galaxy/galaxy-central/tools/protein_analysis/tmhmm2.py "$NSLOTS" /tmp/tmp6hm9Td/database/files/000/dataset_1.dat /tmp/tmp6hm9Td/database/files/000/dataset_2.dat galaxy.tools DEBUG 2013-01-25 10:38:12,265 Error opening galaxy.json file: [Errno 2] No such file or directory: '/mnt/galaxy/galaxy-central/database/job_working_directory/000/2/galaxy.json' galaxy.jobs DEBUG 2013-01-25 10:38:12,411 job 2 ended 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/
Re: [galaxy-dev] Job manager crashes at start of Galaxy
Hi all, Found the solution: the IP address in universe_wsgi.ini was wrong. I entered 0.0.0..0. Perhaps a checking on the IP address format can help to avoid this? Cheers, Joachim Joachim Jacob Rijvisschestraat 120, 9052 Zwijnaarde Tel: +32 9 244.66.34 Bioinformatics Training and Services (BITS) http://www.bits.vib.be @bitsatvib On 01/25/2013 10:13 AM, Joachim Jacob |VIB| wrote: Hi all, The jobmanager crashes when Galaxy starts. Starting server in PID 28704. Traceback (most recent call last): File "./scripts/paster.py", line 34, in command.run() File "/home/galaxy/galaxy-dist/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/command.py", line 84, in run invoke(command, command_name, options, args[1:]) File "/home/galaxy/galaxy-dist/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/command.py", line 123, in invoke exit_code = runner.run(args) File "/home/galaxy/galaxy-dist/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/command.py", line 218, in run result = self.command() File "/home/galaxy/galaxy-dist/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/serve.py", line 303, in command serve() File "/home/galaxy/galaxy-dist/eggs/PasteScript-1.7.3-py2.6.egg/paste/script/serve.py", line 287, in serve server(app) File "/home/galaxy/galaxy-dist/eggs/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py", line 151, in server_wrapper **context.local_conf) File "/home/galaxy/galaxy-dist/eggs/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/util/fixtypeerror.py", line 57, in fix_call val = callable(*args, **kw) File "/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpserver.py", line 1314, in server_runner serve(wsgi_app, **kwargs) File "/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpserver.py", line 1264, in serve threadpool_options=threadpool_options) File "/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpserver.py", line 1114, in __init__ RequestHandlerClass, ssl_context) File "/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpserver.py", line 1094, in __init__ RequestHandlerClass, ssl_context) File "/home/galaxy/galaxy-dist/eggs/Paste-1.6-py2.6.egg/paste/httpserver.py", line 358, in __init__ HTTPServer.__init__(self, server_address, RequestHandlerClass) File "/usr/lib64/python2.6/SocketServer.py", line 402, in __init__ self.server_bind() File "/usr/lib64/python2.6/BaseHTTPServer.py", line 108, in server_bind SocketServer.TCPServer.server_bind(self) File "/usr/lib64/python2.6/SocketServer.py", line 413, in server_bind self.socket.bind(self.server_address) File "", line 1, in bind socket.gaierror: [Errno -2] Name or service not known galaxy.jobs.manager INFO 2013-01-24 14:05:22,524 sending stop signal to worker thread galaxy.jobs.manager INFO 2013-01-24 14:05:22,524 job manager queue stopped galaxy.jobs.manager INFO 2013-01-24 14:05:22,524 sending stop signal to worker thread galaxy.jobs.manager INFO 2013-01-24 14:05:22,524 job manager stop queue stopped Removing PID file manager.pid After searching a bit on that error (socket.gaierror: [Errno -2] Name or service not known), it might be rooted in my fiddling with the hostname (/etc/hosts). However, I cannot seems to resolve it... Any hints? Thanks, Joachim PS: sorry for the repost, but previous message had an inappropriate Subject line ___ 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] Tool metadata of Flexbar
Recently, I updated the Flexbar tool definition in the Galaxy Tool Shed repository flexbar to work with a new version of the program. I changed the version of the tool definition from 2.3 to 2.31, adjusted requirements and uploaded files. However, the Flexbar tool in the repo still shows the old tool version and requirements, whereas the tool command seems to be updated. Furthermore, the change log shows that new repository metadata is associated with the latest change set, but bizarrely the initial metadata is now associated with commit 11 instead of 12, which was the last bugfix commit before the update (commit 13). The update took place more than a week ago. Any suggestions why that is the case? 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/
Re: [galaxy-dev] Error opening galaxy.json file
Hi Peter, As you guessed, this debug statement is not a true error and can be safely ignored. Its part of some undocumented features (read as don't try to use it yet). As this does seem to be causing some confusion lately, perhaps we should remove the log.debug until after the feature is ready, or provide additional information in the message to indicate that it can be safely ignored. Thanks for using Galaxy, Dan On Jan 25, 2013, at 5:45 AM, Peter Cock wrote: > Hi all, > > Could someone explain to me what the "Error opening galaxy.json file" > logging means (set at DEBUG level so perhaps not really an error). I've > seen this when my development Galaxy is running normally (here I have > the logging set to show the DEBUG output) but also for the Galaxy unit > tests. > > e.g. > > galaxy.jobs.manager DEBUG 2013-01-25 10:37:45,645 (2) Job assigned to > handler 'main' > galaxy.jobs DEBUG 2013-01-25 10:37:50,899 (2) Working directory for > job is: /mnt/galaxy/galaxy-central/database/job_working_directory/000/2 > galaxy.jobs.handler DEBUG 2013-01-25 10:37:50,900 dispatching job 2 to > local runner > galaxy.jobs.handler INFO 2013-01-25 10:37:51,175 (2) Job dispatched > galaxy.jobs.runners.local DEBUG 2013-01-25 10:37:51,286 Local runner: > starting job 2 > galaxy.jobs.runners.local DEBUG 2013-01-25 10:37:51,820 executing: > python /mnt/galaxy/galaxy-central/tools/protein_analysis/tmhmm2.py > "$NSLOTS" /tmp/tmp6hm9Td/database/files/000/dataset_1.dat > /tmp/tmp6hm9Td/database/files/000/dataset_2.dat > galaxy.jobs.runners.local DEBUG 2013-01-25 10:38:11,967 execution > finished: python > /mnt/galaxy/galaxy-central/tools/protein_analysis/tmhmm2.py "$NSLOTS" > /tmp/tmp6hm9Td/database/files/000/dataset_1.dat > /tmp/tmp6hm9Td/database/files/000/dataset_2.dat > galaxy.tools DEBUG 2013-01-25 10:38:12,265 Error opening galaxy.json > file: [Errno 2] No such file or directory: > '/mnt/galaxy/galaxy-central/database/job_working_directory/000/2/galaxy.json' > galaxy.jobs DEBUG 2013-01-25 10:38:12,411 job 2 ended > > Thanks, > > Peter > ___ > Please keep all replies on the list by using "reply all" > in your mail client. To manage your subscriptions to this > and other Galaxy lists, please use the interface at: > > http://lists.bx.psu.edu/ ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
Re: [galaxy-dev] Error opening galaxy.json file
On Fri, Jan 25, 2013 at 3:23 PM, Daniel Blankenberg wrote: > Hi Peter, > > As you guessed, this debug statement is not a true error and can be safely > ignored. Its part of some undocumented features (read as don't try to use it > yet). As this does seem to be causing some confusion lately, perhaps we > should remove the log.debug until after the feature is ready, or provide > additional information in the message to indicate that it can be safely > ignored. OK - I'll continue to ignore it :) 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/
Re: [galaxy-dev] Bug in handling user job limits (due to dynamic job runner code?)
Thanks Nate, it's much appreciated. I'm glad I was able to help out a bit, just sorry I wasn't able to provide a complete fix (though maybe that's for the best if there is a rewrite underway). Lance Nate Coraor wrote: Hi Lance, I'm rewriting much of this code, I should have all of it committed (including this fix) some time this week. Thanks for figuring out exactly what's going on here. --nate On Jan 18, 2013, at 5:28 PM, Lance Parsons wrote: Just an update on this issue. Upon further investigation, it looks like the dynamic job runner code in commit 6f3b4e8 broke this. I haven't been able to parse through everything going on yet to propose a fix, but I've discovered two things: 1) Moving the self.__clear_user_job_count() call outside of the if block, does indeed fix that issue 2) Fixing that leads the __check_user_jobs method to fail since it does not check `self.track_jobs_in_database`, but instead assumes that jobs are in the database, resulting in a different exception regarding invalid columns. Lance Parsons wrote: I submitted a trello "ticket" [(https://trello.com/c/6vxkqdjT) regarding this, but wanted to make sure I brought it to someone's attention (it's causing me some queue issues with my instance of galaxy). When registered_user_job_limit and anonymous_user_job_limit are set in universe.wsgi jobs cannot be run, instead the following error occurs: galaxy.jobs.handler ERROR 2012-12-04 12:44:51,869 failure running job 22396 Traceback (most recent call last): File "/data/local/galaxy/galaxy-prod/lib/galaxy/jobs/handler.py", line 183, in __monitor_step job_state = self.__check_if_ready_to_run( job ) File "/data/local/galaxy/galaxy-prod/lib/galaxy/jobs/handler.py", line 253, in __check_if_ready_to_run state = self.__check_user_jobs( job ) File "/data/local/galaxy/galaxy-prod/lib/galaxy/jobs/handler.py", line 274, in __check_user_jobs if not self.user_job_count: AttributeError: 'JobHandlerQueue' object has no attribute 'user_job_count' Commenting out the lines for registered_user_job_limit and anonymous_user_job_limit in universe.wsgi allows job to be queue one again. It looks like this is due to the fact that `self.__clear_user_job_count()` on line 159 of `handler.py` is only called when jobs are tracked in the database. If jobs are not tracked in the database (as in my case), the error occurs. Perhaps the fix would be to simply move the call outside the `if` block. It appears this was broken in the 2012-11-13 revision (73e05bc). -- Lance Parsons - Scientific Programmer 134 Carl C. Icahn Laboratory Lewis-Sigler Institute for Integrative Genomics Princeton University ___ 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] Error loading a BAM file -- dataset needs grooming
Hi, I tried to load a BAM file into our local instance of Galaxy but get the following error. I had preloaded the genome to which it was aligned and the bai file. Do I have to load these using a different method and the file upload? Thanks, Maureen Traceback error: Traceback (most recent call last): File "/work/apps/galaxy/tools/data_source/upload.py", line 384, in __main__() File "/work/apps/galaxy/tools/data_source/upload.py", line 373, in __main__ add_file( dataset, registry, json_file, output_path ) File "/work/apps/galaxy/tools/data_source/upload.py", line 312, in add_file if link_data_only == 'copy_files' and datatype.dataset_content_needs_grooming( output_path ): File "/work/apps/galaxy/lib/galaxy/datatypes/binary.py", line 113, in dataset_content_needs_grooming version = self._get_samtools_version() File "/work/apps/galaxy/lib/galaxy/datatypes/binary.py", line 97, in _get_samtools_version output = subprocess.Popen( [ 'samtools' ], stderr=subprocess.PIPE, stdout=subprocess.PIPE ).communicate()[1] File "/usr/lib64/python2.6/subprocess.py", line 639, in __init__ errread, errwrite) File "/usr/lib64/python2.6/subprocess.py", line 1228, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory -- Maureen J. Donlin, Ph.D. Research Associate Professor Dept. of Biochemistry & Molecular Biology Dept. of Molecular Microbiology & Immunology Saint Louis University School of Medicine 507 Doisy Research Center Office: 314-977-8858 Cell: 314-750-2345 ___ 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 with Univa Grid Engine (UGE) instead of SGE?
On Thu, Jan 24, 2013 at 11:04 AM, Dannon Baker wrote: > Hey Peter, Carlos, > > Thanks for tracking this down, I've updated the composite job/task id tag > to use an underscore instead in changeset 8658:c901bbb4eca8. > Hi Dannon, Thanks for the quick fix. I applied this fix manually to the latest galaxy-dist and I can confirm the issue I was seeing is gone. 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/
[galaxy-dev] Only custom genomes for uploads in data libraries
Hi, I'm running latest galaxy-dist locally. When I try to upload a dataset to a data library through Admin, I only get the two custom genomes I have created for visualizations. If I use the regular upload tool under "Get data", I do get to choose any of the genomes in: tool-data/shared/ucsc/builds.txt I tried deleting the custom genomes and then the dropbox menu in the data libraries upload form is empty. Is there something I'm missing? I would like to be able to select any genome available, custom or not. 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] Tool metadata of Flexbar
Hello Johannes, I reset all of the metadata on your flexbar repository and I believe it now displays everything correctly. Metadata is now associated with the following changeset revisions: 14:69ddef2ec7d2 - this is the repository tip and contains Flexbar version 2.31 12:4cbf6c6d2f2b - this changeset has metadata associated with it because it contains Flexbar version 2.3 5:0a7a3e7559b4 - this changeset also contains Flexbar version 2.3. Metadata is associated with this changeset because you deleted the Flexbar tool from the following changeset (6:c0c9b43670d0) The behavior you describe is a result of the way you uploaded the various changes to independent files. When you upload a file, a new mercurial changeset revision is created, and metadata is defined based on a comparison of the parent changeset revision and the new repository tip. The basic rule for setting metadata is if certain components of the parent changeset is not equal to or a subset f the current changeset (the tip in this discussion). This approach works very well in most cases, but not so well in corner case scenarios like this one. Setting metadata on repositories in the tool shed is a very complex process, so getting it perfect in every scenario is difficult. I'm always improving the process though, and I'll attempt to correct the behavior for this scenario. The workaround that corrects the behavior in this and all other corner-case scenarios is to manually reset all metadata on the repository after all of your uploads are completed. This process inspects the entire changelog instead of just the repository tip and immediate parent changeset. I just committed changeset revision 8663:982aa4ecc7b5 to the Galaxy central repository that allows repository owners to reset all metadata on their repositories using the Repository Actions popup menu form the Manage repository page in the tool shed. This feature used to be restricted to only Tool Shed administrators. This change set is currently running on the test Galaxy tool shed and will be available on the main Galaxy tool shed 2 Galaxy releases from now. Thanks very much for reporting this! Greg Von Kuster On Jan 25, 2013, at 10:21 AM, Johannes Röhr wrote: > Recently, I updated the Flexbar tool definition in the Galaxy Tool Shed > repository flexbar to work with a new version of the program. I changed the > version of the tool definition from 2.3 to 2.31, adjusted requirements and > uploaded files. However, the Flexbar tool in the repo still shows the old > tool version and requirements, whereas the tool command seems to be updated. > > Furthermore, the change log shows that new repository metadata is associated > with the latest change set, but bizarrely the initial metadata is now > associated with commit 11 instead of 12, which was the last bugfix commit > before the update (commit 13). The update took place more than a week ago. > > Any suggestions why that is the case? 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/ ___ 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] maximum recursion depth exceeded while calling a Python object
Hi, I'm running a local instance of Galaxy and no matter what tool I run I get the following error: Error executing tool: maximum recursion depth exceeded while calling a Python object In the log file: galaxy.tools ERROR 2013-01-25 14:06:54,375 Exception caught while attempting tool execution: Traceback (most recent call last): File "/Galaxy/galaxy_dist/lib/galaxy/tools/__init__.py", line 1776, in handle_input _, out_data = self.execute( trans, incoming=params, history=history ) File "/Galaxy/galaxy_dist/lib/galaxy/tools/__init__.py", line 2103, in execute return self.tool_action.execute( self, trans, incoming=incoming, set_output_hid=set_output_hid, history=history, **kwargs ) File "/Galaxy/galaxy_dist/lib/galaxy/tools/actions/__init__.py", line 203, in execute chrom_info = build_fasta_dataset.get_converted_dataset( trans, 'len' ).file_name File "/Galaxy/galaxy_dist/lib/galaxy/model/__init__.py", line 1161, in get_converted_dataset new_dataset = self.datatype.convert_dataset( trans, self, target_ext, return_output=True, visible=False, deps=deps, set_output_history=False ).values()[0] File "/Galaxy/galaxy_dist/lib/galaxy/datatypes/data.py", line 467, in convert_dataset converted_dataset = converter.execute( trans, incoming=params, set_output_hid=visible, set_output_history=set_output_history)[1] File "/Galaxy/galaxy_dist/lib/galaxy/tools/__init__.py", line 2103, in execute return self.tool_action.execute( self, trans, incoming=incoming, set_output_hid=set_output_hid, history=history, **kwargs ) File "/Galaxy/galaxy_dist/lib/galaxy/tools/actions/__init__.py", line 203, in execute chrom_info = build_fasta_dataset.get_converted_dataset( trans, 'len' ).file_name File "/Galaxy/galaxy_dist/lib/galaxy/model/__init__.py", line 1161, in get_converted_dataset new_dataset = self.datatype.convert_dataset( trans, self, target_ext, return_output=True, visible=False, deps=deps, set_output_history=False ).values()[0] File "/Galaxy/galaxy_dist/lib/galaxy/datatypes/data.py", line 467, in convert_dataset converted_dataset = converter.execute( trans, incoming=params, set_output_hid=visible, set_output_history=set_output_history)[1] File "/Galaxy/galaxy_dist/lib/galaxy/tools/__init__.py", line 2103, in execute return self.tool_action.execute( self, trans, incoming=incoming, set_output_hid=set_output_hid, history=history, **kwargs ) File "/Galaxy/galaxy_dist/lib/galaxy/tools/actions/__init__.py", line 203, in execute chrom_info = build_fasta_dataset.get_converted_dataset( trans, 'len' ).file_name File "/Galaxy/galaxy_dist/lib/galaxy/model/__init__.py", line 1161, in get_converted_dataset new_dataset = self.datatype.convert_dataset( trans, self, target_ext, return_output=True, visible=False, deps=deps, set_output_history=False ).values()[0] File "/Galaxy/galaxy_dist/lib/galaxy/datatypes/data.py", line 467, in convert_dataset converted_dataset = converter.execute( trans, incoming=params, set_output_hid=visible, set_output_history=set_output_history)[1] File "/Galaxy/galaxy_dist/lib/galaxy/tools/__init__.py", line 2103, in execute return self.tool_action.execute( self, trans, incoming=incoming, set_output_hid=set_output_hid, history=history, **kwargs ) thousands of lines here...ending with... File "/Galaxy/galaxy_dist/eggs/SQLAlchemy-0.5.6_dev_r6498-py2.6.egg/sqlalchemy/schema.py", line 760, in _make_proxy selectable.columns.add(c) File "/Galaxy/galaxy_dist/eggs/SQLAlchemy-0.5.6_dev_r6498-py2.6.egg/sqlalchemy/sql/expression.py", line 1668, in add self[column.key] = column File "/Galaxy/galaxy_dist/eggs/SQLAlchemy-0.5.6_dev_r6498-py2.6.egg/sqlalchemy/sql/expression.py", line 1671, in __setitem__ if key in self: File "/Galaxy/galaxy_dist/eggs/SQLAlchemy-0.5.6_dev_r6498-py2.6.egg/sqlalchemy/sql/expression.py", line 1702, in __contains__ return util.OrderedProperties.__contains__(self, other) File "/Galaxy/galaxy_dist/eggs/SQLAlchemy-0.5.6_dev_r6498-py2.6.egg/sqlalchemy/util.py", line 652, in __contains__ return key in self._data RuntimeError: maximum recursion depth exceeded while calling a Python object Any help would be much appreciated, Thanks in advance, Liisa ___ 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] Blank history panel / Error in history API at listing contents
They likely shouldn't say 'Error' and do increase the noise to signal in the logs. The web transactions have a convenience function for getting the most current history for that transaction's user (get_history). If I understand correctly, these messages occur the transaction can't get or create a history ( when no user is currently logged in - or other situations where such as web crawlers). You can also see these messages in the day-to-day logs of your server, local instance, or the Galaxy main or test servers. As far as I know, they're harmless. C On Fri, Jan 25, 2013 at 5:41 AM, Peter Cock wrote: > On Tue, Jan 22, 2013 at 4:43 PM, Carl Eberhard > wrote: > >>> Short form: > >>> Both the API and client side should handle single datasets error-ing > more > >>> gracefully than they did and the history panel should be more > resilient and > >>> useful during and after a server error (at least of this kind). > >>> > >>> Please let me know if you see more problems, > >>> C > > I'm seeing some (apparently harmless) errors in the output during the > 'upload' > step when running Galaxy unit tests - in this case for one of my tools: > > functional_tests.py INFO 2013-01-25 10:37:19,810 Functional tests will > be run against localhost:9500 > nose.plugins.manager DEBUG 2013-01-25 10:37:19,865 > DefaultPluginManager load plugin sqlalchemy = > sqlalchemy.test.noseplugin:NoseSQLAlchemy > nose.plugins.manager DEBUG 2013-01-25 10:37:19,986 > DefaultPluginManager load plugin nosetestdiff = > nosetestdiff.plugin:NoseTestDiff > nose.plugins.manager DEBUG 2013-01-25 10:37:19,989 > DefaultPluginManager load plugin nosehtml = nosehtml.plugin:NoseHTML > TMHMM 2.0 ( tmhmm2 ) > Test-1 ... galaxy.web.framework DEBUG > 2013-01-25 10:37:20,366 Error: this request returned None from > get_history(): http://localhost:9500/ > galaxy.web.framework DEBUG 2013-01-25 10:37:20,425 Error: this request > returned None from get_history(): http://localhost:9500/ > galaxy.web.framework DEBUG 2013-01-25 10:37:20,676 Error: this request > returned None from get_history(): http://localhost:9500/user/logout > galaxy.web.framework DEBUG 2013-01-25 10:37:20,731 Error: this request > returned None from get_history(): http://localhost:9500/ > galaxy.tools.actions.upload_common INFO 2013-01-25 10:37:24,312 tool > upload1 created job id 1 > galaxy.jobs.manager DEBUG 2013-01-25 10:37:27,460 (1) Job assigned to > handler 'main' > galaxy.jobs DEBUG 2013-01-25 10:37:32,755 (1) Working directory for > job is: /mnt/galaxy/galaxy-central/database/job_working_directory/000/1 > galaxy.jobs.handler DEBUG 2013-01-25 10:37:32,755 dispatching job 1 to > local runner > galaxy.jobs.handler INFO 2013-01-25 10:37:33,041 (1) Job dispatched > galaxy.jobs.runners.local DEBUG 2013-01-25 10:37:33,153 Local runner: > starting job 1 > galaxy.jobs.runners.local DEBUG 2013-01-25 10:37:33,712 executing: ... > > Are these lines just false positives? > Error: this request returned None from get_history(): > http://localhost:9500/ > Error: this request returned None from get_history(): > http://localhost:9500/user/logout > Error: this request returned None from get_history(): > http://localhost:9500/ > > 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/
[galaxy-dev] ce10
Hello, Could somebody please help me uploading the C. elegans genome (Ce10) into galaxy on the cloud? thanks alfonso ___ 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] Only custom genomes for uploads in data libraries
So my quick hack broke this: https://bitbucket.org/galaxy/galaxy-central/commits/0ec7f0b6dec8707b6f4d114468367c9131e61200 To fix this and related issues, I finally took the step of unifying all builds and build information into a single Python data structure: https://bitbucket.org/galaxy/galaxy-central/commits/f36d5d615dd4/ To fix this, then, you can wait for the next Galaxy dist or apply the above changeset manually. Best, J. On Jan 25, 2013, at 12:02 PM, Carlos Borroto wrote: > Hi, > > I'm running latest galaxy-dist locally. When I try to upload a dataset to a > data library through Admin, I only get the two custom genomes I have created > for visualizations. If I use the regular upload tool under "Get data", I do > get to choose any of the genomes in: > tool-data/shared/ucsc/builds.txt > > I tried deleting the custom genomes and then the dropbox menu in the data > libraries upload form is empty. > > Is there something I'm missing? I would like to be able to select any genome > available, custom or not. > > 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/
Re: [galaxy-dev] Tool metadata of Flexbar
Hey Greg, thank you so much for this very quick and detailed answer, as well as a fix for the issue. The observed inconsistencies in the flexbar repo are resolved now. Kind regards Johannes On Jan 25, 2013, at 7:46 PM, Greg Von Kuster wrote: > Hello Johannes, > > I reset all of the metadata on your flexbar repository and I believe it now > displays everything correctly. Metadata is now associated with the following > changeset revisions: > > 14:69ddef2ec7d2 - this is the repository tip and contains Flexbar version 2.31 > > 12:4cbf6c6d2f2b - this changeset has metadata associated with it because it > contains Flexbar version 2.3 > > 5:0a7a3e7559b4 - this changeset also contains Flexbar version 2.3. Metadata > is associated with this changeset because you deleted the Flexbar tool from > the following changeset (6:c0c9b43670d0) > > The behavior you describe is a result of the way you uploaded the various > changes to independent files. When you upload a file, a new mercurial > changeset revision is created, and metadata is defined based on a comparison > of the parent changeset revision and the new repository tip. The basic rule > for setting metadata is if certain components of the parent changeset is not > equal to or a subset f the current changeset (the tip in this discussion). > This approach works very well in most cases, but not so well in corner case > scenarios like this one. Setting metadata on repositories in the tool shed > is a very complex process, so getting it perfect in every scenario is > difficult. I'm always improving the process though, and I'll attempt to > correct the behavior for this scenario. > > The workaround that corrects the behavior in this and all other corner-case > scenarios is to manually reset all metadata on the repository after all of > your uploads are completed. This process inspects the entire changelog > instead of just the repository tip and immediate parent changeset. > > I just committed changeset revision 8663:982aa4ecc7b5 to the Galaxy central > repository that allows repository owners to reset all metadata on their > repositories using the Repository Actions popup menu form the Manage > repository page in the tool shed. This feature used to be restricted to only > Tool Shed administrators. > > This change set is currently running on the test Galaxy tool shed and will be > available on the main Galaxy tool shed 2 Galaxy releases from now. > > Thanks very much for reporting this! > > Greg Von Kuster > > On Jan 25, 2013, at 10:21 AM, Johannes Röhr wrote: > >> Recently, I updated the Flexbar tool definition in the Galaxy Tool Shed >> repository flexbar to work with a new version of the program. I changed the >> version of the tool definition from 2.3 to 2.31, adjusted requirements and >> uploaded files. However, the Flexbar tool in the repo still shows the old >> tool version and requirements, whereas the tool command seems to be updated. >> >> Furthermore, the change log shows that new repository metadata is associated >> with the latest change set, but bizarrely the initial metadata is now >> associated with commit 11 instead of 12, which was the last bugfix commit >> before the update (commit 13). The update took place more than a week ago. >> >> Any suggestions why that is the case? 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/ > ___ 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/
