Bug 462251 (PyMOL) - Review Request: pymol - python molecular graphics
Summary: Review Request: pymol - python molecular graphics
Keywords:
Status: CLOSED NEXTRELEASE
Alias: PyMOL
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mamoru TASAKA
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 462250
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-09-14 21:00 UTC by Tim Fenn
Modified: 2014-11-06 12:50 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-28 15:41:40 UTC
Type: ---
Embargoed:
mtasaka: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)
gdb log when pymol causes segv (24.22 KB, text/plain)
2008-10-04 19:11 UTC, Mamoru TASAKA
no flags Details
gdb log on segv of rev 3466 (24.29 KB, text/plain)
2008-10-09 08:25 UTC, Mamoru TASAKA
no flags Details

Description Tim Fenn 2008-09-14 21:00:32 UTC
spec url: http://www.stanford.edu/~fenn/packs/pymol.spec
srpm url: http://www.stanford.edu/~fenn/packs/pymol-1.1-1.f8.src.rpm

PyMOL is a molecular graphics system with an embedded Python
interpreter designed for real-time visualization and rapid generation
of high-quality molecular graphics images and animations. It is fully
extensible and available free to everyone via the "Python"
license. Although a newcomer to the field, PyMOL can already be used
to generate stunning images and animations with ease. It can also
perform many other valuable tasks (such as editing PDB files) to
assist you in your research.

Also see:
http://pymol.sourceforge.net/

Comment 1 Mamoru TASAKA 2008-09-26 07:23:31 UTC
Some notes:
* Please also check my comments in bug 462250
* Build failure
  - Your srpm does not build:
    http://koji.fedoraproject.org/koji/taskinfo?taskID=843282
    It seems at least "BuildRequires: libGL-devel" is needed.

* Desktop file
  - If this is GUI application, a proper desktop file must be added:
    https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files

Comment 2 Gianluca Sforna 2008-09-29 07:45:52 UTC
Additional stuff you should consider:

* the %version and %release defines are redundant, since they are filled during build with the "Version" and "Release" tags content.

* Source tag should include the full URI to the package; AFAICT this is not available unless you are paying support to Delano Scientific. If I am correct you will need to create the tarball from upstream SVN, documenting the procedure in the spec file (usually the easiest way is to add a small script to compose the tarball). 

More details about this at:
https://fedoraproject.org/wiki/Packaging/SourceURL

* There is no need to prepare and fill the docs directory, a single line in the files section like:

%doc LICENSE DEVELOPERS README

will do everything for you

* it's the first time I see the sanity check on RPM_BUILD_ROOT before removing it. I can't remember any guideline against it, but I'd avoid it anyway.

