Hi,
I'm running cutadapt (from TS) on a collection with 96 datasets, started
from a workflow as an intermediate step.
About half of them fail with this message.
Traceback (most recent call last):
File "/mnt/galaxy/galaxy-app/lib/galaxy/jobs/runners/__init__.py",
line 590, in finish_job
job_
Indeed, this would be the right approach.
But so far the current strategy is quite imputed also in tools.
E.g. BWA from devteam automatically sorts the bam afterwards - wanted or
not.
2015-07-17 11:59 GMT-05:00 Ryan G :
> I would think the correct approach would be to allow any bam file and if a
I would think the correct approach would be to allow any bam file and if a tool
requires a coordinate sorted bam and one is not provided it would make sense
for the tool to fail with an error.
Does galaxy itself require a coordinate sorted bam or this this so the majority
of tools can functi
I've created a trello card for this, hence making it adding it to the
actual todo list: https://trello.com/c/cqEwunvl
Not sure when I'll get to this but it'll get done.
Thanks.
On Fri, Jul 17, 2015 at 11:27 AM, Alexander Vowinkel <
vowinkel.alexan...@gmail.com> wrote:
> Hi,
>
> I am referring to
Yeah - it seems like ftplib doesn't support proxies and that is what
is used by this script:
https://github.com/galaxyproject/tools-devteam/blob/master/data_managers/data_manager_fetch_genome_all_fasta/data_manager/data_manager_fetch_genome_all_fasta.py
Some relevant discussion here:
http://stack
Hi,
I am referring to this:
http://dev.list.galaxyproject.org/CloudMan-auto-scaling-Use-spot-instance-for-worker-node-tp4665813p4665835.html
I would give an upvote for spot instances for auto-scaling.
Have there been more ideas about this since?
Best,
Alexander
_
I'm not the right person to respond to this but since no one else has
I will explain my limited (probably incorrect) understanding of the
problem and what needs to be done. I believe Galaxy assumes all bam
files are coordinated sorted by default - so Galaxy's bam datatype
would be better thought of
This is a good news, bad news sort of thing. I have opened a PR to fix
the actual uploads here -
https://github.com/galaxyproject/galaxy/pull/474. But I think many
tools don't properly quote file paths with names in them - so I
suspect you will find a lot of tool bugs using these files.
Thanks for
Hi Marius,
I can also confirm that switching branches to revert the patch allows normal
finishing of jobs. So its clearly related to the patches we applied yesterday
to fix the metadata issue (see [galaxy-dev] Slow responses viewing histories).
However, I have noticed that even on an older non-
Hi Richard,
Reverting the patch allows normal finishing of jobs, so unfortunately it
seems
we get a double import somewhere in the patch ... i'm suspecting it's
*from* galaxy *import* app
in lib/galaxy/model/custom_types.py, but I don't know how to circumvent
this.
Marius
On 17 July 2015 at 1
Hi Richard,
Well, I do have the same problem now (running bamtools), after applying the
patch that should fix
metadata issue we discussed yesterday.
I'll dig into this.
Marius
On 17 July 2015 at 11:37, Poole, Richard wrote:
> Hi all,
>
> With the most recent update of Galaxy and also OS X 10
Hi all,
With the most recent update of Galaxy and also OS X 10.10.4 I am seeing this
error message when first starting up the server:
/Users/galaxy/galaxy-dist/lib/galaxy/__init__.py:63: UserWarning: Module yaml
was already imported from
/Library/Python/2.7/site-packages/PyYAML-3.11-py2.7-maco
12 matches
Mail list logo
