Re: [galaxy-dev] customize the Upload File tool form (version 1.1.4)
Hi, This is a quick follow up about the instructions given by Aysam and Martin, which may help others (including me ;-). Indeed I upgraded our galaxy-dist to the last commit and the /client directory showed up. To get the instructions working I had to install as root some grunt related packages, otherwise it failed: including $ sudo apt-get install software-properties-common $ sudo apt-get install python-software-properties $ sudo apt-get update $ sudo npm -g install grunt $ sudo npm install -g grunt-cli Then I had the grunt watch working and could make the changes - *opening another shell session* (I say this because it is not evident for those who are not familiar with grunt). Yet the changes still do not show up in the browser. My guess is that the galaxy configuration model has changed too, with the creation of a config directory. I suppose that the use of the /client directory is specified in the new galaxy.ini file which replaces universe_wsgi.ini in / . More generally, I did not see instructions on how to move from the old .ini file*sss* at / to the new configuration model using the /config directory without crashing the production instance. Is it available somewhere in the wiki or in a discussion ? Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Institut de Biologie Paris Seine http://www.ibps.upmc.fr/fr/Recherche/umr-biologie-developpement/genetique-et-epigenetique-de-la-drosophile 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 christophe.antoniew...@upmc.fr http://drosophile.org 2014-11-12 16:11 GMT+01:00 Aysam Guerler aysam.guer...@gmail.com: Hi Christophe, In order to apply the changes scripts have to be packed properly. Please follow these steps: 1. Go to the client/ directory and type 'npm install' 2. Now type 'grunt watch'. This will start a listener which captures code changes and repacks scripts automatically 3. Finally, make your changes to the code files in client/galaxy/scripts/mvc/upload and reload your browser Let me know if that works for you or if you have any other questions. Thanks, Sam ___ 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] customize the Upload File tool form (version 1.1.4)
Hi, As we have arranged an sftp upload system through ftp port for our Galaxy instance, we would need to customize the Upload File tool form, so that a few more line explain how-to-do in the FTP section of the form, in addition to the This Galaxy server allows you to upload files via FTP. To upload some files, log in to the FTP server at 127.0.0.1 using your Galaxy credentials (email address and password). I dug into /home/galaxy/galaxy-dist/static/scripts/mvc/upload/upload-ftp.js and /home/galaxy/galaxy-dist/static/scripts/packed/mvc/upload/upload-ftp.js but the changes I tried into these files do not show up in the tool form. If someone can indicate the right way to intercept this content and enrich it as mentioned above, I would be grateful ! Cheers Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Institut de Biologie Paris Seine http://www.ibps.upmc.fr/fr/Recherche/umr-biologie-developpement/genetique-et-epigenetique-de-la-drosophile 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 christophe.antoniew...@upmc.fr http://drosophile.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] customize the Upload File tool form (version 1.1.4)
Aysam and Martin, Thanks for your help. I am not familiar with JS development. To make client crystal clear : /client stands for the home directory where Galaxy-dist is installed ? and client/galaxy/scripts/mvc/upload stands for ~/galaxy-dist/scripts/mvc/upload (assuming that the galaxy code is installed in galaxy-dis) ? right ? Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Institut de Biologie Paris Seine http://www.ibps.upmc.fr/fr/Recherche/umr-biologie-developpement/genetique-et-epigenetique-de-la-drosophile 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 christophe.antoniew...@upmc.fr http://drosophile.org 2014-11-12 16:42 GMT+01:00 Martin Čech mar...@bx.psu.edu: I updated our wiki with this new build information. https://wiki.galaxyproject.org/Develop/JSA M. On Wed, Nov 12, 2014 at 10:11 AM, Aysam Guerler aysam.guer...@gmail.com wrote: Hi Christophe, In order to apply the changes scripts have to be packed properly. Please follow these steps: 1. Go to the client/ directory and type 'npm install' 2. Now type 'grunt watch'. This will start a listener which captures code changes and repacks scripts automatically 3. Finally, make your changes to the code files in client/galaxy/scripts/mvc/upload and reload your browser Let me know if that works for you or if you have any other questions. Thanks, Sam On Wed, Nov 12, 2014 at 4:47 AM, Christophe Antoniewski christophe.antoniew...@snv.jussieu.fr wrote: Hi, As we have arranged an sftp upload system through ftp port for our Galaxy instance, we would need to customize the Upload File tool form, so that a few more line explain how-to-do in the FTP section of the form, in addition to the This Galaxy server allows you to upload files via FTP. To upload some files, log in to the FTP server at 127.0.0.1 using your Galaxy credentials (email address and password). I dug into /home/galaxy/galaxy-dist/static/scripts/mvc/upload/upload-ftp.js and /home/galaxy/galaxy-dist/static/scripts/packed/mvc/upload/upload-ftp.js but the changes I tried into these files do not show up in the tool form. If someone can indicate the right way to intercept this content and enrich it as mentioned above, I would be grateful ! Cheers Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Institut de Biologie Paris Seine http://www.ibps.upmc.fr/fr/Recherche/umr-biologie-developpement/genetique-et-epigenetique-de-la-drosophile 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 christophe.antoniew...@upmc.fr http://drosophile.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/ ___ 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] customize the Upload File tool form (version 1.1.4)
Ok I just noticed the new client directory in Bitbucket and the accompanying trello cards. Make things more understandable... Thanks Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Institut de Biologie Paris Seine http://www.ibps.upmc.fr/fr/Recherche/umr-biologie-developpement/genetique-et-epigenetique-de-la-drosophile 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 christophe.antoniew...@upmc.fr http://drosophile.org 2014-11-12 19:23 GMT+01:00 Martin Čech mar...@bx.psu.edu: corrrect: /client is a directory within Galaxy root - it contains all the javascripts The build (grunt) process takes the /client directory and copies the scripts to /static/scripts directory within Galaxy root (and packs them and stuff) from where the files are served to the browser. If you want to make JS changes, make them in /client and propagate it via grunt. Make sure you have up to date version of Galaxy since the grunt building was added fairly recently. note: /scripts directory within Galaxy root has a different purpose, those are python scripts (API and stuff) M. On Wed, Nov 12, 2014 at 1:16 PM, Christophe Antoniewski christophe.antoniew...@snv.jussieu.fr wrote: Aysam and Martin, Thanks for your help. I am not familiar with JS development. To make client crystal clear : /client stands for the home directory where Galaxy-dist is installed ? and client/galaxy/scripts/mvc/upload stands for ~/galaxy-dist/scripts/mvc/upload (assuming that the galaxy code is installed in galaxy-dis) ? right ? Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Institut de Biologie Paris Seine http://www.ibps.upmc.fr/fr/Recherche/umr-biologie-developpement/genetique-et-epigenetique-de-la-drosophile 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 christophe.antoniew...@upmc.fr http://drosophile.org 2014-11-12 16:42 GMT+01:00 Martin Čech mar...@bx.psu.edu: I updated our wiki with this new build information. https://wiki.galaxyproject.org/Develop/JSA M. On Wed, Nov 12, 2014 at 10:11 AM, Aysam Guerler aysam.guer...@gmail.com wrote: Hi Christophe, In order to apply the changes scripts have to be packed properly. Please follow these steps: 1. Go to the client/ directory and type 'npm install' 2. Now type 'grunt watch'. This will start a listener which captures code changes and repacks scripts automatically 3. Finally, make your changes to the code files in client/galaxy/scripts/mvc/upload and reload your browser Let me know if that works for you or if you have any other questions. Thanks, Sam On Wed, Nov 12, 2014 at 4:47 AM, Christophe Antoniewski christophe.antoniew...@snv.jussieu.fr wrote: Hi, As we have arranged an sftp upload system through ftp port for our Galaxy instance, we would need to customize the Upload File tool form, so that a few more line explain how-to-do in the FTP section of the form, in addition to the This Galaxy server allows you to upload files via FTP. To upload some files, log in to the FTP server at 127.0.0.1 using your Galaxy credentials (email address and password). I dug into /home/galaxy/galaxy-dist/static/scripts/mvc/upload/upload-ftp.js and /home/galaxy/galaxy-dist/static/scripts/packed/mvc/upload/upload-ftp.js but the changes I tried into these files do not show up in the tool form. If someone can indicate the right way to intercept this content and enrich it as mentioned above, I would be grateful ! Cheers Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Institut de Biologie Paris Seine http://www.ibps.upmc.fr/fr/Recherche/umr-biologie-developpement/genetique-et-epigenetique-de-la-drosophile 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 christophe.antoniew...@upmc.fr http://drosophile.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/ ___ 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-dev] Dependencies within dependencies
I am trying to move the package_r_3_0_3 repository owned by devteam from the main toolshed to our local toolshed. This does not work as some dependencies required for package_r_3_0_3 are not exported (export capsule) and not included in the archive. For instance, package_freetype_2_5_2 and package_libpng_1_6_7 are present in the capsule and thus moved to the local toolshed, but not package_readline_6_2, package_cairo_1_12_14 and package_pixman_0_32_4. Is it a bug (I would expect a sort of recursivity in the export process) or did I miss some logics behind this ? And do we have to manually export-import the missing dependencies to the local toolshed ? Cheers Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 christophe.antoniew...@upmc.fr http://bio-dev.snv.jussieu.fr/ Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.org http://www.sciencesenmarche.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] no capsule export from a local tool shed
Dave, Thank you very much, it worked indeed. The gz export does not work yet, but this is apparently now due to a problem with mercurial (An error occurred while processing your request: - Archive type not allowed: gz). Anyway, this is not a main issue and we are going to be able to focus on the tools, without apache. Thank thank thank Chris Christophe Antoniewski http://sciencesenmarche.org/ Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 christophe.antoniew...@upmc.fr http://bio-dev.snv.jussieu.fr/ Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.org http://www.sciencesenmarche.org/ 2014-09-11 15:18 GMT+02:00 Dave Bouvier d...@bx.psu.edu: Christophe, Unfortunately, exporting a capsule without a proxy in front of the tool shed will fail to find dependencies if the dependencies were defined with the proxy in place. One solution would be to re-upload the dependency definitions without using the proxy, leaving the changeset_revision and toolshed attributes undefined. This will make the tool shed recalculate tool shed URLs and changeset revisions for the dependency relationships, and the capsule export should then find them. --Dave B. On 09/10/2014 12:11 PM, Christophe Antoniewski wrote: I am replying to myself to report limited progresses... : if we run the tool shed server without apache, the export capsule job works, except that the repository dependencies are not seen (no Export repository dependencies? checkbox to check). Without this new layer of complication, we would leave apache which is not really required for tool development in our local toolshed. But Export repository dependencies matters... Sure we are missing something around Apache and tool_shed_wsgi.ini configuration, but still lost.. Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 christophe.antoniew...@upmc.fr mailto:christophe.antoniew...@upmc.fr http://bio-dev.snv.jussieu.fr/ Tel +33 1 44 27 34 39 Fax+33 1 44 27 34 45 Mobile+33 6 68 60 51 50 http://drosophile.org http://www.sciencesenmarche.org/ 2014-09-08 19:24 GMT+02:00 Christophe Antoniewski christophe.antoniew...@snv.jussieu.fr mailto:christophe.antoniew...@snv.jussieu.fr: Hi, Here is a question maybe to Greg: Since the GCC2014 we started a local toolshed following the instructions in http://gregvonkuster.org/galaxy-tool-shed-framework- building-galaxy-tools/ It works nicely, except that today I tried to export repository capsules (export this revision) from the local toolshed and it returns the following error (see below). I cannot remember whether I had ever tested this particular action since the local tool shed set up. Thus I even cannot say whether the bug is due to an original misconfiguration or it happened later on. I can add that the local toolshed is served by apache with rewriting rules (I am saying this because in addition it is not possible to download repositories as gz archives etc... and suspect that there is maybe a problem, in addition, with the apache config). Any help appreciated ! Regards Christophe --- URL: http://lbcd41.snv.jussieu.fr/toolshed/repository/export? repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f Module galaxy.web.framework.middleware.error:*149* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export? repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#app_iter *=* self*.*application*(*environ*,* sr_checker*)*| Module paste.debug.prints:*106* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export? repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# environ*,* self*.*app*)*| Module paste.wsgilib:*543* in |intercept_output| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export? repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#app_iter *=* application*(*environ*,* replacement_start_response*)*| Module paste.recursive:*84* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export? repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#*return* self*.*application*(*environ*,* start_response*)*| Module paste.httpexceptions:*633* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export? repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#*return* self*.*application*(*environ*,* start_response*)*| Module galaxy.web.framework.base:*132* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export? repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#*return
Re: [galaxy-dev] no capsule export from a local tool shed
I am replying to myself to report limited progresses... : if we run the tool shed server without apache, the export capsule job works, except that the repository dependencies are not seen (no Export repository dependencies? checkbox to check). Without this new layer of complication, we would leave apache which is not really required for tool development in our local toolshed. But Export repository dependencies matters... Sure we are missing something around Apache and tool_shed_wsgi.ini configuration, but still lost.. Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 christophe.antoniew...@upmc.fr http://bio-dev.snv.jussieu.fr/ Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.org http://www.sciencesenmarche.org/ 2014-09-08 19:24 GMT+02:00 Christophe Antoniewski christophe.antoniew...@snv.jussieu.fr: Hi, Here is a question maybe to Greg: Since the GCC2014 we started a local toolshed following the instructions in http://gregvonkuster.org/galaxy-tool-shed-framework-building-galaxy-tools/ It works nicely, except that today I tried to export repository capsules (export this revision) from the local toolshed and it returns the following error (see below). I cannot remember whether I had ever tested this particular action since the local tool shed set up. Thus I even cannot say whether the bug is due to an original misconfiguration or it happened later on. I can add that the local toolshed is served by apache with rewriting rules (I am saying this because in addition it is not possible to download repositories as gz archives etc... and suspect that there is maybe a problem, in addition, with the apache config). Any help appreciated ! Regards Christophe --- URL: http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f Module galaxy.web.framework.middleware.error:*149* in __call__ http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# app_iter *=* self*.*application*(*environ*,* sr_checker*)* Module paste.debug.prints:*106* in __call__ http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# environ*,* self*.*app*)* Module paste.wsgilib:*543* in intercept_output http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# app_iter *=* application*(*environ*,* replacement_start_response*)* Module paste.recursive:*84* in __call__ http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# *return* self*.*application*(*environ*,* start_response*)* Module paste.httpexceptions:*633* in __call__ http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# *return* self*.*application*(*environ*,* start_response*)* Module galaxy.web.framework.base:*132* in __call__ http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# *return* self*.*handle_request*(* environ*,* start_response *)* Module galaxy.web.framework.base:*190* in handle_request http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# body *=* method*(* trans*,* kwargs *)* Module galaxy.webapps.tool_shed.controllers.repository:*1249* in export http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# repositories_archive_filename *=* os*.*path*.*basename*(* repositories_archive*.*name *)* *AttributeError: 'NoneType' object has no attribute 'name'* Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 christophe.antoniew...@upmc.fr http://bio-dev.snv.jussieu.fr/ Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.org http://www.sciencesenmarche.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/
[galaxy-dev] no capsule export from a local tool shed
Hi, Here is a question maybe to Greg: Since the GCC2014 we started a local toolshed following the instructions in http://gregvonkuster.org/galaxy-tool-shed-framework-building-galaxy-tools/ It works nicely, except that today I tried to export repository capsules (export this revision) from the local toolshed and it returns the following error (see below). I cannot remember whether I had ever tested this particular action since the local tool shed set up. Thus I even cannot say whether the bug is due to an original misconfiguration or it happened later on. I can add that the local toolshed is served by apache with rewriting rules (I am saying this because in addition it is not possible to download repositories as gz archives etc... and suspect that there is maybe a problem, in addition, with the apache config). Any help appreciated ! Regards Christophe --- URL: http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f Module galaxy.web.framework.middleware.error:*149* in __call__ http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# app_iter *=* self*.*application*(*environ*,* sr_checker*)* Module paste.debug.prints:*106* in __call__ http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# environ*,* self*.*app*)* Module paste.wsgilib:*543* in intercept_output http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# app_iter *=* application*(*environ*,* replacement_start_response*)* Module paste.recursive:*84* in __call__ http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# *return* self*.*application*(*environ*,* start_response*)* Module paste.httpexceptions:*633* in __call__ http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# *return* self*.*application*(*environ*,* start_response*)* Module galaxy.web.framework.base:*132* in __call__ http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# *return* self*.*handle_request*(* environ*,* start_response *)* Module galaxy.web.framework.base:*190* in handle_request http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# body *=* method*(* trans*,* kwargs *)* Module galaxy.webapps.tool_shed.controllers.repository:*1249* in export http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# repositories_archive_filename *=* os*.*path*.*basename*(* repositories_archive*.*name *)* *AttributeError: 'NoneType' object has no attribute 'name'* Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 christophe.antoniew...@upmc.fr http://bio-dev.snv.jussieu.fr/ Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.org http://www.sciencesenmarche.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/
[galaxy-dev] Problem with editing permissions on Galaxy libraries
Hi, Since an undetermined period of time in our instance, the edit permission panel under admin management of libraries shows an unexpected aspect: The modify library item part of the form is normal, with 2 fields for Roles associated and Roles not associated. However, none of the other parts of the form (access library, add library item, manage library permissions) have the Roles not associated fields. I am not saying that these fields are empty, they are just absent. With the consequence that we cannot really manage anymore the library access rights. Any hints ? Is it a bug or a feature (such as a consequence of managing bad something else somewhere else) ? Thanks Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 http://bio-dev.snv.jussieu.fr/ Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.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] Postgresql database cleaning
That's right I have over-exaggerated: the size of the complete database dump is currently 125 Mo. Yet it does not really change my question about the galaxy database philosophy. With time and instance upscaling, 1To is not so unbelievable, don't you think ? On the other hand, what is the point to keep in the database deleted histories, users, datasets, etc ? Is it just that the db structure is so complicated that real deletion would be too risky ? (indeed I am not a guru of postgresql at all). Apart from this lack of esthetics in the adopted solution to keep everything until the end of times (just my humble opinion), there is other aspects a bit irritating: for instance, when you manage users, as already discussed in previous posts, you get confused by many users who do not exist anymore since a long time. Just an example. Sometime, when I try to imagine the future of our galaxy instance in the next 5 years let's say, I got the feeling that the only solution would be to restart a galaxy instance from scratch, asking users to register again, reimport their datasets etc... which again goes against my sense of esthetics. I would be curious to know what are the plans for the future of https://main.g2.bx.psu.edu/ for instance. Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.org 2013/8/29 Dannon Baker dannon.ba...@gmail.com Can you get a dump of table sizes for us to compare with? http://wiki.postgresql.org/wiki/Disk_Usage On Thu, Aug 29, 2013 at 12:05 PM, Nate Coraor n...@bx.psu.edu wrote: On Aug 29, 2013, at 11:50 AM, Nate Coraor wrote: On Aug 26, 2013, at 5:03 AM, Christophe Antoniewski wrote: Hi everybody, The python scripts to clean histories, datasets, users etc.. are fine... However, the records are not really removed from the postgresql database and as a result, this one gets bigger and bigger with unused records. Ours is above 1 To after 2 years of production. Is there a safe way to clean the database from unused records and their dependencies to reduce it size, without being a postgresql guru ? Hi Chris, The database maintains a permanent record of everything that was done, even though the underlying data can be removed. There are a lot of dependencies between objects in Galaxy and removing records, especially anything with a foreign key, could easily result in a lot of problems with all kinds of things, from the UI to running jobs. Because of this, records cannot be removed from the database. Somehow I missed that you said your database is 1 TB - that should not be the case. Unless your database is not being vacuumed or you create objects at an extreme rate, it seems as though something has been stored in it that should not have. --nate --nate Chris -- Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biolologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.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/ ___ 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/ ___ 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] Postgresql database cleaning
Hi everybody, The python scripts to clean histories, datasets, users etc.. are fine... However, the records are not really removed from the postgresql database and as a result, this one gets bigger and bigger with unused records. Ours is above 1 To after 2 years of production. Is there a safe way to clean the database from unused records and their dependencies to reduce it size, without being a postgresql guru ? Chris -- Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biolologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.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] Path to the bedtools for getting trackster working properly
My fault my own fault ! Our galaxy instance is running as a service. I forgot to modify the export path command in the galaxy daemon config file which we setup in the /etc/init.d directory Shame on me Chris 2013/6/26 Jeremy Goecks jeremy.goe...@emory.edu To have Trackster visualization working properly in Galaxy, one needs bedtools. Yet in our instance (running under Ubuntu OS), installing bedtools in the galaxy home directory and setting the environmental variable PATH in the .profile file so that it includes the path to ~/bin/bedtools does not work. Yet the PATH variable is indeed including the appropriate information as the owner of the galaxy home directory can run the bedtools in command lines. I have also to precise that we use a lot of third party tools (bowtie, cufflinks, etc...) including wigToBigWig which is also required for trackster, and that we have no path problem with these tools. Indeed the only way to get galaxy accessing properly to the bedtools currently is to put the bedtools in the /usr/local/bin directory. Here it works ! I suspect it is a problem of shell specification when the bedtools are used for trackster, but I could not figure out further the issue. It's difficult to speculate about what's going on. Trackster uses the same infrastructure (PATH, submission script, etc.) for running bedtools that other Galaxy tools use, so there's reason to think that Trackster requires something special in any way. I also have multiple instances where bedtools is installed alongside bowtie/cufflinks/tophat/wigToBigWig/etc. in a single bin directory that is in the Galaxy user's path, and that works for me. You could certainly modify the conversion tools that Trackster uses to echo and inspect the PATH. Let us know if you find anything interesting. Best, J. -- Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biolologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.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/
[galaxy-dev] database upgrade crashes after upgrade to the June 3, 2013 Galaxy release
Hi, Sorry to bother again, but we have now a problem with the last release of galaxy-dist The lack of a python module asked by a python eggs seems to interrupt our postgresql database upgrade from version '114' to '115' sh manage_db.sh upgrade Traceback (most recent call last): File ./scripts/manage_db.py, line 13, in module from migrate.versioning.shell import main File /home/galaxy/galaxy-dist/eggs/sqlalchemy_migrate-0.7.2-py2.7.egg/migrate/versioning/shell.py, line 12, in module from migrate.versioning import api File /home/galaxy/galaxy-dist/eggs/sqlalchemy_migrate-0.7.2-py2.7.egg/migrate/versioning/api.py, line 33, in module from migrate.versioning import (repository, schema, version, File /home/galaxy/galaxy-dist/eggs/sqlalchemy_migrate-0.7.2-py2.7.egg/migrate/versioning/repository.py, line 13, in module from migrate.versioning import version, pathed, cfgparse File /home/galaxy/galaxy-dist/eggs/sqlalchemy_migrate-0.7.2-py2.7.egg/migrate/versioning/version.py, line 10, in module from migrate.versioning import pathed, script File /home/galaxy/galaxy-dist/eggs/sqlalchemy_migrate-0.7.2-py2.7.egg/migrate/versioning/pathed.py, line 11, in module from migrate.versioning.util import KeyedInstance File /home/galaxy/galaxy-dist/eggs/sqlalchemy_migrate-0.7.2-py2.7.egg/migrate/versioning/util/__init__.py, line 7, in module from decorator import decorator ImportError: No module named decorator Any idea ? Thanks Chris -- Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biolologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.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] database upgrade crashes after upgrade to the June 3, 2013 Galaxy release
Thank you so much Björn, I made the change of the file directly by hand (not sure to be able to cleanly switch to default from stable with the new mercurial mode) and it worked. Chris 2013/6/12 Björn Grüning bjoern.gruen...@pharmazie.uni-freiburg.de Hi Christophe, can you try to update to the latest revision? It is fixed here: https://bitbucket.org/galaxy/galaxy-central/commits/47b86d6a9077facb54804576be49ca545d18bd4e Cheers, Bjoern Hi, Sorry to bother again, but we have now a problem with the last release of galaxy-dist The lack of a python module asked by a python eggs seems to interrupt our postgresql database upgrade from version '114' to '115' sh manage_db.sh upgrade Traceback (most recent call last): File ./scripts/manage_db.py, line 13, in module from migrate.versioning.shell import main File /home/galaxy/galaxy-dist/eggs/sqlalchemy_migrate-0.7.2-py2.7.egg/migrate/versioning/shell.py, line 12, in module from migrate.versioning import api File /home/galaxy/galaxy-dist/eggs/sqlalchemy_migrate-0.7.2-py2.7.egg/migrate/versioning/api.py, line 33, in module from migrate.versioning import (repository, schema, version, File /home/galaxy/galaxy-dist/eggs/sqlalchemy_migrate-0.7.2-py2.7.egg/migrate/versioning/repository.py, line 13, in module from migrate.versioning import version, pathed, cfgparse File /home/galaxy/galaxy-dist/eggs/sqlalchemy_migrate-0.7.2-py2.7.egg/migrate/versioning/version.py, line 10, in module from migrate.versioning import pathed, script File /home/galaxy/galaxy-dist/eggs/sqlalchemy_migrate-0.7.2-py2.7.egg/migrate/versioning/pathed.py, line 11, in module from migrate.versioning.util import KeyedInstance File /home/galaxy/galaxy-dist/eggs/sqlalchemy_migrate-0.7.2-py2.7.egg/migrate/versioning/util/__init__.py, line 7, in module from decorator import decorator ImportError: No module named decorator Any idea ? Thanks Chris -- Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biolologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.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/ -- Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biolologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.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] the release_2013.04.01 update crashes our galaxy server
Hi James Ross,
here is the static part of our universe_wsgi.in...
# all commented by chris on 30-12-2011 as pages served by apache2
#static_enabled = True
#static_cache_time = 360
#static_dir = %(here)s/static/
#static_images_dir = %(here)s/static/images
#static_favicon_dir = %(here)s/static/favicon.ico
#static_scripts_dir = %(here)s/static/scripts/
#static_style_dir = %(here)s/static/june_2007_style/blue
Yes, it is all commented, but worked fine since December 2011 when we
proxied Galaxy by apache.
Chris
2013/4/16 James Taylor ja...@jamestaylor.org
This looks like just a configuration file problem. What is the value
of the various static_ options (like static_dir =) in your
universe_wsgi.ini?
On Mon, Apr 15, 2013 at 7:25 PM, Christophe Antoniewski
christophe.antoniew...@snv.jussieu.fr wrote:
webapp = wrap_in_static( webapp, global_conf, **kwargs )
File /home/galaxy/galaxy-dist/lib/galaxy/webapps/galaxy/buildapp.py,
line 327, in wrap_in_static
urlmap[/static] = Static( conf.get( static_dir ), cache_time )
File
/home/galaxy/galaxy-dist/lib/galaxy/web/framework/middleware/static.py,
line 16, in __init__
StaticURLParser.__init__( self, directory )
File
/home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/urlparser.py,
line 430, in __init__
self.directory = self.normpath(directory)
File
/home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/urlparser.py,
line 435, in normpath
return os.path.normcase(os.path.abspath(path))
File /usr/lib/python2.7/posixpath.py, line 343, in abspath
if not isabs(path):
File /usr/lib/python2.7/posixpath.py, line 53, in isabs
return s.startswith('/')
AttributeError: 'NoneType' object has no attribute 'startswith'
--
Christophe Antoniewski
Drosophila Genetics and Epigenetics
Laboratoire de Biolologie du Développement
9, Quai St Bernard, Boîte courrier 24
75252 Paris Cedex 05
Tel +33 1 44 27 34 39
Fax +33 1 44 27 34 45
Mobile +33 6 68 60 51 50
http://drosophile.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/
[galaxy-dev] the release_2013.04.01 update crashes our galaxy server
, in wrap_in_static
urlmap[/static] = Static( conf.get( static_dir ), cache_time )
File
/home/galaxy/galaxy-dist/lib/galaxy/web/framework/middleware/static.py,
line 16, in __init__
StaticURLParser.__init__( self, directory )
File
/home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/urlparser.py,
line 430, in __init__
self.directory = self.normpath(directory)
File
/home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/urlparser.py,
line 435, in normpath
return os.path.normcase(os.path.abspath(path))
File /usr/lib/python2.7/posixpath.py, line 343, in abspath
if not isabs(path):
File /usr/lib/python2.7/posixpath.py, line 53, in isabs
return s.startswith('/')
*AttributeError: 'NoneType' object has no attribute 'startswith'*
*galaxy.jobs.handler INFO 2013-04-16 01:00:30,112 sending stop signal to
worker thread*
*galaxy.jobs.handler INFO 2013-04-16 01:00:30,112 job handler queue stopped*
*galaxy.jobs.runners INFO 2013-04-16 01:00:30,112 LWRRunner: Sending stop
signal to monitor thread*
*galaxy.jobs.runners INFO 2013-04-16 01:00:30,112 LWRRunner: Sending stop
signal to 3 worker threads*
*galaxy.jobs.runners INFO 2013-04-16 01:00:30,113 LocalRunner: Sending stop
signal to 5 worker threads*
*galaxy.jobs.handler INFO 2013-04-16 01:00:30,115 sending stop signal to
worker thread*
*galaxy.jobs.handler INFO 2013-04-16 01:00:30,115 job handler stop queue
stopped*
does anyone has a clue about what is going wrong (eggs or something...)
Thanks thanks thanks in advance
--
Christophe Antoniewski
Drosophila Genetics and Epigenetics
Laboratoire de Biolologie du Développement
9, Quai St Bernard, Boîte courrier 24
75252 Paris Cedex 05
Tel +33 1 44 27 34 39
Fax +33 1 44 27 34 45
Mobile +33 6 68 60 51 50
http://drosophile.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] piping two scripts in the same xml tool wrapper
Yes it is working too, avoiding an additional wrapper. Yet, strangely enough, the absolute paths are required in the command line: command python /home/galaxy/galaxy-dist/tools/chrisTools/plotter.py $input $minsize $maxsize $factor $output |bash /home/galaxy/galaxy-dist/tools/chrisTools/r_wrapper.sh $Rplotter/command The galaxy has still some mysteries ;-) Chris 2012/11/19 James Taylor ja...@jamestaylor.org On Sun, Nov 18, 2012 at 1:13 PM, Christophe Antoniewski droso...@gmail.com wrote: but the second script output is empty. I suspect that the second script is launched when the output of the first script is not available yet. I'm pretty sure we do not currently support multiple command tags. However whatever is in the command text is always run through a shell (sh), so you can use pipes and such directly, just don't specify interpreter at all: commandpython plotter.py $input $minsize $maxsize $factor $output | bash r_wrapper.sh $Rplotter/command ...should work. -- ¡ Note that my email address has changed ! ¡ Please update your records with ! ¡ *christophe.antoniew...@snv.jussieu.fr*christophe.antoniew...@snv.jussieu.fr! -- Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biolologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.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/
[galaxy-dev] piping two scripts in the same xml tool wrapper
Hi,
Is there a way to pipe in the same xml wrapper two scripts in different
languages, the output of the first script becoming the input of the second ?
I know that the spirit of galaxy would be to make a workflow, but the
intermediate output in the present case is not interesting at all and may
confuse the user.
I am testing something like :
command interpreter=pythonplotter.py $input $minsize $maxsize
$factor $output/command
command interpreter=bashr_wrapper.sh $Rplotter/command
inputs
param name=input type=data format=tabular
label=Compute Plot table from this bowtie standard output/
param name=minsize type=integer size=3 value=20
label=Min size of small RNA to plot help='20' = 20 nucleotides/
param name=maxsize type=integer size=3 value=22
label=Max size of small RNA to plot help='22' = 22 nucleotides/
param name=factor type=float size=6 value=1.00
label=Normalization factort help=leave at 1.00 for no normalization/
param name=title type=text size=15 value=Main
Title label=Main Titles/
param name=xlabel type=text size=15
value=Coordinates (nt) label=x axis label/
param name=ylabel type=text size=15
value=Normalized number of reads label=y axis label/
param name=yrange type=integer size=6 value=400
label=y axis range/
/inputs
configfiles
configfile name=Rplotter
## Setup R error handling to go to stderr
options( show.error.messages=F,
error = function () { cat( geterrmessage(), file=stderr() );
q( no, 1, F ) } )
tab = read.delim(${output}, header=TRUE)
## Open output PDF file
pdf( ${outputFinal} )
#determining y and x axis ranges
MAXcoord = max(tab[,1]) + 100
MINcoord = min(tab[,1])
MMAX = ${yrange}
plot(tab[,1], tab[,2], type=h, xaxt=n, xlim=c(MINcoord ,
MAXcoord), ylim=c(-MMAX , MMAX), frame.plot=FALSE, lwd=2, las=2, xlab=
${xlabel}, ylab=${ylabel}, main = ${title})
lines(tab[,1], tab[,3], type=h, lwd=2)
axis(1)
## Close the PDF file
devname = dev.off()
/configfile
/configfiles
outputs
data name=output format=tabular label= Data Frame/
data name=outputFinal format=pdf label= PDF plot/
/outputs
but the second script output is empty. I suspect that the second script is
launched when the output of the first script is not available yet.
Thanks for the help
Chris
___
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/
[galaxy-dev] Apache proxy to Galaxy: mod_rewrite or mod_proxy ?
Hi, Currently, the guide lines for using Apache as a reverse proxy to galaxy are to use the mod_rewrite module and the rewrite rules as explained in the galaxy wiki. I was wondering whether anybody has tried to use mod_proxy, mod_proxy-http instead, with proxypass and proxypassreverse directives ? any technical limitations ? could it be more efficient in a production configuration ? Thanks for the info Chris -- ¡ Note that my email address has changed ! ¡ Please update your records with ! ¡ *christophe.antoniew...@snv.jussieu.fr*christophe.antoniew...@snv.jussieu.fr! -- Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biolologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.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/
Re: [galaxy-dev] Problem of global env $PATH when using galaxy in daemon mode in ubuntu
Hi everybody,
I figured out the problem. Here is our solution, inspired from
http://serverfault.com/questions/139970/how-to-tell-start-stop-daemon-to-update-home-and-user-accordingly-to-chuid-p?answertab=active#tab-top,
which may help others:
In the galaxy.debian-init script provided by James Casbon, a line may be
added after the variable assignments and before invoking the
start-stop-daemon command:
export
PATH=${PATH:+$PATH:}/home/galaxy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin
whose purpose is to populate the galaxy $PATH environmental variable, as it
turns out that the start-stop-daemon, even as galaxy user, does not pass
through the galaxy shell, the .profile conf file, etc...
Everything seems to works fine now and we have Galaxy running as a service.
Chris
2012/8/25 Christophe Antoniewski droso...@gmail.com
Hi everybody,
I am getting troubles when I try running our galaxy instance as a daemon
service in ubuntu, using the procedure provided by James Casbon and
available in the /contrib galaxy directory (briefly, installing
the galaxy.debian-init in the /etc/init.d directory)
Everything is OK, *except* that third party softwares that are installed
in /bin of the galaxy home directory fail.
I suspect a problem of $PATH when the service is launched with the command
:
start-stop-daemon --chuid $USER --group $GROUP --start --make-pidfile \
--pidfile $PIDFILE --background --chdir $DIR --exec $PYTHON
-- $OPTS;
in the James bash script.
However, R scripts for instance are run correctly.
Taking this observation into account, we added /home/galaxy/bin in the
/etc/environment
unfortunately without success.
Any advices for fixing this irritating bug is welcome !
Chris
___
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/
[galaxy-dev] Problem of global env $PATH when using galaxy in daemon mode in ubuntu
Hi everybody, I am getting troubles when I try running our galaxy instance as a daemon service in ubuntu, using the procedure provided by James Casbon and available in the /contrib galaxy directory (briefly, installing the galaxy.debian-init in the /etc/init.d directory) Everything is OK, *except* that third party softwares that are installed in /bin of the galaxy home directory fail. I suspect a problem of $PATH when the service is launched with the command : start-stop-daemon --chuid $USER --group $GROUP --start --make-pidfile \ --pidfile $PIDFILE --background --chdir $DIR --exec $PYTHON -- $OPTS; in the James bash script. However, R scripts for instance are run correctly. Taking this observation into account, we added /home/galaxy/bin in the /etc/environment unfortunately without success. Any advices for fixing this irritating bug is welcome ! Chris ___ 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/
[galaxy-dev] wrapping qvalue in Galaxy
Hi, I am trying to wrap the qvalue R package in a script (as I have already done for a dozen), but this time I have repeatedly the same error *In fun(libname, pkgname) : no DISPLAY variable so Tk is not available* or *Loading Tcl/Tk interface ... done* (and red, desperately red box). I already had this type of bugs and fixed them by using the suppressWarnings or suppressMessages R methods. But this time, no way. I really don't need the Tcl/Tk interface and I am not using it with qvalue... frustrating. (my code run into R in command lines like a charm) Any clue to shut off Galaxy and get this miserable pvalue vector output ? Christophe PS. I browsed the net, found traces of problems similar to mine, but unfortunately no trace of solutions. ___ 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/
[galaxy-dev] multiple file input not taken into account in workflows
Hi We recently deployed a new galaxy instance for production, under Apache2 and postgresql. Although I am not familiar with postgresql, I followed the instructions in the wiki and it seems overall to work. However, there is at least an obvious issue with this new instance : when running a workflow with multiple files in input, the job starts well with the first file and proceeds until completion of the whole workflow, then stops, not taking care of the other files defined in the multiple input, and, more irritating, not reporting any bug (at least in the front). The local galaxy instance we've been running for 1 year now under SQlite and the internal web server, is doing well in contrast, so that I suspect a misconfiguration in postgresql, primarily, (I don't really see how Apache could pervert this aspect, but I am not so much a geek so I may be wrong) I tried to find traces of the same issue in the forum but did not find something yet. Any help / suggestion are welcome Cheers -- Christophe ___ 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/
Re: [galaxy-dev] multiple file input not taken into account in workflows
Dannon, This is so great to get a meanful answer 12 min after my post. Thank you ! Chris Le lundi 9 janvier 2012, Dannon Baker dannonba...@me.com a écrit : Christophe, This is an issue that was resolved in changeset 6368:52de9815a7c4. The changeset hasn't made it into galaxy-dist yet, which I assume you're using, but that should happen very soon. You could wait for the update, or if you'd like, you can pull the changes directly from galaxy-central and everything should work fine. Thanks, Dannon On Jan 8, 2012, at 7:21 PM, Christophe Antoniewski wrote: Hi We recently deployed a new galaxy instance for production, under Apache2 and postgresql. Although I am not familiar with postgresql, I followed the instructions in the wiki and it seems overall to work. However, there is at least an obvious issue with this new instance : when running a workflow with multiple files in input, the job starts well with the first file and proceeds until completion of the whole workflow, then stops, not taking care of the other files defined in the multiple input, and, more irritating, not reporting any bug (at least in the front). The local galaxy instance we've been running for 1 year now under SQlite and the internal web server, is doing well in contrast, so that I suspect a misconfiguration in postgresql, primarily, (I don't really see how Apache could pervert this aspect, but I am not so much a geek so I may be wrong) I tried to find traces of the same issue in the forum but did not find something yet. Any help / suggestion are welcome Cheers -- Christophe ___ 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/ -- Christophe Antoniewski 1 rue du Dahomey 75011 Paris +33 6 68 60 51 50 ___ 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/
