MGLTools is a software developed at the Molecular Graphics Laboratory (MGL) of The Scripps Research Institute for visualization and analysis of molecular structures. Short description and demo of its three main applications are given below. AutoDockTools is graphical front-end for setting up and running AutoDock - an automated docking software designed to predict how small molecules, such as substrates or drug candidates, bind to a receptor of known 3D structure. PMV is a powerful molecular viewer that has a number of customizable features and comes with many pluggable commands ranging from displaying molecular surfaces to advanced volume rendering. Vision is a visual-programming environment in which a user can interactively build networks describing novel combinations of computational methods, and yielding new visualizations of their data without actually writing code. Reproducible: Always
Created attachment 147900 [details] mgltools-1.5.1.ebuild The ebuild works fine thought I am not shure about the license handling and the pkg_postinst() { python_mod_cleanup "${MGLPATH}" python_mod_optimize "${MGLPATH}" } kind regards Bjoern
Ah and the original installer is creating a file called "sitecustomize.py" which lives in /usr/lib/python2.5/site-package/ mglroot = '/usr/lib/python2.5/site-packages'# specify mglroot here import sys, os path = os.path.join(mglroot, "MGLToolsPckgs") sys.path.insert(0,path) from Support.path import setSysPath setSysPath(path) #sys.path.insert(0,'.') I didn't recreate this file cause grepping the sourcecode showed only one refference to this file. And this refference is the following: grep -R "sitecustomize" * Support-1.5.1/Support/CVS/Entries:/sitecustomize.py/1.3/Tue Nov 13 23:23:27 2007/-kkv/ Support-1.5.1/Support/CVS/Entries.Extra:/sitecustomize.py///
- Remove the pkg_setup(). Ebuilds should install without interaction, unless the license requires it and this one doesn't. - "proprietary" is not a valid license, we need the license in plain text to put it into the license directory. Attaching the file would be nice.
Created attachment 147902 [details] mgltools-1.5.1.ebuild remove pkg_setup() and proprietary.
Created attachment 147903 [details] mslib-license.txt mslib-license.txt
Created attachment 147904 [details] stride-license.txt stride-license.txt
Created attachment 147906 [details] UTPackages-license.txt UTPackages-license.txt
Created attachment 147909 [details] mgltools-1.5.1.ebuild some more small fixes
What about stride? There is an ebuild for that in the portage. Could they coexist or should stride block mgltools and vice versa? Does this provide msms-bin function? This would make this bug #209161 needless.
(In reply to comment #9) > What about stride? There is an ebuild for that in the portage. Could they > coexist or should stride block mgltools and vice versa? Does this provide > msms-bin function? This would make this bug #209161 needless. > Thats a good question! I have to take a closer look at this. Jet I don't know where mgltools pack is loocking for msms and stride but it looks like the bundled versions are installed into /usr/lib/python2.5/site-packages/MGLToolsPckgs/. If the tools are not loocking in $PATH for these packages we would have to patch the src to check for msms and stride in another location... thougth the bundled packages will not interfere with the gentoo packages (IMHO) kind regards Bjoern
new versions can be found in my svn overlay: http://svn.olausson.de/molmod/trunk/sci-chemistry/
Hi folks, Thanks much for your work. So far I only had a chance to briefly look a the package. It seems to me that the three components (AutoDockTools, PMV, Vision) should really be split into three separate components if possible. They look fairly unrelated in their respective capabilities and I could see users wanting just one of them without ever using the others. Any thoughts? cheers, Markus
(In reply to comment #12) > Hi folks, > > Thanks much for your work. So far I only had a > chance to briefly look a the package. It seems > to me that the three components (AutoDockTools, > PMV, Vision) should really be split into three > separate components if possible. They look fairly > unrelated in their respective capabilities and > I could see users wanting just one of them without > ever using the others. Any thoughts? > > cheers, > Markus > I am unshure about the splitting. It is distributed as package and there is no option to split it up. ADT is build up on PMV and I am unshure wether ADT is just a plugin for PMV. One would have to find out which of those python tools is used by which application (ADT PMV VISION). I will take a look into this. regards Bjoern
Hi Bjoern, Thanks for looking into this. If splitting is impossible or turns out to be a pain, no problem. At a first glance the packages simply looked different enough to me to at least consider splitting them. Thanks, Markus
(In reply to comment #14) > Hi Bjoern, > > Thanks for looking into this. If splitting is impossible > or turns out to be a pain, no problem. At a first glance > the packages simply looked different enough to me to > at least consider splitting them. > > Thanks, > Markus > I guess If someone had enough time the package could be split up in the following packages as they are, as you can see, all packed seperate: AutoDockTools-1.5.1.tar.gz bhtree-1.5.1.tar.gz DejaVu-1.5.1.tar.gz geomutils-1.5.1.tar.gz gle-1.5.1.tar.gz mglutil-1.5.1.tar.gz MolKit-1.5.1.tar.gz mslib-1.5.1.tar.gz NetworkEditor-1.5.1.tar.gz opengltk-1.5.1.tar.gz Pmv-1.5.1.tar.gz PyAutoDock-1.5.1.tar.gz PyBabel-1.5.1.tar.gz pyglf-1.5.1.tar.gz QSlimLib-1.5.1.tar.gz scenario-1.5.1.tar.gz sff-1.5.1.tar.gz stride-1.5.1.tar.gz Support-1.5.1.tar.gz symserv-1.5.1.tar.gz UTpackages-1.5.1.tar.gz ViewerFramework-1.5.1.tar.gz Vision-1.5.1.tar.gz VisionLibraries-1.5.1.tar.gz Volume-1.5.1.tar.gz WebServices-1.5.1.tar.gz But I have no clue which depends on what. So I would go for a monolitic build. And I guess one would have to patch each of these packages to look for the right path if they are not installed all together in /MGLTools/ dir. Just a guess. regards Bjoern
On amd64 i get this error: >>> /usr/bin/runAdt -> /usr/lib64/python2.5/site-packages/MGLToolsPckgs//runAdt * * ERROR: sci-chemistry/mgltools-1.5.1 failed. * Call stack: * ebuild.sh, line 49: Called pkg_postinst * environment, line 2075: Called python_mod_cleanup 'pkg_postinst' * environment, line 2185: Called die * The specific snippet of code: * [[ ${EBUILD_PHASE} != postrm ]] && die "${FUNCNAME} should only be run in pkg_postrm()"; * The die message: * python_mod_cleanup should only be run in pkg_postrm() * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/sci-chemistry/mgltools-1.5.1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-chemistry/mgltools-1.5.1/temp/environment'. * This ebuild is from an overlay: '/usr/local/portage/' * !!! FAILED postinst: 1 * Messages for package sci-chemistry/mgltools-1.5.1: * * ERROR: sci-chemistry/mgltools-1.5.1 failed. * Call stack: * ebuild.sh, line 49: Called pkg_postinst * environment, line 2075: Called python_mod_cleanup 'pkg_postinst' * environment, line 2185: Called die * The specific snippet of code: * [[ ${EBUILD_PHASE} != postrm ]] && die "${FUNCNAME} should only be run in pkg_postrm()"; * The die message: * python_mod_cleanup should only be run in pkg_postrm() * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/sci-chemistry/mgltools-1.5.1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-chemistry/mgltools-1.5.1/temp/environment'. * This ebuild is from an overlay: '/usr/local/portage/' * I'm use python 2.5
Please try the ebuild from http://svn.olausson.de/molmod You can add this svn as overlay. http://svn.olausson.de/layman_molmod.xml If you still get this bug, let me know. Kind regards Bjoern Olausson
Now it work ;) thanks and good work :)
I will put mgltools-1.5.2-r2.ebuild in my SVN repo tonight. http://svn.olausson.de/molmod Please test and report bugs :-) kind regards Bjoern
It doesn't compile with gcc 4.3: x86_64-pc-linux-gnu-g++ -pthread -DNDEBUG -ftracer -O2 -pipe -g -w -march=native -ftree-vectorize -msse4.1 -funsafe-math-optimizations -fivopts -fmodulo-sched -minline-stringops-dynamically -ftree-loop-im -funswitch-loops -fvect-cost-model -fvariable-expansion-in-unroller -fPIC -DHAVE_CONFIG_H -Isrc/libgfx/include -I/usr/lib64/python2.5/site-packages/numpy/core/include -Isrc/mixkit -c -DHAVE_CONFIG_H -Isrc/libgfx/include -I/usr/lib64/python2.5/site-packages/numpy/core/include -Isrc/mixkit -c src/mixkit/MxCmdParser.cxx -o build/temp.linux-x86_64-2.5/src/mixkit/MxCmdParser.o In file included from src/mixkit/MxCmdParser.h:17, from src/mixkit/MxCmdParser.cxx:13: src/mixkit/MxDynBlock.h: In member function 'void MxDynBlock<T>::room_for(int)': src/mixkit/MxDynBlock.h:38: error: there are no arguments to 'resize' that depend on a template parameter, so a declaration of 'resize' must be available src/mixkit/MxDynBlock.h:38: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) src/mixkit/MxDynBlock.h: In member function 'typename MxBlock<T>::iterator MxDynBlock<T>::end()': src/mixkit/MxDynBlock.h:65: error: there are no arguments to 'begin' that depend on a template parameter, so a declaration of 'begin' must be available src/mixkit/MxDynBlock.h: In member function 'typename MxBlock<T>::const_iterator MxDynBlock<T>::end() const': src/mixkit/MxDynBlock.h:66: error: there are no arguments to 'begin' that depend on a template parameter, so a declaration of 'begin' must be available error: command 'x86_64-pc-linux-gnu-g++' failed with exit status 1 The bottom of http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Name-lookup.html looks useful, if anyone would like to come up with a patch.
The same for me. Not compile with gcc 4.3. running build running build_ext language: c building '_efitlib' extension swigging geomutils/efitlib.i to geomutils/efitlib_wrap.c command: ['swig', '-python', '-o', 'geomutils/efitlib_wrap.c', '-outdir', 'geomutils', 'geomutils/efitlib.i'] swig -python -o geomutils/efitlib_wrap.c -outdir geomutils geomutils/efitlib.i C compiler: x86_64-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -march=k8 -msse3 -O2 -pipe -fPIC creating build creating build/temp.linux-x86_64-2.5 creating build/temp.linux-x86_64-2.5/src creating build/temp.linux-x86_64-2.5/src/efit creating build/temp.linux-x86_64-2.5/geomutils compile options: '-Isrc/efit -I/usr/lib64/python2.5/site-packages/numpy/core/include -I/usr/include/python2.5 -c' x86_64-pc-linux-gnu-gcc: src/efit/efit.c src/efit/efit.c: In function ‘main’: src/efit/efit.c:102: warning: incompatible implicit declaration of built-in function ‘strcpy’ x86_64-pc-linux-gnu-gcc: src/efit/efit_io.c x86_64-pc-linux-gnu-gcc: src/efit/efit_aux.c x86_64-pc-linux-gnu-gcc: src/efit/vec.c x86_64-pc-linux-gnu-gcc: geomutils/efitlib_wrap.c creating build/lib.linux-x86_64-2.5 creating build/lib.linux-x86_64-2.5/geomutils x86_64-pc-linux-gnu-gcc -pthread -shared -Wl,-O1 -march=k8 -msse3 -O2 -pipe build/temp.linux-x86_64-2.5/src/efit/efit.o build/temp.linux-x86_64-2.5/src/efit/efit_aux.o build/temp.linux-x86_64-2.5/src/efit/efit_io.o build/temp.linux-x86_64-2.5/src/efit/vec.o build/temp.linux-x86_64-2.5/geomutils/efitlib_wrap.o -L/usr/lib64 -lm -lpython2.5 -o build/lib.linux-x86_64-2.5/geomutils/_efitlib.so language: c++ building '_geomalgorithms' extension --swig-cpp is deprecated - use --swig-opts=-c++ swigging geomutils/geomalgorithms.i to geomutils/geomalgorithms_wrap.cpp command: ['swig', '-python', '-c++', '-o', 'geomutils/geomalgorithms_wrap.cpp', '-outdir', 'geomutils', 'geomutils/geomalgorithms.i'] swig -python -c++ -o geomutils/geomalgorithms_wrap.cpp -outdir geomutils geomutils/geomalgorithms.i C compiler: x86_64-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -march=k8 -msse3 -O2 -pipe -fPIC creating build/temp.linux-x86_64-2.5/src/geomAlgorithms compile options: '-Isrc/geomAlgorithms -I/usr/lib64/python2.5/site-packages/numpy/core/include -I/usr/include/python2.5 -c' x86_64-pc-linux-gnu-gcc: src/geomAlgorithms/distance.cpp x86_64-pc-linux-gnu-gcc: src/geomAlgorithms/Vector.cpp x86_64-pc-linux-gnu-gcc: src/geomAlgorithms/objfile.cpp src/geomAlgorithms/objfile.cpp: In function ‘bool detectObjFileContent(const char*, char (*)[256], unsigned int*, char (*)[256], unsigned int*, char (*)[256], unsigned int*)’: src/geomAlgorithms/objfile.cpp:29: error: ‘strcpy’ was not declared in this scope src/geomAlgorithms/objfile.cpp:66: error: ‘strcmp’ was not declared in this scope src/geomAlgorithms/objfile.cpp:79: error: ‘strcmp’ was not declared in this scope src/geomAlgorithms/objfile.cpp:111: error: ‘strcmp’ was not declared in this scope src/geomAlgorithms/objfile.cpp: In function ‘bool readObjFileGroup(const char*, const char*, char (*)[256], unsigned int*, float (*)[3], unsigned int*, int (*)[3], unsigned int*, float (*)[2], unsigned int*, int (*)[3], unsigned int*, int*, unsigned int*)’: src/geomAlgorithms/objfile.cpp:199: error: ‘strcmp’ was not declared in this scope src/geomAlgorithms/objfile.cpp:233: error: ‘strcmp’ was not declared in this scope src/geomAlgorithms/objfile.cpp:245: error: ‘strcmp’ was not declared in this scope src/geomAlgorithms/objfile.cpp: In function ‘bool detectObjFileContent(const char*, char (*)[256], unsigned int*, char (*)[256], unsigned int*, char (*)[256], unsigned int*)’: src/geomAlgorithms/objfile.cpp:29: error: ‘strcpy’ was not declared in this scope src/geomAlgorithms/objfile.cpp:66: error: ‘strcmp’ was not declared in this scope src/geomAlgorithms/objfile.cpp:79: error: ‘strcmp’ was not declared in this scope src/geomAlgorithms/objfile.cpp:111: error: ‘strcmp’ was not declared in this scope src/geomAlgorithms/objfile.cpp: In function ‘bool readObjFileGroup(const char*, const char*, char (*)[256], unsigned int*, float (*)[3], unsigned int*, int (*)[3], unsigned int*, float (*)[2], unsigned int*, int (*)[3], unsigned int*, int*, unsigned int*)’: src/geomAlgorithms/objfile.cpp:199: error: ‘strcmp’ was not declared in this scope src/geomAlgorithms/objfile.cpp:233: error: ‘strcmp’ was not declared in this scope src/geomAlgorithms/objfile.cpp:245: error: ‘strcmp’ was not declared in this scope error: Command "x86_64-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -march=k8
whiche one does not compile? mgltools-1.5.2-r2.ebuild or mgltools-1.5.1.ebuild? Thought I have no machine with 4.3, I can't test it right now. Did someone already notify the upstream devs? Kind regards Bjoern
someone did: Summary: Does not build with GCC 4.3 http://mgldev.scripps.edu/bugs/show_bug.cgi?id=988 And there is a patch. Could someone test this patch so I can include it into the ebuild? Kind regards Bjoern
this (In reply to comment #23) > someone did: > > > Summary: Does not build with GCC 4.3 > http://mgldev.scripps.edu/bugs/show_bug.cgi?id=988 > This patch is for autodock not for mgltools :-). Autodock with gcc 4.3 and glib2.8 compile and it work. Is mgltools that not compile. I've post the error, and in particular this affect: src/geomAlgorithms/objfile.cpp: In function When i've time i try to write patch. If you or any can try to write patch is ok:) bye GMR
oh! i've type on google search this : src/geomAlgorithms/objfile.cpp and i've find this: http://lists.alioth.debian.org/pipermail/debian-med-commit/2008-June/001995.html i'm just try this patch when i've time :) Added: trunk/packages/mgltools/geomutils/trunk/debian/patches/gcc-4.3-compat.patch =================================================================== --- trunk/packages/mgltools/geomutils/trunk/debian/patches/gcc-4.3-compat.patch (rev 0) +++ trunk/packages/mgltools/geomutils/trunk/debian/patches/gcc-4.3-compat.patch 2008-06-09 14:50:22 UTC (rev 1995) @@ -0,0 +1,9 @@ +--- geomutils-1.5.1.orig/src/geomAlgorithms/objfile.cpp ++++ geomutils-1.5.1/src/geomAlgorithms/objfile.cpp +@@ -1,5 +1,6 @@ + #include <assert.h> + #include <fstream> ++#include <string.h> + + #include "objfile.h" + But i think that i've try TOO MANY PATCH :) ok.. when i succes i post SUCCES! :) bye
ok...now it compile. Add this patch: ######COPY HERE###### --- /var/tmp/portage/sci-chemistry/mgltools-1.5.2-r3/work/mgltools_source_1.5.2/MGLPACKS/geomutils-1.5.2/src/geomAlgorithms/objfile.cpp.orig 2008-09-01 11:15:03.000000000 +0200 +++ /var/tmp/portage/sci-chemistry/mgltools-1.5.2-r3/work/mgltools_source_1.5.2/MGLPACKS/geomutils-1.5.2/src/geomAlgorithms/objfile.cpp 2008-09-01 11:15:14.000000000 +0200 @@ -1,5 +1,6 @@ #include <assert.h> #include <fstream> +#include <string.h> #include "objfile.h" ######CUT HERE######
I'll fix it today. Thanks for the Patch
Done! Patch and mgltools-1.5.2-r3.ebuild added in SVN, please let me know if it works. http://svn.olausson.de/molmod/trunk/sci-chemistry/mgltools/ Kind regards Bjoern
Tests on my box are positive: x86 gcc4.3 glibc2.6
Here's what I got: x86_64-pc-linux-gnu-g++ -pthread -DNDEBUG -ftracer -O2 -pipe -g -w -march=native -ftree-vectorize -msse4.1 -funsafe-math-optimizations -fivopts -fmodulo-sched -minline-stringops-dynamically -ftree-loop-im -funswitch-loops -fvect-cost-model -fvariable-expansion-in-unroller -fPIC -DHAVE_CONFIG_H -Isrc/libgfx/include -I/usr/lib64/python2.5/site-packages/numpy/core/include -Isrc/mixkit -c -DHAVE_CONFIG_H -Isrc/libgfx/include -I/usr/lib64/python2.5/site-packages/numpy/core/include -Isrc/mixkit -c src/mixkit/MxCmdParser.cxx -o build/temp.linux-x86_64-2.5/src/mixkit/MxCmdParser.o In file included from src/mixkit/MxCmdParser.h:17, from src/mixkit/MxCmdParser.cxx:13: src/mixkit/MxDynBlock.h: In member function 'void MxDynBlock<T>::room_for(int)': src/mixkit/MxDynBlock.h:38: error: there are no arguments to 'resize' that depend on a template parameter, so a declaration of 'resize' must be available src/mixkit/MxDynBlock.h:38: error: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) src/mixkit/MxDynBlock.h: In member function 'typename MxBlock<T>::iterator MxDynBlock<T>::end()': src/mixkit/MxDynBlock.h:65: error: there are no arguments to 'begin' that depend on a template parameter, so a declaration of 'begin' must be available src/mixkit/MxDynBlock.h: In member function 'typename MxBlock<T>::const_iterator MxDynBlock<T>::end() const': src/mixkit/MxDynBlock.h:66: error: there are no arguments to 'begin' that depend on a template parameter, so a declaration of 'begin' must be available error: command 'x86_64-pc-linux-gnu-g++' failed with exit status 1 !!! ERROR: sci-chemistry/mgltools-1.5.2-r3 failed.
mpf... bad news... I'll try to contact the upstream devs. Hold on ;-) kind regards Bjoern
mmmh, actually I couldn't reproduce the bug. mgltools-1.5.2-r3.ebuild Compiles fine on both my x86 and x86_64 systems. kind regards Bjoern
I'm on sys-devel/gcc-4.3.1-r1 and sys-libs/glibc-2.8_p20080602
(In reply to comment #33) > I'm on sys-devel/gcc-4.3.1-r1 and sys-libs/glibc-2.8_p20080602 > Okay, I am on sys-devel/gcc-4.1.2 and sys-libs/glibc-2.6.1 As for now I don't want to upgrade, so if anyone finds a sollution... patches are wellcome ;-) Kind regards Bjoern
I fixed the issue Donnie reported and updated to newest stable. Plus all components are splitted into separate ebuilds. in sci overlay now.
*** This bug has been marked as a duplicate of bug 269885 ***
