Re: [galaxy-dev] ncbi_blast_plus - tool shed updates
Hi Shantanu, updates are a little bit special. They refer to a changeset of the tool that is not invasive. For example if the tool number did not change. If the change in will affect reproducibility it will get a new installable revision number. That new revision is only installable with a new installation. Go to the toolshed select ncbi_blast_plus (new revision) hit install. Done. Here is the wiki page with more information: http://wiki.galaxyproject.org/RepositoryRevisions Hope that helps, Bjoern I am trying to get repository updates for the ncbi_blast_plus tool which is making following request to the toolshed site: http://toolshed.g2.bx.psu.edu/repository/check_for_updates?galaxy_url=http://galaxydev.uabgrid.uab.edu/name=ncbi_blast_plusowner=devteamchangeset_revision=d375502056f1 This request is coming back with following response with latest_changeset_revision same as changeset_revision. http://localhost:5000/admin_toolshed/update_to_changeset_revision?tool_shed_url=http://toolshed.g2.bx.psu.edu/name=ncbi_blast_plusowner=devteamchangeset_revision=d375502056f1latest_changeset_revision=d375502056f1latest_ctx_rev=0 This results in following message in the browser: The installed repository named 'ncbi_blast_plus' is current, there are no updates available.. The latest ncbi_blast_plus changeset revision in the toolshed is 9dabbfd73c8a, so I am not sure why above update request is coming back with d375502056f1 revision. Any clues on what might be wrong here? Appreciate any further debugging steps. -- Thanks, Shantanu ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] New misc tool shed wish list
Hi Greg, I tried to extend my old list [1] but I'm not allowed to edit it. Maybe you can add the following items to it. This time I collected a few items that are relevant for the Galaxy site of the Tool Shed ( When the user is installing via webinterface ) - offer an upgrade option, I think normally you are interested in new versions. At least an information about a new version should be displayed during the update. Or next to the revision number (e.g two new versions available) - distinguish more between update and upgrade - group different revisions of the same repository together - indicate if a revision is the latest revision available - a own category for workflows? Or the ability to tag a repository as workflow? - group the installed tools in categories Overall it looks really nice currently and I'm somehow enjoying installing and testing tools :) Thanks, Bjoern [1] https://trello.com/c/CIdMDeCd/988-toolshed-miscellaneous-issues-reported-by-bjorn-on-7-15-13 ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Manhattan/qq plots
Hi Bjoern and Ross, thanks for your replies, we'll try to downgrade the gplot version, but we have to wait until our server admin is back from his vacation. This should be at the beginning of the next week. Best wishes, Thomas Von: Ross [mailto:ross.laza...@gmail.com] Gesendet: Dienstag, 27. August 2013 00:41 An: Bjoern Gruening Cc: Berner, Thomas; galaxy-dev@lists.bx.psu.edu Betreff: Re: [galaxy-dev] Manhattan/qq plots Hi, Thomas. There are no resources available to support that now 3 year old rgenetics code so I'm sad but not surprised to hear of this new problem. The grant ended long ago and I no longer work with SNP so have no excuse to keep fixing or working on it. Is someone using this code willing to take it over, fix these kinds of bugs and add automated installation to bring it up to speed ? I'll help all I can but without a volunteer, the code should be considered deprecated and will soon disappear from the distribution. On Tue, Aug 27, 2013 at 2:14 AM, Bjoern Gruening bjoern.gruen...@gmail.commailto:bjoern.gruen...@gmail.com wrote: Hi Thomas, I think you are running a to new version of gplot http://blog.rstudio.org/2012/09/07/ggplot2-0-9-2/ opts is now deprecated and likely causes that error. Can you downgrade the gplot version? We are working on a R dependencies mechanism but we are not done yet, sorry. Hope that helps, Bjoern Hey guys, we are running a local galaxy instance (10200:fd4113962c32)with R version 3.0.1 and want to use Manhattan/qq, but we are missing the pval manhatan.pdf, only pval qqplot.pdf is generated and we are getting the following error: Nonzero exit code = 1 [1] ### 11008 values read from /opt/galaxy/galaxy-dist/database/files/002/dataset_2408.dat read - now running plots 'opts' is deprecated. Use 'theme' instead. (Deprecated; last used in version 0.9.1) Setting the plot title with opts(title=...) is deprecated. Use labs(title=...) or ggtitle(...) instead. (Deprecated; last used in version 0.9.1) Scale for 'x' is already present. Adding another scale for 'x', which will replace the existing scale. Scale for 'y' is already present. Adding another scale for 'y', which will replace the existing scale. [1] ## qqplot on pval done [1] ## manhattan on pval starting 1 2 3 Error in structure(list(call = match.call(), aesthetics = aesthetics, : argument values is missing, with no default Calls: rgqqMan ... scale_colour_manual - manual_scale - discrete_scale - structure Execution halted At the galaxy-main ist working without any problems using the same input file. All the necessary packages should be installed. Any ideas? Thanks for your help. Thomas ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ -- Ross Lazarus MBBS MPH; Head, Medical Bioinformatics, BakerIDI; Tel: +61 385321444 http://scholar.google.com/citations?hl=enuser=UCUuEM4J ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Tool Shed packages for BLAST+ binaries
Peter, I also tried running the command that returns error code 64 on the same system that runs the automated tests, and it downloaded the correct file for that operating system and architecture. So I'm not sure why it's failing when run through buildbot, but I'll look into it and get back to you. I've added a trello card to track progress on this issue: https://trello.com/c/9ERDMc7j/1079-toolshed-investigate-cause-of-shell-commands-failing-through-buildbot-when-they-are-valid-commands --Dave B. On 08/26/2013 10:32 AM, Peter Cock wrote: On Mon, Aug 26, 2013 at 3:10 PM, Dave Bouvier d...@bx.psu.edu wrote: Peter, I apologize for the delay, here is the information you requested: ubuntu@ip-10-0-0-243:~$ uname -a Linux ip-10-0-0-243 3.8.0-25-generic #37-Ubuntu SMP Thu Jun 6 20:47:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ubuntu@ip-10-0-0-243:~$ arch x86_64 ubuntu@ip-10-0-0-243:~$ echo $0 -bash --Dave B. Thanks Dave, Sadly that looks just like my server where it works, $ uname Linux $ arch x86_64 $ echo $0 -bash I was considering trying to have the tool_dependencies.xml install recipe call a shell or Python script instead - but the new Tool Shed Tool dependency definition repository type prevents that (unless using a workaround like downloading the script first). Hmm. Does anyone have any ideas on this error return code 64? Regards, 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] New misc tool shed wish list
Hello Bjoern, I've updated the Trello card with your requests - thanks! Greg Von Kuster On Aug 27, 2013, at 3:37 AM, Bjoern Gruening bjoern.gruen...@gmail.com wrote: Hi Greg, I tried to extend my old list [1] but I'm not allowed to edit it. Maybe you can add the following items to it. This time I collected a few items that are relevant for the Galaxy site of the Tool Shed ( When the user is installing via webinterface ) - offer an upgrade option, I think normally you are interested in new versions. At least an information about a new version should be displayed during the update. Or next to the revision number (e.g two new versions available) - distinguish more between update and upgrade - group different revisions of the same repository together - indicate if a revision is the latest revision available - a own category for workflows? Or the ability to tag a repository as workflow? - group the installed tools in categories Overall it looks really nice currently and I'm somehow enjoying installing and testing tools :) Thanks, Bjoern [1] https://trello.com/c/CIdMDeCd/988-toolshed-miscellaneous-issues-reported-by-bjorn-on-7-15-13 ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] tool not runing in workflow
Thomas, Did you generate the work flow from scratch or did you make a simple analysis in the history and extracted a work flow from that? The latter we usually do without problems whatever...but we don't use the mothur tools though... Alex Van: galaxy-dev-boun...@lists.bx.psu.edu [mailto:galaxy-dev-boun...@lists.bx.psu.edu] Namens Berner, Thomas Verzonden: maandag 26 augustus 2013 13:45 Aan: galaxy-dev@lists.bx.psu.edu Onderwerp: [galaxy-dev] tool not runing in workflow Hey guys, we installed and used a tool of the mothur_toolsuite in our local galaxy instance named get.otulist, but if we want to integrate it into a workflow (extract from history) we get the following error for the next step: Error due to input mapping of 'Join two datasets' in '__new_primary_file_logfile|0.03.otu__'. A common cause of this is conditional outputs that cannot be determined until runtime, please review your workflow. In the workflow editor only the *.html file is displayed as output but not the tabular file which is generated by the tool normally. There should be an output (tabular) which we want to join with another one, but this doesn't work in the workflow. Can somebody give me a hint for this? Greetings, Thomas ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] Updating Galaxy Instance
I can't seem to find any information on the Galaxy wiki website about the procedure for updating a local Galaxy instance to the newest release. Is there a tutorial for this somewhere? Thank you, Richard ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Updating Galaxy Instance
Please follow the session Keep your code up to date at http://wiki.galaxyproject.org/Admin/Get%20Galaxy --/Vipin On Tue, Aug 27, 2013 at 10:58 AM, Richard Kuo izen...@gmail.com wrote: I can't seem to find any information on the Galaxy wiki website about the procedure for updating a local Galaxy instance to the newest release. Is there a tutorial for this somewhere? Thank you, Richard ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Updating Galaxy Instance
Thank you Vipin. Is there an easy way to see if changes have been made to the database structure between the release you currently have and the newest release? Presumably you would either have to read the news brief for each release between yours and the current one or just pull the change and see if an error occurs. Is there another way to check? Cheers, Richard On Tue, Aug 27, 2013 at 4:09 PM, Vipin TS vipin...@gmail.com wrote: Please follow the session Keep your code up to date at http://wiki.galaxyproject.org/Admin/Get%20Galaxy --/Vipin On Tue, Aug 27, 2013 at 10:58 AM, Richard Kuo izen...@gmail.com wrote: I can't seem to find any information on the Galaxy wiki website about the procedure for updating a local Galaxy instance to the newest release. Is there a tutorial for this somewhere? Thank you, Richard ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Select multiple and conditional
As you discovered, this isn't possible yet. You'll need to break up your
parameters into multiple conditions, so Yes/No for Blast and Yes/No for Fasta.
Best,
J.
On Aug 26, 2013, at 6:33 AM, Kahlke Tim wrote:
Hei,
Is it possible to use a select multiple=True for a conditional? I'm
trying to use it for checkboxes which by default have to have multiple set.
But as soon as I put the multiple-tag in I get an 'no case matched' exception
(see example below).
Any suggestions?
Tim
Example (working)
conditional name=c1
param type=select name=dbt label=Db tools
option value=blastBlast/option
option value=fastaFasta/option
/param
when value=blast
...
/when
/conditional
Example (exception)
conditional name=c1
param type=select name=dbt label=Db tools multiple=True
option value=blastBlast/option
option value=fastaFasta/option
/param
when value=blast
...
/when
/conditional
= Exception: ('No class matched value:' , 'c1' , None)
___
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/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
___
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/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] RuntimeError: maximum recursion depth exceeded while calling a Python object
There are sporadic reports of this issue, but I haven't been able to reproduce it. My best guess is that it's due to trying to use the custom build before Galaxy has finished creating it. To ensure that the custom build is ready for use, make sure to wait for Galaxy to show the number of chromosomes rather than '?' on the custom builds page. It also sometimes happens when I create and share a Trackster visualization. I can access the visualization without problem whereas the users I shared it with can't access it because of the mentioned error or they get a message like Can't load dbkey. Can't load dbkey is a different issue than the server error. If you can provide datasets and/or steps to reproduce either issue, I'm confident that they could be fixed. Thanks, J. ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] tool_dependencies.xml format
On Aug 26, 2013, at 11:59 AM, James Taylor wrote: On Mon, Aug 26, 2013 at 11:48 AM, John Chilton chil...@msi.umn.edu wrote: I think it is interesting that there was push back on providing infrastructure (tool actions) for obtaining CBL from github and performing installs based on it because it was not in the tool shed and therefore less reproducible, but the team believes infrastructure should be put in place to support pypi. Well, first, I'm not sure what the team believes, I'm stating what I believe and engaging in a discussion with the community. At some point this should evolve into what we are actually going to do and be codified in a spec as a Trello card, which is even then not set in stone. Second, I'm not suggesting we depend on PyPI. The nice thing about the second format I proposed on galaxy-dev is that we can easily parse out the URL and archive that file. Then someday we could provide a fallback repository where if the PyPI URL no longer works we still have it stored. I concur here, the experience and lessons learned by long-established package and dependency managers can provide some useful guidance for us going forward. APT has long relied on a model of archiving upstream source (as well as distro-generated binary (dpkg) packages), cataloging changes as a set of patches, and maintaining an understanding of installed files, even those meant to be user-edited. I think there is a strong advantage for us doing this as well. I think we all value reproduciblity here, but we make different calculations on what is reproducible. I think in terms of implementing the ideas James has laid out or similar things I have proposed, it might be beneficial to have some final answers on what external resources are allowed - both for obtaining a Galaxy IUC gold star and for the tool shed providing infrastructure to support their usage. My focus is ensuring that we can archive things that pass through the toolshed. Tarballs from *anywhere* are easy enough to deal with. External version control repositories are a bit more challenging, especially when you are pulling just a particular file out, so that's where things got a little hinky for me. Since we don't have the archival mechanism in place yet anyway, this is more a philosophical discussion and setting the right precedent. And yes, keeping an archive of all the software in the world is a scary prospect, though compared to the amount of data we currently keep for people it is a blip. And I'm not sure how else we can really achieve the level of reproducibility we desire. One additional step that will assist with long-term archival is generating static metadata and allowing the packaging and dependency systems to work outside of the Galaxy and Tool Shed applications. A package metadata catalog and package format that provided descriptions of packages on a generic webserver and installable without a running Galaxy instance are components that I believe are fairly important. As for user-edited files, the env.sh files, which are generated at install-time and then essentially untracked afterward scare me a bit. I think it'd be useful for the packaging system have a tighter concept of environment management. These are just my opinions, of course, and are going to be very APT/dpkg-biased simply due to my experience with and favor for Debian-based distros and dependency/package management, but I think there are useful concepts in this (and other systems) that we can draw from. Along those lines, one more idea I had thrown out a while ago was coming up with a way to incorporate (or at least automatically process so that we can convert to our format) the build definitions for other systems like MacPorts, BSD ports/pkgsrc, dpkg, rpm, etc. so that we can leverage the existing rules for building across our target platforms that have already been worked out by other package maintainers with more time. I think this aligns pretty well with Brad's thinking with CloudBioLinux, the difference in implementation being that we require multiple installable versions and platform independence. I am a bit worried that as we go down the repackage (almost) all dependencies path (which I do think is the right path), we also run the risk of most of our packages being out of date. That's almost a guaranteed outcome when even the huge packaging projects (Debian, Ubuntu, etc.) are rife with out-of-date packages. So being able to incorporate upstream build definitions may help us package dependencies quickly. --nate ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] RuntimeError: maximum recursion depth exceeded while calling a Python object
On 22.08.2013, at 19:50, Jeremy Goecks wrote: Internal Server Error Galaxy was unable to sucessfully complete your request URL: http://127.0.0.1:8081/user/dbkeys Module galaxy.web.framework.middleware.error:149 in __call__ app_iter = self.application(environ, sr_checker) Module paste.recursive:84 in __call__ return self.application(environ, start_response) Module paste.httpexceptions:633 in __call__ return self.application(environ, start_response) Module galaxy.web.framework.base:132 in __call__ return self.handle_request( environ, start_response ) Module galaxy.web.framework.base:190 in handle_request body = method( trans, **kwargs ) Module galaxy.web.framework:98 in decorator return func( self, trans, *args, **kwargs ) Do you have an idea what causes this error? There are sporadic reports of this issue, but I haven't been able to reproduce it. My best guess is that it's due to trying to use the custom build before Galaxy has finished creating it. To ensure that the custom build is ready for use, make sure to wait for Galaxy to show the number of chromosomes rather than '?' on the custom builds page. It also sometimes happens when I create and share a Trackster visualization. I can access the visualization without problem whereas the users I shared it with can't access it because of the mentioned error or they get a message like Can't load dbkey. Is there a way to purge the dbkeys database? Does deleting the custom build work? If not, you can remove a user's custom dbkeys from the database using this SQL command: Unfortunately Galaxy won't let go to the custom builds page and will show error message instead. delete from user_preference where user_id=(select id from galaxy_user where email='user_email') and name='dbkeys'; Thanks, I will try that. Best, J. ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] [galaxy-user] Connecting to new Galaxy Cloudman by FTP
FTP issues are fixed now so things will be functional out of the box without any of these workarounds. On Tue, Jul 16, 2013 at 4:04 PM, Daniel Blankenberg d...@bx.psu.edu wrote: Hey Mo, You can use ssh to connect to the Galaxy machine. If you used cloudlaunch to create your instance, it should display an example connection string that will work from e.g. a linux/mac shell, something like: 'ssh -i cloudman_keypair.pem ubuntu@IP', after your instance launched. Once inside of the machine, you can do something like: 'sudo -iu galaxy', to switch to the galaxy user and then have a look at the mount points under /mnt/. The cloudman_keypair.pem file is the key file that you (should have) downloaded the first time that you launched a cloudman instance, or when you manually generated a keypair. You can create additional keypairs in your aws console if you need to download a new one to use (you can probably delete the existing cloudman_keypair and have it regenerated automatically by cloudman, but I haven't tested this and I wouldn't recommend doing this if an instance is running). You'll need to use the correct .pem file for the keypair that you specified during launch of the instance. See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/generating-a-keypair.htmlfor Amazon's info on creating keypairs (especially if you are using e.g. Windows and putty: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html). Once you make the changes to the files locally, you can use the Cloudman Admin web UI to restart the Galaxy instance. Let us know if you encounter any issues. Thanks for using Galaxy, Dan On Jul 15, 2013, at 7:22 PM, Mohammad Heydarian wrote: Hey Nate, Thanks for the response and instructions. I understand the last three steps of your protocol, but the first step is difficult for me to understand. I'm guessing that, 1. Set 'use_pbkdf2 = False' in universe_wsgi.ini anywhere in the [app:main] section, is telling me to change a setting of Cloudman by command line. This is generally where we get stuck in using Cloudman, because we aren't familiar with command line (we get cold sweats and light palpitations) and are weary of making changes to the Cloudman code. I would ask our IT guys for help, but their expertise ends at updating Office tools. I would bother a programmer or bioinformatician, but most of them are so busy you need a formal collaboration to get on their radar. I would ask people who vaguely know command line for help, but most of the time their knowledge of command line is just higher than mine and we end up troubleshooting an issue neither of us can really grasp. So, is there a webcast, or video, or slideshow, that can show a newbie how to command line into Cloudman and make the changes you outline in step 1? Cheers, Mo Heydarian On Mon, Jul 15, 2013 at 4:22 PM, Nate Coraor n...@bx.psu.edu wrote: On Jul 8, 2013, at 3:50 PM, Mohammad Heydarian wrote: Hi, I am having trouble setting up a FTP connection with the recently released version of Galaxy Cloudman (ami-118bfc78). I have instantiated the new version of Galaxy Cloudman with CloudLaunch and also through the AWS EC2 wizard (using the same security group settings as the previous versions) and neither instance will connect to my FTP connection. Has anyone else had this problem? Does anyone know what is preventing the FTP connection? Any help would be greatly appreciated. Hey Mo, This may be a case of the new password hashing algorithm's incompatibility with the provided ProFTPD config. Could you try the following: 1. Set 'use_pbkdf2 = False' in universe_wsgi.ini anywhere in the [app:main] section 2. Restart Galaxy 3. Reset your password in the Galaxy UI 4. Test FTP again --nate Cheers, Mo Heydarian ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using reply all in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list: http://lists.bx.psu.edu/listinfo/galaxy-dev To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ The Galaxy User list should be
Re: [galaxy-dev] Galaxy CloudMan release - Tophat does not work
Not quite next week, but an update to the tools volume and CloudMan itself was just released so things should be working now. Sorry for the trouble and the delay and let us know if how things are going for you now. Cheers, Enis On Sat, Jul 13, 2013 at 9:27 AM, Enis Afgan afg...@gmail.com wrote: Next week, we'll update the underlying snapshot to correct those symlinks and get Tophat working. Sorry for the trouble. On Fri, Jul 12, 2013 at 9:23 PM, Ravpreet Setia ravpreet.se...@oicr.on.ca wrote: I see you are experiencing the same problem as I am. The reason these programs cannot be found is because the default symlink is broken. The following page describes how the symlink is used by Galaxy: http://wiki.galaxyproject.org/Admin/Config/Tool%20Dependencies Suppose you wish to fix Tophat, then you will need to go to /mnt/galaxy/tools/tophat. Type 'ls –l' and you will notice that the 'default' symlink points to a directory in /mnt/galaxyTools. Recall that this update merged galaxyTools and galaxyData into a single volume – but the symlink was not modified to account for this. Therefore, the symlink should instead point to /mnt/galaxy/tools/tophat/VERSION. Then, go into the directory of the version you specified and modify the env.sh file so it also has the proper path. Let me know if Tophat works for you, even after doing this it fails to run properly for me. However, at least now Galaxy can find the programs. From: Mohammad Heydarian mheyd...@jhmi.edu Date: Fri, 12 Jul 2013 14:21:23 -0400 To: Microsoft Office User ravpreet.se...@oicr.on.ca Cc: Enis Afgan afg...@gmail.com, Galaxy-dev galaxy-...@bx.psu.edu Subject: Re: [galaxy-dev] Galaxy CloudMan release - Tophat does not work Cufflinks, Cuffcompare, and Cuffdiff are also failing to run because they can not be found. I am using the newly released version of Cloudman 2.0 (ami-118bfc78). Any help would be appreciated. Cheers, Mo Heydarian On Mon, Jul 8, 2013 at 5:02 PM, Ravpreet Setia ravpreet.se...@oicr.on.ca wrote: Some tools (tophat is one) are failing to run because they cannot be found. I have noticed that after launching a new instance with the latest AMI, the package/version/default sym-links under /mnt/galaxy/tools point to a directory in /mnt/galaxyTools, which does not exist since this new AMI merged galaxyTools and galaxyData. Additionally, even after manually fixing the symlink and the path in the env.sh file (it also references galaxyTools), running tophat would fail, although now, at least, it can find the program. This document explains how the default symlink is used by Galaxy: http://wiki.galaxyproject.org/Admin/Config/Tool%20Dependencies Thanks for any suggestions. From: Enis Afgan afg...@gmail.com Date: Sun, 30 Jun 2013 07:37:46 +0200 To: Galaxy-dev galaxy-...@bx.psu.edu Subject: [galaxy-dev] Galaxy CloudMan release *Last night, we released an update to Galaxy CloudMan.* CloudMan offers an easy way to get a personal and completely functional instance of Galaxy in the cloud in just a few minutes, without any manual configuration. *IMPORTANT - please read* Any new cluster will automatically start using this version of CloudMan. Existing clusters will be given an option to do an automatic update once the main interface page is refreshed. Note that this upgrade is a major version upgrade and thus the migration is rather complicated. The migration process has been automated but will take a little while to complete. If you have made customizations to your cluster in terms of adding file systems, upgrading the database, or similar, we do not recommend you perform the upgrade. Note that this upgrade comes with (and requires) a new AMI (ami-118bfc78), which will be automatically used if starting an instance via CloudLaunch http://usegalaxy.org/cloudlaunch. *This update brings a large number of updates and new features, the most prominent ones being:* - Unification of *galaxyTools* and *galaxyData* file systems into a single *galaxy* filesystem. This change makes it possible to utilize the Galaxy Tool Shed when installing tools into Galaxy. - Added initial support for Hadoop-type workloads - Added initial support for cluster federation via HTCondor - Added a new file system service for instance's transient storage, allowing it to be used across the cluster over NFS - Added a service for Galaxy Reports webapp - Added optional Loggly (loggly.com) based off-site logging support - Added tags to all resources utilized by CloudMan For more details on the new features, see the the CHANGELOGhttps://bitbucket.org/galaxy/cloudman/src/tip/CHANGELOG.md?at=defaultand for even more details see, all of 291 commit messageshttps://bitbucket.org/galaxy/cloudman/commits/all?search=35baec1%3A8bbae3f from 7 contributors. Enjoy and please let us know what you think, Enis P.S. We also now have a logo for CloudMan [image: Inline image
Re: [galaxy-dev] Cloudman database issue (?)
Hi Mo, Just like in the email I just sent, the new release should fix this. Let us know if you have any more issues. On Tue, Jul 16, 2013 at 6:29 PM, Dannon Baker dannon.ba...@gmail.comwrote: Hey Mo, The new volume we pushed out for the conference has several known issues. Enis and I are both away from the office on travel right now, but updating the volume and fixing these issues is the first thing I'll be doing when I'm back next week. For now, you can launch using the pre-conference AMI and cloudman bucket using something like https://main.g2.bx.psu.edu/cloudlaunch?ami=ami-da58aab3bucket_default=gxy-workshop -Dannon On Tue, Jul 16, 2013 at 12:24 PM, Mohammad Heydarian mheyd...@jhmi.eduwrote: Hello, I found a couple of issues in using the latest version of Cloudman (revision:10201:ebe87051fadf). The Extract Genomic DNA tool returns an error: No sequences are available for 'mm9', request them by reporting this error. Upon trying to report the error in Galaxy (on the page that comes up when you click the bug icon) I get the error: Mail is not configured for this galaxy instance Any help on fixing the Extract Genomic DNA tool would be great. Thanks. Cheers, Mo Heydarian ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] tool_dependencies.xml format
Before I went on that tangent, I should have said I of course agree with 100% of what James said in the original e-mail on this thread. For what it is worth, I believe the higher-level constructs he outlined are essential to the long term adoption of the tool shed. On Tue, Aug 27, 2013 at 1:59 PM, Nate Coraor n...@bx.psu.edu wrote: On Aug 26, 2013, at 11:59 AM, James Taylor wrote: On Mon, Aug 26, 2013 at 11:48 AM, John Chilton chil...@msi.umn.edu wrote: I think it is interesting that there was push back on providing infrastructure (tool actions) for obtaining CBL from github and performing installs based on it because it was not in the tool shed and therefore less reproducible, but the team believes infrastructure should be put in place to support pypi. Well, first, I'm not sure what the team believes, I'm stating what I believe and engaging in a discussion with the community. At some point this should evolve into what we are actually going to do and be codified in a spec as a Trello card, which is even then not set in stone. Second, I'm not suggesting we depend on PyPI. The nice thing about the second format I proposed on galaxy-dev is that we can easily parse out the URL and archive that file. Then someday we could provide a fallback repository where if the PyPI URL no longer works we still have it stored. I concur here, the experience and lessons learned by long-established package and dependency managers can provide some useful guidance for us going forward. APT has long relied on a model of archiving upstream source (as well as distro-generated binary (dpkg) packages), cataloging changes as a set of patches, and maintaining an understanding of installed files, even those meant to be user-edited. I think there is a strong advantage for us doing this as well. I think we all value reproduciblity here, but we make different calculations on what is reproducible. I think in terms of implementing the ideas James has laid out or similar things I have proposed, it might be beneficial to have some final answers on what external resources are allowed - both for obtaining a Galaxy IUC gold star and for the tool shed providing infrastructure to support their usage. My focus is ensuring that we can archive things that pass through the toolshed. Tarballs from *anywhere* are easy enough to deal with. External version control repositories are a bit more challenging, especially when you are pulling just a particular file out, so that's where things got a little hinky for me. Since we don't have the archival mechanism in place yet anyway, this is more a philosophical discussion and setting the right precedent. And yes, keeping an archive of all the software in the world is a scary prospect, though compared to the amount of data we currently keep for people it is a blip. And I'm not sure how else we can really achieve the level of reproducibility we desire. One additional step that will assist with long-term archival is generating static metadata and allowing the packaging and dependency systems to work outside of the Galaxy and Tool Shed applications. A package metadata catalog and package format that provided descriptions of packages on a generic webserver and installable without a running Galaxy instance are components that I believe are fairly important. As for user-edited files, the env.sh files, which are generated at install-time and then essentially untracked afterward scare me a bit. I think it'd be useful for the packaging system have a tighter concept of environment management. These are just my opinions, of course, and are going to be very APT/dpkg-biased simply due to my experience with and favor for Debian-based distros and dependency/package management, but I think there are useful concepts in this (and other systems) that we can draw from. Along those lines, one more idea I had thrown out a while ago was coming up with a way to incorporate (or at least automatically process so that we can convert to our format) the build definitions for other systems like MacPorts, BSD ports/pkgsrc, dpkg, rpm, etc. so that we can leverage the existing rules for building across our target platforms that have already been worked out by other package maintainers with more time. I think this aligns pretty well with Brad's thinking with CloudBioLinux, the difference in implementation being that we require multiple installable versions and platform independence. The CloudBioLinux galaxy tool stuff used by Galaxy-P, CloudMan, and in integrated into tool shed installs with pull request 207 is platform independent (or as platform independent as the tool shed) and allows multiple installable versions. I am a bit worried that as we go down the repackage (almost) all dependencies path (which I do think is the right path), we also run the risk of most of our packages being out of date. That's almost a guaranteed
Re: [galaxy-dev] tool not runing in workflow
Hi Alex, we extracted it from the history. Normally we have no problems with it, but this tool is something special. It generates multiple output files depending on the input. Greetings, Thomas Von: Bossers, Alex [alex.boss...@wur.nl] Gesendet: Dienstag, 27. August 2013 16:12 An: Berner, Thomas Cc: galaxy-dev@lists.bx.psu.edu Betreff: RE: tool not runing in workflow Thomas, Did you generate the work flow from scratch or did you make a simple analysis in the history and extracted a work flow from that? The latter we usually do without problems whatever...but we don’t use the mothur tools though... Alex Van: galaxy-dev-boun...@lists.bx.psu.edu [mailto:galaxy-dev-boun...@lists.bx.psu.edu] Namens Berner, Thomas Verzonden: maandag 26 augustus 2013 13:45 Aan: galaxy-dev@lists.bx.psu.edu Onderwerp: [galaxy-dev] tool not runing in workflow Hey guys, we installed and used a tool of the mothur_toolsuite in our local galaxy instance named “get.otulist”, but if we want to integrate it into a workflow (extract from history) we get the following error for the next step: “Error due to input mapping of ‘Join two datasets’ in ‘__new_primary_file_logfile|0.03.otu__’. A common cause of this is conditional outputs that cannot be determined until runtime, please review your workflow.” In the workflow editor only the *.html file is displayed as output but not the tabular file which is generated by the tool normally. There should be an output (tabular) which we want to join with another one, but this doesn’t work in the workflow. Can somebody give me a hint for this? Greetings, Thomas ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] Mercurial updates not working
Hello all, Mercurial has recently started throwing errors: galaxy@hitmsbhpc1:~/galaxy-dist hg incoming abort: error: _ssl.c:517: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol It has previously worked with issues has anyone seen this before? I don't think anything has changed that would have caused this problem but googling error has proved to be unhelpful so far. Regards, Alistair ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
