Re: [COOT] Which binaries for Fedora release 19(Schrödinger’s Cat)
If you'd like, it is available in the official fedora repos (the stable releases, anyway). Just do: yum install coot (this also works for pymol, BTW) Regards, Tim On Fri, Jul 25, 2014 at 9:17 AM, Mahendra Thapa mahendrabth...@outlook.com wrote: Dear COOT users I am using 'Fedora release 19 (Schrödinger’s Cat)', please suggest me which binaries I need to download to use this COOT software ( http://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/binaries/pre-release/). Any other suggestions/ comments might help me a lot. Thank you, Mahendra Thapa University of Cincinnati,OH,US
Re: [COOT] Coot on Fedora core 17 (error while placing strand)
This is because coot uses guile-gui, which along with guile-gtk is deprecated, no longer has a home and cannot be included/supported with fedora releases. So extensions which depend on it (like add strand) will fail, while those that don't (like add helix) run OK. I'm hoping that eventually these extensions will be updated to use guile-gnome (Paul?). If these functions are important to you, you'll have to use one of Paul's binaries or build it yourself. HTH, Tim On Fri, Mar 1, 2013 at 2:27 PM, Yogesh Gupta yogesh.gu...@mssm.edu wrote: Hello coot users, Recently updated fedora (fedora core 17) and installed coot-0.7 using binary (coot-0.7-1.20120929svn4458.fc17.x86_64). Coot is working normally except in one case when attempted adding a strand, i encountered with following error: ((safe_scheme_command) Error in proc: key: unbound-variable args: (#f Unbound variable: ~S (place-strand-here-gui) #f)) I ran the script (place-strand-here-gui) manually and that too failed with these errors: 1) Error in python scripting panel: coot place-strand-here-gui BL WARNING:: Python error! (Or you attempted to use an invalid guile command...) Python error: name 'place' is not defined type 'exceptions.NameError' coot 2) Error shown in coot terminal window: Read OK: /usr/share/coot/reference-structures/1h97.pdb INFO:: SSE status was OK has 0 sheets Strand addition failure: message: Not Done Also, there was another error at the beginning in coot terminal: load coot-utils.scm (Error in proc: misc-error args: (#f ~A ~S (no code for module (os process)) #f)) I updated guile package but that did not help. Any suggestions on how to fix this? I thank you in advance. Yogesh
Re: [COOT] clean install on RHEL 6.2
coot should be available via yum (albeit 0.6.2) - if there is a problem with the el package, file a bug report - or feel free to use the rpm file as an alternative guide to building it: http://pkgs.fedoraproject.org/gitweb/?p=coot.git HTH, Tim On Wed, Feb 8, 2012 at 12:39 PM, Tim Gruene t...@shelx.uni-ac.gwdg.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Install the developer packages of gtk-2.0 and glib-2.0 !?!? Sorry for an obvious suggestion but you don't say whether or not you've deon that. Tim On 02/08/2012 09:10 PM, Bernhard Rupp (Hofkristallrat a.D.) wrote: Dear Cootsies, following Paul's advice I started to autobuild coot using http://lmb.bioch.ox.ac.uk/coot/build-install-coot-from-scratch.html It is a little bit like whacking hamsters - it needs swig, which needs pcre... Ok then it gets going, but an error appears 2012-02-08 10:45:46 (67.0 KB/s) - ?/root/coot/autobuild/sources/guile-gtk-2.1.tar.gz? saved [781985/781985] awk: cmd. line:1: fatal: cannot open file `/usr/include/gtk-2.0/gtk/gtkversion.h' for reading (No such file or directory) which seems to be a guile version conflict and rears its ugly head when upon ./config make from the newly created package I get checking for GLIB... configure: error: Package requirements (glib-2.0) were not met: No package 'glib-2.0' found I think these problems are connected and I wonder how they can be fixed? Best regards, BR - Bernhard Rupp 001 (925) 209-7429 +43 (676) 571-0536 b...@ruppweb.org hofkristall...@gmail.com http://www.ruppweb.org/ - No animals were hurt or killed during the production of this email. - - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPMt1xUxlJ7aRr7hoRAuvuAJ96MVx/9Ue2XzyrNOduqijavSdklwCfaein d7tEFjbWDByBZrOogaAy8N0= =gPNG -END PGP SIGNATURE-
Re: [COOT] Fedora 14 update kills Coot
On Fri, 9 Sep 2011 14:12:37 -0400 David Schuller dj...@cornell.edu wrote: A friend updated software on his Fedora 14 workstation within the last couple days, and now Coot and pyMol both fail to work. Coot complains that it can find neither the double-buffered visual nor a single-buffered visual. Has anyone else encountered this (yet)? Which packages are the most likely suspects? I'm using both on fedora 15 without problems. Your error message suggests an issue with opengl - are the appropriate drivers/modules available? glxinfo | grep render should say something like: direct rendering: Yes OpenGL renderer string: GeForce GTS 450/PCI/SSE2 Regards, Tim -- - Tim Fenn f...@stanford.edu Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room S221 Stanford, CA 94305-5432 Phone: (860) 782-1495 Fax:(650) 724-4021 -
Re: [COOT] coot on fedora 14 with selinux enabled
On Mon, 11 Apr 2011 10:26:32 -0400 Leonid Flaks fl...@bnl.gov wrote: The proper way might be to compilelink on a FC14 machine. But that boils down to the question for which platforms there have to be separate builds ... have you counted the existing ones? There is a version of coot available as a part of Fedora 14 distribution. Unfortunately it was built some time ago and is rather old on the scale of how fast this program is moving both in fixing bugs and introducing new features. I recently updated the F14 (and upcoming F15) builds to SVN 3442, so a yum update should fix that. Unfortunately, coot still depends on guile-gtk, so there are a few broken scripts. I've pinged Paul about this. In short - this library has a potential security issue in the form it is distributed. If security is your priority, use the fedora packages. If you need bleeding edge, use the nightly builds (caveat emptor, etc, etc). Regards, Tim -- - Tim Fenn f...@stanford.edu Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [COOT] coot stopped working after fedora 14 install
On Fri, 11 Mar 2011 20:41:16 + Alex Soares soa...@bnl.gov wrote: We upgraded to fedora 14, and the built in coot that is in fedora 14 does not work properly. We have ccp4 6.1.3. Error when try to mutate residue range: (mutate-residue-range 0 A 1 2 AA) ((safe_scheme_command) Error in proc: key: unbound-variable args: (#f Unbound variable: ~S (mutate-residue-range) #f)) (update-go-to-atom-window-on-changed-mol 0) This works for me - maybe COOT_SCHEME_DIR was changed somehow, or is being overwritten by your ccp4 install? Error when try to open mtz file with no phases in it: Error in proc: key: unbound-variable args: (#f Unbound variable: ~S (refmac-for-phases-and-make-map) #f)) (calc-phases-generic /img03/data1/pxuser/staff/Soares_x29_Mar11/test_3/1/Solve/output.mtz) Error when try to run refmac: sys:1: GtkWarning: IA__gtk_label_set_text: assertion `GTK_IS_LABEL (label)' failed /usr/bin/coot: line 56: 28477 Segmentation fault (core dumped) $coot_real $* ERROR: no code for module (gtk gdk) both of these are known issues that (I think) Paul has changed/fixed in later builds that don't require guile-gtk/guile-gui (since they're deprecated packages that fedora won't support). I'll try to have a new build available soon. If its really critical stuff, you may want/need to stick with Paul's builds for now. Hope this helps! -Tim -- - Tim Fenn f...@stanford.edu Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [COOT] coot startup error
On Wed, 17 Nov 2010 10:30:40 -0500 Gerwald Jogl gerwald_j...@brown.edu wrote: Don't know if anyone has already observed this: (Fedora Core 14 x86_64, latest coot package installed, I love the FC14 coot package, many thanks to the person who compiles it for FC14!!) Glad it helps! Coot works fine until you set your preferences to not show startup tips. On next start you get the following: INFO:: loading preferences file /home/jogl/.coot-preferences/coot-preferences.scm (set-filter-fileselection-filenames 1) (set-sticky-sort-by-date) (set-colour-map-rotation-on-read-pdb 21.00) (set-colour-map-rotation-on-read-pdb-c-only-flag 1) (set-density-size 10.00) (set-swap-difference-map-colours 0) (set-active-map-drag-flag 1) Backtrace: In /home/jogl/.coot-preferences/coot-preferences.scm: 60: 0* (no-coot-tips) /home/jogl/.coot-preferences/coot-preferences.scm:60:1: In expression (no-coot-tips): /home/jogl/.coot-preferences/coot-preferences.scm:60:1: Unbound variable: no-coot-tips ERROR: no code for module (gtk gdk) Thats probably a problem for me to fix. It might be worthwhile to file a bugzilla report against coot, I'll automatically get emailed/ccd. Did this happen in F13? -Tim -- - Tim Fenn f...@stanford.edu Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
[COOT] coot for fedora
coot is available for testing in the official fedora 13 repo: yum --enablerepo=updates-testing coot coot-doc after some testing (feedback appreciated!), it will be pushed to stable - most likely in a week or so. From there on out, it will be updated with Paul's stable releases. Many thanks to Paul, Kevin and Bill Scott for helping get to this stage! -Tim -- - Tim Fenn f...@stanford.edu Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [COOT] use of RPATH in coot libraries
On Thu, 28 May 2009 23:45:24 -0500 Johan Hattne johan.hat...@utsouthwestern.edu wrote: On 05/27/09 17:28, Matt Harrington wrote: I'm building an RPM from this: http://www.ysbl.york.ac.uk/~emsley/software/binaries/stable/coot-0.5.2-binary-Linux-x86_64-centos-5-gtk2.tar.gz and rpmbuild fails because of invalid RPATHs: snip/ I can circumvent this error by building like this: QA_RPATHS=$[ 0x0001|0x0002 ] rpmbuild -ba coot.spec However, I was wondering if there's a better way than to just ignore this. Perhaps RPATHs could be removed entirely from the upstream build? Couldn't this, perhaps, be fixed using for instance chrpath (disclaimer: I've never used it myself)? I suppose even if the rpaths were removed by upstream, your problem wouldn't go away. I am by no means an expert in these issues, but I firmly believe in correct rpaths, or runpaths, or install_names, or whatever they're called. IMHO, subsequent attempts at mending dynamic linking using LD_LIBRARY_PATH and friends often yield situations which could make grown men cry. rpath and LD_LIBRARY_PATH are both Evil Things that need to die a horrible, painful death. Libraries should go in a standard, non-hard-coded location or use a custom config file in /etc/ld.so.conf.d/ or whatever your *nix flavor uses. Full stop. Both debian and fedora/RH either strictly forbid it or give you evil stares. I'm not sure if this will help: http://www.stanford.edu/~fenn/packs/coot-0.5.2-3.fc11.src.rpm but you'll need the dependencies as well (which distribution are you using?) or tweak the spec file like so: %configure sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool HTH, -Tim -- - Tim Fenn f...@stanford.edu Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [COOT] problem in coot installation in ubuntu
On Wed, 12 Nov 2008 09:03:34 + Kevin Cowtan [EMAIL PROTECTED] wrote: Secondly, if for some reason you do want to build your own (you want to make changes to the code???), then are you using the build-it-gtk2-simple script? http://strucbio.biologie.uni-konstanz.de/ccp4wiki/index.php/COOT#Installation_from_source_code Building coot without this script requires days or weeks of messing around with dependencies. With this script it is usually pretty easy. Why does coot require a 3000 line hand written shell script to set up the build process? -Tim -- - Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [COOT] Fedora 8 binary core dumps - please help
On Fri, 17 Oct 2008 16:55:17 -0700 Scott Classen [EMAIL PROTECTED] wrote: Hello, Desktop effects are NOT turned on. ccp4i 6.0.2 works fine. I just tried the latest nightly and that didn't work either coot-0.5.1-pre-1-revision-1502-binary-Linux-i386-fedora-8-python-gtk2.tar.gz I have a hunch this has something to do with my graphics card. I have an NVIDIA card (GeForce FX 5200) I've installed the nvidia linux drivers NVIDIA Driver Version 169.12 Most likely its a xorg thing - can you post your xorg.conf? Did you check the xorg log for errors? Did you use the nvidia installer script, or a pre-built binary for your distribution? I do recall there being problems with nvidia's driver and the composite extension that would cause this sort of thing (since GLX gets disabled if there is a conflict), you may want to check that the following is in your xorg.conf: Section Extensions Option Composite Disabled EndSection -Tim -- - Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [COOT] can coot link to fftw3?
On Tue, 2 Sep 2008 07:27:17 -0700 William G. Scott [EMAIL PROTECTED] wrote: Hi Kevin: My problem is this: If coot (the binary itself) links to fftw v. 2.1.5, it crashes, reporting a memory conflict error, upon trying to calculate a map. (This happens whether I link to dynamic or static libraries, contrary to my previous report to Paul.) If coot links to fftw v. 2.0.7, supplied by ccp4, it works properly. try compiling clipper with -fno-strict-aliasing, or drop the optimization flags to -O1 or lower. HTH, Tim -- - Tim Fenn [EMAIL PROTECTED] Stanford University, School of Medicine James H. Clark Center 318 Campus Drive, Room E300 Stanford, CA 94305-5432 Phone: (650) 736-1714 FAX: (650) 736-1961 -
Re: [COOT] line 124: 4123 Segmentation fault
On Wed, 2 Jul 2008 22:34:04 +0100 rebecca page [EMAIL PROTECTED] wrote: Dear Coot Community, I recently installed updates on my linux box which is running fedora core 9.0. Now, when I try to run coot, I get the following error: /usr/local/programs/Coot/coot-Linux-i386-fedora-8/bin/coot: line 124: 4123 Segmentation fault $coot_real $* Gtk-WARNING **: Failed to load module libgnomebreakpad.so: libgnomebreakpad.so: cannot open shared object file: No such file or directory coot-exe: /usr/local/programs/Coot/coot-Linux-i386-fedora-8/bin/coot-real coot-version: /usr/local/programs/Coot/coot-Linux-i386-fedora-8/bin/coot-real core: #f No core file found. No debugging I think this has to do with a known bug: https://bugzilla.redhat.com/show_bug.cgi?id=389921 the solution is posted there. -Tim
