[galaxy-dev] Deleting tmp files
Hi all, I would just like to ask if the tmp files in the galaxy-dist/database/tmp could be removed manually. Also, I ran into this error when I was purging my deleted datasets: Error attempting to purge data file: /home/applications/galaxy-dist/database/files/000/dataset_89.dat error: unsupported operand type(s) for -=: 'Decimal' and 'NoneType' What does that mean? I am new to Galaxy and to python, so I was a bit confused after seeing this error. The purging went on fine, though. The datasets have been removed from the database. Cheers, CL ___ 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] run job as real user error: environment variables issue?
Mmm... for some reason LD_LIBRARY_PATH was ignored but it looks like it's working fine when I set the lib path in a .conf file in /etc/ld.so.conf.d/ Hopefully it'll not break again :) Best, L-A Le 19/04/2012 17:19, Louise-Amélie Schmitt a écrit : Hi everyone, I'm currently trying to set up our local Galaxy so it can run jobs as the real user. I followed the documentation and set the galaxy user as a sudoer. However, I get an error message whenever I'm trying to run a job: galaxy.jobs.runners.drmaa ERROR 2012-04-19 14:57:48,376 Uncaught exception queueing job Traceback (most recent call last): File /g/funcgen/galaxy-dev/lib/galaxy/jobs/runners/drmaa.py, line 133, in run_next self.queue_job( obj ) File /g/funcgen/galaxy-dev/lib/galaxy/jobs/runners/drmaa.py, line 219, in queue_job job_id = self.external_runjob(filename, job_wrapper.user_system_pwent[2]).strip() File /g/funcgen/galaxy-dev/lib/galaxy/jobs/runners/drmaa.py, line 427, in external_runjob raise RuntimeError(External_runjob failed (exit code %s)\nCalled from %s:%d\nChild process reported error:\n%s % (str(exitcode), __filename__(), __lineno__(), stderrdata)) RuntimeError: External_runjob failed (exit code 127) Called from /g/funcgen/galaxy-dev/lib/galaxy/jobs/runners/drmaa.py:427 Child process reported error: python: error while loading shared libraries: libpython2.6.so.1.0: cannot open shared object file: No such file or directory Looking closely, it's the non-root user it tries to switch to that doesn't have the LD_LIBRARY_PATH properly set, so there should be an environment inheritance issue. However, I tried to print stuff from the scripts/drmaa_external_runner.py script in EVERY WAY I could think of, to no avail. As if it doesn't even run. Which is surprising since root can run python properly, so it really looks like it's really changing users. I really fail to see where the problem could come from, so if you have leads to suggest, I'll be forever grateful. Best, L-A ___ 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] BAM to BigWig (and tool ID clashes)
On Fri, Apr 20, 2012 at 2:17 AM, Brad Chapman chapm...@50mail.com wrote: Lance and Peter; Peter, thanks for noticing the problem and duplicate tools. Lance, I'm happy to merge these so there are not two different versions out there. I prefer your use for genomeCoverageBed over my custom hacks. That's a nice approach I totally missed. I avoid the need for the sam indexes by creating the file directly from the information in the BAM header. I don't think there is any way around creating it since it's required by the UCSC tools as well, but everything you need is in the BAM header. Indeed - I remember looking at that with you back in March 2011, including the special case of BAM files lacking an embedded SAM header (where the BAM header alone suffices). There might be a sneaky way to do this with samtools -H and awk but I'm not nearly skilled enough to pull that out. Using pysam works nicely, and therefore I stuck with Python ;) Let me know what you think. I can also update my python wrapper script to use the genomeCoverageBed approach instead if you think that's easier. I've made the update to Brad's script from the Tool Shed (attached), switching to using genomeCoverageBed and bedGraphToBigWig (based on the approach used in Lance's script), although in doing so I dropped the region support (which wasn't exposed to the Galaxy interface anyway). Since genomeCoverageBed doesn't support this directly, we could use samtools view for this I think - if you want this functionality. Sadly then I noticed that the Tool Shed version was out of date - lacking the new normalization option added here: https://github.com/chapmanb/bcbb/commits/master/nextgen/scripts/bam_to_wiggle.py This was enough for my immediate needs today, but I'd happily try and merge this into the git version and update the XML file to match and add the new split option. We could list this as three contributing authors if you both like? Peter bam_to_bigwig.py Description: Binary data ___ 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] BAM to BigWig (and tool ID clashes)
I'm happy to have a merged version and put us all down as contributing authors. I won't have a chance to look at the code until next week, but I'd be happy to help out with any merging, etc. Thanks to both of you for you help an input. Lance Peter Cock wrote: On Fri, Apr 20, 2012 at 2:17 AM, Brad Chapmanchapm...@50mail.com wrote: Lance and Peter; Peter, thanks for noticing the problem and duplicate tools. Lance, I'm happy to merge these so there are not two different versions out there. I prefer your use for genomeCoverageBed over my custom hacks. That's a nice approach I totally missed. I avoid the need for the sam indexes by creating the file directly from the information in the BAM header. I don't think there is any way around creating it since it's required by the UCSC tools as well, but everything you need is in the BAM header. Indeed - I remember looking at that with you back in March 2011, including the special case of BAM files lacking an embedded SAM header (where the BAM header alone suffices). There might be a sneaky way to do this with samtools -H and awk but I'm not nearly skilled enough to pull that out. Using pysam works nicely, and therefore I stuck with Python ;) Let me know what you think. I can also update my python wrapper script to use the genomeCoverageBed approach instead if you think that's easier. I've made the update to Brad's script from the Tool Shed (attached), switching to using genomeCoverageBed and bedGraphToBigWig (based on the approach used in Lance's script), although in doing so I dropped the region support (which wasn't exposed to the Galaxy interface anyway). Since genomeCoverageBed doesn't support this directly, we could use samtools view for this I think - if you want this functionality. Sadly then I noticed that the Tool Shed version was out of date - lacking the new normalization option added here: https://github.com/chapmanb/bcbb/commits/master/nextgen/scripts/bam_to_wiggle.py This was enough for my immediate needs today, but I'd happily try and merge this into the git version and update the XML file to match and add the new split option. We could list this as three contributing authors if you both like? Peter -- 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/
Re: [galaxy-dev] BAM to BigWig (and tool ID clashes)
Peter and Lance; I've made the update to Brad's script from the Tool Shed (attached), switching to using genomeCoverageBed and bedGraphToBigWig (based on the approach used in Lance's script), although in doing so I dropped the region support (which wasn't exposed to the Galaxy interface anyway). Since genomeCoverageBed doesn't support this directly, we could use samtools view for this I think - if you want this functionality. Awesome, thanks for doing this so quickly. Leaving out the region support for now is fine with me. I gave both of you write access to that repo on the Toolshed so feel free to check in and edit away. Thanks again for tackling this, Brad ___ 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] BAM to BigWig (and tool ID clashes)
On Fri, Apr 20, 2012 at 4:12 PM, Brad Chapman chapm...@50mail.com wrote: Peter and Lance; I've made the update to Brad's script from the Tool Shed (attached), switching to using genomeCoverageBed and bedGraphToBigWig (based on the approach used in Lance's script), although in doing so I dropped the region support (which wasn't exposed to the Galaxy interface anyway). Since genomeCoverageBed doesn't support this directly, we could use samtools view for this I think - if you want this functionality. Awesome, thanks for doing this so quickly. Leaving out the region support for now is fine with me. I gave both of you write access to that repo on the Toolshed so feel free to check in and edit away. Thanks again for tackling this, Brad Lovely. I propose to initially update the Python script as described, with minor changes to the XML to add the new option and change the dependencies. After that we should probably talk about merging the changes already committed on your github repo (normalization). 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] some weird thing about [shed tools] I have found
Dear all, I installed and uninstalled some shed tools for my Galaxy instance. And I have found some weird things which I don't think they are as expected. 1. After I installed a shed tool using the Galaxy web UI and the tool can run successfully, I didn't find any change of the shed_tool_conf.xml file. According to the instructions under the link http://wiki.g2.bx.psu.edu/Tool%20Shed#Automatic_installation_of_Galaxy_tool_shed_repository_tools_into_a_local_Galaxy_instance, a entry of the newly added tool should be added. Thus I don't know where I go to modify the tools information(such as the section name..) like I did in the tool_conf.xml file. 2. When I go to Admin |Manage installed tool shed repositorieshttp://localhost/admin_toolshed/browse_repositories , I can't find all the installed tools. Only some of them are displayed there. 3. After I uninstalled a shed tool, all the related files are deleted, which is good. But the empty directories(under the Shed_tools) are left. 4. Last, I have one question: if I install a shed tool into a new section(which means it doesn't exist before) , how could we modify the section's name? Anyone have encounter the same problems? Hope someone can explain to me. Thanks in advance!!! Cheers, Tyler ___ 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] Galaxy not updating usage history after data deletion
Hi there, I'm having an issue that I believe is commonplace amongst Galaxy users: that of the webserver failing to update deleted data promptly. I've tried using the Python script to force an update that was suggested somewhere on the Wiki, I believe, but to no avail. In terms of making sure everything is deleted permanently etc., I'm pretty sure I've done it properly. I'm using the Main server it's been, perhaps, two weeks since I've permanently deleted the said data. Any help is appreciated! Many thanks, Eiseart ___ 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] multiple tool outputs
Hello all, I am working on integrating a few tools into Galaxy with multiple outputs. There are examples on the wiki for handling variable outputs determined by parameters and an arbitrary number of outputs, but none of them seemed to apply to this case. This tool must accept two lists of parameters a and b. The number of output files is (len(a) * len(b)) + 2. Is there a way to implement this in Galaxy without having to arbitrarily impose a limit on the length of the parameter lists? Also, if I would be required to use the arbitrary outputs mechanism, could the user still incorporate the output of this tool into workflows? Thank you. Sincerely, Russell Bonneville Russell Bonneville Undergraduate Research Assistant Jin Lab, Department of Biomedical Informatics The Ohio State University Wexner Medical Center bonnevill...@buckeyemail.osu.edumailto:bonnevill...@buckeyemail.osu.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] dynamic_options
Hi all, Is there any help available which describes about the usage of dynamic_options? Is the code file should be a python executable or can we use perl? Thanks and regards, Deepthi ___ 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/
