Thanks for information Greg. Actually, it turned out to be two things
causing my issues:
1) My copy of tool-data/sam_fa_indices.loc.sample was not owned by the
galaxy user (though it was writable by that user). This caused the
exception which caused the installation to get stuck at cloning:
Hi Lance,
Thank you for the pull request. I think this is an excellent way to handle
patches until the toolshed itself provides a better mechanism, particularly for
the devteam owned repositories; other repository owners may prefer different
methods of providing patches, but they can be
Thanks for the quick turnaround Dan. Much appreciated. When I tried to
test updating Freebayes from the toolshed, I get a message that no
updates are available. Perhaps it takes some time before they are
recognized? Or am I missing something?
Lance
Daniel Blankenberg wrote:
Hi Lance,
Hi Lance,
This has to do with the way that the updating currently works. Since the
migrated version is 0.0.2, the automatic update will only update that
particular Tool version (newest version of 0.0.2). To get 0.0.3, you need to
install it as a new tool. This way you are able to have both
Thanks for the explanation. That makes sense. I went ahead and
installed the new version along with dependencies in my development
environments and all went well. Then in production, the installation
seems to have failed and I'm now stuck with freebayes in the cloning
status. I tried to
Hi Lance,
You'll need to execute the following sql manually in your Galaxy database.
update tool_shed_repository set status = 'New' where status = 'Cloning';
Next, you'll have to update your production Galaxy instance code base to at
least changeset 2531e085f262 (the human-readable changeset
I have been using the FreeBayes tool in our local Galaxy instance for
some time. As FreeBayes is a rapidly evolving tool, it has been very
helpful to have Daniel Blankenberg work on keeping an updated wrapper.
Recently, I've run into a rather troublesome bug in FreeBayes
