Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 31 2019 17:58
    jorgemachucav starred galaxyproject/tools-iuc
  • Jan 31 2019 17:45
    bebatut opened #2270
  • Jan 31 2019 16:18
    cpreviti synchronize #2267
  • Jan 31 2019 14:15
    cpreviti synchronize #2267
  • Jan 31 2019 12:42
    bernt-matthias review_requested #2269
  • Jan 31 2019 12:42
    bernt-matthias edited #2269
  • Jan 31 2019 12:41
    bernt-matthias edited #2269
  • Jan 31 2019 12:40
    bernt-matthias synchronize #2269
  • Jan 31 2019 12:13
    cpreviti commented #2267
  • Jan 31 2019 12:07
    nsoranzo commented #2267
  • Jan 31 2019 12:01
    cpreviti synchronize #2267
  • Jan 31 2019 11:21
    cpreviti synchronize #2267
  • Jan 31 2019 09:47
    cpreviti synchronize #2267
  • Jan 31 2019 09:27
    cpreviti synchronize #2267
  • Jan 30 2019 20:38
    bernt-matthias commented #2131
  • Jan 30 2019 20:19
    hepcat72 commented #2239
  • Jan 30 2019 19:50
    lparsons commented #2239
  • Jan 30 2019 18:36
    bgruening commented #2268
  • Jan 30 2019 15:23
    nsoranzo commented #2268
  • Jan 30 2019 15:23
    nsoranzo commented #2267
