Menu
▾
▴
#4867 pymol-py.-1.8.5.0-1
closed-accepted
nobody
5
2017-02-11
2016-12-20
No
Update the pymol-py package to the current 1.8.5.0 release at r4165 using the Info file changes...
Index: pymol-py.info
===================================================================
RCS file: /cvsroot/fink/dists/10.9-libcxx/stable/main/finkinfo/sci/pymol-py.info,v
retrieving revision 1.5
diff -u -r1.5 pymol-py.info
--- pymol-py.info 30 Aug 2016 22:37:46 -0000 1.5
+++ pymol-py.info 20 Dec 2016 12:03:55 -0000
@@ -1,13 +1,13 @@
Info2: <<
Package: pymol-py%type_pkg[python]
-Version: 1.8.3.2
+Version: 1.8.5.0
Revision: 1
UseMaxBuildJobs: false
Maintainer: None <fink-devel@lists.sourceforge.net>
Type: python (2.7 3.4 3.5)
-# r4160
+# r4165
Source: mirror:sourceforge:fink/pymol-%v-src.tar.bz2
-Source-MD5: 8c18b689d95b9a1e76e3efbfbb754816
+Source-MD5: 2161f1a063872a57145a484fa8573971
Source2: http://www.weizmann.ac.il/ISPC/eMovie.py
Source2-MD5: 832252d4cee1ba88d50a35681b5ecd4b
Source3: http://www.weizmann.ac.il/ISPC/eMovie_rigimol.inp
@@ -113,8 +113,8 @@
DescPackaging: <<
The tarball used for this version was created in accordance to the BSD
license of pymol using the following instructions...
- svn -r4160 co https://svn.code.sf.net/p/pymol/code/trunk/pymol pymol-1.8.3.2
- tar --exclude=.svn -jcvf pymol-1.8.3.2-src.tar.bz2 pymol-1.8.3.2
+ svn -r4165 co https://svn.code.sf.net/p/pymol/code/trunk/pymol pymol-1.8.5.0
+ tar --exclude=.svn -jcvf pymol-1.8.5.0-src.tar.bz2 pymol-1.8.5.0
Added eMovie.py plug-in manually. Commented out line that opens the window for eMovie by
default every time pymol is started as this is annoying behavior. eMovie is activated via
the plugin menu.
Tested on 10.11 with 'fink -m' and requires the fink mirrors to be populated with a source tarball generated wtih the commands...
svn -r4165 co https://svn.code.sf.net/p/pymol/code/trunk/pymol pymol-1.8.5.0
tar --exclude=.svn -jcvf pymol-1.8.5.0-src.tar.bz2 pymol-1.8.5.0
The changes since 1.8.3.2 are...
r4165 | speleo3 | 2016-12-14 14:07:39 -0500 (Wed, 14 Dec 2016) | 7 lines
molfile plugins, fetch URLs, ...
- update molfile plugins to VMD version 1.9.3
- fetch 2fofc/fofc: update URLs, EDS will retire in 2017
- fix sf#102 pseudoatom multi-state problem
- editor.attach_amino_acid: fix PRO/N geometry
r4164 | speleo3 | 2016-12-05 14:04:04 -0500 (Mon, 05 Dec 2016) | 18 lines
1.8.5.0 (unstable/experimental)
- avoid selection keyword name conflicts, append underscore
- load: allow format=plugin (by extension) and format=plugin:PLUGIN (with PLUGIN being a molfile plugin identifier)
- load format "vdb": VIPERdb PDB variant with retain_order=1
- load/load_traj: guess trajectory object
- fetch
- new setting "fetch_type_default"
- type=mmtf: fetch MMTF format
- type=2fofc/fofc: get spacegroup from PDBe API
- update download URLs
- new setting: editor_auto_measure
- new default: ray_transparency_oblique_power=4.0
- "update" command: support "current state" (-1)
- alter elem -> update protons and vdw
- don't allow "import cmd" (corrupts PyMOL namespace)
- support "python -m pymol" to launch PyMOL
r4163 | speleo3 | 2016-10-18 06:37:13 -0400 (Tue, 18 Oct 2016) | 2 lines
backport C++11 features for gcc-4.5
r4162 | speleo3 | 2016-10-05 11:23:46 -0400 (Wed, 05 Oct 2016) | 2 lines
1.8.4.0
r4161 | speleo3 | 2016-09-26 15:49:55 -0400 (Mon, 26 Sep 2016) | 6 lines
1.8.3.3 (unstable/experimental)
- pse_export_version: legacy scenes support
- use ignore_case setting with set_name command
- setup.py: detect anaconda prefix
Info file changes for pymol-py.-1.8.5.0-1
Revised patch for pymol-py-unused.patch
I got MD5=67752b321923ce89d432dfbbe097a66a for the tarball I created by that method. I don't know the details of the checkout process, if there are expected to be such variations and the MD5 in the .info needs to be set once we have a tarball.
Do you have a place you can host the tarball yourself (which gives us a stable MD5) long enough for the master mirror to pick it up (or for us to manually transfer it)?
Given the upstream is sf.net SVN, isn't there a way to have that web service generate a snapshot, which we could use as a stable Source URL (if it's indeed stable) or at least to get a fix on the MD5 while we re-host it?
Use 'Download Snapshot' link to auto-generate tarball and support python 3.6.
Tested on 10.11 with 'fink -m'
Info file changes for pymol-py.-1.8.5.0-1 using 'Download Snapshot' link to auto-generate tarball and support python 3.6.
Python 3.6 support requires...
https://sourceforge.net/p/fink/package-submissions/4870/
https://sourceforge.net/p/fink/package-submissions/4871/
https://sourceforge.net/p/fink/package-submissions/4872/
It appears that sourceforge has broken their previous method of deliverying specific svn revisions as a tarball.
The behavior of the upstream link for generating the zip archives must clear the cached copies routinely and has some really odd behavior. I went to https://sourceforge.net/p/pymol/code/HEAD/tree/ and clicked on the Download Snapshot link. This lead to a web page with the meassage "We're having trouble finding that snapshot. Would you like to resubmit?" but then proceeded to download the tarball from https://sourceforge.net/code-snapshots/svn/p/py/pymol/code/pymol-code-4166-trunk.zip anyway. So I assume you have to kick the upstream server to manually regenerate the desired tarball and make sure the fink mirrors start caching it before the upstream sourceforge servers clear it.
OK. I was able kickstart the tarball creation (for r4165) using from the web page and then immediately told fink to fetch the snapshot and it worked. But the checksums are different.
Probably because file timestamps are based on tarball generation and not on file creation/modification in the repository.
Are you sure it is really creating a tarball for r4165 and not r4166? As far as I can tell, the pymol svn web interface only seems to generate tarballs for the most current commit in pymol trunk. So if we want to use upstream to generate the tarball, it seems the best we can do is generate the tarball for the current svn commit and immediately use that to populate the fink mirrors for further use.
Yes, I made sure I was at r4165. From
https://sourceforge.net/p/pymol/code/HEAD/tree/, click"History", then[r4165], then"Browse code at this revision", and that gives me apymol-code-r4165-trunk.ziptarball.Also, I'm getting this error in InstallScript:
eMovie.py was downloaded and is available at
/sw/build.build/pymol-py27-1.8.5.0-1/eMovie.py. Thecpcommand needs to be../../eMovie.pybecause you are one directory deeper thanks to theSourceDirectory:field.Update info file change to r4166 and fix path to eMovie.py and eMovie_rigimol.inp with...
Tested on 10.12 with 'fink -m' for python 2.7 variant.
Made a fresh r4166 remote tarball and commmitted. Let's hope the sourcedist mirrors are faster than SF's cache clearing.