pymol 0.99rev8 is out since January. Version bump should be in order. The code for this release is available from svn repository, it can be checked out as svn export -r 2805 https://svn.sourceforge.net/svnroot/pymol/branches/b099/pymol pymol-0.99rev8 I hope this can be integrated into ebuild, or that ebuild would ask first for the source code to be downloaded from svn repository. The code compiles with pymol-0.99_rc6-r2.ebuild (only patch needs to be updated) and seems to run OK. Reproducible: Always
SVN ebuilds are discouraged, and I personally don't like the direction Mr. Delano seems to be taking the project. There's nothing wrong with making a buck, but his educational access forms are ridiculous.
I also do not like current DeLano Scientific's current policies and that is why we should use free source code available from svn repository. The svn link is to the tagged code, which should not change. Alternatively, maybe the code can be hosted on some gentoo server, pymol code is free to redistribute.
Hmm .. live SVN ebuilds are discouraged, because they give irreproduceable results. But an SVN ebuild of a specific revision should be fine.
(In reply to comment #3) > Hmm .. live SVN ebuilds are discouraged, because they give irreproduceable > results. But an SVN ebuild of a specific revision should be fine. > Yes, the svn "link" is to the revision 2805, so I think it should be OK. Now, can the code be checked out from svn automatically from ebuild?
Yes, it can. For a look at how it can be implemented see here: http://overlays.gentoo.org/dev/dberkholz/browser/sci-chemistry/pymol/pymol-9999.ebuild
(In reply to comment #5) > Yes, it can. > For a look at how it can be implemented see here: > http://overlays.gentoo.org/dev/dberkholz/browser/sci-chemistry/pymol/pymol-9999.ebuild > Very cool, I will probably use this in my overlay. But for official portage tree, is there a way to specify svn revision number?
Just fiddle with ESVN_UPDATE_CMD in the ebuild. The default is "svn update" so you need to get the revision number into there.
Created attachment 117122 [details] pymol 0.99rc8 ebuild Suggested ebuild
Created attachment 117123 [details, diff] patch for pymol 0.99 rc8
Created ebuild and patch for pymol 0.99rc8. Note that patch pymol-0.99_rc8-data-path.patch was updated, it has to include mutagenesis.py. Seems to work fine on my machine. Please test it and add it to the portage.
Okay, I've put pymol-0.99_rc8 in the science overlay if anybody wants to fiddle with it. I'll add it to portage in a week or so... Thanks hodak!
i could not install pymol because it depends on media-libs/glut. but media-libs/glut is blocked by media-libs/freeglut. i changed media-libs/glut to virtual/glut in DEPEND and pymol works fine on my computer with freeglut. so maybe you could consider to depend on virtual/glut instead.
I seem to recall there was a problem with freeglut, and for that reason glut was preferred. Cursory searches don't turn up anything but I vaguely remember pymol failing for me with freeglut. Does anyone have something more concrete?
it's in the ChangeLog - Sept 19 2006 http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-chemistry/pymol/ChangeLog?rev=1.20 I'll try freeglut when I get time, but that won't be for several days...
i've checked it again. no messages, accelerated rendering works fine. my system is mostly stable x86, ecxept the ati-drivers. but i also had never trouble with pymol and freeglut before.
With freeglut, pymol couldn't obtain a direct rendering context.
Okay, I can't comment on the "direct rendering context" issue, but what I noticed (by eyeballing it) was about 20% better performance with glut over freeglut. My test consisted of loading up the biggest pdb I could find in short order (2.1M - 1SG5.pdb) and playing around with it. Lag was evident with freeglut that wasn't there with glut. No errors were thrown, but regardless I think we should keep the dependency on media-libs/glut.
