Re: [galaxy-dev] Error in creating admin user during tool shed bootstrap
I successfully did the tool shed bootstrapping with postgresql once. But beyond that, I don't think I can offer much advice. -Will On Thu, Nov 13, 2014 at 7:41 AM, John Chilton jmchil...@gmail.com wrote: Hey Bruno, So Greg has moved on new exciting things and I am not sure if there is anyone who now routinely does the tool shed bootstrapping workflow that can help. I tried the bootstrapping process and it worked fine with an sqlite database - maybe it is not compatible with postgres? Want to try sqlite instead - should be fine for testing? -John On Mon, Nov 10, 2014 at 3:42 PM, Bruno Grande bgra...@sfu.ca wrote: I had the brilliant idea of sending the previous email out on a Friday afternoon/evening. I'm just following up with this thread. Best regards, Bruno -- Bruno Grande, B.Sc. (Hons) M.Sc. Candidate Dr. Ryan Morin's Laboratory Molecular Biology and Biochemistry, Simon Fraser University SSB7133, University Drive, Burnaby, BC, Canada, V5A 1S6 On Fri, Nov 7, 2014 at 2:17 PM, Bruno Grande bgra...@sfu.ca wrote: I'm setting up a local development Tool Shed according to Greg Von Kuster's blog post. During the bootstrapping process, it seems that the creation of the admin user based on the information in user_info.xml fails because of a SQLAlchemy error (see attached stdout.txt). As a result, I believe the API calls for creating categories and users also fail, because they depend on the existence of admin user. This error seems to be due to a missing repository table in the database. I ran the SQL query against the Tool Shed database within PostgreSQL after the failed bootstrapping command and it returned no error, because the repository table actually exists. So, I don't know whether the SQL query is being run against the wrong database (e.g. the Galaxy database) or if the database schema isn't properly set up by the time SQLAlchemy attempts the query. I'm using the latest version of Galaxy (revision 83f821c5ecc1). Best regards, Bruno ___ 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/ -- The information contained in this e-mail message or any attachment(s) may be confidential and/or privileged and is intended for use only by the individual(s) to whom this message is addressed. If you are not the intended recipient, any dissemination, distribution, copying, or use is strictly prohibited. If you receive this e-mail message in error, please e-mail the sender at who...@lygos.com and destroy this message and remove the transmission from all computer directories (including e-mail servers). Please consider the environment before printing this email. ___ 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] Login with a system user
This should be possible with Apache as the proxy and the mod_auth_pam Apache module. From a high level, the configuration should be similar to using mod_authnz_ldap or mod_auth_kerb as documented here: https://wiki.galaxyproject.org/Admin/Config/ExternalUserDatbases -Will On Wed, Oct 1, 2014 at 10:03 AM, John Chilton jmchil...@gmail.com wrote: I don't know how one would do this precisely but I believe it is possible at the proxy level - i.e. setting up Apache to handle this and authenticate with system resources. I believe Tim Booth's work on integrating galaxy into biolinux uses system users for authentication by default. The following thread has more discussion on that: http://lists.bx.psu.edu/pipermail/galaxy-dev/2014-March/018770.html More generic information on configuring an Apache Proxy can be found here: https://wiki.galaxyproject.org/Admin/Config/ApacheProxy Hope this helps. -John On Tue, Sep 30, 2014 at 9:22 AM, Daniel Ruiz Molina daniel.r...@aomail.uab.es wrote: Hello, I have configured Galaxy, but I would be very interested in configure it with PAM or /etc/passwd (/etc/shadow) instead of creating a user in the web interface. How can I configure Galaxy for authenticating with system files? Thanks. ___ 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/ -- The information contained in this e-mail message or any attachment(s) may be confidential and/or privileged and is intended for use only by the individual(s) to whom this message is addressed. If you are not the intended recipient, any dissemination, distribution, copying, or use is strictly prohibited. If you receive this e-mail message in error, please e-mail the sender at who...@lygos.com and destroy this message and remove the transmission from all computer directories (including e-mail servers). Please consider the environment before printing this email. ___ 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] problems installing tool dependency
I also was able to download quicktree.tar.gz by clicking on the URL in your message. However, when I manually ftp into ftp.sanger.ac.uk, there is no /pub4 directory. I'm a bit confused about how those two statements are both true, but maybe it will help someone else figure this out. Removing the '4' does result in a valid path ( ftp://ftp.sanger.ac.uk/pub/resources/software/quicktree/quicktree.tar.gz). -Will On Wed, Sep 24, 2014 at 10:57 AM, Sajdak, Doris dj...@buffalo.edu wrote: Hi all, I am trying to install the Genome Diversity tools from the Miller Lab that are in the Galaxy toolshed. I’ve been able to get all dependencies installed except Quicktree. Whenever I try to install it, I get the error: Error downloading from URL ftp://ftp.sanger.ac.uk/pub4/resources/software/quicktree/quicktree.tar.gz: urlopen error ftp error: 550 pub4: No such file or directory This is the tool_dependencies.xml file for installing quicktree: ?xml version=1.0? tool_dependency package name=quicktree version=1.1 install version=1.0 actions !-- Download source code -- action type=download_by_url target_filename=quicktree_1.1.tar.gz ftp://ftp.sanger.ac.uk/pub4/resources/software/quicktree/quicktree.tar.gz /action !-- Build quicktree -- action type=shell_commandmake quicktree/action !-- Install quicktree -- action type=shell_commandcp -R bin $INSTALL_DIR/action !-- Set environment for dependent repositories -- action type=set_environment environment_variable name=PATH action=prepend_to$INSTALL_DIR/bin/environment_variable /action /actions /install /package /tool_dependency I know this is not their file I’m downloading but the thing is, if I copy and paste the URL, I can download it with no problem. I’m not sure why it’s reporting that it can’t be found but the xml looks right to me. I’ve tried contacting the Miller Lab about this but haven’t heard from anyone so I’m hoping someone here can tell me how to move past this problem. Is there a way to install this tool manually and have the main Genome Diversity tools recognize it on the Galaxy server? Also, I noticed when looking at the Tool Dependency Definitions at https://toolshed.g2.bx.psu.edu/ there are errors going back many versions for this tool (see Test runs – Installation errors – Tool dependencies). Thank you for any help you can provide. Dori ** Dori Sajdak Senior Systems Administrator State University of NY at Buffalo Center for Computational Research 701 Ellicott St Buffalo, NY 14203 Phone: (716) 881-8934 Fax: (716) 849-6656 Web: http://ccr.buffalo.edu ** ___ 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] interpreter option for version_command tag
The documentation for the version_command tag doesn't mention it can take an interpreter option: https://wiki.galaxyproject.org/Admin/Tools/ToolConfigSyntax#A.3Cversion_command.3E_tag_set I looked at the code in lib/galaxy/tools/__init__.py to see how this was implemented. I was surprised to see that if the interpreter option is passed to version_command, then the interpreter value from the command tag is used in generating the version number response. The version_command interpreter value is never used. For example, I tried the following: version_command interpreter=foobarmyPythonTool -v/version_command command interpreter=pythonmyPythonTool someCheetahCode/command And Galaxy successfully got the version number. Is this the expected behavior? -Will ___ 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] Postgresql database time wrong...
Hmm. You are probably very similar to my setup (ubuntu 12.04, Postgres 9.1), and my Postgres install did manage to use the system timezone. I would check two things: 1) /etc/timezone 2) run psql and execute 'show timezone;' If those values look reasonable, then I'm out of suggestions. -Will On Tue, Jun 17, 2014 at 8:12 PM, neil.burd...@csiro.au wrote: Thanks, but looking at /etc/postgresql/9.1/main/postgresql.conf i have the following: #timezone = '(defaults to server environment setting)' #timezone_abbreviations = 'Default' # Select the set of available time zone # abbreviations. Currently, there are # Default # Australia # India # You can create your own file in # share/timezonesets/. So i assume it should get the time from the ubuntu machine it runs on. I have not done any configuration to the postgresql database. Only installing it. Neil -- *From:* Will Holtz [who...@lygos.com] *Sent:* Wednesday, June 18, 2014 10:25 AM *To:* Burdett, Neil (CCI, Herston - RBWH) *Cc:* galaxy-dev@lists.bx.psu.edu *Subject:* Re: [galaxy-dev] Postgresql database time wrong... Postgres generally stores datatime fields in GMT, and then translates them to the local time zone when generating a query. Check the TimeZone variable in your postgres.conf. http://www.postgresql.org/docs/9.3/static/datatype-datetime.html#DATATYPE-TIMEZONES -Will On Tue, Jun 17, 2014 at 4:29 PM, neil.burd...@csiro.au wrote: Hi I have quite a strange issue. I have a local install of Galaxy setup. When I type 'date' on my Ubuntu machine I get something like: Wed Jun 18 09:25:22 EST 2014 When i then execute a job and look in the database at the create_time i.e. # select create_time from job order by create_time; I get 2014-06-17 23:20:00.133828 So about 10 hours different. Is there some configuration I need to set as Brisbane is 10hrs ahead of GMT (coincidence?) Thanks Neil ___ 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] Import of Capsules failing on local toolshed instance
Hi Greg, I used the toolshed bootstrapping script and was able to get capsules from testtoolshed to import. Here are a couple of notes that you may find interesting. 1) In a few places you reference the directory ~/lib/tool_shed/scripts/api/bootstrap_from_toolshed/ and these should be changed to ~/lib/tool_shed/scripts/bootstrap_from_toolshed/ 2) I was worried that 'use_remote_user=True' was going to negatively impact the bootstrap process, as accounts are being created that don't exist in LDAP. However, there didn't appear to be any such negative interaction. In user_info.xml I used my email address that maps to my LDAP login ( who...@lygos.com), a long gibberish password, and wholtz for my username. Thank you for your help Greg. -Will On Tue, Jun 17, 2014 at 7:51 PM, Greg Von Kuster g...@bx.psu.edu wrote: Hello Will, On Jun 17, 2014, at 6:06 PM, Will Holtz who...@lygos.com wrote: It looks like Dave fixed this issue in 4c58aa19a3d7. Thank you! However I am still having import issues. I am now getting the message: Archive of repository package_bowtie_0_12_7 owned by devteam Import failed: repository owner devteam does not have an account in this Tool Shed. This is on a local toolshed running 9b78595ec11 where I am performing the input from an admin account. I'm guessing the issue is that I have 'use_remote_user=True' for LDAP authentication and that means that a devteam account cannot be automatically created to allow this capsule to be added without modification. Sorry you're still running into problems. No regular development or testing is done using the use_remote_user setting due to resource limitations. Perhaps on import of a capsule (by an administrator) they could be given the option of preserving the existing owners or re-assigning ownership to an existing user (defaulting to self)? This would be non-trivial, and probably would introduce fragility into the process. However, I believe there is a solution (see my next comment) although I haven't tested it with the use_remote_user setting. Of course, what I really want is inter-toolshed dependancies. Maybe I'm missing something, but I'm finding it quite painful just to get a tool development environment setup that makes use of any existing repositories. There was some work done in this area in the June 2, 2014 release. Here is some information for more easily setting up a local development Tool Shed that use new features introduced in the release. Hopefully this will help. Greg Von Kuster Bootstrapping a New Development Tool Shed The June 2, 2014 release introduces the ability to easily bootstrap a new development Tool Shed to prepare it for importing a repository capsule whose contained repositories can be used as the foundation for developing new Galaxy tools and other utilities. This development Tool Shed can be treated as a component in a multi-step process that simplifies and streamlines Galaxy tool development and validation in the local Tool Shed and moving the validated repositories into the test or main public Galaxy Tool Sheds. Tool Shed framework enhancements included in the June 2, 2014 release support this overall process, which will be explained fully in a future article. Here we’ll restrict our discussion to highlights of the enhancements. Several files are included in a new directory named *~/lib/tool_shed/scripts/api/bootstrap_from_toolshed*. The file named *user_info.xml.sample* should be copied to a file with the same name, but eliminating the .sample extension (i.e., *user_info.xml*). The information in this file is used to automatically create a new “admin” user account in your local development Tool Shed. This should be the account you use in the test and main public Galaxy Tool Sheds if you plan to export your work from your development Tool Shed and import it into one or both of the public Tool Sheds. If you plan to use this new bootstrapping process, make sure your local development Tool Shed environment is pristine: - The *hgweb.config* file must be empty or missing (it will automatically get created if it doesn’t exist) and the configured location for repositories must be an empty directory. - The configured database must be new and not yet migrated. - Make sure the *~/lib/tool_shed/scripts/api/bootstrap_from_toolshed/user_info.xml *file contains the desired account information. The *~/run_tool_shed.sh* script, used for starting up a Tool Shed, has been enhanced to enable this bootstrapping process by using a new *-bootstrap_from_tool_shed* flag. Here’s an example. %sh run_tool_shed.sh -bootstrap_from_tool_shed http://toolshed.g2.bx.psu.edu The above example will initialize a local development Tool Shed (here we’ll assume its URL is http://localhost:9009) by bootstrapping from the main public Galaxy Tool Shed. The bootstrapping process will perform the following actions in the order listed
Re: [galaxy-dev] Import of Capsules failing on local toolshed instance
It looks like Dave fixed this issue in 4c58aa19a3d7. Thank you! However I am still having import issues. I am now getting the message: Archive of repository package_bowtie_0_12_7 owned by devteam Import failed: repository owner devteam does not have an account in this Tool Shed. This is on a local toolshed running 9b78595ec11 where I am performing the input from an admin account. I'm guessing the issue is that I have 'use_remote_user=True' for LDAP authentication and that means that a devteam account cannot be automatically created to allow this capsule to be added without modification. Perhaps on import of a capsule (by an administrator) they could be given the option of preserving the existing owners or re-assigning ownership to an existing user (defaulting to self)? Of course, what I really want is inter-toolshed dependancies. Maybe I'm missing something, but I'm finding it quite painful just to get a tool development environment setup that makes use of any existing repositories. thank you for your help, -Will On Wed, Jun 11, 2014 at 12:40 PM, Will Holtz who...@lygos.com wrote: I am now able to export capsules from the main/test toolsheds -- thanks Dave! When attempting to import these capsules into my local toolshed (latest_2014.06.02 for changeset fb68af9a775a) I receive the following error: URL: https://galaxy.lygos.com:99/repository/import_capsule File '/home/galaxy/galaxy-dist/lib/galaxy/web/framework/middleware/error.py', line 149 in __call__ app_iter = self.application(environ, sr_checker) File '/home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/debug/prints.py', line 106 in __call__ environ, self.app) File '/home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/wsgilib.py', line 543 in intercept_output app_iter = application(environ, replacement_start_response) File '/home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/recursive.py', line 84 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dist/lib/galaxy/webapps/tool_shed/framework/middleware/remoteuser.py', line 74 in __call__ return self.app( environ, start_response ) File '/home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/httpexceptions.py', line 633 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dist/lib/galaxy/web/framework/base.py', line 132 in __call__ return self.handle_request( environ, start_response ) File '/home/galaxy/galaxy-dist/lib/galaxy/web/framework/base.py', line 190 in handle_request body = method( trans, **kwargs ) File '/home/galaxy/galaxy-dist/lib/galaxy/webapps/tool_shed/controllers/repository.py', line 1992 in import_capsule import_util.check_status_and_reset_downloadable( trans, import_results_tups ) File '/home/galaxy/galaxy-dist/lib/tool_shed/util/import_util.py', line 34 in check_status_and_reset_downloadable tip_changeset_revision = repository.tip( trans.app ) AttributeError: 'NoneType' object has no attribute 'tip' I have seen the same behavior for capsules based on the following repositories from the test toolshed: package_biopython_1_62, package_vienna_rna_2_1, and package_bowtie_0_12_7. I am logged in as an admin user for the import process. thanks, -Will ___ 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] Postgresql database time wrong...
Postgres generally stores datatime fields in GMT, and then translates them to the local time zone when generating a query. Check the TimeZone variable in your postgres.conf. http://www.postgresql.org/docs/9.3/static/datatype-datetime.html#DATATYPE-TIMEZONES -Will On Tue, Jun 17, 2014 at 4:29 PM, neil.burd...@csiro.au wrote: Hi I have quite a strange issue. I have a local install of Galaxy setup. When I type 'date' on my Ubuntu machine I get something like: Wed Jun 18 09:25:22 EST 2014 When i then execute a job and look in the database at the create_time i.e. # select create_time from job order by create_time; I get 2014-06-17 23:20:00.133828 So about 10 hours different. Is there some configuration I need to set as Brisbane is 10hrs ahead of GMT (coincidence?) Thanks Neil ___ 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] Import of Capsules failing on local toolshed instance
I am now able to export capsules from the main/test toolsheds -- thanks Dave! When attempting to import these capsules into my local toolshed (latest_2014.06.02 for changeset fb68af9a775a) I receive the following error: URL: https://galaxy.lygos.com:99/repository/import_capsule File '/home/galaxy/galaxy-dist/lib/galaxy/web/framework/middleware/error.py', line 149 in __call__ app_iter = self.application(environ, sr_checker) File '/home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/debug/prints.py', line 106 in __call__ environ, self.app) File '/home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/wsgilib.py', line 543 in intercept_output app_iter = application(environ, replacement_start_response) File '/home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/recursive.py', line 84 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dist/lib/galaxy/webapps/tool_shed/framework/middleware/remoteuser.py', line 74 in __call__ return self.app( environ, start_response ) File '/home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/httpexceptions.py', line 633 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dist/lib/galaxy/web/framework/base.py', line 132 in __call__ return self.handle_request( environ, start_response ) File '/home/galaxy/galaxy-dist/lib/galaxy/web/framework/base.py', line 190 in handle_request body = method( trans, **kwargs ) File '/home/galaxy/galaxy-dist/lib/galaxy/webapps/tool_shed/controllers/repository.py', line 1992 in import_capsule import_util.check_status_and_reset_downloadable( trans, import_results_tups ) File '/home/galaxy/galaxy-dist/lib/tool_shed/util/import_util.py', line 34 in check_status_and_reset_downloadable tip_changeset_revision = repository.tip( trans.app ) AttributeError: 'NoneType' object has no attribute 'tip' I have seen the same behavior for capsules based on the following repositories from the test toolshed: package_biopython_1_62, package_vienna_rna_2_1, and package_bowtie_0_12_7. I am logged in as an admin user for the import process. thanks, -Will ___ 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] RFC: Citations for tools
As hinted at in the Trello card Greg posted, it could be much simpler if
the citation tag just took a DOI. It appears that the DOI to bibtex
conversion can be done by Crossref:
http://tex.stackexchange.com/questions/6848/automatically-dereference-doi-to-bib
-Will
On Tue, May 27, 2014 at 10:16 AM, Greg Von Kuster g...@bx.psu.edu wrote:
Peter, this may be the Trello card you were thinking of.
https://trello.com/c/kY7RCnd0/95-tool-shed-citation-for-tools-dois
Greg Von Kuster
On May 27, 2014, at 1:09 PM, Peter Cock p.j.a.c...@googlemail.com wrote:
Hi Eric,
I was sure there was a Trello card for this, but I can't find it right
now...
I've pushed this idea on the mailing list before, and in person at
the Galaxy Community Conference too. See also these threads:
http://lists.bx.psu.edu/pipermail/galaxy-dev/2011-December/007873.html
http://lists.bx.psu.edu/pipermail/galaxy-dev/2012-June/010178.html
Are you familiar enough with the area of semantic web/linked
data to know what would be the best XML based markup to
use for embedding the citations?
i.e. We should not reinvent the wheel here ;)
Peter
On Tue, May 27, 2014 at 5:54 PM, James Taylor ja...@jamestaylor.org
wrote:
Eric, I'm very much in favor of this feature, and particularly the
idea of generating a list of citations from a history or workflow. I
imagine the only thing to quibble about will be the syntax. There are
already some efforts to represent bibtex in xml (e.g.
https://github.com/Zearin/BibTeXML), however they have always struck
me as overly verbose.
-- jt
On Tue, May 27, 2014 at 12:45 PM, Eric Rasche rasche.e...@yandex.ru
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'd want to open up discussion on a feature I'd like to see. I'll try
and implement it if I can find time this summer. I didn't see a trello
card for anything like this yet, but please feel free to direct me
there
if I missed it.
I'd like to see citations as a part of every tool.
This would happen in the form of a citation block in the XML, which
would contain sub-elements with text. These sub-elements could be based
off of BibTeX, since they have existing specs for citing things:
https://en.wikipedia.org/wiki/BibTeX
These citations would then be accessible in the HTML generated tool
pages, or via a View/Download button somewhere on the tool page. By
storing as an XML tree, we could render these citations as BibTeX
entries for the LaTeX users, and I believe there are ways to convert
BibTeX to EndNote XML and so on.
This could be extended for use in workflows so that when you run
workflows, somehow a list of citations for all tools used could be
generated.
Anyone have thoughts or opinions on this?
Using the example bibtex entry from the wikipedia page:
@Book{abramowitz+stegun,
author= Milton {Abramowitz} and Irene A. {Stegun},
title = Handbook of Mathematical Functions with
Formulas, Graphs, and Mathematical Tables,
publisher = Dover,
year = 1964,
address = New York,
edition = ninth Dover printing, tenth GPO printing
}
I imagine it'd look like the following in a real-life tool:
tool
...
citation type=book
authorMilton Abramowitz and Irene A. Stegun/author
titleHandbook of Mathematical Functions with Formulas, Graphs, and
Mathematical Tables/title
publisherDover/publisher
year1964/year
addressNew York/address
editionninth Dover printing, tenth GPO printing/edition
/citation
/tool
Cheers,
Eric
- --
Eric Rasche
Programmer II
Center for Phage Technology
Texas AM University
College Station, TX 77843
404-692-2048
e...@tamu.edu
rasche.e...@yandex.ru
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
iQIcBAEBAgAGBQJThMEUAAoJEMqDXdrsMcpVe9AP/1BjPbP5JdK6KDybOeV2ElvC
jvmUGetAjdQzkKO1Ikeuxb46yp0j4abAGGG92AccxlBYALsT3jsPv5dYjm505vcU
IwlfTBE7gc5y19x3zx1CuAd7PB11tryODz2LwXNKI75f39bNdX6Qe5aA74Vn/k8a
FBeFL/EvkZwI8Z6CvuTGtZrEHvDXVvTFoxMX875f59g2vNy7W8Fh5wQCQ8qgiogi
0SWGIGZ6OJdqX60h2hOjJ06NhzBcTsjQea+AwTo5wAkyGPFJy4DV78jKOvsd5PMG
qkk4U6gBcmcFolCeItlLPa/C4uiyOK2wVWHyTnEeKjdpD6dwLuemRmwtZrModbQu
PPPFkKzQhUnh5Wgq8TIP4kSc2t1/jSpdV8MHqM0piqOFnR52fExPrwLn82WEFcp8
tXfHHTaZj+6gL+IGswdAgqvxk1V+6QTjH57igWmYtcENpIDbhZVBh+HOD8SS2qdv
ohwFg/Vn8VrCeTGGehNSBvkam0HXjXXq7mZ8W4xrOS8vxv8HPAFZHze2sPlUG/Ob
WeOdiLgD2HCH95SXYDDBNFG6HwFkLETA3DjpfvgHqPdaLmEfIZW+ks1WF9RG+Pmo
jhbWH8OmtTk5A/Zh63uRowMaDe7QSCruPIfIwlrgqLozOj8htMyJPBIW9oZGGkqC
7Vu5UFeL8gcigRmQv5NA
=ceAo
-END PGP SIGNATURE-
___
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
[galaxy-dev] Problem upgrading bx-python to fix trackster error.
I have a set of galaxy generated bam and bigwig files containing over 600 contigs. When I attempt to view any of these files with trackster (on a local server running current galaxy-dist) I get the following in my log file: galaxy.webapps.galaxy.api.datasets ERROR 2014-04-09 17:41:16,063 Error in dataset API at listing contents: 'BinaryFileReader' object has no attribute 'read_bits64': 'BinaryFileReader' object has no attribute 'read_bits64' Traceback (most recent call last): File /home/galaxy/galaxy-dist/lib/galaxy/webapps/galaxy/api/datasets.py, line 44, in show is_true( kwd.get( 'retry', False ) ) ) File /home/galaxy/galaxy-dist/lib/galaxy/webapps/galaxy/api/datasets.py, line 106, in _converted_datasets_state if not data_provider.has_data( chrom ): File /home/galaxy/galaxy-dist/lib/galaxy/visualization/data_providers/genome.py, line 1078, in has_data all_dat = bbi.query( chrom, 0, 2147483647, 1 ) or \ File bbi_file.pyx, line 215, in bx.bbi.bbi_file.BBIFile.query (lib/bx/bbi/bbi_file.c:5596) File bbi_file.pyx, line 222, in bx.bbi.bbi_file.BBIFile.query (lib/bx/bbi/bbi_file.c:5210) File bbi_file.pyx, line 183, in bx.bbi.bbi_file.BBIFile.summarize (lib/bx/bbi/bbi_file.c:4475) File bbi_file.pyx, line 248, in bx.bbi.bbi_file.BBIFile._get_chrom_id_and_size (lib/bx/bbi/bbi_file.c:5656) File bpt_file.pyx, line 76, in bx.bbi.bpt_file.BPTFile.find (lib/bx/bbi/bpt_file.c:1388) File bpt_file.pyx, line 55, in bx.bbi.bpt_file.BPTFile.r_find (lib/bx/bbi/bpt_file.c:1154) AttributeError: 'BinaryFileReader' object has no attribute 'read_bits64' Two people have previously reported similar errors to this list. I don't know how to reply to messages that predate me joining the list, so here are links to the threads: http://dev.list.galaxyproject.org/read-bits64-error-when-loading-large-genomes-data-into-trackster-tp4663622.html http://dev.list.galaxyproject.org/trackster-error-for-viewing-rat-data-rn5-tp4662664.html Following the suggestion of Jeremy Goecks in one of those old threads, I checked my bx-python version. The directory name bx-python is installed in indicates that I have version 0.7.1. Version 0.7.1 is from 2011 and pre-dates the the bug Jeremy mentioned (https://bitbucket.org/james_taylor/bx-python/commits/24893a84ce13a18815e3006c9f89b3828022ac96). Additionally, I ran: strings ./galaxy-dist/eggs/bx_python-0.7.1_7b95ff194725-py2.7-linux-x86_64-ucs4.egg/bx/bbi/bpt_file.so | grep read_bits64 and found a match, thus confirming the installed version pre-dates the bug fix, as all references to read_bits64 were removed in that commit. Additionally I cloned and compiled the current version of bx-python and found that the above command did not find any matches. The offending installation of bx-python is part of the base installation of galaxy and not an item I added from the toolshed. I am unsure of how to go about replacing this egg with the newer version of bx-python. If someone can update the bx-python egg on http://eggs.g2.bx.psu.edu/ or give me instructions on how to replace my copy of the egg, I would greatly appreciate it! Additionally, I found that all three of the versions of bx-python in the galaxy-main toolshed still contain this bug. Of the three versions of bx-python int the galaxy-test toolshed, only 3:5457e32b427c (2013-12-14) contains the bug fix. Thank you in advance for your assistance! -Will ___ 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] maximum recursion depth error
Hi, I used the SAM to FASTQ tool to divide78 lines of Illimina paired end sequences in SAM format to FASTQ format. The read 2 data set works fine, and I used the FASTQ masker and then FASTQ to FASTA tools. I went to repeat those steps with the the read 1 data set. It errors with: Error executing tool: maximum recursion depth exceeded while calling a Python object. Thinking maybe the format was corrupted, I ran FASTQ groomer. Same result: Error executing tool: maximum recursion depth exceeded while calling a Python object. Thinking the SAM to FASTQ had a problem, I repeated it. Same result: Error executing tool: maximum recursion depth exceeded while calling a Python object. You get thepicture. Anything I try with this data gives the same error. When I googled the error, the top results were all about large data sets, but this isn't a large set. Any help greatly appreciated, Ann Thanks for your help. CONFIDENTIALITY NOTICE: This electronic message is intended to be for the use only of the named recipient, and may contain information that is confidential or privileged. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this message is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately by contacting the sender at the electronic mail address noted above, and delete and destroy all copies of this message. Thank you. ___ 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/
