, 15 February 2014 4:37 a.m.
To: Björn Grüning
Cc: Guest, Simon; galaxy-dev@lists.bx.psu.edu
Subject: Re: [galaxy-dev] Difficulty dispatching toolshed tool jobs via
job_conf.xml
Hi Björn,
It should be fixed, the problem was with tools with uppercase characters
in the guid:
https
At Thu, 24 Oct 2013 10:03:14 -0400,
Greg Von Kuster wrote:
Hello Simon,
On Oct 23, 2013, at 5:01 PM, Simon Guest simon.gu...@agresearch.co.nz wrote:
We've noticed a funny about resetting repository metadata from the
toolshed web interface.
My understanding is that this is used to
At Mon, 14 Oct 2013 20:22:06 -0500,
John Chilton wrote:
Simon,
Very cool! I have two concerns. Rather than adding a new
configuration option I think I would prefer to just check the
configured dependency resolvers and then infer from them if the tool
shed will be used. The configuration
At Fri, 4 Oct 2013 23:12:01 -0500,
John Chilton wrote:
I understand the desire to not want to try to execute the tool shed
actions if tool_shed_packages are not specified in the dependency
resolvers list. I have created a Trello card for it
(https://trello.com/c/CPeU3VlR). It sounds like the
At Thu, 10 Oct 2013 00:31:56 -0500,
John Chilton wrote:
Simon, using your test tools I was able to reproduce your errors. Pull
request 233 is my attempt to fix them with a lighter touch than just
immediately converting outputs to ascii. Do these patches work on your
end?
Bjoern, do these
I look forward to some more details from Dan on *.loc
file setup.
Hi Peter, Dan and all,
What a timely discussion! I am just in the process of setting up loc files for
some new indexes I have created (bowtie2, etc), and would really like to see
this automated.
I see there is a Galaxy
Dear Galaxy developers,
Currently our production Galaxy runs the stable branch. However, I see one or
two reasons to want to run the development (default) branch for a while.
This will involved migrating the database to a later version, which is fine, as
migration scripts exists.
What I am
(Just testing that my Exchange Server admin guy has managed to disable the
stupid legal disclaimers on my postings to this list.)
___
Please keep all replies on the list by using reply all
in your mail client. To manage your subscriptions
At Fri, 27 Sep 2013 00:23:37 -0500,
John Chilton wrote:
Simon,
What is the advantage of putting that XML definition in the tool shed?
It is not 100% true because of prior_install_required dependencies,
but for the most part sourcing/load the environment for tools is a
Galaxy problem, not
At Thu, 26 Sep 2013 22:03:09 -0400,
Greg Von Kuster wrote:
Hi John,
On Sep 26, 2013, at 9:15 PM, John Chilton chil...@msi.umn.edu wrote:
I was not even thinking we needed to modify the tool shed to implement
this. I was hoping (?) you could just modify:
Nothing in the Tool Shed
At Thu, 19 Sep 2013 11:44:35 +0200,
Bjoern Gruening wrote:
Hi Simon,
it's just a guess but can you try the attached patch if you have a
reproducible case. It is not tested, but at least it should point you in
the right direction. If its working, I will create a pull request.
Hi Bjoern,
Hi Nikhil,
I've been using your Galaxy wrapper for deseq_and_sam2counts.
I fixed it up to run the R script from the tool install directory directly, so
no manual copying of the script is required after installation in the Galaxy
GUI.
I attach my patch (as a Mercurial export), and hope you
problem. Pesky web
proxy, bah!
You should never trust random strangers on the net, by the way. ;-)
cheers,
Simon
-Original Message-
From: Guest, Simon
Sent: Thursday, 5 September 2013 1:38 p.m.
To: Alistair Chilcott
Cc: galaxy-dev@lists.bx.psu.edu
Subject: RE: Mercurial updates
I've finally joined the happy throng suffering from Unicode errors. In my
particular case, running the deseq tool from the main toolshed brought down my
Galaxy server, and it wouldn't restart. The traceback in paster.log contained
this
Traceback (most recent call last):
[snip]
File
Hi Bjoern,
I can see man years of effort being spent on solving this problem within
Galaxy. I was going to title this email Danger, Will Robinson, but I didn't
want to be disrespectful. I think the path being embarked upon, tool
dependency packaging, tool versioning, reproducibility, and
Message-
From: Greg Von Kuster [mailto:g...@bx.psu.edu]
Sent: Friday, 6 September 2013 1:00 p.m.
To: Guest, Simon
Cc: galaxy-dev@lists.bx.psu.edu
Subject: Re: [galaxy-dev] Bug in toolshed: changing public name breaks
repo path
Hello Simon,
The tool shed middleware basically consists
Another vote for the excellent modules system from us at AgResearch
Galaxy's dependency injection works in a similar way, without requiring
all the external dependencies. We don't need unload since we compose a
unique environment for every tool execution. This is much cleaner that
loading
Just been reading a bit more about the Galaxy packaging system. Here's a
slight modification to what I was suggesting that might fit in a bit better.
Apologies for not being more familiar with the existing system before proposing
extensions.
Recall that my goal is to support using a
Hi Joachim,
At AgResearch we are using ZFS for our HPC storage, which is used by our
internal Galaxy instance. Currently we are running on FreeNAS (FreeBSD
derivative), but we are in transition to ZFS on Linux. We export the
filesystem over NFS (10Gb Ethernet), but not the database
From: Nate Coraor [mailto:n...@bx.psu.edu]
This should work, it looks like there may be a bug with handling tool shed
IDs when determining job destinations. You are actually supposed to be
able to use any of:
shed_host/repos/owner/repo/tool_id/version
I am having trouble getting a toolshed tool to be dispatched to the destination
I list in the job_conf.xml file.
My job_conf.xml file looks like this:
?xml version=1.0?
job_conf
plugins
plugin id=local type=runner
load=galaxy.jobs.runners.local:LocalJobRunner workers=20/
to
know how others are doing that.
cheers,
Simon
-Original Message-
From: Greg Von Kuster [mailto:g...@bx.psu.edu]
Sent: Friday, 6 September 2013 1:17 a.m.
To: Guest, Simon
Cc: Dave Bouvier; galaxy-dev@lists.bx.psu.edu
Subject: Re: [galaxy-dev] Bug in toolshed: changing public name
, or
am I outside the bounds of what has been tested so far?
Thanks for your help, much appreciated.
cheers,
Simon
-Original Message-
From: Dave Bouvier [mailto:d...@bx.psu.edu]
Sent: Thursday, 5 September 2013 1:07 a.m.
To: Greg Von Kuster
Cc: Guest, Simon; galaxy-dev@lists.bx.psu.edu
Hi Alistair,
I have seen error output like this from mercurial when the client is running a
newer version than the server.
Maybe you recently upgraded your machine, and your mercurial version is now too
recent.
Hope that helps. Of course, it may be a complete red herring, YMMV. ;-)
cheers,
I'm just setting up a local toolshed. After creating a repo, I changed my
public name (from the default guestsi to simon-guest) on the web interface, and
got this traceback when I tried to look at my repo:
Internal Server Error
Galaxy was unable to sucessfully complete your request
URL:
It looks like it's trying to use the public name in the repo path, which
isn't going to work very well if public names can be changed.
Changing my public name back to what it was before made it start working
again.
To reply to my own post, I see now that when you create a user, a comment on
Simon wrote:
An example is the NCBI BLAST+ suite, which failed to build on my
(EL6) system, because it couldn't run /usr/bin/touch. That's pretty
dumb, and pretty simple to solve in isolation - it needs to be running
/bin/touch instead.
This was an oddity in the NCBI compile scripts
Dear Galaxians,
This email is about difficulties with the current approach for installing tool
dependency binaries from the Galaxy Toolshed, and what might be done to improve
the situation. It comes down to this: packaging software to run on different
systems is tricky. It is a problem that
Just catching up with the galaxy-dev mailing list, and found some remarks about
RPy not working with R 3.0. If that's bugging you, you may be interested in my
patches for RPy-1.0.3a, which enable it to work with R 3.0.1 (and probably
3.0.0, but we've moved on from that here).
Attached, in
Hi Simon,
Significant changes to the way that job run parameters are defined will be
included in a future release. In specific, there'll be no more job runner
URLs, and parameters will be specified with a more robust XML language.
These changes aren't stable enough to go out in the next
Dear Galaxians,
We are using Galaxy with RepeatMasker 3.3.0. I don't know whether that is the
expected version, as I can't find any statement about what is required in the
Galaxy tool dependencies for RepeatMasker.
Anyway, when a job is submitted with no repeats, RepeatMasker 3.3.0 doesn't
We have set up our local Galaxy installation to submit jobs by default through
HTCondor, using the drmaa tool runner. We override this on a tool-by-tool
basis in universe_wsgi.ini, to specify certain tools we always want to run
locally.
The problem is that EMBOSS tools have a tool id like
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
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
Rpy is only used by a handful of tools (should be listed on the tool
dependencies page). Everything else in Galaxy should work fine without it.
Yes, I realise that. It's that handful of tools I'm interested in.
I expect they will do their thing just fine with a semi-broken RPy, but I was
Dear Galaxy devs,
We are in the process of deploying Galaxy internally here at AgResearch, and I
am currently installing required dependencies. My question relates to RPy. It
seems that RPy2 is not yet supported by Galaxy, so we're stuck with RPy 1.0.3a,
and this seems to have rusted quite
36 matches
Mail list logo