Comment 3 Tim Fenn 2008-10-02 00:14:03 UTC
(In reply to comment #1)
> Some notes:
> * Please also check my comments in bug 462250
> * Build failure
>   - Your srpm does not build:
>     http://koji.fedoraproject.org/koji/taskinfo?taskID=843282
>     It seems at least "BuildRequires: libGL-devel" is needed.
> 

fixed.

> * Desktop file
>   - If this is GUI application, a proper desktop file must be added:
>     https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files

done.

> * the %version and %release defines are redundant, since they are filled 
> during build with the "Version" and "Release" tags content.

Done.

> * Source tag should include the full URI to the package; AFAICT this is not
> available unless you are paying support to Delano Scientific. If I am correct
> you will need to create the tarball from upstream SVN, documenting the
> procedure in the spec file (usually the easiest way is to add a small script
> to compose the tarball). 

Done.

> * There is no need to prepare and fill the docs directory, a single line in 
> the files section like:

This was only done since the python setup script does not install the files into RPM_BUILD_ROOT.

> * it's the first time I see the sanity check on RPM_BUILD_ROOT before removing
> it. I can't remember any guideline against it, but I'd avoid it anyway.

removed.

new spec url: http://www.stanford.edu/~fenn/packs/pymol.spec
srpm url: http://www.stanford.edu/~fenn/packs/pymol-1.1-2.f8.src.rpm

Comment 4 Gianluca Sforna 2008-10-02 10:36:25 UTC
(In reply to comment #3)
> > you will need to create the tarball from upstream SVN, documenting the
> > procedure in the spec file (usually the easiest way is to add a small script
> > to compose the tarball). 
> 
> Done.

That's better, but getting sources off the 1.1 branch does not guarantee we can reproduce the build at any random time in the future because the branch will likely be modified by bug fix commits.

You need to locate a suitable revision (possibly, but not necessarily, off the 1.1 branch) and pull that one. I failed to note this also imply you need rename the release tag according to:

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#SnapshotPackages

so the package will be named something like:

pymol-1.1-x.YYYYMMDDsvnREV


> 
> > * There is no need to prepare and fill the docs directory, a single line in 
> > the files section like:
> 
> This was only done since the python setup script does not install the files
> into RPM_BUILD_ROOT.

Yeah, that's normal. But files listed in %doc are picked up from RPM_BUILD_DIR so it will work (I just tested it locally)

> 
> > * it's the first time I see the sanity check on RPM_BUILD_ROOT before removing
> > it. I can't remember any guideline against it, but I'd avoid it anyway.
> 
> removed.

You removed too much ;) %install and %clean section must start with 
rm -rf ${RPM_BUILD_ROOT}
I was suggesting removing just to the check ${RPM_BUILD_ROOT} != "/"


lastly, mock build still fails due to unpackaged egg-info file, please add 
%{python_sitearch}/*egg-info

to %files. Full details at http://fedoraproject.org/wiki/Packaging/Python

Comment 5 Mamoru TASAKA 2008-10-02 17:04:08 UTC
Also,

* Please write the origin of SOURCE1 (if possible write a full URL, or
  write comments how you gained the SOURCE1)
* Remove redundant Requires. python-pwm already Requires python, tkinter
  so these need not be listed on the Requires of this rpm.
* When using or "install" commands add "-p" option to keep timestamps
  on installed files.
* Replace %_usr by %_prefix

Comment 6 Tim Fenn 2008-10-04 03:30:09 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > > you will need to create the tarball from upstream SVN, documenting the
> > > procedure in the spec file (usually the easiest way is to add a small script
> > > to compose the tarball). 
> > 
> > Done.
> 
> That's better, but getting sources off the 1.1 branch does not guarantee we can
> reproduce the build at any random time in the future because the branch will
> likely be modified by bug fix commits.
> 

Fixed.

> 
> > 
> > > * There is no need to prepare and fill the docs directory, a single line in 
> > > the files section like:
> > 
> > This was only done since the python setup script does not install the files
> > into RPM_BUILD_ROOT.
> 
> Yeah, that's normal. But files listed in %doc are picked up from RPM_BUILD_DIR
> so it will work (I just tested it locally)
> 

Ah, I didn't have them listed as %doc before - fixed this.

> > 
> > > * it's the first time I see the sanity check on RPM_BUILD_ROOT before removing
> > > it. I can't remember any guideline against it, but I'd avoid it anyway.
> > 
> > removed.
> 
> You removed too much ;) %install and %clean section must start with 
> rm -rf ${RPM_BUILD_ROOT}
> I was suggesting removing just to the check ${RPM_BUILD_ROOT} != "/"
> 

Whoops - fixed.

> 
> lastly, mock build still fails due to unpackaged egg-info file, please add 
> %{python_sitearch}/*egg-info
> 
> to %files. Full details at http://fedoraproject.org/wiki/Packaging/Python

I followed https://fedoraproject.org/wiki/Packaging/Python/Eggs to properly set up the egg-info files.

new spec url: http://www.stanford.edu/~fenn/packs/pymol.spec
srpm url: http://www.stanford.edu/~fenn/packs/pymol-1.1-3.20080912svn3419.f8.src.rpm

Comment 7 Tim Fenn 2008-10-04 15:09:22 UTC
(In reply to comment #5)
> Also,
> 
> * Please write the origin of SOURCE1 (if possible write a full URL, or
>   write comments how you gained the SOURCE1)

Fixed.

> * Remove redundant Requires. python-pwm already Requires python, tkinter
>   so these need not be listed on the Requires of this rpm.

Fixed.

> * When using or "install" commands add "-p" option to keep timestamps
>   on installed files.

thanks.

> * Replace %_usr by %_prefix

Removed (no longer necessary with some of the changes given above)

the spec and srpm given in https://bugzilla.redhat.com/show_bug.cgi?id=462251#c6 include these changes.

Comment 8 Mamoru TASAKA 2008-10-04 19:11:53 UTC
Created attachment 319472 [details]
gdb log when pymol causes segv

Well, for 1.1-3svn:

* License
------------------------------------------------
Overall license : MIT

contrib/modules/ExtensionClass.LICENSE		ZPLv2.0
contrib/modules/ExtensionClass.c-py152		BSD
contrib/uiuc/plugins/LICENSE			BSD
contrib/uiuc/plugins/molfile_plugin/LICENSE	BSD
layer1/FontTTF.h				Bitstream Vera
layer1/FontTTF2.h				OFL
ov/src/OVRandom.c				BSD
------------------------------------------------
  - The license tag should be "MIT and BSD and ZPLv2.0 and
    Bitstream Vera and OFL".

* Source0
  - Please add revision number of svn also to the name of
    Source0 tarball (i.e. pymol-1.1-20080912svn3419.tar.gz)

* python modules dependency
  - Please check if all python modules related rpms are correctly
    added to Requires.
    * For example chempy/fast/__init__.py contains:
------------------------------------------------
     6  from Numeric import *
     7  from Precision import *
------------------------------------------------
      I guess pymol should have "Requires: python-numeric" (maybe even
      more)
    

* optflags
  - build.log shows:
------------------------------------------------
   226  creating build/temp.linux-i686-2.5/layer5
   227  gcc -pthread -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -fPIC -D_PYMOL_MODULE -D_PYMOL_INLINE -D_PYMOL_FREETYPE -D_HAVE_LIBPNG -Iov/src -Ilayer0 -Ilayer1 -Ilayer2 -Ilayer3 -Ilayer4 -Ilayer5 -I/usr/include/freetype2 -I/usr/include/python2.5 -c ov/src/OVContext.c -o build/temp.linux-i686-2.5/ov/src/OVContext.o -ffast-math -funroll-loops -O3
------------------------------------------------
    Please remove "-ffast-math -funroll-loops -O3". These flags makes
    debugging difficult, or changes calculation precision.

* Document
  - Please also add the following file(s) to %doc
-------------------------------------------------
AUTHORS
-------------------------------------------------

* generic rpmlint issue
-------------------------------------------------
pymol.i386: W: incoherent-version-in-changelog 1.1-3 1.1-3.20080912svn3419.fc10
pymol-debuginfo.i386: W: spurious-executable-perm /usr/src/debug/pymol-1.1/contrib/champ/feedback2.c
pymol-debuginfo.i386: W: spurious-executable-perm /usr/src/debug/pymol-1.1/contrib/champ/feedback2.h
pymol-debuginfo.i386: W: spurious-executable-perm /usr/src/debug/pymol-1.1/contrib/champ/err2.c
-------------------------------------------------
  - Change the %changelog entry like below:
-------------------------------------------------
* Thu Oct 02 2008 Tim Fenn <fenn> - 1.1-3-20080912svn3419
- fix release tag, add egg-info, minor fixes
-------------------------------------------------
  - Fix the permissions of C codes in the tarball to 0644 to suppress
    rpmlint warnings for debuginfo rpm.

* segv
  - By the way for pymol causes segv with
-------------------------------------------------
pymol-1.1-3.20080912svn3419.fc10.i386
mesa-libGL-7.1-0.37.fc10.i386
python-2.5.2-1.fc10.i386
-------------------------------------------------
    when just launching pymol.
    gdb log attached.

Comment 9 Mamoru TASAKA 2008-10-04 19:16:33 UTC
By the way output from pymol seems to be saying that this is a pre-version
of 1.1. In such cases please follow:

https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages
i.e. release number should be 0.3.20080912svn3419%{?dist}, for example.

Comment 10 Tim Fenn 2008-10-06 18:57:46 UTC
(In reply to comment #8)
>   - The license tag should be "MIT and BSD and ZPLv2.0 and
>     Bitstream Vera and OFL".
> 

Done.

> * Source0
>   - Please add revision number of svn also to the name of
>     Source0 tarball (i.e. pymol-1.1-20080912svn3419.tar.gz)
> 

Done.

> * python modules dependency
>   - Please check if all python modules related rpms are correctly
>     added to Requires.
>     * For example chempy/fast/__init__.py contains:
> ------------------------------------------------
>      6  from Numeric import *
>      7  from Precision import *
> ------------------------------------------------
>       I guess pymol should have "Requires: python-numeric" (maybe even
>       more)
> 

I did my best to double-check all the python imports, everything should be covered now.

> 
> * optflags
>   - build.log shows:
> ------------------------------------------------
>    226  creating build/temp.linux-i686-2.5/layer5
>    227  gcc -pthread -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386
> -mtune=generic -fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -O2 -g -pipe
> -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
> -fasynchronous-unwind-tables -fPIC -D_PYMOL_MODULE -D_PYMOL_INLINE
> -D_PYMOL_FREETYPE -D_HAVE_LIBPNG -Iov/src -Ilayer0 -Ilayer1 -Ilayer2 -Ilayer3
> -Ilayer4 -Ilayer5 -I/usr/include/freetype2 -I/usr/include/python2.5 -c
> ov/src/OVContext.c -o build/temp.linux-i686-2.5/ov/src/OVContext.o -ffast-math
> -funroll-loops -O3
> ------------------------------------------------
>     Please remove "-ffast-math -funroll-loops -O3". These flags makes
>     debugging difficult, or changes calculation precision.
> 

Done - I set up the optflags as just "-O2" - is this sufficient?

> * Document
>   - Please also add the following file(s) to %doc
> -------------------------------------------------
> AUTHORS
> -------------------------------------------------
> 

Done.

> * generic rpmlint issue
> -------------------------------------------------
> pymol.i386: W: incoherent-version-in-changelog 1.1-3 1.1-3.20080912svn3419.fc10
> pymol-debuginfo.i386: W: spurious-executable-perm
> /usr/src/debug/pymol-1.1/contrib/champ/feedback2.c
> pymol-debuginfo.i386: W: spurious-executable-perm
> /usr/src/debug/pymol-1.1/contrib/champ/feedback2.h
> pymol-debuginfo.i386: W: spurious-executable-perm
> /usr/src/debug/pymol-1.1/contrib/champ/err2.c

Fixed.

> -------------------------------------------------
>   - Change the %changelog entry like below:
> -------------------------------------------------
> * Thu Oct 02 2008 Tim Fenn <fenn> - 1.1-3-20080912svn3419
> - fix release tag, add egg-info, minor fixes

done.

> * segv
>   - By the way for pymol causes segv with
> -------------------------------------------------
> pymol-1.1-3.20080912svn3419.fc10.i386
> mesa-libGL-7.1-0.37.fc10.i386
> python-2.5.2-1.fc10.i386
> -------------------------------------------------
>     when just launching pymol.
>     gdb log attached.

I can't reproduce this on my F8 machine, I'll try to find a machine for F10 testing.  I'll also get in touch with upstream and see if there are any suggestions there.

spec url: http://www.stanford.edu/~fenn/packs/pymol.spec
srpm url:
http://www.stanford.edu/~fenn/packs/pymol-1.1-4.20080912svn3419.f8.src.rpm

Comment 11 Tim Fenn 2008-10-06 19:02:01 UTC
(In reply to comment #9)
> By the way output from pymol seems to be saying that this is a pre-version
> of 1.1. In such cases please follow:
> 
> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages
> i.e. release number should be 0.3.20080912svn3419%{?dist}, for example.

I'll check with upstream - according to the website, its an "official" 1.1 release with fixes/patches backported from 1.2:

http://www.pymol.org/news.html

Comment 12 Susi Lehtola 2008-10-06 20:58:13 UTC
> # The source for this package was pulled from upstream's vcs.  Use the
> # following commands to generate the tarball:
> #  svn co https://pymol.svn.sourceforge.net/svnroot/pymol/branches/b11/pymol pymol-1.1
> #  tar cvzf pymol-1.1-20080912svn3419.tar.gz pymol-1.1
> Source0: pymol-1.1-20080912svn3419.tar.gz

- More exactly:
svn co -r 3419 https://pymol.svn.sourceforge.net/svnroot/pymol/branches/b11/pymol pymol-1.1

so you don't get the current revision.


- Group: Development/Tools

Wouln't Applications/Engineering be a better choice? This is a atomistic visualisation program, after all. (Applications/Science would of course be better if it existed..)

- Separate BuildRequires and Requires should be made for each required package. 


- export RPM_OPT_FLAGS="-O2"

Is there some reason not to use %optflags?

- typo %%doc in changelog.

Comment 13 Susi Lehtola 2008-10-06 21:07:08 UTC
Also, python-devel is redundant since python-setuptools-devel requires it.

Comment 14 Gianluca Sforna 2008-10-06 21:16:30 UTC
(In reply to comment #12)
> - More exactly:
> svn co -r 3419
> https://pymol.svn.sourceforge.net/svnroot/pymol/branches/b11/pymol pymol-1.1
> 
> so you don't get the current revision.

right

> 
> 
> - Group: Development/Tools
> 
> Wouln't Applications/Engineering be a better choice? This is a atomistic
> visualisation program, after all. (Applications/Science would of course be
> better if it existed..)

IIRC the Group tag is not really used these days, groups are composed from comps.xml, so it's not that really important. 

> - export RPM_OPT_FLAGS="-O2"
> 
> Is there some reason not to use %optflags?

yes, you should use the standard %optflags

> 
> - typo %%doc in changelog.

Nope, in changelog you need to use %% to avoid the macro expansion

Comment 15 Susi Lehtola 2008-10-06 21:34:14 UTC
(In reply to comment #14)
> > - Group: Development/Tools
> > 
> > Wouln't Applications/Engineering be a better choice? This is a atomistic
> > visualisation program, after all. (Applications/Science would of course be
> > better if it existed..)
> 
> IIRC the Group tag is not really used these days, groups are composed from
> comps.xml, so it's not that really important. 

Still, Development/Tools is not the right place for pymol.
 
> > - typo %%doc in changelog.
> 
> Nope, in changelog you need to use %% to avoid the macro expansion

Duh, of course. Thanks.

Comment 16 Mamoru TASAKA 2008-10-07 18:11:18 UTC
At least please fix %optflags issue
(By the way you can simply remove "export RPM_OPT_FLAGS="-O2" line. In rpmbuild
 $RPM_OPT_FLAGS is already set and is the same as %optflags).

Then I will re-check your srpm.

Comment 17 Susi Lehtola 2008-10-07 18:40:02 UTC
(In reply to comment #12)
> - Separate BuildRequires and Requires should be made for each required package. 

Hmh, how did I manage to state this so unclearly? I mean, of course, that the requires should be broken one per line, in alphabetized order. That way they're a lot easier to read and the spec file looks cleaner.

When you modify the spec file, in addition to removing the RPM_OPT_FLAGS line please add also the revision argument to the svn command in the comment and correct the group.

Thanks for packaging btw, I'll be one of the users when the rpm hits the repos.

Comment 18 Tim Fenn 2008-10-07 19:08:54 UTC
(In reply to comment #12)
> > # The source for this package was pulled from upstream's vcs.  Use the
> > # following commands to generate the tarball:
> > #  svn co https://pymol.svn.sourceforge.net/svnroot/pymol/branches/b11/pymol pymol-1.1
> > #  tar cvzf pymol-1.1-20080912svn3419.tar.gz pymol-1.1
> > Source0: pymol-1.1-20080912svn3419.tar.gz
> 
> - More exactly:
> svn co -r 3419
> https://pymol.svn.sourceforge.net/svnroot/pymol/branches/b11/pymol pymol-1.1
> 

Done.

> 
> - Group: Development/Tools
> 
> Wouln't Applications/Engineering be a better choice? This is a atomistic
> visualisation program, after all. (Applications/Science would of course be
> better if it existed..)
> 

Changed to Applications/Engineering

> - Separate BuildRequires and Requires should be made for each required package. 
> 

Done according to https://bugzilla.redhat.com/show_bug.cgi?id=462251#c17

> 
> - export RPM_OPT_FLAGS="-O2"
> 
> Is there some reason not to use %optflags?
> 

Fixed.

spec url: http://www.stanford.edu/~fenn/packs/pymol.spec
srpm url:
http://www.stanford.edu/~fenn/packs/pymol-1.1-5.20080912svn3419.f8.src.rpm

Comment 19 Mamoru TASAKA 2008-10-09 08:25:26 UTC
Created attachment 319834 [details]
gdb log on segv of rev 3466

Well, I tried revision 3466 but it still crashes
as attached.
Would you contact the upstream?

Comment 20 Tim Fenn 2008-10-09 08:40:27 UTC
(In reply to comment #19)
> Created an attachment (id=319834) [details]
> gdb log on segv of rev 3466
> 
> Well, I tried revision 3466 but it still crashes
> as attached.
> Would you contact the upstream?

I have - waiting for a response.  I'll try to replicate the segfault in the meantime.

Comment 21 Tim Fenn 2008-10-09 19:12:24 UTC
response from upstream:

<quote>
So far, I haven't been able to reproduce the crash.  It may be specific
and reflective of a bug in that particular version of Mesa.  The
offending call appears to be glBegin(GL_POLYGON), which suggests that
the problem may not be PyMOL itself...

The version 1.1 SVN source is between releases: 1.1r1 is known to be
broken in other ways, but 1.1r2 hasn't yet been Q.C'd...hence the "pre"
designation.
</quote>

I'll change the release number accordingly.  WRT the opengl issue, is it possible to test using 7.2 of mesa-libGL?

Comment 22 Mamoru TASAKA 2008-10-10 04:49:59 UTC
(In reply to comment #21)
> I'll change the release number accordingly.  WRT the opengl issue, is it
> possible to test using 7.2 of mesa-libGL?

Unfortunately I meet with rather serious issue on mesa 7.2 (bug 461460)
and so I cannot test this on mesa 7.2.

Comment 23 Tim Fenn 2008-10-12 08:51:04 UTC
Tested using F10 beta running:

pymol-1.1-5.20080912svn3419.fc10.x86_64
mesa-libGL-7.2-0.7.fc10.x86_64
python-2.5.2-1.fc10.x86_64

nVidia Corporation GeForce 8600 GT (rev a1)
(using the nv driver)

no problems on startup, loaded a PDB file and ran a few checks, seemed OK.

Comment 24 Mamoru TASAKA 2008-10-15 12:57:23 UTC
Well, while I does not have nVidia (I use intel), when I switch
to vesa there does not seem to have any problem on this package.
So for now I assume that there is something wrong with
either X driver or mesa.

So, @Tim if you have something you want to modify on your srpm
would you do so and post on this bug the newest of URLs of your spec/srpm
_anyway_ ? Then I will recheck your srpm again.

Comment 25 Tim Fenn 2008-10-15 19:03:38 UTC
(In reply to comment #24)
> Well, while I does not have nVidia (I use intel), when I switch
> to vesa there does not seem to have any problem on this package.
> So for now I assume that there is something wrong with
> either X driver or mesa.
> 
> So, @Tim if you have something you want to modify on your srpm
> would you do so and post on this bug the newest of URLs of your spec/srpm
> _anyway_ ? Then I will recheck your srpm again.

I bumped my SVN rev to 3468, and according to https://bugzilla.redhat.com/show_bug.cgi?id=462251#c21, it seems like its a candidate release package.  So, going by https://fedoraproject.org/wiki/Packaging/NamingGuidelines, would a name like:

pymol-1.1-20081015svn3468.CR2.tar.gz  (version 1.1 candidate release 2, svn rev 3468)

be OK for this package?

Comment 26 Susi Lehtola 2008-10-15 19:43:19 UTC
(In reply to comment #25)
> pymol-1.1-20081015svn3468.CR2.tar.gz  (version 1.1 candidate release 2, svn rev
> 3468)
> 
> be OK for this package?

Actually, shouldn't it be pymol-1.1-5.3419svn ?
Or, if this is more a prerelease of 1.2 than a release of the 1.1 series, then pymol-1.2-0.1.3419svn .

Comment 27 Tim Fenn 2008-10-15 23:04:28 UTC
(In reply to comment #26)
> (In reply to comment #25)
> > pymol-1.1-20081015svn3468.CR2.tar.gz  (version 1.1 candidate release 2, svn rev
> > 3468)
> > 
> > be OK for this package?
> 
> Actually, shouldn't it be pymol-1.1-5.3419svn ?

I updated my SVN checkout to correspond to 1.1r2 (3468)

> Or, if this is more a prerelease of 1.2 than a release of the 1.1 series, then
> pymol-1.2-0.1.3419svn .

SVN trunk represents 1.2, the b11 branch should be 1.1:

http://pymol.org/news.html

Comment 28 Mamoru TASAKA 2008-10-16 15:23:40 UTC
(In reply to comment #25)
> pymol-1.1-20081015svn3468.CR2.tar.gz  (version 1.1 candidate release 2, svn rev
> 3468)

Main version, date when checked out and svn revision number information 
is enough for tarball naming and rpm versioning in this case (RC2 information
is not so useful for this case).

Comment 29 Tim Fenn 2008-10-16 17:24:59 UTC
(In reply to comment #28)
> (In reply to comment #25)
> > pymol-1.1-20081015svn3468.CR2.tar.gz  (version 1.1 candidate release 2, svn rev
> > 3468)
> 
> Main version, date when checked out and svn revision number information 
> is enough for tarball naming and rpm versioning in this case (RC2 information
> is not so useful for this case).

OK, let me know if this one looks alright:

spec url: http://www.stanford.edu/~fenn/packs/pymol.spec
srpm url:
http://www.stanford.edu/~fenn/packs/pymol-1.1-6.20081015svn3468.f8.src.rpm

Comment 30 Mamoru TASAKA 2008-10-17 18:27:54 UTC
For -6:

* Python module dependency
  - Would you check python module dependency again?

    For example pmg_tk/startup/apbs_tools.py says
-----------------------------------------------------
    46  
    47  import os,math
    48  import Tkinter
    49  from Tkinter import *
    50  import Pmw
-----------------------------------------------------
    so this script requires tkinter (note: tkinter
    requires tk and tcl)

    And another example is that pmg_wx/__init__.py,
    which contains:
-----------------------------------------------------
    22  import threading
    23  import sys
    24  from wxPython.wx import *
    25  
-----------------------------------------------------
    This scripts requires wxPython.
    However these dependencies may be optional and
    I am not sure what python modules pymol requires
    _at least_.

* optflags
  - build.log still says that compiler options "-ffast-math -funroll-loops -O3"
    are used:
    http://koji.fedoraproject.org/koji/taskinfo?taskID=886320
    Please patch these options out (I guess that changing ext_comp_args
    in setup.py will do this).
    ! Note that Fedora specific compilation flags should not be
      removed.

Comment 31 Tim Fenn 2008-10-17 19:13:12 UTC
(In reply to comment #30)
> For -6:
> 
> * Python module dependency
>   - Would you check python module dependency again?
> 
>     For example pmg_tk/startup/apbs_tools.py says
> -----------------------------------------------------
>     46  
>     47  import os,math
>     48  import Tkinter
>     49  from Tkinter import *
>     50  import Pmw
> -----------------------------------------------------
>     so this script requires tkinter (note: tkinter
>     requires tk and tcl)
> 

Right, but python-pmw pulls tkinter in already.

>     And another example is that pmg_wx/__init__.py,
>     which contains:
> -----------------------------------------------------
>     22  import threading
>     23  import sys
>     24  from wxPython.wx import *
>     25  
> -----------------------------------------------------
>     This scripts requires wxPython.
>     However these dependencies may be optional and
>     I am not sure what python modules pymol requires
>     _at least_.
> 

wxPython can be used as an alternative to tcl/tk, but is optional.  I guess in which case the pmg_wx module should be removed?

> * optflags
>   - build.log still says that compiler options "-ffast-math -funroll-loops -O3"
>     are used:
>     http://koji.fedoraproject.org/koji/taskinfo?taskID=886320
>     Please patch these options out (I guess that changing ext_comp_args
>     in setup.py will do this).
>     ! Note that Fedora specific compilation flags should not be
>       removed.

doh!  Fixed.

spec url: http://www.stanford.edu/~fenn/packs/pymol.spec
srpm url:
http://www.stanford.edu/~fenn/packs/pymol-1.1-7.20081015svn3468.f8.src.rpm

Comment 32 Mamoru TASAKA 2008-10-18 16:02:58 UTC
For -7:

(In reply to comment #31)
> (In reply to comment #30)
> > * Python module dependency
> >   - Would you check python module dependency again?
> >     For example pmg_tk/startup/apbs_tools.py says
> >     so this script requires tkinter (note: tkinter
> >     requires tk and tcl)
> Right, but python-pmw pulls tkinter in already.

  - Ah, okay. Thanks.

> >     And another example is that pmg_wx/__init__.py,
> >     This scripts requires wxPython.
> >     However these dependencies may be optional and
> >     I am not sure what python modules pymol requires
> >     _at least_.
> wxPython can be used as an alternative to tcl/tk, but is optional.  I guess in
> which case the pmg_wx module should be removed?
  - No need to remove. However it is also a good idea to create a subpackage
    (like -wxpython), then split wxPython related files to that subpackage.

> > * optflags
> >   - build.log still says that compiler options "-ffast-math -funroll-loops -O3"
> >     are used:
> doh!  Fixed.
  - Well, about how to apply a patch in the spec file see
    the explanation
    http://docs.fedoraproject.org/drafts/rpm-guide-en/ch09s04.html
    and the example:
    http://cvs.fedoraproject.org/viewvc/rpms/pcmanfm/devel/pcmanfm.spec?view=co

Comment 33 Tim Fenn 2008-10-18 23:31:33 UTC
(In reply to comment #32)
> For -7:
> 
> (In reply to comment #31)
> > (In reply to comment #30)
> > >     And another example is that pmg_wx/__init__.py,
> > >     This scripts requires wxPython.
> > >     However these dependencies may be optional and
> > >     I am not sure what python modules pymol requires
> > >     _at least_.
> > wxPython can be used as an alternative to tcl/tk, but is optional.  I guess in
> > which case the pmg_wx module should be removed?
>   - No need to remove. However it is also a good idea to create a subpackage
>     (like -wxpython), then split wxPython related files to that subpackage.
> 

Good idea - done in -8.

> > > * optflags
> > >   - build.log still says that compiler options "-ffast-math -funroll-loops -O3"
> > >     are used:
> > doh!  Fixed.
>   - Well, about how to apply a patch in the spec file see
>     the explanation
>     http://docs.fedoraproject.org/drafts/rpm-guide-en/ch09s04.html
>     and the example:
>     http://cvs.fedoraproject.org/viewvc/rpms/pcmanfm/devel/pcmanfm.spec?view=co

Ah, thanks.  Fixed.

spec url: http://www.stanford.edu/~fenn/packs/pymol.spec
srpm url:
http://www.stanford.edu/~fenn/packs/pymol-1.1-8.20081015svn3468.f8.src.rpm

Comment 34 Mamoru TASAKA 2008-10-19 16:12:34 UTC
Okay. For consistency please use %defattr(-,root,root,-) also
for subpackages (you can fix this when importing to Fedora CVS).

---------------------------------------------------------------
   This package (pymol) is APPROVED by mtasaka
---------------------------------------------------------------

Comment 35 Tim Fenn 2008-10-20 01:34:30 UTC
New Package CVS Request
=======================
Package Name: pymol
Short Description: python molecular graphics
Owners: timfenn
Branches: F-10 EL-5
InitialCC: timfenn

Comment 36 Susi Lehtola 2008-10-20 06:32:16 UTC
Please add also F-9 branch.

Comment 37 Huzaifa S. Sidhpurwala 2008-10-20 08:45:51 UTC
cvs done

Comment 38 Adam Huffman 2008-10-21 14:22:40 UTC
Have just tried installing this in F9, both using the binary in koji and by rebuilding myself, and there's an unfulfilled dependency on python-pmw:

rpm -ivh /home/adam/rpmbuild/RPMS/x86_64/pymol-1.1-9.20081015svn3468.fc9.x86_64.rpm /home/adam/rpmbuild/RPMS/x86_64/pymol-wxpython-1.1-9.20081015svn3468.fc9.x86_64.rpm
error: Failed dependencies:
	python-pmw is needed by pymol-1.1-9.20081015svn3468.fc9.x86_64

(if this needs to be reported in a normal bugzilla entry, let me know)

Comment 39 Tim Fenn 2008-10-21 17:02:13 UTC
(In reply to comment #38)
> Have just tried installing this in F9, both using the binary in koji and by
> rebuilding myself, and there's an unfulfilled dependency on python-pmw:
> 
> rpm -ivh
> /home/adam/rpmbuild/RPMS/x86_64/pymol-1.1-9.20081015svn3468.fc9.x86_64.rpm
> /home/adam/rpmbuild/RPMS/x86_64/pymol-wxpython-1.1-9.20081015svn3468.fc9.x86_64.rpm
> error: Failed dependencies:
>  python-pmw is needed by pymol-1.1-9.20081015svn3468.fc9.x86_64
> 
> (if this needs to be reported in a normal bugzilla entry, let me know)


I'm waiting to get F-9 added as a branch for python-pmw (I originally only requested F-10 and EL5 for both, but F-9 was added by request for pymol and not python-pmw):

https://bugzilla.redhat.com/show_bug.cgi?id=462250

I should have it straightened out as soon as the CVS request is done.

Comment 40 Adam Huffman 2008-10-21 19:40:56 UTC
Have now installed it on a Rawhide box.  Tried running some of the demos but the demo files seem to be missing?:

ExecutiveProcessPDBFile-Error: Unable to open file '/usr/lib64/python2.5/site-packages/pymol/pymol_path/data/demo/il2.pdb'.
Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib64/python2.5/threading.py", line 486, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.5/threading.py", line 446, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.5/site-packages/pymol/wizard/demo.py", line 280, in roving
    self.cmd.load("$PYMOL_DATA/demo/il2.pdb")
  File "/usr/lib64/python2.5/site-packages/pymol/importing.py", line 696, in load
    if _self._raising(r,_self): raise pymol.CmdException
CmdException: <pymol.CmdException instance at 0x2c02dd0>
 
ExecutiveProcessPDBFile-Error: Unable to open file '/usr/lib64/python2.5/site-packages/pymol/pymol_path/data/demo/il2.pdb'.
Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib64/python2.5/threading.py", line 486, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.5/threading.py", line 446, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.5/site-packages/pymol/wizard/demo.py", line 280, in roving
    self.cmd.load("$PYMOL_DATA/demo/il2.pdb")
  File "/usr/lib64/python2.5/site-packages/pymol/importing.py", line 696, in load
    if _self._raising(r,_self): raise pymol.CmdException
CmdException: <pymol.CmdException instance at 0x26c1368>


[adam@vaio data]$ pwd
/usr/lib64/python2.5/site-packages/pymol/pymol_path/data
[adam@vaio data]$ ls
pymol

Is there a problem with the licensing of the demo files or do they just need to be added?

Comment 41 Tim Fenn 2008-10-21 19:56:40 UTC
(In reply to comment #40)
> 
> [adam@vaio data]$ pwd
> /usr/lib64/python2.5/site-packages/pymol/pymol_path/data
> [adam@vaio data]$ ls
> pymol
> 
> Is there a problem with the licensing of the demo files or do they just need to
> be added?

I just never added them - I'll add them to the spec and retag.

Comment 42 Tim Fenn 2008-10-22 17:30:02 UTC
ok - tagged/built.  final spec/srpm:

spec url: http://www.stanford.edu/~fenn/packs/pymol.spec
srpm url:
http://www.stanford.edu/~fenn/packs/pymol-1.1-10.20081015svn3468.f8.src.rpm

Mamoru, ok to close?  Also, can you ping someone to update the CVS branch on python-pmw (https://bugzilla.redhat.com/show_bug.cgi?id=462250) - i updated the flags, but it doesn't seem to be gathering any attention.

Comment 43 Mamoru TASAKA 2008-10-22 18:01:59 UTC
Before closing this bug, please submit a request on bodhi
to push F-9 pymol to the repository. 

It is highly preferable that you rebuild python-pwm first on F-9
and submit both pymol and python-pwm as one set of request (bodhi
supports a request containing several packages)

(In reply to comment #42)
> Mamoru, ok to close?  Also, can you ping someone to update the CVS branch on
> python-pmw (https://bugzilla.redhat.com/show_bug.cgi?id=462250) - i updated the
> flags, but it doesn't seem to be gathering any attention.

Please just wait :)

Comment 44 Tim Fenn 2008-10-27 20:31:50 UTC
submitted to F-9 as a newpackage request.

https://admin.fedoraproject.org/updates/python-pmw-1.3.2-5.fc9,pymol-1.1-10.20081015svn3468.fc9

Comment 45 Mamoru TASAKA 2008-10-28 15:41:40 UTC
Okay, thanks.

Comment 46 Susi Lehtola 2008-10-28 15:54:36 UTC
Did you build the EL-5 branch yet? The packages aren't available yet in EPEL testing..

Comment 47 Tim Fenn 2008-10-28 18:50:45 UTC
(In reply to comment #46)
> Did you build the EL-5 branch yet? The packages aren't available yet in EPEL
> testing..

Ah, had my plague client misconfigured.  Fixed and builds submitted.

Comment 48 Susi Lehtola 2008-10-30 13:53:38 UTC
(In reply to comment #47)
> (In reply to comment #46)
> > Did you build the EL-5 branch yet? The packages aren't available yet in EPEL
> > testing..
> 
> Ah, had my plague client misconfigured.  Fixed and builds submitted.

Now python-pmw has appeared in EPEL testing, but pymol is still missing..

Comment 49 Tim Fenn 2008-10-30 17:04:41 UTC
(In reply to comment #48)
> 
> Now python-pmw has appeared in EPEL testing, but pymol is still missing..

There was a snag related to the .desktop file on EL, see:

https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02586.html

it should appear soon in EL testing.

Comment 50 Fabien Archambault 2010-03-11 14:30:18 UTC
Hello all,

I am not sure this is the good place but is it possible to have an update of the rpm of pymol which is for the moment at the version 3866 in Fedora 12 and the cvs is at the version 3897.

Thanks in advance

Comment 51 Mamoru TASAKA 2010-03-11 15:01:48 UTC
Please file a bug against pymol.

Comment 52 Tim Fenn 2014-11-06 03:28:14 UTC
Package Change Request
======================
Package Name: pymol
New Branches: epel7
Owners: timfenn
InitialCC: timfenn

Comment 53 Gwyn Ciesla 2014-11-06 12:50:35 UTC
Git done (by process-git-requests).


Note You need to log in before you can comment on or make changes to this bug.