Nicola Soranzo
@nsoranzo
Alexie Papanicolaou
@alpapan
@nsoranzo done, thanks!
Robert Leach
@hepcat72
BTW, I wrote the lumpyexpress wrapper because the lumpy-sv galaxy tool was getting an error on data I was successfully processing on my mac locally. Instead of dealing with the $HEXDUMP environment variable, I noticed that the versions on galaxy versus my mac were different. Local version: 0.2.13 Galaxy version: 0.2.14a. So I tried simply downgrading the version I'd wrapped to be the same, but now I run into the same error on galaxy that I get when running the existing lumpy galaxy wrapper. Suspecting that possibly the versions between my mac and galaxy (though reporting as the same) were possibly different, I tried copying the lumpyexpress script to my machine and comparing them. I installed lumpy locally using homebrew. There were in fact a few differences in the script, but when I ran the galaxy version of the script on my mac, it completes successfully. So I figure either the compiled version of lumpy on galaxy is different and has a bug compared to my version, or it is a bug that only affects linux... or perhaps there's some dependency or config issue in the galaxy version... I'm going to keep digging. I posted on lumpy-discuss.
Martin Cech
@martenson
Is suite_gemini going to be updated automatically after a tool within has a version bump?
Martin Cech
@martenson
oh, they won't get updated because they are on the skiplist?
Nicola Soranzo
@nsoranzo
They were not pushed to the TS in https://travis-ci.org/galaxyproject/tools-iuc/jobs/442711626 , if that's what you meant
Martin Cech
@martenson
that was one of my questions, other is whether the planemo update automatically updates the suite when a tool changes
Nicola Soranzo
@nsoranzo
Not sure, suites are a bit weird
Nicola Soranzo
@nsoranzo
We should manually planemo shed_update the gemini tools after galaxyproject/tools-iuc#2147 is merged
Martin Cech
@martenson
but we don't know if that updates the suite, do we?
Nicola Soranzo
@nsoranzo
I don' think it does, but as said above, I'm not sure.
Nicola Soranzo
@nsoranzo
Actually the suite was updated
jhl667
@jhl667
Hi there. I have what I believe is an easy question. How do I access an input data format inside the cheetah section? For instance, if my input is a vcf, I would like to append a vcf suffix to the output file name.
jhl667
@jhl667
nvm, I found the magic variable name :-)
Robert Leach
@hepcat72
So I found the bug in lumpy that was causing lumpy to error out on galaxy and causing my lumpyexpress wrapper to segfault. Just submitted a PR that is a work-around to the issue, until they figure out a more elegant/comprehensive solution. Basically, a change in the latest version caused lumpyexpress to segfault and the lumpy galaxy wrapper to fail with an error on samples that had arbitrarily too few reads to calculate an insert mean & stdev. The old version of lumpy always spit out values. The new version spit out "NA"s, but the lumpy c program doesn't account for that (as in the galaxy tool and fails), or for the omission of the affected discordant files (as in lumpyexpress and segfaults).
Marius van den Beek
@mvdbeek
awesome, thanks for digging into this @hepcat72. hope that wasn't my python 3 port :D
Robert Leach
@hepcat72
I wouldn’t think so. It appeared to be an intentional change to get reasonably reliable insert insert size predictions. The problem though is that it wasn’t fully accounted for downstream. The discordant file’s we’re being removed from the lumpy call in the specific case where mean & stdev were being set to “NA”. Those were both new changes. Though it appears that the removal wasn’t tested when split reads were also supplied.
foellmelanie
@foellmelanie
Hi, does anyone know if it is possible to filter an output for a parameter that is inside a conditional and a repeat? I would like to filter for this parameter: https://github.com/galaxyproteomics/tools-galaxyp/blob/master/tools/maldiquant/maldi_quant_peakdetection.xml#L458
foellmelanie
@foellmelanie
Hi, thanks for the link but I cannot find any repeat in your xml file, the repeat is my major problem...
Robert Leach
@hepcat72
Why is it that when I run MEME in galaxy, the HTML output doesn't have an <HTML>, <HEAD>, or <BODY> tags and displays as code in a browser? I tried converting the xml to html using meme's meme_xml_to_html utility, but it gives me the following errors:
Failed to write HTML output due to errors processing the XML:
training_set@primary_sequences missing
training_set@primary_count missing
training_set@primary_positions missing
training_set@control_sequences missing
training_set@control_count missing
training_set@control_positions missing at /usr/local/meme/libexec/meme-5.0.1/meme_xml_to_html line 453, <$fh> line 165.
Robert Leach
@hepcat72
Never mind. meme had to be whitelisted.
Jennifer Hillman-Jackson
@jennaj
@bgruening the repo for hicexplorer states that the minimum Galaxy version is 16.01... there is a user running 16.04 where the tool fails to install correctly. Could you help? https://biostar.usegalaxy.org/p/29819/
Björn Grüning
@bgruening
@jennaj I did. I think the conda package is just not properly installed
thanks for the pointer!
Jennifer Hillman-Jackson
@jennaj
appreciate the help :)
Robert Leach
@hepcat72
I have a question. I mucked up my tool shed repository somehow. I suspect maybe I unwittingly changed the tool ID. The latest revision is installable and it works, but if you previously installed the first revision, galaxy will always tell you a newer version is available but when you try to update it, it tells you your version is already up-to-date (even though it's not). Is there a way to fix that so that the others who installed the first version can update to the latest revision? https://toolshed.g2.bx.psu.edu/repository?repository_id=03a7aba90bfaa97c
I managed to install the latest revision, but I had to delete what appeared to be 2 already-installed versions before I could get the latest
Jennifer Hillman-Jackson
@jennaj
@hepcat72 Do you mean that the "Versions" menu is not correctly switching tool versions? What version of Galaxy are you running (dev, prerelease 18.09, or ??). I checked the MTS and the tool id is the same in the metadata and looks nested correctly.
Also, did you install using the GUI Admin functions or from your dev repo?
I can't help with MTS details, but this will give more info once the devs get back online tomorrow.
I did notice that the MTS only has two tool revisions, not three, so it skips whatever was intermediate. Revision: 0:e5150e64206a && Revision: 3:d637435b1227
Marius van den Beek
@mvdbeek
@hepcat72 yeah, tool ids should be constant, so don't include the tool version in the id, we got the version attribute for that. The other thing is that every revision remains in the admin panel, so it'll always say that a new revision is available. As an admin you just want to sure that at least exactly one of the installed revisions is the latest
Robert Leach
@hepcat72

The tool IDs all match now (via shed updates), but I had installed an earlier version which had a different tool ID. I don't know if anyone else installed that older version. Hopefully not. If they did, they may have the same trouble I did where it wouldn't update the tool to the latest version.

Anyway, I have another question. I've been tweaking my lumpyexpress galaxy wrapper to try and work around an issue with lumpyexpress (for which I submitted a PR - but I guess I'm just impatient). I implemented a workaround, did planemo test and I even tested it on my own dev version of galaxy. Then I put it on the test toolshed, installed it in my dev version of galaxy and tested it again. Everything works. But once I install it on an instance of galaxy on another machine via the toolshed and test it, it fails. How can I avoid such failures?

