Re: [galaxy-dev] TestToolShed failure, Exception: History in error state.
Hi Dave, You are right that on closer inspection I've mixed tool_dependencies.xml and repository_dependencies.xml *again*. Evidentially my mental model does not match Greg's here: (*) I need to define a tool installation recipe for something not in the Tool Shed -- write an install script called tool_dependencies.xml (*) I need to depend on a Python package by pointing at another repository in the Tool Shed -- repository_dependencies.xml (*) I need to depend on a datatype package by pointing at another repository in the Tool Shed -- repository_dependencies.xml (*) I need to depend on a binary package by pointing at another repository in the Tool Shed -- repository_dependencies.xml ? No. You need tool_dependencies.xml for this too. But that aside, the test framework error here is completely unhelpful. Why is there no error message about missing a dependency? Was there an error from running my tool which was not shown? Thanks, Peter On Wed, Jul 30, 2014 at 6:07 PM, Dave Bouvier d...@bx.psu.edu wrote: Peter, I believe part of the problem is that the install and test framework is unable to resolve the dependency on blast+ 2.2.29 because it is defined as a repository dependency, not a tool dependency. I would recommend replacing the repository dependency in the blast_rbh repository with a tool dependency definition that references package_blast_plus_2_2_29. --Dave B. On 07/30/2014 05:27 AM, Peter Cock wrote: Hi all, I'm not sure when this started (having hardly looked at my Tool Shed test results since GCC2014), but I think this is a fairly recent problem with my BLAST RBH tests failing (which has held me back from posting this to the main Tool Shed). This could be some silly mistake in my tar-ball, but usually missing test files and the like get an explicit error. The tests are passing on my GitHub/TravisCI setup (using Twill and the API backend): e.g. https://travis-ci.org/peterjc/galaxy_blast/builds/30592097 Here is the current error (the same for the last few Test Tool Shed runs), https://testtoolshed.g2.bx.psu.edu/view/peterjc/blast_rbh Traceback (most recent call last): File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py, line 108, in test_tool self.do_it( td ) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py, line 35, in do_it self._verify_outputs( testdef, test_history, shed_tool_id, data_list, galaxy_interactor ) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py, line 69, in _verify_outputs galaxy_interactor.verify_output( history, output_data, output_testdef=output_testdef, shed_tool_id=shed_tool_id, maxseconds=maxseconds ) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py, line 53, in verify_output self.wait_for_history( history_id, maxseconds ) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py, line 107, in wait_for_history self.twill_test_case.wait_for( lambda: not self.__history_ready( history_id ), maxseconds=maxseconds) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/twilltestcase.py, line 2453, in wait_for result = func() File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py, line 107, in lambda self.twill_test_case.wait_for( lambda: not self.__history_ready( history_id ), maxseconds=maxseconds) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py, line 257, in __history_ready return self._state_ready( state, error_msg=History in error state. ) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py, line 316, in _state_ready raise Exception( error_msg ) Exception: History in error state. Is a more detailed log available which might help debug this? Thanks, Peter As an aside, this looks like the Test Tool Shed is still using the Twill backend for the functional tests? ___ 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:
Re: [galaxy-dev] TestToolShed failure, Exception: History in error state.
Hi Peter, 2014-07-31 10:57 GMT+02:00 Peter Cock p.j.a.c...@googlemail.com: Hi Dave, You are right that on closer inspection I've mixed tool_dependencies.xml and repository_dependencies.xml *again*. Evidentially my mental model does not match Greg's here: (*) I need to define a tool installation recipe for something not in the Tool Shed -- write an install script called tool_dependencies.xml (*) I need to depend on a Python package by pointing at another repository in the Tool Shed -- repository_dependencies.xml I might be wrong, but I think that also goes to tool_dependencies.xml (*) I need to depend on a datatype package by pointing at another repository in the Tool Shed -- repository_dependencies.xml (*) I need to depend on a binary package by pointing at another repository in the Tool Shed -- repository_dependencies.xml ? No. You need tool_dependencies.xml for this too As far as I understood, everything that is referenced in the tool.xml under the requirement section, needs to be in a tool_dependencies.xml file. Any other dependency are from the repository (data_types, data_manager, workflows ...). Ciao, Bjoern But that aside, the test framework error here is completely unhelpful. Why is there no error message about missing a dependency? Was there an error from running my tool which was not shown? Thanks, Peter On Wed, Jul 30, 2014 at 6:07 PM, Dave Bouvier d...@bx.psu.edu wrote: Peter, I believe part of the problem is that the install and test framework is unable to resolve the dependency on blast+ 2.2.29 because it is defined as a repository dependency, not a tool dependency. I would recommend replacing the repository dependency in the blast_rbh repository with a tool dependency definition that references package_blast_plus_2_2_29. --Dave B. On 07/30/2014 05:27 AM, Peter Cock wrote: Hi all, I'm not sure when this started (having hardly looked at my Tool Shed test results since GCC2014), but I think this is a fairly recent problem with my BLAST RBH tests failing (which has held me back from posting this to the main Tool Shed). This could be some silly mistake in my tar-ball, but usually missing test files and the like get an explicit error. The tests are passing on my GitHub/TravisCI setup (using Twill and the API backend): e.g. https://travis-ci.org/peterjc/galaxy_blast/builds/30592097 Here is the current error (the same for the last few Test Tool Shed runs), https://testtoolshed.g2.bx.psu.edu/view/peterjc/blast_rbh Traceback (most recent call last): File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py, line 108, in test_tool self.do_it( td ) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py, line 35, in do_it self._verify_outputs( testdef, test_history, shed_tool_id, data_list, galaxy_interactor ) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py, line 69, in _verify_outputs galaxy_interactor.verify_output( history, output_data, output_testdef=output_testdef, shed_tool_id=shed_tool_id, maxseconds=maxseconds ) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py, line 53, in verify_output self.wait_for_history( history_id, maxseconds ) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py, line 107, in wait_for_history self.twill_test_case.wait_for( lambda: not self.__history_ready( history_id ), maxseconds=maxseconds) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/twilltestcase.py, line 2453, in wait_for result = func() File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py, line 107, in lambda self.twill_test_case.wait_for( lambda: not self.__history_ready( history_id ), maxseconds=maxseconds) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py, line 257, in __history_ready return self._state_ready( state, error_msg=History in error state. ) File /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py, line 316, in _state_ready raise Exception( error_msg ) Exception: History in error state. Is a more detailed log available which might help debug this? Thanks, Peter As an aside, this looks like the Test Tool Shed is still using the Twill backend for the functional tests? ___ Please keep all replies on
Re: [galaxy-dev] TestToolShed failure, Exception: History in error state.
On Thu, Jul 31, 2014 at 5:21 PM, bjoern.gruen...@googlemail.com bjoern.gruen...@gmail.com wrote: Hi Peter, 2014-07-31 10:57 GMT+02:00 Peter Cock p.j.a.c...@googlemail.com: Hi Dave, You are right that on closer inspection I've mixed tool_dependencies.xml and repository_dependencies.xml *again*. Evidentially my mental model does not match Greg's here: (*) I need to define a tool installation recipe for something not in the Tool Shed -- write an install script called tool_dependencies.xml (*) I need to depend on a Python package by pointing at another repository in the Tool Shed -- repository_dependencies.xml I might be wrong, but I think that also goes to tool_dependencies.xml Correct, e.g. https://github.com/peterjc/pico_galaxy/tree/master/tools/seq_select_by_id Thanks! (*) I need to depend on a datatype package by pointing at another repository in the Tool Shed -- repository_dependencies.xml (*) I need to depend on a binary package by pointing at another repository in the Tool Shed -- repository_dependencies.xml ? No. You need tool_dependencies.xml for this too As far as I understood, everything that is referenced in the tool.xml under the requirement section, needs to be in a tool_dependencies.xml file. Any other dependency are from the repository (data_types, data_manager, workflows ...). Ciao, Bjoern Sure, there is a logic here - but its a definition which I seem to still struggle with :( But that aside, the test framework error here is completely unhelpful. Why is there no error message about missing a dependency? Was there an error from running my tool which was not shown? Thanks, Peter I'd still like to get a more explicit error from the test suite than History in error state though ;) 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/
[galaxy-dev] fastq-mcf parameter bug
First time posting so I hope I do this correctly. I am using galaxy locally and installed the ea-utils fastq-mcf (FastqMcf). When using the trimming options (not defaults) the -C option gets set to the -s option. I checked the fastq-mcf.xml wrapper and indeed there is an mistake on line 42. -s $trimming.sampcnt Should be -C $trimming.sampcnt I hope this helps, Cheers, Mike --CONFIDENTIALITY NOTICE--: The information contained in this email is intended for the exclusive use of the addressee and may contain confidential information. If you are not the intended recipient, you are hereby notified that any form of dissemination of this communication is strictly prohibited. www.benaroyaresearch.org ___ 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] package_r_2_11_0 and ggplot2
Bjoern,
FYI, I found that package_gatk_1_4 from the main Galaxy toolshed
produces Rscript files for VariantRecalibrator and other commands that
require ggplot_0.8.8 and reshape_0.8.4. This applies to GATK versions
1.4-20 and 1.4-37.
The magic incantation to get a systemwide R v3.1 setup properly is:
r - getOption(repos);
r[CRAN] - http://cran.rstudio.com/;;
options(repos=r);
install.packages(c('devtools','gsalib'));
require(devtools);
install_url('http://cran.r-project.org/src/contrib/Archive/plyr/plyr_1.7.1.tar.gz');
install_url('http://cran.r-project.org/src/contrib/Archive/reshape/reshape_0.8.4.tar.gz');
install_url('http://cran.r-project.org/src/contrib/Archive/ggplot2/ggplot2_0.8.8.tar.gz');
I'm not sure gsalib is required, but it is better to play it safe IMO.
Can you add this to the package_gatk_1_4 documentation to help others
along? It would be even better if the package_gatk_1_4 could also
install those R libraries itself.
Cheers,
-E
-Evan Bollig
Research Associate | Application Developer | User Support Consultant
Minnesota Supercomputing Institute
599 Walter Library
612 624 1447
e...@msi.umn.edu
boll0...@umn.edu
On Tue, Jul 29, 2014 at 4:22 PM, Björn Grüning
bjoern.gruen...@gmail.com wrote:
Am 29.07.2014 um 22:45 schrieb Evan Bollig:
Hey Bjoern,
I'm trying to use variant_recalibrator, xy_plot and other tools that
depend on package_r_2_11_0 and require ggplot2 to be installed. Since
CRAN support for R 2.11.0 and 2.15.0 is on the out, perhaps its a
better idea to update the packages the depend on those versions to R
3.0 or 3.1?
Yes, this would be a better idea!
The variant_recalibrator tool generates an Rscript
incompatible with modern versions of ggplot2, so this could be a quite
involved undertaking.
Oh :( ... can we somehow get an old tarball of ggplot2? Have you looked at
older linux disributions, debian stable for example?
I found ggplot on download_store ;)
https://github.com/bgruening/download_store/blob/master/gatk2_R_deps/ggplot2_0.9.3.1.tar.gz
Is that old enough?
Meanwhile I'll look into the download_store option. You download all
of the tarballs and install them individually with R CMD INSTALL?
Not really, we have a nice routine in the toolshed for such tasks:
Have a look at:
https://github.com/bgruening/galaxytools/tree/master/orphan_tool_dependencies/package_deseq2_1_2_10
Note: the order of the packages are important ...
Ciao,
Bjoern
Cheers,
-E
-Evan Bollig
Research Associate | Application Developer | User Support Consultant
Minnesota Supercomputing Institute
599 Walter Library
612 624 1447
e...@msi.umn.edu
boll0...@umn.edu
On Tue, Jul 29, 2014 at 2:46 PM, Björn Grüning
bjoern.gruen...@gmail.com wrote:
Hi Evan,
do you have somehow access to this tarball? Than we can put it on
https://github.com/bgruening/download_store
I use that to host R packages to save them for reproducibility.
Can I install another package_r and have packages that depend on
package_r_2_11_0 use the newer version?
I don't think so. But that depends very much on your package. Is it not
possible to use a newer R version? In either case you should save all
tarballs somehow to archive them!
Cheers,
Bjoern
-Evan Bollig
Research Associate | Application Developer | User Support Consultant
Minnesota Supercomputing Institute
599 Walter Library
612 624 1447
e...@msi.umn.edu
boll0...@umn.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/
Re: [galaxy-dev] package_r_2_11_0 and ggplot2
Hi Evan,
unfortunately I have no access to this repository. I'm only the
maintainer of the galaxytools in github. But I have CC'ed Dave, he is
responsible for the devteam packages!
Cheers and thanks for sharing your information!
Bjoern
Am 31.07.2014 um 20:47 schrieb Evan Bollig:
Bjoern,
FYI, I found that package_gatk_1_4 from the main Galaxy toolshed
produces Rscript files for VariantRecalibrator and other commands that
require ggplot_0.8.8 and reshape_0.8.4. This applies to GATK versions
1.4-20 and 1.4-37.
The magic incantation to get a systemwide R v3.1 setup properly is:
r - getOption(repos);
r[CRAN] - http://cran.rstudio.com/;;
options(repos=r);
install.packages(c('devtools','gsalib'));
require(devtools);
install_url('http://cran.r-project.org/src/contrib/Archive/plyr/plyr_1.7.1.tar.gz');
install_url('http://cran.r-project.org/src/contrib/Archive/reshape/reshape_0.8.4.tar.gz');
install_url('http://cran.r-project.org/src/contrib/Archive/ggplot2/ggplot2_0.8.8.tar.gz');
I'm not sure gsalib is required, but it is better to play it safe IMO.
Can you add this to the package_gatk_1_4 documentation to help others
along? It would be even better if the package_gatk_1_4 could also
install those R libraries itself.
Cheers,
-E
-Evan Bollig
Research Associate | Application Developer | User Support Consultant
Minnesota Supercomputing Institute
599 Walter Library
612 624 1447
e...@msi.umn.edu
boll0...@umn.edu
On Tue, Jul 29, 2014 at 4:22 PM, Björn Grüning
bjoern.gruen...@gmail.com wrote:
Am 29.07.2014 um 22:45 schrieb Evan Bollig:
Hey Bjoern,
I'm trying to use variant_recalibrator, xy_plot and other tools that
depend on package_r_2_11_0 and require ggplot2 to be installed. Since
CRAN support for R 2.11.0 and 2.15.0 is on the out, perhaps its a
better idea to update the packages the depend on those versions to R
3.0 or 3.1?
Yes, this would be a better idea!
The variant_recalibrator tool generates an Rscript
incompatible with modern versions of ggplot2, so this could be a quite
involved undertaking.
Oh :( ... can we somehow get an old tarball of ggplot2? Have you looked at
older linux disributions, debian stable for example?
I found ggplot on download_store ;)
https://github.com/bgruening/download_store/blob/master/gatk2_R_deps/ggplot2_0.9.3.1.tar.gz
Is that old enough?
Meanwhile I'll look into the download_store option. You download all
of the tarballs and install them individually with R CMD INSTALL?
Not really, we have a nice routine in the toolshed for such tasks:
Have a look at:
https://github.com/bgruening/galaxytools/tree/master/orphan_tool_dependencies/package_deseq2_1_2_10
Note: the order of the packages are important ...
Ciao,
Bjoern
Cheers,
-E
-Evan Bollig
Research Associate | Application Developer | User Support Consultant
Minnesota Supercomputing Institute
599 Walter Library
612 624 1447
e...@msi.umn.edu
boll0...@umn.edu
On Tue, Jul 29, 2014 at 2:46 PM, Björn Grüning
bjoern.gruen...@gmail.com wrote:
Hi Evan,
do you have somehow access to this tarball? Than we can put it on
https://github.com/bgruening/download_store
I use that to host R packages to save them for reproducibility.
Can I install another package_r and have packages that depend on
package_r_2_11_0 use the newer version?
I don't think so. But that depends very much on your package. Is it not
possible to use a newer R version? In either case you should save all
tarballs somehow to archive them!
Cheers,
Bjoern
-Evan Bollig
Research Associate | Application Developer | User Support Consultant
Minnesota Supercomputing Institute
599 Walter Library
612 624 1447
e...@msi.umn.edu
boll0...@umn.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/
Re: [galaxy-dev] package_r_2_11_0 and ggplot2
Btw, I forgot: plyr_1.7.1 is also required for package_gatk_1_4. Hence
the install_url call for it below.
-E
-Evan Bollig
Research Associate | Application Developer | User Support Consultant
Minnesota Supercomputing Institute
599 Walter Library
612 624 1447
e...@msi.umn.edu
boll0...@umn.edu
On Thu, Jul 31, 2014 at 1:51 PM, Björn Grüning
bjoern.gruen...@gmail.com wrote:
Hi Evan,
unfortunately I have no access to this repository. I'm only the maintainer
of the galaxytools in github. But I have CC'ed Dave, he is responsible for
the devteam packages!
Cheers and thanks for sharing your information!
Bjoern
Am 31.07.2014 um 20:47 schrieb Evan Bollig:
Bjoern,
FYI, I found that package_gatk_1_4 from the main Galaxy toolshed
produces Rscript files for VariantRecalibrator and other commands that
require ggplot_0.8.8 and reshape_0.8.4. This applies to GATK versions
1.4-20 and 1.4-37.
The magic incantation to get a systemwide R v3.1 setup properly is:
r - getOption(repos);
r[CRAN] - http://cran.rstudio.com/;;
options(repos=r);
install.packages(c('devtools','gsalib'));
require(devtools);
install_url('http://cran.r-project.org/src/contrib/Archive/plyr/plyr_1.7.1.tar.gz');
install_url('http://cran.r-project.org/src/contrib/Archive/reshape/reshape_0.8.4.tar.gz');
install_url('http://cran.r-project.org/src/contrib/Archive/ggplot2/ggplot2_0.8.8.tar.gz');
I'm not sure gsalib is required, but it is better to play it safe IMO.
Can you add this to the package_gatk_1_4 documentation to help others
along? It would be even better if the package_gatk_1_4 could also
install those R libraries itself.
Cheers,
-E
-Evan Bollig
Research Associate | Application Developer | User Support Consultant
Minnesota Supercomputing Institute
599 Walter Library
612 624 1447
e...@msi.umn.edu
boll0...@umn.edu
On Tue, Jul 29, 2014 at 4:22 PM, Björn Grüning
bjoern.gruen...@gmail.com wrote:
Am 29.07.2014 um 22:45 schrieb Evan Bollig:
Hey Bjoern,
I'm trying to use variant_recalibrator, xy_plot and other tools that
depend on package_r_2_11_0 and require ggplot2 to be installed. Since
CRAN support for R 2.11.0 and 2.15.0 is on the out, perhaps its a
better idea to update the packages the depend on those versions to R
3.0 or 3.1?
Yes, this would be a better idea!
The variant_recalibrator tool generates an Rscript
incompatible with modern versions of ggplot2, so this could be a quite
involved undertaking.
Oh :( ... can we somehow get an old tarball of ggplot2? Have you looked
at
older linux disributions, debian stable for example?
I found ggplot on download_store ;)
https://github.com/bgruening/download_store/blob/master/gatk2_R_deps/ggplot2_0.9.3.1.tar.gz
Is that old enough?
Meanwhile I'll look into the download_store option. You download all
of the tarballs and install them individually with R CMD INSTALL?
Not really, we have a nice routine in the toolshed for such tasks:
Have a look at:
https://github.com/bgruening/galaxytools/tree/master/orphan_tool_dependencies/package_deseq2_1_2_10
Note: the order of the packages are important ...
Ciao,
Bjoern
Cheers,
-E
-Evan Bollig
Research Associate | Application Developer | User Support Consultant
Minnesota Supercomputing Institute
599 Walter Library
612 624 1447
e...@msi.umn.edu
boll0...@umn.edu
On Tue, Jul 29, 2014 at 2:46 PM, Björn Grüning
bjoern.gruen...@gmail.com wrote:
Hi Evan,
do you have somehow access to this tarball? Than we can put it on
https://github.com/bgruening/download_store
I use that to host R packages to save them for reproducibility.
Can I install another package_r and have packages that depend on
package_r_2_11_0 use the newer version?
I don't think so. But that depends very much on your package. Is it not
possible to use a newer R version? In either case you should save all
tarballs somehow to archive them!
Cheers,
Bjoern
-Evan Bollig
Research Associate | Application Developer | User Support Consultant
Minnesota Supercomputing Institute
599 Walter Library
612 624 1447
e...@msi.umn.edu
boll0...@umn.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] Galaxy Security Vulnerability
A security vulnerability was recently discovered by Inge Alexander Raknes that would allow a malicious person to execute arbitrary code on a Galaxy server. The vulnerability was in a method that uses Python pickle functionality to decode state information from tool forms. Because pickles can be used to instantiate arbitrary Python objects, tool states could be constructed to exploit this vulnerability. Because this vulnerability allows for arbitrary code execution, administrators are strongly encouraged to apply this fix IMMEDIATELY. We have tried to make it as easy and quick as possible for server administrators to update their Galaxy instances. The fix has been applied to every stable release from 2013.01.13 until the tip, so it is possible to get this fix on older releases without updating to a newer feature release. You can do this by identifying your current release and updating to the `latest_release_date` tag corresponding to your release. For example, if you are running release_2013.11.04 (or a subsequent commit to the stable branch of Galaxy between release_2013.11.04 and release_2014.02.10), you can update with: % hg pull % hg update latest_2013.11.04 For the changes to take effect, YOU MUST RESTART ALL GALAXY SERVER PROCESSES. If you do not want to pull any upstream changes, we have also created a standalone patch that fixes this problem, with multiple versions depending on your current Galaxy release: - pickle-2013.11.04.patch - This patch should apply cleanly (with offset/fuzz) to releases from 2013.11.04 up to the current stable tip. Available at: https://depot.galaxyproject.org/patch/pickle-2013.11.04.patch - pickle-2013.01.13.patch - This patch should apply cleanly (with offset/fuzz) to releases from 2013.01.13 up to 2013.08.12, and possibly older versions of Galaxy as well. Available at: https://depot.galaxyproject.org/patch/pickle-2013.01.13.patch If you happen to be running a very recent revision on the default branch or the newly created next-stable branch, a pickle-default.patch file exists at the same place. For older releases or instances with conflicting local modifications, manual application of the patch should not be difficult as it only includes a few small changes. To apply the patch, navigate to the root of your Galaxy directory, then run (replacing url_to_patch with the URL above that is correct for your release): % wget -O pickle.patch url_to_patch or: % curl -o pickle.patch url_to_patch and then: % patch -p1 pickle.patch patching file lib/galaxy/util/__init__.py Hunk #1 succeeded at 575 with fuzz 2 (offset -113 lines). patching file lib/galaxy/webapps/galaxy/controllers/ucsc_proxy.py Again, for the changes to take effect, YOU MUST RESTART ALL GALAXY SERVER PROCESSES. The Galaxy Team would like to extend special thanks to Inge Alexander Raknes and colleagues, who privately disclosed the vulnerability, with a full analysis and proof of concept. Credit for the fix and subsequent testing goes to my fellow Galaxy Team members John Chilton and Dannon Baker. On behalf of the Galaxy Team, --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/
