Re: [galaxy-dev] Reg: Issue while adding simple repository dependencies for custom tool
Hi JanakiRam, galaxy-dist is the stable version of Galaxy and galaxy-central is the development version. But you can also track galaxy-central and the stable branch as I do. Galaxy-central [stable] should be the same as galaxy-dist in theory. In practise galaxy-central [stable] get more fixes during a development window. Galaxy is released ~ every 2 month and the next release will happen in the next 1-2 weeks I think. Galaxy-central (stable-next) ist already branched. Cheers, Bjoern Am 04.04.2014 07:56, schrieb Janaki Rama Rao Gollapudi: Hi Greg/Bjoern, Thanks for all your help. I checkout the galaxy-central code base(previously I am using galaxy-dist code base) and uploaded my custom tool(with both tool and repository dependency) in to toolshed and also installed custom tool from galaxy. The dependency tool also installed successfully. I have few doubts: - When are you planning to merge these changes into galaxy-dist ? - As mentioned in the galaxy wikihttps://wiki.galaxyproject.org/Admin/GetGalaxy we are using galaxy-dist code base. Can we use galaxy-central ? - What is the difference between galaxy-dist and galaxy-central ? Thanks, JanakiRam On Thu, Apr 3, 2014 at 7:54 PM, Björn Grüning bjoern.gruen...@gmail.comwrote: Hi, thanks for fixing it Greg. Would it also be possible to get a more concrete error message in such cases where the repository_dependencies.xml file is somehow broken? Thanks, Bjoern Am 03.04.2014 16:22, schrieb Greg Von Kuster: I should have handled the import in the same commit, but did so in the following changeset. It will eliminate the problematic prior_installation_required=False attribute from the repository tag when a capsule is being imported. changeset: 12944:59bd7349a128 tag: tip user:greg date:Thu Apr 03 10:19:46 2014 -0400 summary: Upon import, handle problematic prior_installation_required attribute incorrectly added (and set to False) to the repository tag when a repository was exported. Greg Von Kuster On Apr 3, 2014, at 9:53 AM, Janaki Rama Rao Gollapudi janakiram.gollap...@india.semanticbits.com wrote: Thanks Greg, I will verify with new changes. Thanks, JanakiRam On Thu, Apr 3, 2014 at 7:05 PM, Greg Von Kuster g...@bx.psu.edu wrote: Hello Janaki and Björn, This problematic behavior is a result of a bug in the repository export process which has been fixed in the following changeset which is currently available in the Galaxy central repo. Thanks very much for reporting this. https://bitbucket.org/galaxy/galaxy-central/commits/ 773578e65580e3488fadc144739d82f86d9b30f3 Greg Von Kuster On Apr 3, 2014, at 7:53 AM, Greg Von Kuster g...@bx.psu.edu wrote: Yes, if that is the behavior, that is definitely a bug. I'll take a look and get back to you on this. Thanks! On Apr 3, 2014, at 7:35 AM, Björn Grüning bjoern.gruen...@gmail.com wrote: Hi JanakiRam, I will take Greg into CC. He is the main Tool Shed developer, maybe we spotted a bug in populating prior_installation_required in repository_dependencies.xml file. He probably knows if that is supposed to work. Greg, to summarize our findings. It seems that if JanakiRam uploads a repository_dependencies.xml file into a local toolshed the prior_installation_required='False' will be inserted. If he tries to install it, Galaxy complains about a wrong syntax inside the repository_dependecies.xml file. Imho prior_installation_required does not make sense in repository_dependencies.xml or? Is that an bug? JanakiRam can you confirm my summary? Thanks, Bjoern Am 03.04.2014 12:49, schrieb Janaki Rama Rao Gollapudi: Hi, I am using latest checkout from https://bitbucket.org/galaxy/galaxy-dist/(Just now I also updated my local galaxy code base). Yes, without repository dependency everything working fine. Thanks, JanakiRam On Thu, Apr 3, 2014 at 3:39 PM, Björn Grüning bjoern.gruen...@gmail.comwrote: Hi, I just tested it in the test-toolshed and for me 'prior_installation_required' is not inserted. Which Galaxy version do you use? Please note, that I'm not sure if that is really causing the trouble you have seen. If you remove the repository dependency everything is working as expected? Am 03.04.2014 12:01, schrieb Janaki Rama Rao Gollapudi: Hi Bjoern, Please see my comments inline. On Thu, Apr 3, 2014 at 3:14 PM, Björn Grüning bjoern.gruen...@gmail.com wrote: Hi Janaki, can you try to remove this prior_installation_required completely? I didn't added 'prior_installation_required' in the repository_dependencies.xml(as this is optional), it got added when I exported repository files from tool shed. Actual repository_dependencies.xml file has below content. ?xml version=1.0? repositories description=test description repository name=string_occurrence owner=janakiram-t1 / /repositories Also why do you need a repository dependency, I think that is not needed or? This is the
Re: [galaxy-dev] Strange issue with datatypes in Galaxy version of last week
Hi Alex, all
FYI - I've added the card to https://trello.com/c/ro8knsaa some time ago. Can
you please vote for it?
Thanks,
Pieter.
From: Bossers, Alex
Sent: dinsdag 25 maart 2014 16:52
To: Lukasse, Pieter
Cc: galaxy-dev@lists.bx.psu.edu
Subject: RE: [galaxy-dev] Strange issue with datatypes in Galaxy version of
last week
Pieter,
I just experienced the same with another generic tabular .tab file output. It
broke the filename at dash without any extension.
The file itself was ok, just the name.
Alex
Van:
galaxy-dev-boun...@lists.bx.psu.edumailto:galaxy-dev-boun...@lists.bx.psu.edu
[mailto:galaxy-dev-boun...@lists.bx.psu.edu] Namens Lukasse, Pieter
Verzonden: dinsdag 25 maart 2014 16:33
Aan: galaxy-dev@lists.bx.psu.edumailto:galaxy-dev@lists.bx.psu.edu
Onderwerp: [galaxy-dev] Strange issue with datatypes in Galaxy version of last
week
Hi,
Apparently a new datatypes bug has been introduced in the Galaxy version of
last week:
I have a tool that generates a csv file. Tool configuration is like this:
outputs
data name=simOut format=msclust.csv label=${tool.name} on ${on_string}
- SIM file/
The datatypes has this entry:
datatype extension=msclust.csv type=galaxy.datatypes.tabular:Tabular
mimetype=text/csv display_in_upload=true subclass=true/
At first Galaxy output seems fine:
[cid:image001.png@01CF4FF4.E1830B70]
But when I download the file, the downloaded file name will be :
Galaxy40-[MsClust_on_data_1_-_SIM_file]-
When I go to edit attributes and just click save, then upon downloading
again, the file name is correct...
Galaxy40-[MsClust_on_data_1_-_SIM_file].msclust.csv .
Anyone faced this issue?
Thanks and regards,
Pieter.
Pieter Lukasse
Wageningen UR, Plant Research International
Departments of Bioscience and Bioinformatics
Wageningen Campus, Building 107, Droevendaalsesteeg 1, 6708 PB,
Wageningen, the Netherlands
+31-317481122; skype: pieter.lukasse.wur
http://www.pri.wur.nlhttp://www.pri.wur.nl/
inline: image001.png___
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] Reg: Issue while adding simple repository dependencies for custom tool
Hello Björn, I've enhanced the error message displayed in 12959:64d677b1e16a, which is available in the next-stable branch, so it will be included in the upcoming release. This message is tricky, because it is only displayed when visiting the Tool Shed from Galaxy to install a repository that has an invalid repository dependency definition. This scenario does not provide the context for the precise cause of the invalid definition. Visiting the Tool Shed directlry (not from Galaxy) and dispaying the repositoryu should provide a more detailed message regarding the problem. Thanks! Greg Von Kuster On Apr 3, 2014, at 10:24 AM, Björn Grüning bjoern.gruen...@gmail.com wrote: Hi, thanks for fixing it Greg. Would it also be possible to get a more concrete error message in such cases where the repository_dependencies.xml file is somehow broken? Thanks, Bjoern Am 03.04.2014 16:22, schrieb Greg Von Kuster: I should have handled the import in the same commit, but did so in the following changeset. It will eliminate the problematic prior_installation_required=False attribute from the repository tag when a capsule is being imported. changeset: 12944:59bd7349a128 tag: tip user:greg date:Thu Apr 03 10:19:46 2014 -0400 summary: Upon import, handle problematic prior_installation_required attribute incorrectly added (and set to False) to the repository tag when a repository was exported. Greg Von Kuster On Apr 3, 2014, at 9:53 AM, Janaki Rama Rao Gollapudi janakiram.gollap...@india.semanticbits.com wrote: Thanks Greg, I will verify with new changes. Thanks, JanakiRam On Thu, Apr 3, 2014 at 7:05 PM, Greg Von Kuster g...@bx.psu.edu wrote: Hello Janaki and Björn, This problematic behavior is a result of a bug in the repository export process which has been fixed in the following changeset which is currently available in the Galaxy central repo. Thanks very much for reporting this. https://bitbucket.org/galaxy/galaxy-central/commits/773578e65580e3488fadc144739d82f86d9b30f3 Greg Von Kuster On Apr 3, 2014, at 7:53 AM, Greg Von Kuster g...@bx.psu.edu wrote: Yes, if that is the behavior, that is definitely a bug. I'll take a look and get back to you on this. Thanks! On Apr 3, 2014, at 7:35 AM, Björn Grüning bjoern.gruen...@gmail.com wrote: Hi JanakiRam, I will take Greg into CC. He is the main Tool Shed developer, maybe we spotted a bug in populating prior_installation_required in repository_dependencies.xml file. He probably knows if that is supposed to work. Greg, to summarize our findings. It seems that if JanakiRam uploads a repository_dependencies.xml file into a local toolshed the prior_installation_required='False' will be inserted. If he tries to install it, Galaxy complains about a wrong syntax inside the repository_dependecies.xml file. Imho prior_installation_required does not make sense in repository_dependencies.xml or? Is that an bug? JanakiRam can you confirm my summary? Thanks, Bjoern Am 03.04.2014 12:49, schrieb Janaki Rama Rao Gollapudi: Hi, I am using latest checkout from https://bitbucket.org/galaxy/galaxy-dist/(Just now I also updated my local galaxy code base). Yes, without repository dependency everything working fine. Thanks, JanakiRam On Thu, Apr 3, 2014 at 3:39 PM, Björn Grüning bjoern.gruen...@gmail.comwrote: Hi, I just tested it in the test-toolshed and for me 'prior_installation_required' is not inserted. Which Galaxy version do you use? Please note, that I'm not sure if that is really causing the trouble you have seen. If you remove the repository dependency everything is working as expected? Am 03.04.2014 12:01, schrieb Janaki Rama Rao Gollapudi: Hi Bjoern, Please see my comments inline. On Thu, Apr 3, 2014 at 3:14 PM, Björn Grüning bjoern.gruen...@gmail.com wrote: Hi Janaki, can you try to remove this prior_installation_required completely? I didn't added 'prior_installation_required' in the repository_dependencies.xml(as this is optional), it got added when I exported repository files from tool shed. Actual repository_dependencies.xml file has below content. ?xml version=1.0? repositories description=test description repository name=string_occurrence owner=janakiram-t1 / /repositories Also why do you need a repository dependency, I think that is not needed or? This is the first time I working with repository dependencies, so for testing I am trying to add simple repository dependency to my custom tool. Cheers, Bjoern Am 03.04.2014 09:30, schrieb Janaki Rama Rao Gollapudi: Hi Bjoern, I also exported both the repositories from local toolshed. Please find the attached files. Thanks, JanakiRam On Thu, Apr 3, 2014 at 12:50 PM, Janaki Rama Rao Gollapudi janakiram.gollap...@india.semanticbits.com
[galaxy-dev] The main Galaxy Tool Shed is now running the next-stable branch
For those interested, The main Galaxy Tool Shed is now running the next-stable branch in preparation for the upcoming Galaxy release currently scheduled for about 2 weeks from now. We'll continue to update the Tool Shed as new changeset are pushed to the next-stable branch. We'll alert you wnen the main Tool Shed is updated to the stable branch when it is tagged for the next Galaxy release. As usual, the test Galaxy Tool Shed continues to track the default branch. Thanks! Greg Von Kuster ___ 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] Download workflow from main Galaxy
Dear there, I tried to download workflow and import it into another my local Galaxy instance. But, when I downloaded and exported it from main Galaxy by Download to File, it showed as below. Not Found The resource could not be found. No route for /u/w/imported-cloudmap-ems-variant-density-mapping-workflow-takes-vcf-of-heterozygous-and-homozygous-variants-to-subtract/json-download Then, I tried URL for Importing to Another Galaxy Use this URL to import the workflow directly into another Galaxy server: https://usegalaxy.org/u//w/imported-cloudmap-ems-variant-density-mapping-workflow-takes-vcf-of-heterozygous-and-homozygous-variants-to-subtract/json (Copy this URL into the box titled 'Workflow URL' in the Import Workflow page.) , it showed Failed to open URL: https://usegalaxy.org/u//w/imported-cloudmap-ems-variant-density-mapping-workflow-takes-vcf-of-heterozygous-and-homozygous-variants-to-subtract/json Exception: HTTP Error 404: Not Found What is the reason for this? Many thanks for helping me! Best, Xiaofei ___ 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] version of SAM-to-BAM (CloudMap)
Hi Xiaofei, You should be able to install 1.1.3 by selecting revision 3 of sam_to_bam from the Preview and install page (Admin - Search and browse tool sheds - Galaxy main tool shed - sam_to_bam - Preview and install), and then clicking Install to Galaxy. [image: Inline image 1] You can tell what version of the tool it'll install by looking at the Valid tools section of the Contents of this repository box. --nate On Thu, Apr 3, 2014 at 6:16 PM, Wang, Xiaofei xfw...@ku.edu wrote: Dear there, When I run CloudMap EMS Variant Density Mapping workflow (takes VCF of heterozygous and homozygous variants to subtract) (imported from uploaded file) on local Galaxy instance, I got this , when I wanted to edit the workflow. Also, I got this The following tools are beinge executed with a different version from what was available when this workflow was last saved because the previous version is no longer available for use on this galaxy instance. To upgrade your workflow and dismiss this message simply edit the workflow and re-save it to update the stored tool version. - toolshed.g2.bx.psu.edu/repos/devteam/sam_to_bam/sam_to_bam/1.1.2: using version '1.1.2' instead of version '1.1.3' indicated in this workflow. - ,when I wanted to run the workflow. I know it is the problem with version of SAM-to-BAM. But, when I searched the Tool sheds Search and browse tool sheds, there is only version 1.1.4 for SAM-to-BAM. When I tried to edit the workflow from Workflow ... Edit, I did not find where could I change the version of SAM-to-BAM. When I clicked on SAM-to-BAM on the Workflow Canvas, it showed the version is 1.1.3 for it. Could you tell me which version do I need exactly, and how to figure out this? Thanks a lot! Best, Xiaofei ___ 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/ inline: sam_to_bam_3.png___ 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] Download workflow from main Galaxy
Hello Xiaofei, it seems you don't have username set in usegalaxy.org and thus the links generated are wrong. Can you please set one (user/preferences/manage information) and try again? thanks Martin Galaxy team On Fri, Apr 4, 2014 at 12:07 PM, Wang, Xiaofei xfw...@ku.edu wrote: Dear there, I tried to download workflow and import it into another my local Galaxy instance. But, when I downloaded and exported it from main Galaxy by Download to File, it showed as below. Not Found The resource could not be found. No route for /u/w/imported-cloudmap-ems-variant-density-mapping-workflow-takes-vcf-of-heterozygous-and-homozygous-variants-to-subtract/json-download Then, I tried URL for Importing to Another Galaxy Use this URL to import the workflow directly into another Galaxy server: https://usegalaxy.org/u//w/imported-cloudmap-ems-variant-density-mapping-workflow-takes-vcf-of-heterozygous-and-homozygous-variants-to-subtract/json (Copy this URL into the box titled 'Workflow URL' in the Import Workflow page.) , it showed Failed to open URL: *https://usegalaxy.org/u//w/imported-cloudmap-ems-variant-density-mapping-workflow-takes-vcf-of-heterozygous-and-homozygous-variants-to-subtract/json https://usegalaxy.org/u//w/imported-cloudmap-ems-variant-density-mapping-workflow-takes-vcf-of-heterozygous-and-homozygous-variants-to-subtract/json* Exception: HTTP Error 404: Not Found What is the reason for this? Many thanks for helping me! Best, Xiaofei ___ 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] Problem with Tools in Workflow Editor
Hi All, I posted this earlier in the week, but haven't heard anything. I changed the title of the email to hopefully attract more attention. We are getting errors when creating a workflow. Some of the tools, when selected, say only error loading field data. As such, we cannot use them in workflows, even though the tools work fine in Analyze Data. This seems like it is correlated with the fact that we developed these tools, and changed their names along the way. If this is the cause, one solution could be for us to clear Tool Versions/Version lineage in our galaxy instance. Is there a way to clear our cluttered tool lineages? Thanks for any insights, Todd Oakley, UCSB ___ 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] Download workflow from main Galaxy
Yes, I really appreciate for your help! From: emulato...@gmail.com [emulato...@gmail.com] on behalf of Martin Čech [mar...@bx.psu.edu] Sent: Friday, April 04, 2014 11:28 AM To: Wang, Xiaofei Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Download workflow from main Galaxy Hello Xiaofei, it seems you don't have username set in usegalaxy.orghttp://usegalaxy.org and thus the links generated are wrong. Can you please set one (user/preferences/manage information) and try again? thanks Martin Galaxy team On Fri, Apr 4, 2014 at 12:07 PM, Wang, Xiaofei xfw...@ku.edumailto:xfw...@ku.edu wrote: Dear there, I tried to download workflow and import it into another my local Galaxy instance. But, when I downloaded and exported it from main Galaxy by Download to File, it showed as below. Not Found The resource could not be found. No route for /u/w/imported-cloudmap-ems-variant-density-mapping-workflow-takes-vcf-of-heterozygous-and-homozygous-variants-to-subtract/json-download Then, I tried URL for Importing to Another Galaxy Use this URL to import the workflow directly into another Galaxy server: https://usegalaxy.org/u//w/imported-cloudmap-ems-variant-density-mapping-workflow-takes-vcf-of-heterozygous-and-homozygous-variants-to-subtract/json (Copy this URL into the box titled 'Workflow URL' in the Import Workflow page.) , it showed Failed to open URL: https://usegalaxy.org/u//w/imported-cloudmap-ems-variant-density-mapping-workflow-takes-vcf-of-heterozygous-and-homozygous-variants-to-subtract/json Exception: HTTP Error 404: Not Found What is the reason for this? Many thanks for helping me! Best, Xiaofei ___ 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] version of SAM-to-BAM (CloudMap)
Yes, it is figured out when I downloaded the version of 1.1.2. I thought is no longer available. Thank you so much! Best, Xiaofei From: Nate Coraor [n...@bx.psu.edu] Sent: Friday, April 04, 2014 11:20 AM To: Wang, Xiaofei Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] version of SAM-to-BAM (CloudMap) Hi Xiaofei, You should be able to install 1.1.3 by selecting revision 3 of sam_to_bam from the Preview and install page (Admin - Search and browse tool sheds - Galaxy main tool shed - sam_to_bam - Preview and install), and then clicking Install to Galaxy. [Inline image 1] You can tell what version of the tool it'll install by looking at the Valid tools section of the Contents of this repository box. --nate On Thu, Apr 3, 2014 at 6:16 PM, Wang, Xiaofei xfw...@ku.edumailto:xfw...@ku.edu wrote: Dear there, When I run CloudMap EMS Variant Density Mapping workflow (takes VCF of heterozygous and homozygous variants to subtract) (imported from uploaded file) on local Galaxy instance, I got this [X] , when I wanted to edit the workflow. Also, I got this The following tools are beinge executed with a different version from what was available when this workflow was last saved because the previous version is no longer available for use on this galaxy instance. To upgrade your workflow and dismiss this message simply edit the workflow and re-save it to update the stored tool version. * toolshed.g2.bx.psu.edu/repos/devteam/sam_to_bam/sam_to_bam/1.1.2http://toolshed.g2.bx.psu.edu/repos/devteam/sam_to_bam/sam_to_bam/1.1.2: using version '1.1.2' instead of version '1.1.3' indicated in this workflow. * ,when I wanted to run the workflow. I know it is the problem with version of SAM-to-BAM. But, when I searched the Tool sheds Search and browse tool sheds, there is only version 1.1.4 for SAM-to-BAM. When I tried to edit the workflow from Workflow ... Edit, I did not find where could I change the version of SAM-to-BAM. When I clicked on SAM-to-BAM on the Workflow Canvas, it showed the version is 1.1.3 for it. Could you tell me which version do I need exactly, and how to figure out this? Thanks a lot! Best, Xiaofei ___ 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/ inline: sam_to_bam_3.png___ 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] Depth of Coverage (local galaxy __ CloudMap)
Dear there, I got this error when I run CloudMap EMS Variant Density Mapping workflow for Depth of Coverage on the local Galaxy instance on Mac. In fact, it works fine for Depth of Coverage when I run another workflow (Unmapped Mutant workflow) locally. I really appreciate you guys for helping me to figure out so many problems! Thanks a lot! Best, Xiaofei Traceback (most recent call last): File /Users/xiaofeiwang/softwares/galaxy-dist/lib/galaxy/jobs/runners/__init__.py, line 152, in prepare_job job_wrapper.prepare() File /Users/xiaofeiwang/softwares/galaxy-dist/lib/galaxy/jobs/__init__.py, line 652, in prepare if job.user is None and job.galaxy_session is None: File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/attributes.py, line 168, in __get__ return self.impl.get(instance_state(instance),dict_) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/attributes.py, line 453, in get value = self.callable_(state, passive) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/strategies.py, line 508, in _load_for_state return self._emit_lazyload(session, state, ident_key) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/strategies.py, line 552, in _emit_lazyload return q._load_on_ident(ident_key) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/query.py, line 2512, in _load_on_ident return q.one() File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/query.py, line 2184, in one ret = list(self) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/query.py, line 2227, in __iter__ return self._execute_and_instances(context) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/query.py, line 2242, in _execute_and_instances result = conn.execute(querycontext.statement, self._params) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/engine/base.py, line 1449, in execute params) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/engine/base.py, line 1584, in _execute_clauseelement compiled_sql, distilled_params File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/engine/base.py, line 1698, in _execute_context context) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/engine/base.py, line 1691, in _execute_context context) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/engine/default.py, line 331, in do_execute cursor.execute(statement, parameters) OperationalError: (OperationalError) database is locked u'SELECT galaxy_user.id AS galaxy_user_id, galaxy_user.create_time AS galaxy_user_create_time, galaxy_user.update_time AS galaxy_user_update_time, galaxy_user.email AS galaxy_user_email, galaxy_user.username AS galaxy_user_username, galaxy_user.password AS galaxy_user_password, galaxy_user.external AS galaxy_user_external, galaxy_user.form_values_id AS galaxy_user_form_values_id, galaxy_user.deleted AS galaxy_user_deleted, galaxy_user.purged AS galaxy_user_purged, galaxy_user.disk_usage AS galaxy_user_disk_usage, galaxy_user.active AS galaxy_user_active, galaxy_user.activation_token AS galaxy_user_activation_token \nFROM galaxy_user \nWHERE galaxy_user.id = ?' (1,) ___ 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] Depth of Coverage (local galaxy __ CloudMap)
Hi Xiaofei, SQLite is not suitable for complex tasks like running workflows. Please switch to PostgreSQL: https://wiki.galaxyproject.org/Admin/Config/Performance/ProductionServer#Switching_to_a_database_server --nate On Fri, Apr 4, 2014 at 1:35 PM, Wang, Xiaofei xfw...@ku.edu wrote: Dear there, I got this error when I run CloudMap EMS Variant Density Mapping workflow for Depth of Coverage on the local Galaxy instance on Mac. In fact, it works fine for Depth of Coverage when I run another workflow (Unmapped Mutant workflow) locally. I really appreciate you guys for helping me to figure out so many problems! Thanks a lot! Best, Xiaofei Traceback (most recent call last): File /Users/xiaofeiwang/softwares/galaxy-dist/lib/galaxy/jobs/runners/__init__.py, line 152, in prepare_job job_wrapper.prepare() File /Users/xiaofeiwang/softwares/galaxy-dist/lib/galaxy/jobs/__init__.py, line 652, in prepare if job.user is None and job.galaxy_session is None: File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/attributes.py, line 168, in __get__ return self.impl.get(instance_state(instance),dict_) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/attributes.py, line 453, in get value = self.callable_(state, passive) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/strategies.py, line 508, in _load_for_state return self._emit_lazyload(session, state, ident_key) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/strategies.py, line 552, in _emit_lazyload return q._load_on_ident(ident_key) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/query.py, line 2512, in _load_on_ident return q.one() File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/query.py, line 2184, in one ret = list(self) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/query.py, line 2227, in __iter__ return self._execute_and_instances(context) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/orm/query.py, line 2242, in _execute_and_instances result = conn.execute(querycontext.statement, self._params) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/engine/base.py, line 1449, in execute params) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/engine/base.py, line 1584, in _execute_clauseelement compiled_sql, distilled_params File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/engine/base.py, line 1698, in _execute_context context) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/engine/base.py, line 1691, in _execute_context context) File /Users/xiaofeiwang/softwares/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-macosx-10.6-intel-ucs2.egg/sqlalchemy/engine/default.py, line 331, in do_execute cursor.execute(statement, parameters) OperationalError: (OperationalError) database is locked u'SELECT galaxy_user.id AS galaxy_user_id, galaxy_user.create_time AS galaxy_user_create_time, galaxy_user.update_time AS galaxy_user_update_time, galaxy_user.email AS galaxy_user_email, galaxy_user.username AS galaxy_user_username, galaxy_user.password AS galaxy_user_password, galaxy_user.external AS galaxy_user_external, galaxy_user.form_values_id AS galaxy_user_form_values_id, galaxy_user.deleted AS galaxy_user_deleted, galaxy_user.purged AS galaxy_user_purged, galaxy_user.disk_usage AS galaxy_user_disk_usage, galaxy_user.active AS galaxy_user_active, galaxy_user.activation_token AS galaxy_user_activation_token \nFROM galaxy_user \nWHERE galaxy_user.id = ?' (1,) ___ 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
[galaxy-dev] This tool was disabled before the job completed. Please contact your Galaxy administrator.
Hi devs, I deleted a tool called upload_local_file and tried to restart galaxy server but I keep getting the following error. Any idea how to solve this? File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/webapps/galaxy/buildapp.py, line 39, in app_factory app = UniverseApplication( global_conf = global_conf, **kwargs ) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/app.py, line 130, in __init__ self.job_manager = manager.JobManager( self ) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/manager.py, line 37, in __init__ self.job_handler.start() File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/handler.py, line 35, in start self.job_queue.start() File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/handler.py, line 78, in start self.__check_jobs_at_startup() File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/handler.py, line 109, in __check_jobs_at_startup JobWrapper( job, self ).fail( 'This tool was disabled before the job completed. Please contact your Galaxy administrator.' ) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/__init__.py, line 761, in fail self.app.object_store.update_from_file(dataset.dataset, create=True) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/objectstore/__init__.py, line 349, in update_from_file self.create(obj, **kwargs) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/objectstore/__init__.py, line 298, in create open(path, 'w').close() # Should be rb? IOError: [Errno 2] No such file or directory: '/global/scratch/galaxy/webapp/files/000/dataset_194.dat' Thanks Ravi___ 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] [CONTENT] Re: Re: Re: Re: Unable to remove old datasets
Hi Ravi, I believe admin_cleanup_datasets.py only works on database times. The rest of your assumptions are likely correct, although without looking at more details of the database I can't confirm. --nate On Fri, Mar 28, 2014 at 5:12 PM, Sanka, Ravi rsa...@jcvi.org wrote: Hi Nate, I checked and there are 3 rows of dataset 301 in the history_dataset_association table (none in library_dataset_dataset_association): dataset_id create_time update_time deleted 301 2/14/14 18:49 3/25/14 20:27 TRUE 301 3/6/14 15:48 3/25/14 18:41 TRUE 301 3/6/14 20:11 3/6/14 20:11 FALSE The one with the most recent create_time has its deleted status set to false. The other 2, older ones are true. I would have guessed that the most recent create_time instance is still false due being created within 30 days, but the second most recent is only 5 hours older and is set to true. Perhaps that instance was deleted by its user. That would cause its deleted status to become true, correct? I assume that if I were to wait until all 3 instances' create_times are past 30 days, my process will work, as admin_cleanup_datasets.py will set all 3 instances to false. Perchance, is there any setting on admin_cleanup_datasets.py that would cause it to judge datasets by their physical file's timestamp instead? -- Ravi Sanka ICS - Sr. Bioinformatics Engineer J. Craig Venter Institute 301-795-7743 -- From: Nate Coraor n...@bx.psu.edu Date: Friday, March 28, 2014 1:56 PM To: Ravi Sanka rsa...@jcvi.org Cc: Carl Eberhard carlfeberh...@gmail.com, Peter Cock p.j.a.c...@googlemail.com, galaxy-dev@lists.bx.psu.edu galaxy-dev@lists.bx.psu.edu Subject: [CONTENT] Re: Re: [galaxy-dev] Re: Re: Unable to remove old datasets Hi Ravi, Can you check whether any other history_dataset_association or library_dataset_dataset_association rows exist which reference the dataset_id that you are attempting to remove? When you run admin_cleanup_datasets.py, it'll set history_dataset_association.deleted = true. After that is done, you need to run cleanup_datasets.py with the `-6 -d 0` option to mark dataset.deleted = true, followed by `-3 -d 0 -r ` to remove the dataset file from disk and set dataset.purged = true. Note that the latter two operations will not do anything until *all* associated history_dataset_association and library_dataset_dataset_association rows are set to deleted = true. --nate On Fri, Mar 28, 2014 at 1:52 PM, Sanka, Ravi rsa...@jcvi.org wrote: Hi Nate, I checked the dataset's entry in history_dataset_association, and the value in field deleted is true. But if this does not enable the cleanup scripts to remove the dataset from disk, then how can I accomplish that? As an admin, my intention is to completely remove datasets that are past a certain age from Galaxy, including all instances of the dataset that may exist, regardless of whether or not the various users who own said instances have deleted them from their histories. Can this be done with admin_cleanup_datasets.py? If so, how? -- Ravi Sanka ICS - Sr. Bioinformatics Engineer J. Craig Venter Institute 301-795-7743 -- From: Nate Coraor n...@bx.psu.edu Date: Friday, March 28, 2014 9:59 AM To: Ravi Sanka rsa...@jcvi.org Cc: Carl Eberhard carlfeberh...@gmail.com, Peter Cock p.j.a.c...@googlemail.com, galaxy-dev@lists.bx.psu.edu galaxy-dev@lists.bx.psu.edu Subject: [CONTENT] Re: [galaxy-dev] Re: Re: Unable to remove old datasets Hi Ravi, If you take a look at the dataset's entry in the history_dataset_association table, is that marked deleted? admin_cleanup_datasets.py only marks history_dataset_association rows deleted, not datasets. Running the cleanup_datasets.py flow with -d 0 should have then caused the dataset to be deleted and purged, but this may not be the case if there is more than one instance of the dataset you are trying to purge (either another copy in a history somewhere, or in a library). --nate On Tue, Mar 25, 2014 at 5:12 PM, Sanka, Ravi rsa...@jcvi.org wrote: I have now been able to successfully remove datasets from disk. After deleting the dataset or history from the front-end interface (as the user), I then run the cleanup scripts as admin: python ./scripts/cleanup_datasets/cleanup_datasets.py ./universe_wsgi.ini -d 0 -1 $@ ./scripts/cleanup_datasets/delete_userless_histories.log python ./scripts/cleanup_datasets/cleanup_datasets.py ./universe_wsgi.ini -d 0 -2 -r $@ ./scripts/cleanup_datasets/purge_histories.log python ./scripts/cleanup_datasets/cleanup_datasets.py ./universe_wsgi.ini -d 0 -3 -r $@ ./scripts/cleanup_datasets/purge_datasets.log python ./scripts/cleanup_datasets/cleanup_datasets.py ./universe_wsgi.ini -d 0 -5 -r $@ ./scripts/cleanup_datasets/purge_folders.log
Re: [galaxy-dev] Galaxy packages for Bio-Linux - an update + Apache proxying
Hi Tim, I agree the single tool_data_table_conf.xml is a problem and it would be nice to implement functionality for multiple. I've added a Trello card for it here: https://trello.com/c/rm2p8PpZ As to the location file collections, I can foresee a few problems, e.g. conflicting definitions, bad formatting of the metadata in location file comments, and still needing to specify multiple paths where these location files can exist. --nate On Mon, Mar 31, 2014 at 8:00 AM, Tim Booth tbo...@ceh.ac.uk wrote: Hi Nate, It's great to hear that my rearrangements for packaging Galaxy are somewhat in line with what you are doing. My package is a bit of a rats-nest of symlinks right now but I'll clean these up as things become more configurable. One thing I'm a bit stuck on is the tool_data_table_conf.xml and shed_tool_data_table_conf.xml files. If the former is installed and updated by my package and the latter is managed by the internal tool-shed logic then this leaves nowhere for the user to make manual edits (we can use the debian config-files system to share ownership but it's awkward). Also I've made a galaxy-tools-bl package that adds some standard tool definitions in a file called bl_tool_conf.xml. I can set things up so this is seen by Galaxy: [app:main] ... tool_config_file = tool_conf.xml,shed_tool_conf.xml,bl_tool_conf.xml So I can split out tool_conf.xml but currently I can't split out items in tool_data_table_conf.xml (unless I make a startup script that compiles it on the fly from XML fragments, in the style of build_universe_config.py). Now if it were me I'd try and eliminate this XML file altogether, and have Galaxy just collect up all the available .loc files on startup without the need for a central registry file. This would involve embedding the couple of bits of metadata from the tool_data_table_conf.xml XML file into the .loc files themselves, and maybe there is some reason I've not spotted why this would be a bad idea. Any thoughts on this? Is it something you have considered or would consider? Cheers, TIM On Fri, 2014-03-28 at 18:49 +, Nate Coraor wrote: Hi Tim, I have recently been working on getting Galaxy Main's configs and server-modified files and directories out of the galaxy-dist directory, so our goals are aligning. Not everything can be moved without some trickery (e.g. symlinks) but most paths, including the paths to shed_*.xml are configurable in universe_wsgi.ini (which itself need not live in the galaxy-dist directory). --nate On Mon, Mar 24, 2014 at 1:38 PM, Tim Booth tbo...@ceh.ac.uk wrote: Hi, This is mainly a message to Carlos and Eric who volunteered to get involved with my Debian packaging, but of course any other help will also be appreciated. If either of you can spare time now it is a good moment to do so. I've been working on my package stuff over the last couple of weeks and have uploaded the latest to Debian-Med ready to build: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/galaxy/trunk/debian/?view=log Note that you need the re-packed tarball as generated by get-orig-source.sh and if you have a problem generating that you can grab a copy of it here: https://launchpad.net/~nebc/+archive/galaxy/+files/galaxy_1.bl.py27.20140210.orig.tar.xz I've only built this for Ubuntu, and I know that to get it working on Debian you'll at least need to replace the upstart job with an /etc/init.d script. After that I think you should have something working (see my commit notes). My latest efforts have been to try and get tool-shed installs working. Galaxy expects to be able to write to its own shed_tools_*_conf.xml files as well as to shed_tools and the tool-data directory. It looks like there is work to have a separate shed_tool-data folder but this is not fully working so I'm seeing if I can patch it. Either way, it's vital for packaging that the files managed by DPKG and the files (over)written by the Galaxy server are separated out into /var and /usr respectively. Cheers, TIM On Mon, 2013-12-16 at 16:27 +, Carlos Borroto wrote: Hi Tim, This sounds great. I'll be happy to help testing and hopefully find some time to help packaging once it gets into Debian Med(are you submitting all your packages there?). One question, for apache/nginx configuration why not use something ala phpMyAdmin which ask you if you want to preconfigure the package with
Re: [galaxy-dev] This tool was disabled before the job completed. Please contact your Galaxy administrator.
Anyone please?? I cannot even start the galaxy server. Makes me wonder if something in the database got messed up. On Apr 4, 2014, at 11:16 AM, Ravi Alla ravi.a...@berkeley.edu wrote: Hi devs, I deleted a tool called upload_local_file and tried to restart galaxy server but I keep getting the following error. Any idea how to solve this? File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/webapps/galaxy/buildapp.py, line 39, in app_factory app = UniverseApplication( global_conf = global_conf, **kwargs ) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/app.py, line 130, in __init__ self.job_manager = manager.JobManager( self ) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/manager.py, line 37, in __init__ self.job_handler.start() File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/handler.py, line 35, in start self.job_queue.start() File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/handler.py, line 78, in start self.__check_jobs_at_startup() File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/handler.py, line 109, in __check_jobs_at_startup JobWrapper( job, self ).fail( 'This tool was disabled before the job completed. Please contact your Galaxy administrator.' ) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/__init__.py, line 761, in fail self.app.object_store.update_from_file(dataset.dataset, create=True) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/objectstore/__init__.py, line 349, in update_from_file self.create(obj, **kwargs) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/objectstore/__init__.py, line 298, in create open(path, 'w').close() # Should be rb? IOError: [Errno 2] No such file or directory: '/global/scratch/galaxy/webapp/files/000/dataset_194.dat' Thanks Ravi ___ 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] This tool was disabled before the job completed. Please contact your Galaxy administrator.
Never mind, I figured it out. I deleted all instances of the job and the temp dataset. Thanks R On Apr 4, 2014, at 2:29 PM, Ravi Alla ravi.a...@berkeley.edu wrote: Anyone please?? I cannot even start the galaxy server. Makes me wonder if something in the database got messed up. On Apr 4, 2014, at 11:16 AM, Ravi Alla ravi.a...@berkeley.edu wrote: Hi devs, I deleted a tool called upload_local_file and tried to restart galaxy server but I keep getting the following error. Any idea how to solve this? File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/webapps/galaxy/buildapp.py, line 39, in app_factory app = UniverseApplication( global_conf = global_conf, **kwargs ) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/app.py, line 130, in __init__ self.job_manager = manager.JobManager( self ) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/manager.py, line 37, in __init__ self.job_handler.start() File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/handler.py, line 35, in start self.job_queue.start() File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/handler.py, line 78, in start self.__check_jobs_at_startup() File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/handler.py, line 109, in __check_jobs_at_startup JobWrapper( job, self ).fail( 'This tool was disabled before the job completed. Please contact your Galaxy administrator.' ) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/jobs/__init__.py, line 761, in fail self.app.object_store.update_from_file(dataset.dataset, create=True) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/objectstore/__init__.py, line 349, in update_from_file self.create(obj, **kwargs) File /srv/www/galaxy/source/galaxy-dist/lib/galaxy/objectstore/__init__.py, line 298, in create open(path, 'w').close() # Should be rb? IOError: [Errno 2] No such file or directory: '/global/scratch/galaxy/webapp/files/000/dataset_194.dat' Thanks Ravi ___ 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/