So, for instance, I wanted to do something that I thought would be very simple: I needed to change the value of a variable in a script that lumpyexpress calls from 1000 to 1. So I wanted to copy a script from the lumpy package to the workdir, change the value of a variable set on one line of the script, copy the config file to set a new location for that script, and run lumpyexpress (supplying the new config file in the workdir). Doing that worked on my machine, but when it runs somewhere else, it complains about a missing bamlib.py. I don't care about this particular effort with lumpyexpress. It will eventually get fixed in lumpy itself. I was just being impatient. But in general, unless I'm submitting a package to conda-recipes, how can I test that my galaxy wrapper is going to work elsewhere? Is there a local circleci I can run to do planemo test on?

Marius van den Beek
@mvdbeek

would be very simple: I needed to change the value of a variable in a script that lumpyexpress calls from 1000 to 1

That doesn't sound simple at all, that sounds like it would be very likely to break. The more reasonable approach IMO is to package up your fork of lumpy, push it to your conda channel and install from there.

But in general, unless I'm submitting a package to conda-recipes, how can I test that my galaxy wrapper is going to work elsewhere? Is there a local circleci I can run to do planemo test on?

This is a fairly universal problem for which there are many solutions. I guess the easiest is to build on a service like travis or circle-ci (that's what the IUC is doing), or you can use a dockerized galaxy using planemo. You'll want to isolate your development environment from your tests. The other, qicker, but not as thorough alternative is to be careful to have nothing global in your environment

Brad Langhorst
@bwlang
I need the methylkit tool… which @bgruening has in his repo. It’s old, missing package versions etc. Should I updated it where it is now or should it be moved to iuc or somewhere else?
Robert Leach
@hepcat72

Thanks @mvdbeek. I had considered forking, but I imagine the developer will eventually fix the issue. I guess I was just being impatient. I reverted my tool to just suffer the failure and ping the developer once in awhile.

And thanks for the advice about testing. I will definitely try out one of your suggestions.

Updates are welcome!
Brad Langhorst
@bwlang
@bgruening - dang.. i missed that requirements section - thought i’d find it higher up. I’ll send a PR to your repo when i figure out why it won’t install.
Björn Grüning
@bgruening
probably conda problems?
and update is probably good :)
Nicola Soranzo
@nsoranzo
Suggestions for galaxyproject/tools-iuc#2160 ? If someone merges it, I can push the repositories to TTS and MTS, then the failing pull requests can be rebased.
Marius van den Beek
@mvdbeek
@nsoranzo thanks, I just merged it
Nicola Soranzo
@nsoranzo
Thanks, I've pushed to the TSs the repos for which the automatic deployment on merge failed. I've also restarted the Travis builds for the PRs where needed, we should be back on track now.
Martin Cech
@martenson
@nsoranzo which repos are failing to be updated via travis? Some different from what @abretaud has?
Nicola Soranzo
@nsoranzo
@martenson Different issue, due to the new release of flake8, fixed by