[galaxy-dev] workflow Editor
Hi, I want to know about workflow editor and how it works internally? what type of canvas editor are you using ? doest it support only python environment ? if you have any documents related with ,can i get it . Regards shashi --- This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. --- ___ 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] History not updating automatically
Hi list, I have a weird problem after updating to the latest version. After doing the update as usual, the history panel is not updating automatically anymore. And when I press refresh, I get an javascript popup saying: Error getting history updates from the server. Forbidden Also, in the log I see the following: galaxy.web.framework WARNING 2013-01-28 12:30:01,673 User logged in as '(null)' externally, but has a cookie as 'sa...@embl.de' invalidating session We are using LDAP to connect to Galaxy, but I don't know if this has something to do with the problem. As I said, it was working perfectly fine before the update. Does someone know the problem or has any ideas? Thanks for your help, Sajoscha ___ 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] History not updating automatically
Hi Sajoscha: I have exactly the same problem… it started about a month ago. Also with external ldap auth. I have not yet investigated in detail, since it's not crippling - just annoying. Brad On Jan 28, 2013, at 6:38 AM, Sajoscha Sauer wrote: > Hi list, > > I have a weird problem after updating to the latest version. > > After doing the update as usual, the history panel is not updating > automatically anymore. And when I press refresh, I get an javascript popup > saying: > > Error getting history updates from the server. > Forbidden > > > Also, in the log I see the following: > > galaxy.web.framework WARNING 2013-01-28 12:30:01,673 User logged in as > '(null)' externally, but has a cookie as 'sa...@embl.de' invalidating session > > > We are using LDAP to connect to Galaxy, but I don't know if this has > something to do with the problem. As I said, it was working perfectly fine > before the update. > > Does someone know the problem or has any ideas? > > Thanks for your help, > > Sajoscha > > > > ___ > 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/ -- Brad Langhorst langho...@neb.com ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
[galaxy-dev] Uploading large files as Admin Still slow!
Hi, I am trying to upload 2x 2.5GB files to my data libraries (in Admin on a local instance) but it has so far been running over night and not completed. How can I speed this up? Can I upload compressed files? Can I not just copy these files directly in to $galaxy-dist/database/files/000 ? Thanks, Jack ___ 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] Uploading large files as AdminŠ Still slow!
What probably happened here is that due to the filesize, the browser upload failed but this went undetected. The good news is that you *can* tell galaxy to copy directly, or you could even use the files exactly where they are without any copy. What you want to do is enable this section in your universe_wsgi.ini, and then restart galaxy, after which you'll be able to just paste in the local path and galaxy will handle the rest. # Add an option to the admin library upload tool allowing admins to paste # filesystem paths to files and directories in a box, and these paths will be # added to a library. Set to True to enable. Please note the security # implication that this will give Galaxy Admins access to anything your Galaxy # user has access to. #allow_library_path_paste = False -Dannon On Jan 28, 2013, at 8:21 AM, Jackie Lighten wrote: > Hi, > > I am trying to upload 2x 2.5GB files to my data libraries (in Admin on a > local instance) but it has so far been running over night and not completed. > How can I speed this up? > Can I upload compressed files? > Can I not just copy these files directly in to > $galaxy-dist/database/files/000 ? > > Thanks, > > Jack > > ___ > 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] Nice 'citable' URLs for Galaxy Tool Shed repositories
Dear all, Something I am conscious of every time I have directed someone to a tool or wrapper on the Galaxy Tool Shed is the lack of nice stable URLs. The current frame based design hinders this - and as a result I usually just have to give the ToolShed URL and tell them what to search for. This problem is particularly acute for citing a tool shed entry, where a nice URL would be far better. I appreciate moving away from the current frame interface is a lot of work - although what Jeremy Goecks wrote last week suggests that is a long term goal: http://lists.bx.psu.edu/pipermail/galaxy-dev/2013-January/012792.html I would like something similar to the repository URL, but for the ToolShed interface. e.g. The repository view for my MIRA wrapper: http://toolshed.g2.bx.psu.edu/repos/peterjc/mira_assembler Perhaps is the short-term what could be done is to enhance the repository view, and include links between this and the current "Tool Shed" frame based page? That way we can share a nice URL like http://toolshed.g2.bx.psu.edu/repos/peterjc/mira_assembler to direct someone to a resource in the Tool Shed? e.g. (1) When viewing an entry on the "Tool Shed", include a prominent link to the repository URL (perhaps even with social media links like tweet or share this to emphasise this is the best URL to share). (2) In the header for each repo (perhaps in place of the current Mercuiral logo?) have a link to the "Tool Shed" frameset for the tool being viewed. 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] Uploading large files as AdminŠ Still slow!
Thanks. I now have the option to upload via directory path. How do I create the ability to use files in their current location without a copy into Galaxy database ? Thanks, J On 2013-01-28 9:30 AM, "Dannon Baker" wrote: >What probably happened here is that due to the filesize, the browser >upload failed but this went undetected. > >The good news is that you *can* tell galaxy to copy directly, or you >could even use the files exactly where they are without any copy. > >What you want to do is enable this section in your universe_wsgi.ini, and >then restart galaxy, after which you'll be able to just paste in the >local path and galaxy will handle the rest. > ># Add an option to the admin library upload tool allowing admins to paste ># filesystem paths to files and directories in a box, and these paths >will be ># added to a library. Set to True to enable. Please note the security ># implication that this will give Galaxy Admins access to anything your >Galaxy ># user has access to. >#allow_library_path_paste = False > >-Dannon > >On Jan 28, 2013, at 8:21 AM, Jackie Lighten wrote: > >> Hi, >> >> I am trying to upload 2x 2.5GB files to my data libraries (in Admin on >>a local instance) but it has so far been running over night and not >>completed. >> How can I speed this up? >> Can I upload compressed files? >> Can I not just copy these files directly in to >>$galaxy-dist/database/files/000 ? >> >> Thanks, >> >> Jack >> >> ___ >> 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] Uploading large files as AdminŠ Still slow!
Sorry. I got it O the drop down menu. Thanks again. J On 2013-01-28 9:30 AM, "Dannon Baker" wrote: >What probably happened here is that due to the filesize, the browser >upload failed but this went undetected. > >The good news is that you *can* tell galaxy to copy directly, or you >could even use the files exactly where they are without any copy. > >What you want to do is enable this section in your universe_wsgi.ini, and >then restart galaxy, after which you'll be able to just paste in the >local path and galaxy will handle the rest. > ># Add an option to the admin library upload tool allowing admins to paste ># filesystem paths to files and directories in a box, and these paths >will be ># added to a library. Set to True to enable. Please note the security ># implication that this will give Galaxy Admins access to anything your >Galaxy ># user has access to. >#allow_library_path_paste = False > >-Dannon > >On Jan 28, 2013, at 8:21 AM, Jackie Lighten wrote: > >> Hi, >> >> I am trying to upload 2x 2.5GB files to my data libraries (in Admin on >>a local instance) but it has so far been running over night and not >>completed. >> How can I speed this up? >> Can I upload compressed files? >> Can I not just copy these files directly in to >>$galaxy-dist/database/files/000 ? >> >> Thanks, >> >> Jack >> >> ___ >> 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] Selecting Intermediary Files in a Workflow
You can work around this using the from_work_dir attribute when specifying the output file in your tool config. -- jt (composed on my phone) On Jan 27, 2013, at 6:13 PM, Peter Cock wrote: > On Sun, Jan 27, 2013 at 10:26 PM, Kolby Chien wrote: >> Hello, >> >> I've been working with a local installation of Galaxy and my question is >> about how Galaxy chooses which file to use in the next step of the workflow. >> >> I have created a custom file type called "cub" which is required for my >> custom tools and I have added this custom file type into the extension list. >> When I run the first step of my workflow, Galaxy will create an intermediate >> cub file called dataset_51.dat.cub containing my processed data, but also an >> empty intermediate dat file as well of the same name sans cub extension >> (dataset_51.dat) . The next tool in the workflow requires a cub file type >> input, but instead of using the cub file, it chooses to process the empty >> .dat file instead, causing the tool to process incorrectly. >> >> I've looked over some settings and double checked that my tool xml files >> specify cub as the output file type and as the input file type for the next >> tool, but now I am at a loss. Is there anyway to specify to Galaxy that the >> cub file should be used in the next step of the workflow instead of the dat >> file? > > Galaxy wants all the files to use the names Galaxy tells the tool, > and those filenames all end with .dat - the problem is probably > Galaxy has told you (i.e. your tool) to use dataset_51.dat as the > output file, but your tool has instead used dataset_51.dat.cub > (which Galaxy will ignore). > > 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] Only custom genomes for uploads in data libraries
On Sun, Jan 27, 2013 at 10:04 AM, Jeremy Goecks wrote: > > Actually, there an easier way to fix this without patching your Galaxy > installation. Builds will show up in the library dbkey box if there's a > chromosome length file associated with the build. Chromosome length files are > used in some format converters (e.g. wig/bedgraph-to-bigwig) and for > visualization. > > You can download len files by doing the following: > > (1) Uncomment/add len_file_path to your universe.wsgi.ini file, e.g.: > > len_file_path = tool-data/shared/ucsc/chrom > > > (2) Run these commands from your Galaxy install to download len files from > UCSC: > > mkdir ./tool-data/shared/ucsc/chrom/ > python ./cron/build_chrom_db.py ./tool-data/shared/ucsc/chrom/ > > (3) Restart Galaxy. > Thanks Jeremy, I will try this and report back. ___ 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] workflow Editor
The client side of the workflow editor is in javascript, using a mix of HTML5 Canvas and DOM elements. It communicates with the server using JSON. The server side is written in Python. The editor could be decoupled and reused, however there are some details that are fairly Galaxy specific right now (particularly how tool states -- the values of the various input parameters -- are encoded). -- James Taylor, Assistant Professor, Biology/CS, Emory University On Mon, Jan 28, 2013 at 5:17 AM, wrote: > Hi, > > I want to know about workflow editor and how it works internally? what > type of canvas editor are you using ? doest it support only python > environment ? > if you have any documents related with ,can i get it . > > Regards > shashi > > --- > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies and the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this email > is strictly prohibited and appropriate legal action will be taken. > --- > > ___ > 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] workflows stop prematurely
Hi All On my local install of galaxy I'm having problems executing workflows. I will upload data into a new history and then select to run a saved workflow. This initiates fine but, after the completion of a variable number of steps, the workflow just stops after the successful completion of a step. No errors appear in the web interface and all I can see in the paster.log is something like 90 HTTP/1.1" 200 - "http://127.0.0.1:8081/history"; "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0" 127.0.0.1 - - [28/Jan/2013:12:29:07 -0400] "GET /api/histories/82b264d8c3d11790 HTTP/1.1" 200 - "http://127.0.0.1:8081/history"; "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0" galaxy.jobs.runners.local DEBUG 2013-01-28 12:29:08,621 execution finished: python /home/rosema1/Projects/galaxy-dist/tools/fastq/fastq_trimmer_by_quality.py '/home/rosema1/Projects/galaxy-dist/database/files/000/dataset_590.dat' '/home/rosema1/Projects/galaxy-dist/database/files/000/dataset_592.dat' -f 'sanger' -s '5' -t '1' -e '53' -a 'mean' -x '0' -c '>=' -q '20.0' galaxy.jobs DEBUG 2013-01-28 12:29:08,838 Tool did not define exit code or stdio handling; checking stderr for success galaxy.tools DEBUG 2013-01-28 12:29:09,135 Error opening galaxy.json file: [Errno 2] No such file or directory: '/home/rosema1/Projects/galaxy-dist/database/job_working_directory/000/418/galaxy.json' galaxy.jobs DEBUG 2013-01-28 12:29:09,439 job 418 ended galaxy.jobs DEBUG 2013-01-28 12:29:10,041 (420) Working directory for job is: /home/rosema1/Projects/galaxy-dist/database/job_working_directory/000/420 galaxy.jobs.handler DEBUG 2013-01-28 12:29:10,042 dispatching job 420 to local runner galaxy.jobs.handler INFO 2013-01-28 12:29:10,200 (420) Job dispatched galaxy.jobs.runners.local DEBUG 2013-01-28 12:29:10,385 Local runner: starting job 420 galaxy.jobs.runners.local DEBUG 2013-01-28 12:29:10,759 executing: python /home/rosema1/Projects/galaxy-dist/tools/fastq/fastq_filter.py /home/rosema1/Projects/galaxy-dist/database/files/000/dataset_592.dat /home/rosema1/Projects/galaxy-dist/database/job_working_directory/000/420/tmph0Ll2V /home/rosema1/Projects/galaxy-dist/database/files/000/dataset_594.dat /home/rosema1/Projects/galaxy-dist/database/job_working_directory/000/420/dataset_594_files 'sanger' 127.0.0.1 - - [28/Jan/2013:12:29:12 -0400] "GET /api/histories/82b264d8c3d11790 HTTP/1.1" 200 - "http://127.0.0.1:8081/history"; "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0" 127.0.0.1 - - [28/Jan/2013:12:29:12 -0400] "GET /api/users/f2db41e1fa331b3e HTTP/1.1" 200 - "http://127.0.0.1:8081/history"; "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0" 127.0.0.1 - - [28/Jan/2013:12:29:12 -0400] "GET /api/histories/82b264d8c3d11790/contents?ids=3da459a26c8f00b4%2C736af8f0a76a2e71 HTTP/1.1" 200 - "http://127.0.0.1:8081/history"; "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0" 127.0.0.1 - - [28/Jan/2013:12:29:16 -0400] "GET /api/histories/82b264d8c3d11790 HTTP/1.1" 200 - "http://127.0.0.1:8081/history"; "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0" Though I seem to see this even when a step completes and the workflow proceeds. Moreover, if I then begin executing the next steps in the workflow, they work, but create new entries in the history. So, some questions: Why is this happening and what can I do to get workflows to run to completion? Also, is it possible to reinitiate the workflow from the premature stopping point without having to launch each step individually and point each at new inputs rather than the ones dictated in the workflow? Thanks Mark This message may contain confidential information. If you are not the designated recipient, please notify the sender immediately, and delete the original and any copies. Any use of the message by you is prohibited. ___ 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] Pull request for bowtie_wrappers tool
Dear Galaxy DevTeam, I have made a few updates to the bowtie_wrappers tool from the Tool Shed, may someone please pull from: https://bitbucket.org/nsoranzo/bowtie_wrappers/ for the following changes: - Add fields for --nofw and --norc options also for single-end reads - Remove field for --cutoff option of bowtie-build - Do not show fields for --best and --strata options for paired-end reads - Add control to choose between -a and -k options - Show fields for --pairtries and --maxbts options only when noTryHard - Add control to choose between Maq- and SOAP-like alignment - Add range validators to all integer parameters I am not sure this mailing list is the correct place for such pull requests, if not please advise me! Thanks, Nicola -- Nicola Soranzo, Ph.D. CRS4 Bioinformatics Program Loc. Piscina Manna 09010 Pula (CA), Italy http://www.bioinformatica.crs4.it/ ___ 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] Nice 'citable' URLs for Galaxy Tool Shed repositories
Hi Peter, Thanks for your request, having citable tool shed URLs is definitely important. I've got this on my list (which is maxed out as usual). I will look into this in a timely manner and keep you posted appropriately. Greg Von Kuster On Jan 28, 2013, at 8:41 AM, Peter Cock wrote: > Dear all, > > Something I am conscious of every time I have directed someone > to a tool or wrapper on the Galaxy Tool Shed is the lack of nice > stable URLs. The current frame based design hinders this - and > as a result I usually just have to give the ToolShed URL and tell > them what to search for. This problem is particularly acute for > citing a tool shed entry, where a nice URL would be far better. > > I appreciate moving away from the current frame interface is a > lot of work - although what Jeremy Goecks wrote last week suggests > that is a long term goal: > http://lists.bx.psu.edu/pipermail/galaxy-dev/2013-January/012792.html > > I would like something similar to the repository URL, but for the > ToolShed interface. e.g. The repository view for my MIRA wrapper: > http://toolshed.g2.bx.psu.edu/repos/peterjc/mira_assembler > > Perhaps is the short-term what could be done is to enhance the > repository view, and include links between this and the current > "Tool Shed" frame based page? That way we can share a nice URL > like http://toolshed.g2.bx.psu.edu/repos/peterjc/mira_assembler > to direct someone to a resource in the Tool Shed? e.g. > > (1) When viewing an entry on the "Tool Shed", include a prominent > link to the repository URL (perhaps even with social media links like > tweet or share this to emphasise this is the best URL to share). > > (2) In the header for each repo (perhaps in place of the current > Mercuiral logo?) have a link to the "Tool Shed" frameset for the > tool being viewed. > > 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] Nice 'citable' URLs for Galaxy Tool Shed repositories
On Mon, Jan 28, 2013 at 6:49 PM, Greg Von Kuster wrote: > Hi Peter, > > Thanks for your request, having citable tool shed URLs is definitely > important. I've got this on my list (which is maxed out as usual). > I will look into this in a timely manner and keep you posted appropriately. > > Greg Von Kuster Sounds like my to do list too :( Is there a Trello issue on this, or should I file one? Thanks, Peter P.S. Citable Tool Shed URLs would also be good for the @GalaxyProject tweets, as pointed out by John Chilton: https://twitter.com/jmchilton/status/295890843372515328 ___ 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] History not updating automatically
Hi Brad and Sajoscha, Is there any chance that your proxy configurations are not passing the username in the REMOTE_USER header when the request is to an /api path? Could you provide the relevant portions of your proxy server configs? Thanks, --nate On Jan 28, 2013, at 7:12 AM, Langhorst, Brad wrote: > Hi Sajoscha: > > I have exactly the same problem… it started about a month ago. > > Also with external ldap auth. > > I have not yet investigated in detail, since it's not crippling - just > annoying. > > Brad > > > On Jan 28, 2013, at 6:38 AM, Sajoscha Sauer > wrote: > >> Hi list, >> >> I have a weird problem after updating to the latest version. >> >> After doing the update as usual, the history panel is not updating >> automatically anymore. And when I press refresh, I get an javascript popup >> saying: >> >> Error getting history updates from the server. >> Forbidden >> >> >> Also, in the log I see the following: >> >> galaxy.web.framework WARNING 2013-01-28 12:30:01,673 User logged in as >> '(null)' externally, but has a cookie as 'sa...@embl.de' invalidating session >> >> >> We are using LDAP to connect to Galaxy, but I don't know if this has >> something to do with the problem. As I said, it was working perfectly fine >> before the update. >> >> Does someone know the problem or has any ideas? >> >> Thanks for your help, >> >> Sajoscha >> >> >> >> ___ >> 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/ > > -- > Brad Langhorst > langho...@neb.com > > > > > > > ___ > Please keep all replies on the list by using "reply all" > in your mail client. To manage your subscriptions to this > and other Galaxy lists, please use the interface at: > > 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] Nice 'citable' URLs for Galaxy Tool Shed repositories
I've opened a Trello card, but it's in the Galaxy development project, so not sure if you can see it or not. Here's the link to the card just in case... https://trello.com/card/nice-citable-urls-for-galaxy-tool-shed-repositories/506338ce32ae458f6d15e4b3/182 On Jan 28, 2013, at 2:28 PM, Peter Cock wrote: > On Mon, Jan 28, 2013 at 6:49 PM, Greg Von Kuster wrote: >> Hi Peter, >> >> Thanks for your request, having citable tool shed URLs is definitely >> important. I've got this on my list (which is maxed out as usual). >> I will look into this in a timely manner and keep you posted appropriately. >> >> Greg Von Kuster > > Sounds like my to do list too :( > > Is there a Trello issue on this, or should I file one? > > Thanks, > > Peter > > P.S. Citable Tool Shed URLs would also be good for the > @GalaxyProject tweets, as pointed out by John Chilton: > https://twitter.com/jmchilton/status/295890843372515328 ___ 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] History not updating automatically
Nate: I used the config from the wiki directly… … RequestHeader set REMOTE_USER %{AUTHENTICATE_sAMAccountName}e ... but I also had a section like this below it... # # Satisfy Any # Allow from all # I thought that the /api location would inherit the auth and headers stuff of it's container, but that's not true. Commenting the api location fixes the problem form e. Brad On Jan 28, 2013, at 2:35 PM, Nate Coraor wrote: > Hi Brad and Sajoscha, > > Is there any chance that your proxy configurations are not passing the > username in the REMOTE_USER header when the request is to an /api path? > Could you provide the relevant portions of your proxy server configs? > > Thanks, > --nate > > On Jan 28, 2013, at 7:12 AM, Langhorst, Brad wrote: > >> Hi Sajoscha: >> >> I have exactly the same problem… it started about a month ago. >> >> Also with external ldap auth. >> >> I have not yet investigated in detail, since it's not crippling - just >> annoying. >> >> Brad >> >> >> On Jan 28, 2013, at 6:38 AM, Sajoscha Sauer >> wrote: >> >>> Hi list, >>> >>> I have a weird problem after updating to the latest version. >>> >>> After doing the update as usual, the history panel is not updating >>> automatically anymore. And when I press refresh, I get an javascript popup >>> saying: >>> >>> Error getting history updates from the server. >>> Forbidden >>> >>> >>> Also, in the log I see the following: >>> >>> galaxy.web.framework WARNING 2013-01-28 12:30:01,673 User logged in as >>> '(null)' externally, but has a cookie as 'sa...@embl.de' invalidating >>> session >>> >>> >>> We are using LDAP to connect to Galaxy, but I don't know if this has >>> something to do with the problem. As I said, it was working perfectly fine >>> before the update. >>> >>> Does someone know the problem or has any ideas? >>> >>> Thanks for your help, >>> >>> Sajoscha >>> >>> >>> >>> ___ >>> 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/ >> >> -- >> Brad Langhorst >> langho...@neb.com >> >> >> >> >> >> >> ___ >> Please keep all replies on the list by using "reply all" >> in your mail client. To manage your subscriptions to this >> and other Galaxy lists, please use the interface at: >> >> http://lists.bx.psu.edu/ >> > -- Brad Langhorst langho...@neb.com ___ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
[galaxy-dev] Galaxy with EMBOSS 5 or EMBOSS 6 ?
Dear Galaxians, I am troubleshooting a problem with running EMBOSS infoseq on our local galaxy installation. We are running EMBOSS 6.5. There is a mismatch between the options Galaxy is passing to infoseq (-version), and what infoseq wants (-seqversion). This breaks the tool. While this would be easy to fix in this instance, I wonder if I should be using EMBOSS 5 (which is *really* old, mind you) instead of EMBOSS 6. I suspect with EMBOSS 6 there may be a whole host of similar changes to be made. Can anyone advise? If it turns out that EMBOSS 5 is actually required, perhaps someone could update the relevant info on the Galaxy dependencies page, or at least point me to the place where it says this. cheers, Simon Simon Guest Senior UNIX Technical Consultant AgResearch === Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. === ___ 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 EMBOSS 5 or EMBOSS 6 ?
> There is a mismatch between the options Galaxy is passing to infoseq (- > version), and what infoseq wants (-seqversion). This breaks the tool. Clarification: I see the -version/-seqversion change to infoseq was made in EMBOSS 6.2.0. I'm still wondering which version I should be using with Galaxy. Maybe 6.1.0 from Jul 2009 is OK? Or should we just fix Galaxy to use the latest and greatest EMBOSS? cheers, Simon PS: Apologies for the crass disclaimer === Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. === ___ 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] Loading a library of bam files
Hi Kyle, I'm hoping I can help you a bit on this, although i am not very familiar with the code that is producing this behavior. Your previous reply mentions the following: During job cleanup, galaxy.jobs.__init__.py:412, because external_metadata_set_successfully returns false. An external set_metadata.sh job was run, but it doesn't seem to call samtools. Maybe if I figure out why set_metadata.sh isn't working, this problem will go away. Based on your comments, there are a few things you can do: 1. If setting external metadata results in an error, the error should be printed out in your paster log. Do you see anything relevant there? 2. You also may be able to discover the error if you perform the following sql manually - make sure your have the correct job_id: select filename_results_code from job_external_output_metadata where job_id = ; 3. Make sure you have the following config setting uncommented and set to False in your universe_wsgi.ini (the default is set to True): # Although it is fairly reliable, setting metadata can occasionally fail. In # these instances, you can choose to retry setting it internally or leave it in # a failed state (since retrying internally may cause the Galaxy process to be # unresponsive). If this option is set to False, the user will be given the # option to retry externally, or set metadata manually (when possible). retry_metadata_internally = False Let me know if any of this helps you resolve the problem, and if not, we'll figure out next steps if possible. Thanks, Greg Von Kuster On Jan 24, 2013, at 4:36 PM, Kyle Ellrott wrote: > I'm willing to put in the coding time, but I'd need some pointers on the best > way to go about making the changes. > > Kyle > > > On Wed, Jan 23, 2013 at 6:35 PM, Anthonius deBoer wrote: > I also second this request to get it addressed (Where can we vote on bug > fixes ?! :) ...It is very weird that samtools is run on the local machine and > it even does the indexing sequentially... > Thon > > > On Jan 23, 2013, at 03:28 PM, Kyle Ellrott wrote: > >> I'm currently in the process of loading (path paste) a large library of BAM >> files (>1) into the shared Data Libraries of our local galaxy >> installation, but I'm finding this process to be very slow. >> I'm doing a path paste, and not actually copying the files. I have disabled >> local running of 'upload1', so that it will run on the cluster, and set >> 'set_metadata_externally' to true. >> It looks like the job handlers are calling 'samtools index' directly. >> Looking through the code, that seems to happen in galaxy/datatypes/binary in >> Bam.dataset_content_needs_grooming, where it calls 'samtools index' and then >> waits. >> What would be the most efficient way to start changing the code so that this >> process can be done by an external script, at a deferred time out on the >> cluster? >> >> Kyle >> ___ >> 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/ ___ 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 EMBOSS 5 or EMBOSS 6 ?
Hey Simon, You're right -- the EMBOSS version supported by the Galaxy wrappers is currently EMBOSS 5. We do have a Tool Dependency page here: http://wiki.galaxyproject.org/Admin/Tools/Tool%20Dependencies, but unfortunately while it lists versions for many tools it doesn't cover them all. I'll update the EMBOSS entry. As far as updating the galaxy EMBOSS wrappers to use a newer version, I'm not aware of any plans to do this currently (though someone could certainly do this if so inclined). -Dannon On Jan 28, 2013, at 3:10 PM, "Guest, Simon" wrote: > Dear Galaxians, > > I am troubleshooting a problem with running EMBOSS infoseq on our local > galaxy installation. We are running EMBOSS 6.5. > > There is a mismatch between the options Galaxy is passing to infoseq > (-version), and what infoseq wants (-seqversion). This breaks the tool. > > While this would be easy to fix in this instance, I wonder if I should be > using EMBOSS 5 (which is *really* old, mind you) instead of EMBOSS 6. I > suspect with EMBOSS 6 there may be a whole host of similar changes to be made. > > Can anyone advise? > > If it turns out that EMBOSS 5 is actually required, perhaps someone could > update the relevant info on the Galaxy dependencies page, or at least point > me to the place where it says this. > > cheers, > Simon > > > Simon Guest > Senior UNIX Technical Consultant > AgResearch > > > === > Attention: The information contained in this message and/or attachments > from AgResearch Limited is intended only for the persons or entities > to which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipients is prohibited by AgResearch > Limited. If you have received this message in error, please notify the > sender immediately. > === > ___ > 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] Galaxy with EMBOSS 5 or EMBOSS 6 ?
> You're right -- the EMBOSS version supported by the Galaxy wrappers is > currently EMBOSS 5. We do have a Tool Dependency page here: > http://wiki.galaxyproject.org/Admin/Tools/Tool%20Dependencies, but > unfortunately while it lists versions for many tools it doesn't cover them > all. I'll update the EMBOSS entry. Hi Dannon, Thanks. After a bit more looking around, I also found the version in the tool_conf.xml file, which confirmed I need to install EMBOSS 5.0.0. > > As far as updating the galaxy EMBOSS wrappers to use a newer version, I'm > not aware of any plans to do this currently (though someone could > certainly do this if so inclined). We may do this ourselves, and contribute the updates. First we'll get it all rolled out with EMBOSS 5. Later on I may be back in touch about how we can contribute updates into the Galaxy mainline. cheers, Simon === Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. === ___ 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 uploading file with fresh installation: this request returned None from get_history()
I was incorrect in stating that the changes in the next galaxy-dist will help in this case, unfortunately. From the stack trace you posted, there is a deeper error with your instance that the client-side changes won't help. Can you post the size, type, and name of the file you're trying to upload? On Thu, Jan 24, 2013 at 6:12 PM, Dan Tenenbaum wrote: > On Wed, Jan 23, 2013 at 3:19 PM, Carl Eberhard > wrote: > > Another thing you might try is to upload the file to our test server: > > https://test.g2.bx.psu.edu/ and see if that works. > > > > Thanks, that does work. > > Setting up an FTP server on my local installation seems pretty > complex. All I really want to do is work around this issue and fool > Galaxy into thinking that I have uploaded a file using the > uploader...since this is a local installation I can put a file > anywhere on my system, I don't have to actually upload it, just place > it in a directory. > > If there is no such workaround, I'll wait for the fix, I guess. Thanks > very much for working on this! > Dan > > > > > > On Wed, Jan 23, 2013 at 6:06 PM, Carl Eberhard > > wrote: > >> > >> If this is happening consistently and a refresh on the history isn't > doing > >> anything, you might try ftp upload: > http://wiki.galaxyproject.org/FTPUpload > >> or if you have permissions or are an admin you can try uploading to a > data > >> library: > >> http://wiki.galaxyproject.org/Admin/DataLibraries/UploadingLibraryFiles > >> > >> > >> > >> On Wed, Jan 23, 2013 at 5:44 PM, Dan Tenenbaum > wrote: > >>> > >>> On Wed, Jan 23, 2013 at 2:42 PM, Carl Eberhard < > carlfeberh...@gmail.com> > >>> wrote: > >>> > What sort of database are you using on your local instance? > >>> > > >>> > >>> The default (sqlite I guess). It's a completely vanilla instance, I > >>> have not touched the config files. > >>> Dan > >>> > >>> > >>> > > >>> > On Wed, Jan 23, 2013 at 5:37 PM, Dan Tenenbaum > >>> > wrote: > >>> >> > >>> >> On Wed, Jan 23, 2013 at 2:35 PM, Carl Eberhard > >>> >> > >>> >> wrote: > >>> >> > Thanks, Dan. That helps and I'll start looking into this. > >>> >> > > >>> >> > We will be pushing out a new galaxy-dist revision sometime this > week > >>> >> > if > >>> >> > all > >>> >> > goes well. This revision includes some code for the history panel > >>> >> > that > >>> >> > may > >>> >> > help handle this situation a bit better. I'd recommend updating to > >>> >> > that > >>> >> > revision when it comes out. > >>> >> > > >>> >> > >>> >> Thanks! Is there a workaround to upload a file or add it to my > history > >>> >> in the meantime? Command-line is ok. If there isn't one, that's ok > >>> >> too > >>> >> Dan > >>> >> > >>> >> > >>> >> > >>> >> > I'll let you know what I can find. > >>> >> > Carl > >>> >> > > >>> >> > > >>> >> > > >>> >> > On Wed, Jan 23, 2013 at 5:18 PM, Dan Tenenbaum < > dtene...@fhcrc.org> > >>> >> > wrote: > >>> >> >> > >>> >> >> Hi Carl, > >>> >> >> > >>> >> >> On Wed, Jan 23, 2013 at 2:14 PM, Carl Eberhard > >>> >> >> > >>> >> >> wrote: > >>> >> >> > Heya, Dan. > >>> >> >> > > >>> >> >> > Sorry for the trouble. > >>> >> >> > When you get that error again look for a line like you have > >>> >> >> > above: > >>> >> >> > Debug at: http://localhost:8080/_debug/view/1358978130 > >>> >> >> > > >>> >> >> > If you open a new tab or window in your browser and go to the > >>> >> >> > address > >>> >> >> > ('http://localhost:8080/_debug ...'), you should see a more > >>> >> >> > informative > >>> >> >> > error message - complete with a list of function calls that led > >>> >> >> > to > >>> >> >> > the > >>> >> >> > error > >>> >> >> > (a stack trace). > >>> >> >> > > >>> >> >> > Can you post that stack trace when you see it? > >>> >> >> > > >>> >> >> > >>> >> >> Thanks for the quick response. Here it is: > >>> >> >> > >>> >> >> URL: http://localhost:8080/tool_runner/upload_async_create > >>> >> >> File > >>> >> >> > >>> >> >> > >>> >> >> > '/Users/dtenenba/dev/galaxy-dist/eggs/WebError-0.8a-py2.7.egg/weberror/evalexception/middleware.py', > >>> >> >> line 364 in respond > >>> >> >> app_iter = self.application(environ, detect_start_response) > >>> >> >> File > >>> >> >> > >>> >> >> > >>> >> >> > '/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/debug/prints.py', > >>> >> >> line 98 in __call__ > >>> >> >> environ, self.app) > >>> >> >> File > >>> >> >> > >>> >> >> > >>> >> >> > '/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/wsgilib.py', > >>> >> >> line 539 in intercept_output > >>> >> >> app_iter = application(environ, replacement_start_response) > >>> >> >> File > >>> >> >> > >>> >> >> > >>> >> >> > '/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/recursive.py', > >>> >> >> line 80 in __call__ > >>> >> >> return self.application(environ, start_response) > >>> >> >> File > >>> >> >> > >>> >> >> > >>> >> >> > '/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/httpexceptions.py', > >>> >> >> line 632 in __call__ > >>>
Re: [galaxy-dev] error uploading file with fresh installation: this request returned None from get_history()
On Mon, Jan 28, 2013 at 1:40 PM, Carl Eberhard wrote: > I was incorrect in stating that the changes in the next galaxy-dist will > help in this case, unfortunately. From the stack trace you posted, there is > a deeper error with your instance that the client-side changes won't help. > > Can you post the size, type, and name of the file you're trying to upload? > I can reproduce this by just typing "hello, world" into the "URL/Text:" box on the "Upload File" page. Any file of any type seems to trigger this problem. Thanks, Dan > > On Thu, Jan 24, 2013 at 6:12 PM, Dan Tenenbaum wrote: >> >> On Wed, Jan 23, 2013 at 3:19 PM, Carl Eberhard >> wrote: >> > Another thing you might try is to upload the file to our test server: >> > https://test.g2.bx.psu.edu/ and see if that works. >> > >> >> Thanks, that does work. >> >> Setting up an FTP server on my local installation seems pretty >> complex. All I really want to do is work around this issue and fool >> Galaxy into thinking that I have uploaded a file using the >> uploader...since this is a local installation I can put a file >> anywhere on my system, I don't have to actually upload it, just place >> it in a directory. >> >> If there is no such workaround, I'll wait for the fix, I guess. Thanks >> very much for working on this! >> Dan >> >> >> > >> > On Wed, Jan 23, 2013 at 6:06 PM, Carl Eberhard >> > wrote: >> >> >> >> If this is happening consistently and a refresh on the history isn't >> >> doing >> >> anything, you might try ftp upload: >> >> http://wiki.galaxyproject.org/FTPUpload >> >> or if you have permissions or are an admin you can try uploading to a >> >> data >> >> library: >> >> http://wiki.galaxyproject.org/Admin/DataLibraries/UploadingLibraryFiles >> >> >> >> >> >> >> >> On Wed, Jan 23, 2013 at 5:44 PM, Dan Tenenbaum >> >> wrote: >> >>> >> >>> On Wed, Jan 23, 2013 at 2:42 PM, Carl Eberhard >> >>> >> >>> wrote: >> >>> > What sort of database are you using on your local instance? >> >>> > >> >>> >> >>> The default (sqlite I guess). It's a completely vanilla instance, I >> >>> have not touched the config files. >> >>> Dan >> >>> >> >>> >> >>> > >> >>> > On Wed, Jan 23, 2013 at 5:37 PM, Dan Tenenbaum >> >>> > wrote: >> >>> >> >> >>> >> On Wed, Jan 23, 2013 at 2:35 PM, Carl Eberhard >> >>> >> >> >>> >> wrote: >> >>> >> > Thanks, Dan. That helps and I'll start looking into this. >> >>> >> > >> >>> >> > We will be pushing out a new galaxy-dist revision sometime this >> >>> >> > week >> >>> >> > if >> >>> >> > all >> >>> >> > goes well. This revision includes some code for the history panel >> >>> >> > that >> >>> >> > may >> >>> >> > help handle this situation a bit better. I'd recommend updating >> >>> >> > to >> >>> >> > that >> >>> >> > revision when it comes out. >> >>> >> > >> >>> >> >> >>> >> Thanks! Is there a workaround to upload a file or add it to my >> >>> >> history >> >>> >> in the meantime? Command-line is ok. If there isn't one, that's ok >> >>> >> too >> >>> >> Dan >> >>> >> >> >>> >> >> >>> >> >> >>> >> > I'll let you know what I can find. >> >>> >> > Carl >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > On Wed, Jan 23, 2013 at 5:18 PM, Dan Tenenbaum >> >>> >> > >> >>> >> > wrote: >> >>> >> >> >> >>> >> >> Hi Carl, >> >>> >> >> >> >>> >> >> On Wed, Jan 23, 2013 at 2:14 PM, Carl Eberhard >> >>> >> >> >> >>> >> >> wrote: >> >>> >> >> > Heya, Dan. >> >>> >> >> > >> >>> >> >> > Sorry for the trouble. >> >>> >> >> > When you get that error again look for a line like you have >> >>> >> >> > above: >> >>> >> >> > Debug at: http://localhost:8080/_debug/view/1358978130 >> >>> >> >> > >> >>> >> >> > If you open a new tab or window in your browser and go to the >> >>> >> >> > address >> >>> >> >> > ('http://localhost:8080/_debug ...'), you should see a more >> >>> >> >> > informative >> >>> >> >> > error message - complete with a list of function calls that >> >>> >> >> > led >> >>> >> >> > to >> >>> >> >> > the >> >>> >> >> > error >> >>> >> >> > (a stack trace). >> >>> >> >> > >> >>> >> >> > Can you post that stack trace when you see it? >> >>> >> >> > >> >>> >> >> >> >>> >> >> Thanks for the quick response. Here it is: >> >>> >> >> >> >>> >> >> URL: http://localhost:8080/tool_runner/upload_async_create >> >>> >> >> File >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> '/Users/dtenenba/dev/galaxy-dist/eggs/WebError-0.8a-py2.7.egg/weberror/evalexception/middleware.py', >> >>> >> >> line 364 in respond >> >>> >> >> app_iter = self.application(environ, detect_start_response) >> >>> >> >> File >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> '/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/debug/prints.py', >> >>> >> >> line 98 in __call__ >> >>> >> >> environ, self.app) >> >>> >> >> File >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> '/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/wsgilib.py', >> >>> >> >> line 539 in intercept_output >> >>> >> >> app_iter = application(environ, replac
Re: [galaxy-dev] error uploading file with fresh installation: this request returned None from get_history()
If you go to your galaxy root in a terminal and then cd to eggs, what is the version listed for SQLAlchemy? Do you have SQLAlchemy installed already on that machine (apart from the one in Galaxy's eggs)? On Mon, Jan 28, 2013 at 4:50 PM, Dan Tenenbaum wrote: > On Mon, Jan 28, 2013 at 1:40 PM, Carl Eberhard > wrote: > > I was incorrect in stating that the changes in the next galaxy-dist will > > help in this case, unfortunately. From the stack trace you posted, there > is > > a deeper error with your instance that the client-side changes won't > help. > > > > Can you post the size, type, and name of the file you're trying to > upload? > > > > I can reproduce this by just typing "hello, world" into the > "URL/Text:" box on the "Upload File" page. Any file of any type seems > to trigger this problem. > > Thanks, > Dan > > > > > > On Thu, Jan 24, 2013 at 6:12 PM, Dan Tenenbaum > wrote: > >> > >> On Wed, Jan 23, 2013 at 3:19 PM, Carl Eberhard > > >> wrote: > >> > Another thing you might try is to upload the file to our test server: > >> > https://test.g2.bx.psu.edu/ and see if that works. > >> > > >> > >> Thanks, that does work. > >> > >> Setting up an FTP server on my local installation seems pretty > >> complex. All I really want to do is work around this issue and fool > >> Galaxy into thinking that I have uploaded a file using the > >> uploader...since this is a local installation I can put a file > >> anywhere on my system, I don't have to actually upload it, just place > >> it in a directory. > >> > >> If there is no such workaround, I'll wait for the fix, I guess. Thanks > >> very much for working on this! > >> Dan > >> > >> > >> > > >> > On Wed, Jan 23, 2013 at 6:06 PM, Carl Eberhard < > carlfeberh...@gmail.com> > >> > wrote: > >> >> > >> >> If this is happening consistently and a refresh on the history isn't > >> >> doing > >> >> anything, you might try ftp upload: > >> >> http://wiki.galaxyproject.org/FTPUpload > >> >> or if you have permissions or are an admin you can try uploading to a > >> >> data > >> >> library: > >> >> > http://wiki.galaxyproject.org/Admin/DataLibraries/UploadingLibraryFiles > >> >> > >> >> > >> >> > >> >> On Wed, Jan 23, 2013 at 5:44 PM, Dan Tenenbaum > >> >> wrote: > >> >>> > >> >>> On Wed, Jan 23, 2013 at 2:42 PM, Carl Eberhard > >> >>> > >> >>> wrote: > >> >>> > What sort of database are you using on your local instance? > >> >>> > > >> >>> > >> >>> The default (sqlite I guess). It's a completely vanilla instance, I > >> >>> have not touched the config files. > >> >>> Dan > >> >>> > >> >>> > >> >>> > > >> >>> > On Wed, Jan 23, 2013 at 5:37 PM, Dan Tenenbaum < > dtene...@fhcrc.org> > >> >>> > wrote: > >> >>> >> > >> >>> >> On Wed, Jan 23, 2013 at 2:35 PM, Carl Eberhard > >> >>> >> > >> >>> >> wrote: > >> >>> >> > Thanks, Dan. That helps and I'll start looking into this. > >> >>> >> > > >> >>> >> > We will be pushing out a new galaxy-dist revision sometime this > >> >>> >> > week > >> >>> >> > if > >> >>> >> > all > >> >>> >> > goes well. This revision includes some code for the history > panel > >> >>> >> > that > >> >>> >> > may > >> >>> >> > help handle this situation a bit better. I'd recommend updating > >> >>> >> > to > >> >>> >> > that > >> >>> >> > revision when it comes out. > >> >>> >> > > >> >>> >> > >> >>> >> Thanks! Is there a workaround to upload a file or add it to my > >> >>> >> history > >> >>> >> in the meantime? Command-line is ok. If there isn't one, that's > ok > >> >>> >> too > >> >>> >> Dan > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > I'll let you know what I can find. > >> >>> >> > Carl > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > On Wed, Jan 23, 2013 at 5:18 PM, Dan Tenenbaum > >> >>> >> > > >> >>> >> > wrote: > >> >>> >> >> > >> >>> >> >> Hi Carl, > >> >>> >> >> > >> >>> >> >> On Wed, Jan 23, 2013 at 2:14 PM, Carl Eberhard > >> >>> >> >> > >> >>> >> >> wrote: > >> >>> >> >> > Heya, Dan. > >> >>> >> >> > > >> >>> >> >> > Sorry for the trouble. > >> >>> >> >> > When you get that error again look for a line like you have > >> >>> >> >> > above: > >> >>> >> >> > Debug at: http://localhost:8080/_debug/view/1358978130 > >> >>> >> >> > > >> >>> >> >> > If you open a new tab or window in your browser and go to > the > >> >>> >> >> > address > >> >>> >> >> > ('http://localhost:8080/_debug ...'), you should see a more > >> >>> >> >> > informative > >> >>> >> >> > error message - complete with a list of function calls that > >> >>> >> >> > led > >> >>> >> >> > to > >> >>> >> >> > the > >> >>> >> >> > error > >> >>> >> >> > (a stack trace). > >> >>> >> >> > > >> >>> >> >> > Can you post that stack trace when you see it? > >> >>> >> >> > > >> >>> >> >> > >> >>> >> >> Thanks for the quick response. Here it is: > >> >>> >> >> > >> >>> >> >> URL: http://localhost:8080/tool_runner/upload_async_create > >> >>> >> >> File > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > '/Users/dtenenba/dev/galaxy-dist/eggs/WebError-0.8a-py2
Re: [galaxy-dev] error uploading file with fresh installation: this request returned None from get_history()
On Mon, Jan 28, 2013 at 1:59 PM, Carl Eberhard wrote: > If you go to your galaxy root in a terminal and then cd to eggs, what is the > version listed for SQLAlchemy? > SQLAlchemy-0.5.6_dev_r6498-py2.7.egg > Do you have SQLAlchemy installed already on that machine (apart from the one > in Galaxy's eggs)? > I don't think so. I never knowingly installed it and in a fresh python session, 'import sqlalchemy' returns an error that there is no such module. Thanks, Dan > > > On Mon, Jan 28, 2013 at 4:50 PM, Dan Tenenbaum wrote: >> >> On Mon, Jan 28, 2013 at 1:40 PM, Carl Eberhard >> wrote: >> > I was incorrect in stating that the changes in the next galaxy-dist will >> > help in this case, unfortunately. From the stack trace you posted, there >> > is >> > a deeper error with your instance that the client-side changes won't >> > help. >> > >> > Can you post the size, type, and name of the file you're trying to >> > upload? >> > >> >> I can reproduce this by just typing "hello, world" into the >> "URL/Text:" box on the "Upload File" page. Any file of any type seems >> to trigger this problem. >> >> Thanks, >> Dan >> >> >> > >> > On Thu, Jan 24, 2013 at 6:12 PM, Dan Tenenbaum >> > wrote: >> >> >> >> On Wed, Jan 23, 2013 at 3:19 PM, Carl Eberhard >> >> >> >> wrote: >> >> > Another thing you might try is to upload the file to our test server: >> >> > https://test.g2.bx.psu.edu/ and see if that works. >> >> > >> >> >> >> Thanks, that does work. >> >> >> >> Setting up an FTP server on my local installation seems pretty >> >> complex. All I really want to do is work around this issue and fool >> >> Galaxy into thinking that I have uploaded a file using the >> >> uploader...since this is a local installation I can put a file >> >> anywhere on my system, I don't have to actually upload it, just place >> >> it in a directory. >> >> >> >> If there is no such workaround, I'll wait for the fix, I guess. Thanks >> >> very much for working on this! >> >> Dan >> >> >> >> >> >> > >> >> > On Wed, Jan 23, 2013 at 6:06 PM, Carl Eberhard >> >> > >> >> > wrote: >> >> >> >> >> >> If this is happening consistently and a refresh on the history isn't >> >> >> doing >> >> >> anything, you might try ftp upload: >> >> >> http://wiki.galaxyproject.org/FTPUpload >> >> >> or if you have permissions or are an admin you can try uploading to >> >> >> a >> >> >> data >> >> >> library: >> >> >> >> >> >> http://wiki.galaxyproject.org/Admin/DataLibraries/UploadingLibraryFiles >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Jan 23, 2013 at 5:44 PM, Dan Tenenbaum >> >> >> wrote: >> >> >>> >> >> >>> On Wed, Jan 23, 2013 at 2:42 PM, Carl Eberhard >> >> >>> >> >> >>> wrote: >> >> >>> > What sort of database are you using on your local instance? >> >> >>> > >> >> >>> >> >> >>> The default (sqlite I guess). It's a completely vanilla instance, I >> >> >>> have not touched the config files. >> >> >>> Dan >> >> >>> >> >> >>> >> >> >>> > >> >> >>> > On Wed, Jan 23, 2013 at 5:37 PM, Dan Tenenbaum >> >> >>> > >> >> >>> > wrote: >> >> >>> >> >> >> >>> >> On Wed, Jan 23, 2013 at 2:35 PM, Carl Eberhard >> >> >>> >> >> >> >>> >> wrote: >> >> >>> >> > Thanks, Dan. That helps and I'll start looking into this. >> >> >>> >> > >> >> >>> >> > We will be pushing out a new galaxy-dist revision sometime >> >> >>> >> > this >> >> >>> >> > week >> >> >>> >> > if >> >> >>> >> > all >> >> >>> >> > goes well. This revision includes some code for the history >> >> >>> >> > panel >> >> >>> >> > that >> >> >>> >> > may >> >> >>> >> > help handle this situation a bit better. I'd recommend >> >> >>> >> > updating >> >> >>> >> > to >> >> >>> >> > that >> >> >>> >> > revision when it comes out. >> >> >>> >> > >> >> >>> >> >> >> >>> >> Thanks! Is there a workaround to upload a file or add it to my >> >> >>> >> history >> >> >>> >> in the meantime? Command-line is ok. If there isn't one, that's >> >> >>> >> ok >> >> >>> >> too >> >> >>> >> Dan >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> > I'll let you know what I can find. >> >> >>> >> > Carl >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > On Wed, Jan 23, 2013 at 5:18 PM, Dan Tenenbaum >> >> >>> >> > >> >> >>> >> > wrote: >> >> >>> >> >> >> >> >>> >> >> Hi Carl, >> >> >>> >> >> >> >> >>> >> >> On Wed, Jan 23, 2013 at 2:14 PM, Carl Eberhard >> >> >>> >> >> >> >> >>> >> >> wrote: >> >> >>> >> >> > Heya, Dan. >> >> >>> >> >> > >> >> >>> >> >> > Sorry for the trouble. >> >> >>> >> >> > When you get that error again look for a line like you have >> >> >>> >> >> > above: >> >> >>> >> >> > Debug at: http://localhost:8080/_debug/view/1358978130 >> >> >>> >> >> > >> >> >>> >> >> > If you open a new tab or window in your browser and go to >> >> >>> >> >> > the >> >> >>> >> >> > address >> >> >>> >> >> > ('http://localhost:8080/_debug ...'), you should see a more >> >> >>> >> >> > informative >> >> >>> >> >> > error message - complete with a list of function calls that >> >> >>> >> >> > led >> >> >>> >> >> > to >>
[galaxy-dev] Tool shed and tools with dynamically generated select list parameters
Hi, I'm trying to get lastz to show a locally cached reference. As I'm used to do I went ahead and copy tool-data/lastz_seqs.loc.sample(still included with galaxy-dist) to tool-data/lastz_seqs.loc and added my local references. Nothing happened. I get: galaxy.tools.parameters.dynamic_options WARNING 2013-01-28 16:42:58,203 Data table named 'lastz_seqs' is required by tool but not configured I realized there are these two files in the lastz repository: ../shed_tools/toolshed.g2.bx.psu.edu/repos/devteam/lastz/0801f8207d30/lastz/tool_data_table_conf.xml.sample ../shed_tools/toolshed.g2.bx.psu.edu/repos/devteam/lastz/0801f8207d30/lastz/tool-data/lastz_seqs.loc.sample I created their minus '.sample' versions in the same locations and added my local references to this lastz_seqs.loc, still nothing. I finally manually edited the main tool_data_table_conf.xml adding: value, name, path And that did the trick. Is this the expected way of handling these cases?. This paragraph from the wiki didn't clarify much for me: http://wiki.galaxyproject.org/InstallingRepositoriesToGalaxy "Tool shed repositories that contain tools that include dynamically generated select list parameters that refer to an entry in the tool_data_table_conf.xml file must contain a tool_data_table_conf.xml.sample file that contains the required entry for each dynamic parameter. Similarly, any index files (i.e., ~/tool-data/xxx.loc files) to which the tool_data_table_conf.xml file entries refer must be defined in xxx.loc.sample files included in the tool shed repository along with the tools. If any of these tool_data_table_conf.xml entries or any of the required xxx.loc.sample files are missing from the tool shed repository, the tools will not properly load and metadata will not be generated for the repository. This means that the tools cannot be automatically installed into a Galaxy instance." Best regards, 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 shed and tools with dynamically generated select list parameters
Hello Carlos, On Jan 28, 2013, at 5:13 PM, Carlos Borroto wrote: > Hi, > > I'm trying to get lastz to show a locally cached reference. As I'm > used to do I went ahead and copy tool-data/lastz_seqs.loc.sample(still > included with galaxy-dist) to tool-data/lastz_seqs.loc and added my > local references. Nothing happened. I get: > galaxy.tools.parameters.dynamic_options WARNING 2013-01-28 > 16:42:58,203 Data table named 'lastz_seqs' is required by tool but not > configured > > I realized there are these two files in the lastz repository: > ../shed_tools/toolshed.g2.bx.psu.edu/repos/devteam/lastz/0801f8207d30/lastz/tool_data_table_conf.xml.sample > ../shed_tools/toolshed.g2.bx.psu.edu/repos/devteam/lastz/0801f8207d30/lastz/tool-data/lastz_seqs.loc.sample > > I created their minus '.sample' versions in the same locations and > added my local references to this lastz_seqs.loc, still nothing. > > I finally manually edited the main tool_data_table_conf.xml adding: > > >value, name, path > > > > And that did the trick. Is this the expected way of handling these cases?. Yes, however, if your install the repository from the Galaxy administrator interface, this should all happen automatically for you. If you download the repository as a tar archive and manually install it from outside of the Galaxy interface, you'll have to do all of this manually. > > This paragraph from the wiki didn't clarify much for me: > http://wiki.galaxyproject.org/InstallingRepositoriesToGalaxy > "Tool shed repositories that contain tools that include dynamically > generated select list parameters that refer to an entry in the > tool_data_table_conf.xml file must contain a > tool_data_table_conf.xml.sample file that contains the required entry > for each dynamic parameter. Similarly, any index files (i.e., > ~/tool-data/xxx.loc files) to which the tool_data_table_conf.xml file > entries refer must be defined in xxx.loc.sample files included in the > tool shed repository along with the tools. If any of these > tool_data_table_conf.xml entries or any of the required xxx.loc.sample > files are missing from the tool shed repository, the tools will not > properly load and metadata will not be generated for the repository. > This means that the tools cannot be automatically installed into a The next paragraph in the same wiki page clarifies this: For those tools that include dynamically generated select list parameters that require a missing entry in the tool_data_table_conf.xml file, this file will be modified in real time by adding the entry from a tool_data_table_conf.xml.sample file contained in the tool shed repository. > Galaxy instance." > > Best regards, > 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 shed and tools with dynamically generated select list parameters
On Mon, Jan 28, 2013 at 5:29 PM, Greg Von Kuster wrote: > And that did the trick. Is this the expected way of handling these cases?. > > > Yes, however, if your install the repository from the Galaxy administrator > interface, this should all happen automatically for you. If you download > the repository as a tar archive > and manually install it from outside of the Galaxy interface, you'll have to > do all of this manually. > I guess I overwrote the main tool_data_table_conf.xml with the sample one at some point, cause I don't remember installing this repository manually. > > The next paragraph in the same wiki page clarifies this: > > For those tools that include dynamically generated select list parameters > that require a missing entry in the tool_data_table_conf.xml file, this file > will be modified in real time by adding the entry from a > tool_data_table_conf.xml.sample file contained in the tool shed repository. > Ooops, I stopped reading too soon. 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] Loading a library of bam files
It looks like if I set 'retry_metadata_internally = False' it stops trying to index them on the queue node. The datasets get added into the library, without a BAM index file, but without error. I guess the index files can be generated on demand later on. Kyle On Mon, Jan 28, 2013 at 12:42 PM, Greg Von Kuster wrote: > Hi Kyle, > > I'm hoping I can help you a bit on this, although i am not very familiar > with the code that is producing this behavior. Your previous reply > mentions the following: > > During job cleanup, > galaxy.jobs.__init__.py:412, because > external_metadata_set_successfully returns false. > An external set_metadata.sh job was run, but it doesn't seem to call > samtools. Maybe if I figure out why set_metadata.sh isn't working, > this problem will go away. > > Based on your comments, there are a few things you can do: > > 1. If setting external metadata results in an error, the error should be > printed out in your paster log. Do you see anything relevant there? > > 2. You also may be able to discover the error if you perform the following > sql manually - make sure your have the correct job_id: > > select filename_results_code from job_external_output_metadata where > job_id = ; > > 3. Make sure you have the following config setting uncommented and set to > False in your universe_wsgi.ini (the default is set to True): > > # Although it is fairly reliable, setting metadata can occasionally fail. > In > # these instances, you can choose to retry setting it internally or leave > it in > # a failed state (since retrying internally may cause the Galaxy process > to be > # unresponsive). If this option is set to False, the user will be given > the > # option to retry externally, or set metadata manually (when possible). > retry_metadata_internally = False > > Let me know if any of this helps you resolve the problem, and if not, > we'll figure out next steps if possible. > > Thanks, > > Greg Von Kuster > > > On Jan 24, 2013, at 4:36 PM, Kyle Ellrott wrote: > > I'm willing to put in the coding time, but I'd need some pointers on the > best way to go about making the changes. > > Kyle > > > On Wed, Jan 23, 2013 at 6:35 PM, Anthonius deBoer wrote: > >> I also second this request to get it addressed (Where can we vote on bug >> fixes ?! :) ...It is very weird that samtools is run on the local machine >> and it even does the indexing sequentially... >> Thon >> >> >> On Jan 23, 2013, at 03:28 PM, Kyle Ellrott wrote: >> >> I'm currently in the process of loading (path paste) a large library of >> BAM files (>1) into the shared Data Libraries of our local galaxy >> installation, but I'm finding this process to be very slow. >> I'm doing a path paste, and not actually copying the files. I have >> disabled local running of 'upload1', so that it will run on the cluster, >> and set 'set_metadata_externally' to true. >> It looks like the job handlers are calling 'samtools index' directly. >> Looking through the code, that seems to happen in galaxy/datatypes/binary >> in Bam.dataset_content_needs_grooming, where it calls 'samtools index' and >> then waits. >> What would be the most efficient way to start changing the code so that >> this process can be done by an external script, at a deferred time out on >> the cluster? >> >> Kyle >> ___ >> 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/ > > > ___ 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/