Bug 472150 (coot)

Just tried building the coot SRPM after manually installing the dependencies, on an F9 system.  Here's the output:

rpmbuild --rebuild coot-0.5-1.f8.src.rpm 
Installing coot-0.5-1.f8.src.rpm
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.76679
+ umask 022
+ cd /home/adam/rpmbuild/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /home/adam/rpmbuild/BUILD
+ rm -rf coot-0.5
+ /usr/bin/gzip -dc /home/adam/rpmbuild/SOURCES/coot-0.5.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd coot-0.5
+ /usr/bin/gzip -dc /home/adam/rpmbuild/SOURCES/coot-reference-structures.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
++ /usr/bin/id -u
+ '[' 500 = 0 ']'
++ /usr/bin/id -u
+ '[' 500 = 0 ']'
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ echo 'Patch #0 (configure.in.patch):'
Patch #0 (configure.in.patch):
+ patch -p0 -s
+ cp /home/adam/rpmbuild/SOURCES/coot.in ./
+ cp src/blank.cc src/coot_wrap_guile.cc
+ rm src/coot_wrap_python_pre.cc
+ iconv -f iso8859-1 -t utf-8 README
+ mv -f README.conv README
+ aclocal -I macros
configure.in:101: warning: macro `AM_PATH_GTKGLEXT_1_0' not found in library
+ libtoolize --automake --copy
+ autoconf
configure.in:101: error: possibly undefined macro: AM_PATH_GTKGLEXT_1_0
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
error: Bad exit status from /var/tmp/rpm-tmp.76679 (%prep)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.76679 (%prep)

so I think you need to add a BuildRequires for gtkglext.  After installling that, here's what I see (which I think is expected until the mmdb situation is resolved):

checking for GTK... yes
checking for GNOME_CANVAS... yes
checking for pkg-config... /usr/bin/pkg-config
checking for GtkGLExt - version >= 1.0.0... yes (version 1.2.0)
checking for GLUT... yes
checking for MMDB... configure: error: Package requirements (mmdb >= 1.12) were not met:

Requested 'mmdb >= 1.12' but version of mmdb is 1.09.1

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables MMDB_CFLAGS
and MMDB_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

error: Bad exit status from /var/tmp/rpm-tmp.80390 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.80390 (%build)

gtkglext-devel, I should have said

Have just updated to new mmdb and latest version of refmac-dictionary.

There's still a problem building coot:

(cd .libs && rm -f libcoot-shelx.so.0 && ln -s libcoot-shelx.so.0.0.0 libcoot-shelx.so.0)
(cd .libs && rm -f libcoot-shelx.so && ln -s libcoot-shelx.so.0.0.0 libcoot-shelx.so)
creating libcoot-shelx.la
(cd .libs && rm -f libcoot-shelx.la && ln -s ../libcoot-shelx.la libcoot-shelx.la)
/bin/sh ../libtool --tag=CXX   --mode=link g++ -DHAVE_GSL  -DPKGDATADIR='"/usr/share/coot"' -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing   -o testshelxreader test-shelx-reader.o ./libcoot-shelx.la ./libcoot-coord-utils.la ./libcoot-utils.la -lclipper -lsrfftw -lsfftw -lm -lmmdb -lgpp4   -lmmdb   
/bin/sh ../libtool --tag=CXX   --mode=link g++ -DHAVE_GSL  -DPKGDATADIR='"/usr/share/coot"' -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing   -o testcootutils test-utils.o ./libcoot-shelx.la ./libcoot-coord-utils.la ./libcoot-utils.la -lclipper -lsrfftw -lsfftw -lm -lmmdb -lgpp4   -lmmdb   
g++ -DHAVE_GSL -DPKGDATADIR=\"/usr/share/coot\" -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing -o .libs/testshelxreader test-shelx-reader.o  ./.libs/libcoot-shelx.so ./.libs/libcoot-coord-utils.so ./.libs/libcoot-utils.so -lclipper -lsrfftw -lsfftw -lm -lgpp4 -lmmdb
g++ -DHAVE_GSL -DPKGDATADIR=\"/usr/share/coot\" -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing -o .libs/testcootutils test-utils.o  ./.libs/libcoot-shelx.so ./.libs/libcoot-coord-utils.so ./.libs/libcoot-utils.so -lclipper -lsrfftw -lsfftw -lm -lgpp4 -lmmdb
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBFile::SetSpaceGroup(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBFile::ReadCoorFile(char*, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBCoorManager::GetAtom(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFStruct::GetReal(double&, char*, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFFile::ReadMMCIFFile(char*, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBCoorManager::GetModel(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBFile::WriteMMDBF(char*, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFLoop::GetReal(double&, char*, int, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBCoorManager::GetResidue(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFData::GetLoop(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFData::GetStructure(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBCoorManager::GetChain(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `FirstOccurence(char*, char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFLoop::GetInteger(int&, char*, int, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFLoop::GetString(char*, int, int&)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBFile::WriteCIFASCII(char*, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFStruct::GetString(char*, int&)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBFile::WritePDBASCII(char*, unsigned char)'
collect2: ld returned 1 exit status
make[1]: *** [testshelxreader] Error 1
make[1]: *** Waiting for unfinished jobs....
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBFile::SetSpaceGroup(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBFile::ReadCoorFile(char*, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBCoorManager::GetAtom(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFStruct::GetReal(double&, char*, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFFile::ReadMMCIFFile(char*, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBCoorManager::GetModel(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBFile::WriteMMDBF(char*, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFLoop::GetReal(double&, char*, int, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBCoorManager::GetResidue(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFData::GetLoop(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFData::GetStructure(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBCoorManager::GetChain(char*)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `FirstOccurence(char*, char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFLoop::GetInteger(int&, char*, int, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFLoop::GetString(char*, int, int&)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBFile::WriteCIFASCII(char*, unsigned char)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMCIFStruct::GetString(char*, int&)'
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/libclipper.so: undefined reference to `CMMDBFile::WritePDBASCII(char*, unsigned char)'
collect2: ld returned 1 exit status
make[1]: *** [testcootutils] Error 1
make[1]: Leaving directory `/home/adam/rpmbuild/BUILD/coot-0.5/coot-utils'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.53148 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.53148 (%build)

I'm updating clipper and ssm to fix the mmdb related build errors, they should be in soon.

Have updated to the latest versions of clipper and ssm as of today - 2.1-2 and 0.1-11 respectively.  Seeing some different build errors now - posting as an attachment since the log is quite long.

Created attachment 324492 [details]
rpmbuild -ba log showing build failure

Just built Coot successfully with the latest clipper and ssm updates on an F9 x86_64 box.  The program starts and is able to open a .pdb file.

I've included the latest spec/srpm that should pull in all the proper buildreqs here:

Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/coot-0.5-3.f8.src.rpm

note: I've added guile support as well to the build.

Sorry, wrong SRPM link:

SRPM URL: http://www.stanford.edu/~fenn/packs/coot-0.5-3.f10.src.rpm

Created attachment 327603 [details]
rpmlint non-weak-symbol messages

posted for my own reference - need to sort these out and submit patches upstream.

update to 0.5.2, fixed most rpmlint errors (most of the rest require significant changes to upstream package, will discuss with upstream):

Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/coot-0.5.2-1.fc10.src.rpm

need some info re. if its OK to progress with the existing rpmlint issues.

This failed to build for me in rawhide; it looks like it will need some fixes in order to build with gcc 4.4:

coot-utils.cc: In function 'std::string coot::util::int_to_string(int)':
coot-utils.cc:307: error: 'snprintf' was not declared in this scope
coot-utils.cc: In function 'std::string coot::util::long_int_to_string(long int)':
coot-utils.cc:314: error: 'snprintf' was not declared in this scope
coot-utils.cc: In function 'std::string coot::util::float_to_string(float)':
coot-utils.cc:321: error: 'snprintf' was not declared in this scope
coot-utils.cc: In function 'std::string coot::util::float_to_string_using_dec_pl(float, short unsigned int)':
coot-utils.cc:332: error: 'snprintf' was not declared in this scope
make[1]: *** [coot-utils.lo] Error 1

About the rpmlint complaints, the unused-direct-shlib-dependency ones just indicate that a library is linked against libm but doesn't actually call any functions in it.  It's not really a problem.

All of the undefined-non-weak symbol complaints come from the fact that one library calls functions in another without being linked against it.  Things still work because the the final executables link against all of the libraries.  It's really bad form, but unless the libraries are expected to be used by other packages it's not really a huge problem.  It's something I would complain to upstream about and perhaps try to work out a fix (after all, it is a lot of rpmlint warnings and it shouldn't be all that hard to make them go away) but I don't think it would block this review.

Also, you probably don't want to pass --vendor=fedora to desktop-file-install.

(In reply to comment #12)
> This failed to build for me in rawhide; it looks like it will need some fixes
> in order to build with gcc 4.4:
> 

OK - once I get my devel machine working with gcc 4.4 I'll fix this (waiting for the beta freeze)

> 
> About the rpmlint complaints, the unused-direct-shlib-dependency ones just
> indicate that a library is linked against libm but doesn't actually call any
> functions in it.  It's not really a problem.
> 
> All of the undefined-non-weak symbol complaints come from the fact that one
> library calls functions in another without being linked against it.  Things
> still work because the the final executables link against all of the libraries.
>  It's really bad form, but unless the libraries are expected to be used by
> other packages it's not really a huge problem.  It's something I would complain
> to upstream about and perhaps try to work out a fix (after all, it is a lot of
> rpmlint warnings and it shouldn't be all that hard to make them go away) but I
> don't think it would block this review.
> 

Thanks for the tips.  I've sent all my patches upstream, hopefully the next point release will fix most of these problems.

> Also, you probably don't want to pass --vendor=fedora to desktop-file-install.  

Oops, thanks.

added a gcc 4.4 patch and fixed desktop-file-install - tested OK on my devel machine:

Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/coot-0.5.2-2.fc10.src.rpm

Indeed this does build.  Here's the complete rpmlint listing; I'm sorry for
any terrible line wrapping; this is big enough that I'm working in an external
editor.

  coot.x86_64: W: name-repeated-in-summary Coot
Please don't include the name of the package in the summary.

  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-tw.so.0.0.0 /lib64/libm.so.6
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-skeleton.so.0.0.0 /usr/lib64/libcoot-mini-mol.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-skeleton.so.0.0.0 /usr/lib64/libcoot-shelx.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-skeleton.so.0.0.0 /usr/lib64/libcoot-coord-utils.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-skeleton.so.0.0.0 /usr/lib64/libcoot-utils.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libccp4mg-surface.so.0.0.0 /usr/lib64/libgpp4.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-high-res.so.0.0.0 /usr/lib64/libcoot-shelx.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-high-res.so.0.0.0 /usr/lib64/libcoot-ideal.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-high-res.so.0.0.0 /usr/lib64/libgsl.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-high-res.so.0.0.0 /usr/lib64/libgslcblas.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-high-res.so.0.0.0 /usr/lib64/libcoot-coord-extras.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-high-res.so.0.0.0 /usr/lib64/libcoot-geometry.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-high-res.so.0.0.0 /usr/lib64/libcoot-db-main.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-high-res.so.0.0.0 /usr/lib64/libcoot-utils.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-high-res.so.0.0.0 /usr/lib64/libccp4mg-utils.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-utils.so.0.0.0 /lib64/libm.so.6
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /usr/lib64/libart_lgpl_2.so.2
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /usr/lib64/libatk-1.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /lib64/libgio-2.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /usr/lib64/libpangoft2-1.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /usr/lib64/libgdk_pixbuf-2.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /usr/lib64/libpangocairo-1.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /usr/lib64/libcairo.so.2
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /usr/lib64/libpango-1.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /usr/lib64/libfreetype.so.6
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /usr/lib64/libfontconfig.so.1
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /lib64/libgmodule-2.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /usr/lib64/libcoot-atomutils.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /usr/lib64/libclipper.so.2
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /usr/lib64/libcoot-utils.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-sequence-view.so.0.0.0 /lib64/libm.so.6
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-isosurface.so.0.0.0 /usr/lib64/libcoot-mini-mol.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-isosurface.so.0.0.0 /usr/lib64/libcoot-shelx.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-isosurface.so.0.0.0 /usr/lib64/libcoot-coord-utils.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-isosurface.so.0.0.0 /usr/lib64/libmmdb.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-isosurface.so.0.0.0 /usr/lib64/libcoot-utils.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-map-utils.so.0.0.0 /usr/lib64/libcoot-utils.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-analysis.so.0.0.0 /usr/lib64/libclipper.so.2
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-analysis.so.0.0.0 /usr/lib64/libcoot-utils.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-map-heavy.so.0.0.0 /usr/lib64/libgslcblas.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-map-heavy.so.0.0.0 /usr/lib64/libcoot-utils.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-atomutils.so.0.0.0 /lib64/libm.so.6
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-cabuild.so.0.0.0 /usr/lib64/libmmdb.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-ligand.so.0.0.0 /usr/lib64/libcoot-shelx.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-ligand.so.0.0.0 /usr/lib64/libgsl.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-ligand.so.0.0.0 /usr/lib64/libgslcblas.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-mini-mol.so.0.0.0 /usr/lib64/libcoot-utils.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-mini-mol.so.0.0.0 /lib64/libm.so.6
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libglut.so.3
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libXmu.so.6
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libgtk-x11-2.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libgdk-x11-2.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libatk-1.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /lib64/libgio-2.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libpangoft2-1.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libgdk_pixbuf-2.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libpangocairo-1.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libcairo.so.2
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libpango-1.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libfreetype.so.6
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libfontconfig.so.1
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /lib64/libgobject-2.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /lib64/libgmodule-2.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /lib64/libglib-2.0.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libsrfftw.so.2
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libsfftw.so.2
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-surface.so.0.0.0 /usr/lib64/libgpp4.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-ideal.so.0.0.0 /usr/lib64/libgslcblas.so.0
  coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-coords.so.0.0.0 /usr/lib64/libclipper.so.2
Did you consider cleaning these up at all?

  coot.x86_64: W: shared-lib-calls-exit /usr/lib64/libcoot-coords.so.0.0.0 exit.5
  coot.x86_64: W: shared-lib-calls-exit /usr/lib64/libcoot-map-heavy.so.0.0.0 exit.5
  coot.x86_64: W: shared-lib-calls-exit /usr/lib64/libcoot-ligand.so.0.0.0 exit.5
These are bugs and should be reported upstream, but they aren't blockers.
 
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-skeleton.so.0.0.0 _ZN15graphics_info_t9moleculesE
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-skeleton.so.0.0.0 _ZN21molecule_class_info_t9makebondsEff
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-skeleton.so.0.0.0 _ZN21molecule_class_info_t45initialize_coordinate_things_on_read_moleculeESs
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-skeleton.so.0.0.0 _ZN21molecule_class_info_t9makebondsEv
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-skeleton.so.0.0.0 _ZN21molecule_class_info_t9makebondsEf
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-skeleton.so.0.0.0 _ZN21molecule_class_info_t13make_ca_bondsEff
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-sequence-view.so.0.0.0 _ZN15graphics_info_t9moleculesE
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-sequence-view.so.0.0.0 _ZN21molecule_class_info_t9makebondsEff
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-sequence-view.so.0.0.0 _ZN21molecule_class_info_t45initialize_coordinate_things_on_read_moleculeESs
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-sequence-view.so.0.0.0 _ZN21molecule_class_info_t9makebondsEv
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-sequence-view.so.0.0.0 _ZN21molecule_class_info_t9makebondsEf
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-sequence-view.so.0.0.0 _ZN21molecule_class_info_t13make_ca_bondsEff
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-sequence-view.so.0.0.0 _ZN15graphics_info_t32update_things_on_move_and_redrawEv
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-sequence-view.so.0.0.0 _ZN15graphics_info_t30try_centre_from_new_go_to_atomEv
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-sequence-view.so.0.0.0 _ZN15graphics_info_t23set_go_to_atom_moleculeEi
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-sequence-view.so.0.0.0 set_sequence_view_is_displayed
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-sequence-view.so.0.0.0 _ZN15graphics_info_t29set_go_to_residue_intelligentERKSsiS1_
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-atomutils.so.0.0.0 _ZN15graphics_info_t9moleculesE
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-atomutils.so.0.0.0 _ZN21molecule_class_info_t9makebondsEff
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-atomutils.so.0.0.0 _ZN21molecule_class_info_t45initialize_coordinate_things_on_read_moleculeESs
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-atomutils.so.0.0.0 _ZN21molecule_class_info_t9makebondsEv
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-atomutils.so.0.0.0 _ZN21molecule_class_info_t9makebondsEf
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-atomutils.so.0.0.0 _ZN21molecule_class_info_t13make_ca_bondsEff
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-coord-extras.so.0.0.0 _ZN4coot16protein_geometry15try_dynamic_addERKSsi
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-coord-extras.so.0.0.0 _ZNK4coot16protein_geometry22get_monomer_restraintsERKSs
  coot.x86_64: W: undefined-non-weak-symbol /usr/lib64/libcoot-coord-extras.so.0.0.0 _ZN4coot16protein_geometry32have_dictionary_for_residue_typeERKSsi
Did you consider cleaning these up at all, by properly linking the libraries
together?
  
  coot-debuginfo.x86_64: E: script-without-shebang /usr/src/debug/coot-0.5.2/ccp4mg-utils/cartesian.cc
  coot-debuginfo.x86_64: E: script-without-shebang /usr/src/debug/coot-0.5.2/src/coot_pythonmodule.cc
  coot-debuginfo.x86_64: E: script-without-shebang /usr/src/debug/coot-0.5.2/coot-surface/rgbreps.cc
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXFortranFile.h
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXTriangle.h
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXSurface.cpp
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXChargeTable.cpp
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXSurfaceVertex.cpp
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXCoord.h
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXFFTSolventMap.h
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXTorusNode.h
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXSurface.h
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXCoord.cpp
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/TokenIterator.h
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXTriangle.cpp
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXTorusNode.cpp
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/coot-surface/rgbreps.h
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXTorusElement.h
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/ccp4mg-utils/cartesian.h
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXQADSurface.cpp
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXFortranFile.cpp
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXFFTSolventMap.cpp
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXTorusElement.cpp
  coot-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/coot-0.5.2/surface/CXXSurfaceVertex.h
These all stem from the fact that bits of the source are executable.  I can't
imagine why the source code would need to be executable; can you run a
find/chmod over it in %prep to clean this up?

  coot-devel.x86_64: W: no-documentation
This is OK.

Some other comments:

I'm unsure of the license of this package.  You indicate that it's GPLv2 only.
COPYING contains GPLv3 (which doesn't generally mean that the source is
actually under version 3).  The source seems to be a mix of GPLv3+ and GPLv2+,
LGPLv2+.  For example, run
  grep -r 'version.*of the' *
and see what you get.  There's too much code for me to do a full license
review here; you'll need to see what source files are compiled into which
binaries and object files and compute the results of those license
combinations for each binary and each standalone file.  If they aren't all the
same, you'll need to provide a breakdown.  See
http://fedoraproject.org/wiki/Licensing and
http://fedoraproject.org/wiki/Packaging/LicensingGuidelines for more
information.

Also, I'm not sure it's OK to just pull the contents of
coot-guile-extras.tar.gz from other upstream packages; they each have their
own attributions and, I believe, different licensing terms.  For example,
goosh.scm is GPL but no version is given, which means we can choose any
version, so its license is GPL+.  Is there any reason not to just use the
pristine original tarballs for those files?  If you don't need the included
buildsystems you can just pick the files you need, but you may also need to
include documentation and license files.

(In reply to comment #15)
>   coot.x86_64: W: name-repeated-in-summary Coot
> Please don't include the name of the package in the summary.
> 

done.

>   coot.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcoot-tw.so.0.0.0
> /lib64/libm.so.6
>   coot.x86_64: W: unused-direct-shlib-dependency
> /usr/lib64/libcoot-skeleton.so.0.0.0 /usr/lib64/libcoot-mini-mol.so.0

<snip>

> /usr/lib64/libcoot-ideal.so.0.0.0 /usr/lib64/libgslcblas.so.0
>   coot.x86_64: W: unused-direct-shlib-dependency
> /usr/lib64/libcoot-coords.so.0.0.0 /usr/lib64/libclipper.so.2
> Did you consider cleaning these up at all?
> 

Yes - the problem with this group was that sublibrary A calls sublibrary B which calls sublibrary C - B is properly linked to C, but A is not linked to C.  This led to a kind of cascade of additional linkages that needed to be made to sort this out - I'm hoping to get this solved upstream rather than figure out the dependency web.

> 
>   coot.x86_64: W: undefined-non-weak-symbol
> /usr/lib64/libcoot-skeleton.so.0.0.0 _ZN15graphics_info_t9moleculesE
>   coot.x86_64: W: undefined-non-weak-symbol
> /usr/lib64/libcoot-skeleton.so.0.0.0 _ZN21molecule_class_info_t9makebondsEff
>   coot.x86_64: W: undefined-non-weak-symbol

<snip>

> /usr/lib64/libcoot-coord-extras.so.0.0.0
> _ZNK4coot16protein_geometry22get_monomer_restraintsERKSs
>   coot.x86_64: W: undefined-non-weak-symbol
> /usr/lib64/libcoot-coord-extras.so.0.0.0
> _ZN4coot16protein_geometry32have_dictionary_for_residue_typeERKSsi
> Did you consider cleaning these up at all, by properly linking the libraries
> together?
> 

I did try, and realized that in this set of cases, A links to B *and vice versa*.  But we can't build A before B *and* B before A, so some group of links are broken.  Again, an issue I'm hoping to resolve upstream.

>   coot-debuginfo.x86_64: E: script-without-shebang
> /usr/src/debug/coot-0.5.2/ccp4mg-utils/cartesian.cc
>   coot-debuginfo.x86_64: E: script-without-shebang
> /usr/src/debug/coot-0.5.2/src/coot_pythonmodule.cc

<snip>

> /usr/src/debug/coot-0.5.2/surface/CXXFFTSolventMap.cpp
>   coot-debuginfo.x86_64: W: spurious-executable-perm
> /usr/src/debug/coot-0.5.2/surface/CXXTorusElement.cpp
>   coot-debuginfo.x86_64: W: spurious-executable-perm
> /usr/src/debug/coot-0.5.2/surface/CXXSurfaceVertex.h
> These all stem from the fact that bits of the source are executable.  I can't
> imagine why the source code would need to be executable; can you run a
> find/chmod over it in %prep to clean this up?
> 

done.

> 
> Some other comments:
> 
> I'm unsure of the license of this package.  You indicate that it's GPLv2 only.
> COPYING contains GPLv3 (which doesn't generally mean that the source is
> actually under version 3).  The source seems to be a mix of GPLv3+ and GPLv2+,
> LGPLv2+.  For example, run
>   grep -r 'version.*of the' *
> and see what you get.  There's too much code for me to do a full license
> review here; you'll need to see what source files are compiled into which
> binaries and object files and compute the results of those license
> combinations for each binary and each standalone file.  If they aren't all the
> same, you'll need to provide a breakdown.  See
> http://fedoraproject.org/wiki/Licensing and
> http://fedoraproject.org/wiki/Packaging/LicensingGuidelines for more
> information.
> 

two of the library files are LGPLv2+, the rest of the code is a mix of GPLv2+ and GPLv3+ (all the guile extras are GPLv2+), so I've done my best to make note of the LGPL stuff in the spec file, before the %source definitions and at the list of %files.  Is this reasonable?

> Also, I'm not sure it's OK to just pull the contents of
> coot-guile-extras.tar.gz from other upstream packages; they each have their
> own attributions and, I believe, different licensing terms.  For example,
> goosh.scm is GPL but no version is given, which means we can choose any
> version, so its license is GPL+.  Is there any reason not to just use the
> pristine original tarballs for those files?  If you don't need the included
> buildsystems you can just pick the files you need, but you may also need to
> include documentation and license files.  

Done - I'm using the original tarballs and including just the required files and relevant docs (AUTHORS, READMEs).

Thanks for all the help on this one, I realize its a bit daunting.

Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/coot-0.5.2-3.fc11.src.rpm

(In reply to comment #16)
> 
> Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
> SRPM URL: http://www.stanford.edu/~fenn/packs/coot-0.5.2-3.fc11.src.rpm  

Not sure if anyone has noticed, but I just built this in koji and found it is missing a

BuildRequires: ghostscript

(It uses ps2pdf, which doesn't appear to be provided by anything else).  Of course I am building against a RHEL/CentOS 5.3 rebuild so I'm not sure if something magic^Wdifferent happens for FC11 here?

Ghostscript is in the dependency tree of tetex-latex on F11, even though no supported Fedora release has had tetex for some time now.  Some texlive package should probably be required instead.  Of course, if you wanted to eventually build this for EPEL then you'd either need a different spec file or some conditionals.  In that case, a build dependency on ghostscript to help RHEL5 wouldn't hurt.

However, a rawhide build fails for me way down in the %install section:

install -p -m 644 background_demo.py coot_utils.py get_ebi.py mutate.py hello.py raster3d.py brute_lsqman.py refmac.py coot_gui.py filter.py libcheck.py coot_load_modules.py local_code.py gap.py povray.py coot_lsq.py shelx.py group_settings.py fitting.py americanisms.py tips.py tips_gui.py generic_objects.py cns2coot.py extensions.py ncs.py clear_backup.py bones_reader.py shelx_extensions.py coot_toolbuttons.py ../src/coot.py coot-python-functions.texi coot_load_modules.py '/builddir/build/BUILDROOT/coot-0.5.2-3.fc12.x86_64/usr/share/coot/python'

install: will not overwrite just-created `/builddir/build/BUILDROOT/coot-0.5.2-3.fc12.x86_64/usr/share/coot/python/coot_load_modules.py' with `coot_load_modules.py'

Note that the install command tries to install coot_load_modules.py twice.

(In reply to comment #18)
> Ghostscript is in the dependency tree of tetex-latex on F11, even though no
> supported Fedora release has had tetex for some time now.  Some texlive package
> should probably be required instead.  Of course, if you wanted to eventually
> build this for EPEL then you'd either need a different spec file or some
> conditionals.  In that case, a build dependency on ghostscript to help RHEL5
> wouldn't hurt.
> 

Would something like:

BuildRequires: ghostscript
BuildRequires: /usr/bin/latex

be sufficient for both EL and fedora?

> However, a rawhide build fails for me way down in the %install section:
> 
<cut>
> 
> Note that the install command tries to install coot_load_modules.py twice.  

Thanks - I'll post a new src.rpm once the latex issue is fixed.

I'm currently attempting to delve more deeply into the circular dependency issue as well, but that will probably take a large chunk of time.

Was there ever any progress on this package?  I wouldn't object to those build dependencies, though these days we prefer using "tex(latex)" in Fedora to avoid talking about any specific TeX distribution.  I've honestly no idea what might be required for EPEL as it's getting so far behind in packaging now.

(In reply to comment #20)
> Was there ever any progress on this package?

I've been keeping an eye on upstream and submitting patches, mostly related to circular dependencies and weak links.  However, most of the problems haven't been fixed.  For example, see:

http://code.google.com/p/coot/source/browse/trunk/ideal/Makefile.am

and the commented out sections.

0.6.1 is due out soon, and I have more recent versions of the package based on SVN builds that are essentially "pre" packages, so I've been kind of sitting on this until 0.6.1 arrives.

> I wouldn't object to those build
> dependencies, though these days we prefer using "tex(latex)" in Fedora to avoid
> talking about any specific TeX distribution.  I've honestly no idea what might
> be required for EPEL as it's getting so far behind in packaging now.  

Sure, I'll make the edits to the .spec and post something this afternoon.

Here's a build based on the 0.6pre, the code is still changing rapidly, but a release is due "soon":

Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/coot-0.6-1.20090920svn2334.fc10.src.rpm

Just to let you know, tried building this on an F10 box with a Koji-build version of MMDB.  The build failed with the following error:

g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"co
ot\" -DVERSION=\"0.6-pre-1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_M
EMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I../compat -I../coords -
I../ccp4mg-utils -I../coot-utils -I../intl -I../skeleton -I../angles -I../atom-utils -I../db-main -I../mini-mol -I../ligand -I../se
quence-view -I../geometry -I../ideal -I../coot-surface -I../surface -I../density-contour -I../build -I../high-res -I../analysis -I.
./cootaneer -DHAVE_SYS_STDTYPES_H=0 -DUSE_GUILE   -pthread  -DHAVE_GNOME_CANVAS -I/usr/include/libgnomecanvas-2.0 -I/usr/include/pa
ngo-1.0 -I/usr/include/gail-1.0 -I/usr/include/libart-2.0 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/atk-1.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng12   -DCOOT_USE_GTK2_INTERFACE  -I/usr/include/gtkglext-1.0 -I/usr/lib64/gtkglext-1.0/include -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/atk-1.0   -I/usr/include/libglade-2.0 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12  -DHAVE_SSMLIB   -DHAVE_MMDB_IGNORE_HASH -DHAVE_MMDB_WITH_CISPEP   -I/usr/include -I/usr/include/gpp4   -I/usr/include/pygtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include    -I/usr/include/mmdb -I/usr/include/ssm -DPKGDATADIR='"/usr/share/coot"' -DPACKAGE_LOCALE_DIR='"/usr/share/coot/locale"' -DDATADIR='"/usr/share"' -DCOOT_SYS_BUILD_TYPE='"Linux-x86_64-fedora-10-python-gtk2"' -DHAVE_SYS_STDTYPES_H=0 -DUSE_GUILE  -pthread -DUSE_PYTHON -I/usr/include/python2.5 -DUSE_PYGTK  -DHAVE_GSL -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing -MT c-interface-gui.o -MD -MP -MF .deps/c-interface-gui.Tpo -c -o c-interface-gui.o c-interface-gui.cc
c-interface-gui.cc: In function 'void coot_real_exit(int)':
c-interface-gui.cc:1208: error: 'class clipper::ClipperInstance' has no member named 'destroy'
c-interface-gui.cc: In function 'void add_filechooser_filter_button(GtkWidget*, short int)':
c-interface-gui.cc:1279: warning: unused variable 'i'
c-interface-gui.cc: In function 'void add_recentre_on_read_pdb_checkbutton(GtkWidget*)':
c-interface-gui.cc:1763: warning: unused variable 'tooltips'
c-interface-gui.cc: In function 'void set_refine_params_toggle_buttons(GtkWidget*)':
c-interface-gui.cc:2319: warning: unused variable 'link_torsion_type_vbox'
c-interface-gui.cc: In function 'void show_model_toolbar_all_icons()':
c-interface-gui.cc:2595: warning: comparison between signed and unsigned integer expressions
c-interface-gui.cc: In function 'void show_model_toolbar_main_icons()':
c-interface-gui.cc:2622: warning: comparison between signed and unsigned integer expressions
c-interface-gui.cc: In function 'void update_model_toolbar_icons_menu()':
c-interface-gui.cc:2654: warning: comparison between signed and unsigned integer expressions
c-interface-gui.cc: In function 'void fill_go_to_atom_window(GtkWidget*)':
c-interface-gui.cc:4509: warning: unused variable 'text'
c-interface-gui.cc: In function 'GtkWidget* wrapped_create_add_additional_representation_gui()':
c-interface-gui.cc:5181: warning: unused variable 'chain_id_entry'
c-interface-gui.cc:5182: warning: unused variable 'resno_start_entry'
c-interface-gui.cc:5183: warning: unused variable 'resno_end_entry'
c-interface-gui.cc:5184: warning: unused variable 'ins_code_entry'
c-interface-gui.cc:5185: warning: unused variable 'string_selection_entry'
c-interface-gui.cc:5187: warning: unused variable 'position_radiobutton'
c-interface-gui.cc:5188: warning: unused variable 'resno_radiobutton'
c-interface-gui.cc:5189: warning: unused variable 'selection_string_radiobutton'
c-interface-gui.cc:5191: warning: unused variable 'add_reps_fat_bonds_radiobutton'
c-interface-gui.cc:5192: warning: unused variable 'add_reps_ball_and_stick_radiobutton'
c-interface-gui.cc: In function 'void add_additional_representation_by_widget(GtkWidget*)':
c-interface-gui.cc:5215: warning: unused variable 'option_menu'
c-interface-gui.cc:5227: warning: unused variable 'add_reps_fat_bonds_radiobutton'
c-interface-gui.cc: In function 'void show_restraints_editor_by_index(int)':
c-interface-gui.cc:5334: warning: comparison between signed and unsigned integer expressions

There were further warnings after this.  The version of clipper installed is clipper-2.1-4.fc10.x86_64

(In reply to comment #23)
> Just to let you know, tried building this on an F10 box with a Koji-build
> version of MMDB.  The build failed with the following error:
> 
> c-interface-gui.cc: In function 'void coot_real_exit(int)':
> c-interface-gui.cc:1208: error: 'class clipper::ClipperInstance' has no member
> named 'destroy'
> 
> There were further warnings after this.  The version of clipper installed is
> clipper-2.1-4.fc10.x86_64  

Yeah, you'll need to upgrade clipper as well.  You can find the latest either in koji or in the F12 alpha/beta packages.  Unforunately, the clipper API changes without bumping the sonames (or the library version number), so its a bit tricky to determine which "version" you need to have installed.  >.<

I'm not sure if you think this is ready to be reviewed or not, but I did a "quick" build and while there are still 4300+ lines of rpmlint complaints, I can ignore all of the shared-lib-calls-exit and undefined-non-weak-symbol warnings and get something reasonable.

  coot.x86_64: W: name-repeated-in-summary Coot
I suggest s/Coot - t/T/ in the Summary:.

  coot.x86_64: W: incoherent-version-in-changelog 0.6-20090920svn2334
   ['0.6-1.20090920svn2334.fc12', '0.6-1.20090920svn2334']
The release changelog entry is missing a "1.".

  coot.x86_64: E: non-executable-script
   /usr/lib/python2.6/site-packages/coot/create_server.py 0644 /usr/bin/python
Is this file supposed to be called by anything?

  coot-debuginfo.x86_64: W: spurious-executable-perm
   /usr/src/debug/coot-0.6/surface/CXXFFTSolventMap.h
  coot-debuginfo.x86_64: E: script-without-shebang
   /usr/src/debug/coot-0.6/coot-surface/rgbreps.cc
Loads of these; the source code really shouldn't be executable.  A quick find/chmod should fix it up.

  coot-devel.x86_64: W: no-documentation
Not a problem.

It looks like the upstream URL has moved.

Otherwise I did a cursory skim over the built packages and everything looks to be in place.  I would need to do some testing, but if the above were cleaned up and the licensing checks out then I'd say this package would be pretty close to ready.

(In reply to comment #25)
> I'm not sure if you think this is ready to be reviewed or not, but I did a
> "quick" build and while there are still 4300+ lines of rpmlint complaints, I
> can ignore all of the shared-lib-calls-exit and undefined-non-weak-symbol
> warnings and get something reasonable.
> 

I've been submitting patches for the non-weak-symbol problems for quite some time without much upstream action.  I'll ask again.

>   coot.x86_64: W: name-repeated-in-summary Coot
> I suggest s/Coot - t/T/ in the Summary:.
> 

done.

>   coot.x86_64: W: incoherent-version-in-changelog 0.6-20090920svn2334
>    ['0.6-1.20090920svn2334.fc12', '0.6-1.20090920svn2334']
> The release changelog entry is missing a "1.".
> 

oops, fixed.

>   coot.x86_64: E: non-executable-script
>    /usr/lib/python2.6/site-packages/coot/create_server.py 0644 /usr/bin/python
> Is this file supposed to be called by anything?
> 

I checked the code, doesn't seem to be.  I've taken the shebang line out.

>   coot-debuginfo.x86_64: W: spurious-executable-perm
>    /usr/src/debug/coot-0.6/surface/CXXFFTSolventMap.h
>   coot-debuginfo.x86_64: E: script-without-shebang
>    /usr/src/debug/coot-0.6/coot-surface/rgbreps.cc
> Loads of these; the source code really shouldn't be executable.  A quick
> find/chmod should fix it up.
> 

done.

> 
> It looks like the upstream URL has moved.
> 

fixed.

> Otherwise I did a cursory skim over the built packages and everything looks to
> be in place.  I would need to do some testing, but if the above were cleaned up
> and the licensing checks out then I'd say this package would be pretty close to
> ready.  

I've been doing some testing here and noticed the biggest problem is during startup that some python modules aren't found.  I'll look into this.  And yes, this package needs testers!

Latest build:

Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
SRPM URL:
http://www.stanford.edu/~fenn/packs/coot-0.6-2.20090920svn2334.fc11.src.rpm

Not certain on the formal - "tester" requirements but I'm happy to give it ago. Currently dowloading src will buildlocal & mockbuild and test.

Coot fails to build:
mmdb-devel > 1.20 is needed by coot-0.6-2.20090920svn2334.fc11.src current version is 1.19 in the main Fedora 11 release. Are you using a testing repo?

(In reply to comment #29)
> Coot fails to build:
> mmdb-devel > 1.20 is needed by coot-0.6-2.20090920svn2334.fc11.src current
> version is 1.19 in the main Fedora 11 release. Are you using a testing repo?  

Yes - you'll need to update mmdb and clipper to the -devel branch versions.

Finally got some action from upstream.  Most of the rpmlint issues have been resolved except for some unused-direct-shlib-dependencies and shared-lib-calls-exit issues.  I've also fixed the startup script so the python modules are resolved properly.

Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
SRPM URL:
http://www.stanford.edu/~fenn/packs/coot-0.6-3.20091005svn2400.fc11.src.rpm

I can't unpack the SRPM.  I have tried wget'ing it several times just in case, but always with the same result:

[cs1jrj@torbay cs1jrj]$ rpm -Uvh coot-0.6-3.20091005svn2400.fc11.src.rpm 
   1:coot                   warning: user fennt does not exist - using root
warning: group fennt does not exist - using root
########################################### [100%]
error: unpacking of archive failed on file /tmp/cs1jrj/SOURCES/__init__.py;4acaf6b0: cpio: MD5 sum mismatch

(In reply to comment #32)
> I can't unpack the SRPM.  I have tried wget'ing it several times just in case,
> but always with the same result:
> 
> [cs1jrj@torbay cs1jrj]$ rpm -Uvh coot-0.6-3.20091005svn2400.fc11.src.rpm 
>    1:coot                   warning: user fennt does not exist - using root
> warning: group fennt does not exist - using root
> ########################################### [100%]
> error: unpacking of archive failed on file
> /tmp/cs1jrj/SOURCES/__init__.py;4acaf6b0: cpio: MD5 sum mismatch  

Are you using a Fedora 11 machine? The checksum changed in Fedora 11 from MD5 to SHA256 so the author of the source needs to use:

rpmbuild -bs --define _source_filedigest_algorithm=1 specfilename

instead of just rpmbuild -bs not certain how to go the other way?

How is the weather in Bath today?

To clarify the src only needs the different rpmbuild to be backwards compatible Fedora 11 swings both ways so is not bothered.

No, I just wanted to unpack the sources so that I can repack them and put them through our koji server, for our RHEL rebuild.

PS
The weather here is quite wet.  It is drizzling now but it was raining more heavily earlier.  At least it is fairly warm.

I hadn't realised that there was a change to the checksum in FC11.  I have unpacked using rpmcpio/cpio directly, and that works fine, so you can disregard my previous comments.

For backwards compatibility, the dependency on tex(latex) has to be modified to refer to tetex-latex.

Is it really necessary for mmdb to be >= 1.20?

(In reply to comment #37)
> For backwards compatibility, the dependency on tex(latex) has to be modified to
> refer to tetex-latex.
> 

I'm going by the information given in comment 20 - is that inaccurate?

> Is it really necessary for mmdb to be >= 1.20?  

According to upstream:

"Thanks for your efforts with this whole thing - I'm looking forward to 
it working eventually.  I've moved to mmdb-1.21, fixes a LINK
format problem, IIRC."

So it may build with earlier versions, I'm only using >= 1.20 to coincide with Paul.

Comment 20 isn't inaccurate in the least, but neither is comment 37.  The issue is "backwards compatibility".  Frankly it's up to you; I review packages for Fedora according to the guidelines which relate to supported Fedora releases, but if you want to push packages to EPEL you'll have to deal with an ever-increasing number of incompatibilities.  Personally I prefer for the Fedora packages to be clean and for EPEL-related cruft to be kept to the EPEL branches (if you even intend to request them); someone who intends to take the Fedora package and rebuild it on some old release may grumble about backwards compatibility but that's really their problem.

(In reply to comment #37)
> 
> Is it really necessary for mmdb to be >= 1.20?  

I should also mention an issue regarding versions is that clipper needs to be 2.1-090520 SVN or later, but the soname and library version didn't change (I'll mention this to upstream), so that dependency may not get picked up - see comment 24.

Re #39, it isn't 'some old release', I'm making sure it builds for the current RHEL.  The reason we don't use CentOS is because they use a bastardised plague (in contrast we use koji), which causes their packages to have some odd quirks.  We have a mixture of people with supported RHEL installations and our rebuild of it.

FC11 isn't stable enough for our needs, and the RH support is a requirement for many of our users.

Re #40, thanks for that.  I'll have to check what clipper version we are using.  It is almost certainly whatever is currently shipped by either RHEL or EPEL.

I would certainly be interested in an EPEL branch.  Happy to maintain it myself, if necessary.

The clipper for EL will need updating if/when this package is accepted.  In the meantime, use the version in -devel to test this package with (mmdb in EL5 is 1.19, which may work OK for coot, please test and let me know!).  I'd also be glad to have a comaintainer for the EL branch. :)

mmdb 1.21 does build against RHEL, although I've not had a chance to test it yet.  The patches that had been in the package for 1.19 appear to have been accepted so they weren't needed for 1.21.

I'll have to check what else will be affected by updating clipper before I can look at that one.

Clipper compiles just fine on Centos (clipper-2.1-11.20090714cvs)

gtkglext is missing on centos/epel. Is the name different or it's really missing? I have seen a rpm on DAG, I'll try with this one.

I have clipper-2.1.5 on our koji server, and gtkglext-1.2.0.  I can put those both up somewhere more publicly accessible if that would be helpful?

I used http://koji.fedoraproject.org/koji/buildinfo?buildID=118213 but it's not compiling on centos, because of the conditions %if 0%{?fedora} < 8
I managed to get a rpm anyway.

About Coot which is the main thing here, centos is not happy:
+ find . -executable '(' -name '*.cc' -o -name '*.cpp' -o -name '*.h' -o -name '*.hh' ')' -exec chmod 644 '{}' ';'
find: invalid predicate `-executable'

[pascal@localhost rpmbuild]$ find --version
GNU find version 4.2.27

I just removed -executable to continue

I also modified the latex part:
%if "%{dist}" >= ".fc"
BuildRequires: tex(latex)
%else
BuildRequires: tetex-latex
%endif

I built it against mmdb 1.19

Finally it's working. I don't know coot, so I couldn't test correctly. I load a mdb file and got the structure on the screen, that's it.

I don't know the consequence of using an old mmdb either.

I can also try on fedora 10. Is there anything specific to try?

Re https://bugzilla.redhat.com/show_bug.cgi?id=472150#c46 - yes, that would be helpful.

I've thrown up the clipper and gtkglext packages here:

http://people.bath.ac.uk/cs1jrj/software/

(In reply to comment #47)
> 
> I can also try on fedora 10. Is there anything specific to try?  

I'm working on setting up a %check macro in the rpm now, I'll try to have that ready soon.  I'm also working with upstream to clarify the license.

Sorry to continue changing things, but this version is close to complete:

Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
SRPM URL: 
http://www.stanford.edu/~fenn/packs/coot-0.6-4.20091007svn2404.fc11.src.rpm

I've rechecked which files fall under which license, and updated to SVN 2404 (which clarifies the licensing on some of the source files).  I also added the tetex conditional for EL builds.  Finally, I've updated the Buildrequires:

mmdb must be >= 1.19, according to upstream.
clipper must be >= 2.1-7 (which corresponds to the 090522 snapshot release, required according to upstream and testing).

So Jess, would you mind updating your packages?

If J. Tibbitts is still watching this bugreport, I'd appreciate feedback - things are "review-worthy" for fedora, IMO.

I'm still checking what else depends on clipper, so that I can make sure that none of the other packages we have is adversely affected by the update, but I have an updated mmdb (1.21).  Once I'm happy that upgrading clipper isn't an issue, I'll replace the one I uploaded with a newer version.

I've had no time for reviews recently, but I have a little now.

This builds find on rawhide, but not F11 because of the clipper-devel dependency.  A version build for F12 will install on F11 but won't run.  My "not-quite-F12" boxes are all at work, which makes testing difficult; I can run it remotely, but it fails with "*** Cannot find the double-buffered visual."  Looks like you just can't go GLX over SSH, which I swear used to work OK.  Unfortunately I can't really do a proper review if I can't do any testing.

Anyway, I can make a few comments:

The build is fine; rpmlint has just the expected unused-direct-shlib-dependency complaints, along with a couple of shared-lib-calls-exit and a single no-documentation complaint, all of which are OK.

When I installed this I tried to find the icon, only to find that it shows up in the Graphics category.  Unfortunately the desktop file spec doesn't really have a top-level category that fits this package, but I'd at least expect to see "Graphics;Science;", maybe with Engineering or DataVisualization if they're appropriate.

Honestly the only real issue I see at this point is the wholesale inclusion of unrelated upstream projects in the coot/scheme directory.  Generally we don't do that kind of thing; it's basically the situation from http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
I didn't really notice before that those were separate projects; I originally thought they were part of coot but carried different licenses.  Now I see that they are merely prerequisites that shouldn't be part of this package.

Honestly I don't know what to do about that.  I guess I'd package guile-gui, goosh and net-http separately (although probably using a "guile-" prefix for the latter two) and then figure out how to make this package use the packaged versions.  Unfortunately I know very little about guile; jugding from the guile-lib package, it should be as simple as sticking the scheme files in %{_datadir}/guile/site/goosh or whatever.  Getting coot to use those files may be more difficult; I'm not at all sure.

(In reply to comment #53)
> I've had no time for reviews recently, but I have a little now.
> 

Thanks again for helping with this.

> This builds find on rawhide, but not F11 because of the clipper-devel
> dependency.  A version build for F12 will install on F11 but won't run.  My
> "not-quite-F12" boxes are all at work, which makes testing difficult; I can run
> it remotely, but it fails with "*** Cannot find the double-buffered visual." 
> Looks like you just can't go GLX over SSH, which I swear used to work OK. 
> Unfortunately I can't really do a proper review if I can't do any testing.
> 

You can grab the clipper .src.rpm from F12 and build it under F11, it should build OK, if that helps...

> 
> When I installed this I tried to find the icon, only to find that it shows up
> in the Graphics category.  Unfortunately the desktop file spec doesn't really
> have a top-level category that fits this package, but I'd at least expect to
> see "Graphics;Science;", maybe with Engineering or DataVisualization if they're
> appropriate.
> 

Yeah, I just followed what I did with pymol (https://bugzilla.redhat.com/show_bug.cgi?id=462251), I really wasn't sure what to put there.  I'll make the change to Graphics;Science (and in pymol as well, for that matter).

> Honestly the only real issue I see at this point is the wholesale inclusion of
> unrelated upstream projects in the coot/scheme directory.  Generally we don't
> do that kind of thing; it's basically the situation from
> http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
> I didn't really notice before that those were separate projects; I originally
> thought they were part of coot but carried different licenses.  Now I see that
> they are merely prerequisites that shouldn't be part of this package.
> 

I brought this up with upstream.  My concern was that guile net-http and guile-gui are unsupported, and goosh is part of the guile os process, and thus isn't maintained as its own package anymore.  Therefore, I figured it wasn't worth separating them out into their own packages.  Paul (upstream) has suggested he'll just include the code as part of the coot distribution and maintain it himself, but this was a few months ago - I'll ask him again about this and post an update soon.

(In reply to comment #54)
> (In reply to comment #53)
> 
> > Honestly the only real issue I see at this point is the wholesale inclusion of
> > unrelated upstream projects in the coot/scheme directory.  Generally we don't
> > do that kind of thing; it's basically the situation from
> > http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
> > I didn't really notice before that those were separate projects; I originally
> > thought they were part of coot but carried different licenses.  Now I see that
> > they are merely prerequisites that shouldn't be part of this package.
> > 
> 
> I brought this up with upstream.  My concern was that guile net-http and
> guile-gui are unsupported, and goosh is part of the guile os process, and thus
> isn't maintained as its own package anymore.  Therefore, I figured it wasn't
> worth separating them out into their own packages.  Paul (upstream) has
> suggested he'll just include the code as part of the coot distribution and
> maintain it himself, but this was a few months ago - I'll ask him again about
> this and post an update soon.  

OK, upstream will be removing net-http in favor of libcurl and remove the goosh dependency (instead using the guile os process). guile-gui is still maintained, so I'll package that independently and pull it in as a requirement.  I'll work on that today/tomorrow, and update this bugreport once upstream removes the net-http/goosh dependencies.

Feel free to CC me on any other packages you submit that lead up to this one and I'll try to get them reviewed for you.

so upon further investigation, guile-gui requires guile-gtk, which has been replaced by guile-gnome.  So guile-gui would need to be updated to use guile-gnome, which it seems won't happen (even though there is a maintainer, it seems he isn't working on it actively). Coot allows for the building of guile support, but not guile-gtk support, which will just disable a bunch of the extensions.  This isn't a big deal, and upstream does have plans to move all the guile-gtk stuff to use guile-gnome instead, so I'll just flip the switch when the code is updated to support guile-gnome.

tl;dr: no guile-gui package, disable guile-gtk in coot, lose a few of the extensions, enable extensions when coot supports guile-gnome.

I'm currently waiting for upstream to implement libcurl support in place of net-http (the goosh dependency is gone now), then all should be good to go.  Will update when that is done.

libcurl support is due in 0.6.1 according to upstream.  Therefore, a few menu options do not work in this build:

Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
SRPM URL: 
http://www.stanford.edu/~fenn/packs/coot-0.6-5.20091130svn2528.fc12.src.rpm

However, its trivial to download the deprecated guile libraries to add support for those that are interested, until 0.6.1 comes along.

Updated to the official 0.6 release:

Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
SRPM URL: 
http://www.stanford.edu/~fenn/packs/coot-0.6-6.20091203svn2545.fc12.src.rpm

Note that I haven't forgotten about this; I'm just trying to find the time.

(In reply to comment #60)
> Note that I haven't forgotten about this; I'm just trying to find the time.    

No worries, thanks again for your help.  0.6.1 was released, so I've updated the package:

Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
SRPM URL: 
http://www.stanford.edu/~fenn/packs/coot-0.6.1-1.20100127svn2740.fc12.src.rpm

as mentioned above, this release uses libcurl.

Jason - would it be possible within the next few weeks to fix any remaining issues with this package?  I'd like to do some testing on F13, and if all looks good try to include it.

Is anyone still reviewing this package?

Had forgotten but will do so this week.  Been distracted by the new RHEL 6 beta.

Output from rpmlint (one warning):

$ rpmlint coot.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
$ rpmlint coot-0.6.1-1.20100127svn2740.fc12.src.rpm 
coot.src: W: strange-permission coot.in 0755

By the way, I note that this isn't the latest version in trunk, do we want to update it before it goes any further?

(In reply to comment #66)
> By the way, I note that this isn't the latest version in trunk, do we want to
> update it before it goes any further?    

I'm going by the latest stable release, 0.6.1 - do you recommend we go with a prerelease?

(In reply to comment #67)
> (In reply to comment #66)
> > By the way, I note that this isn't the latest version in trunk, do we want to
> > update it before it goes any further?    
> 
> I'm going by the latest stable release, 0.6.1 - do you recommend we go with a
> prerelease?    

No, I wouldn't recommend that - I hadn't realised it wasn't just bugfixes.

Failed on a few minor things (see list below).  Please fix and let me know and I will re-review it.

- = N/A
 / = Check
 x = Problem
 ? = Not evaluated

=== REQUIRED ITEMS ===
 [/] Package is named according to the Package Naming Guidelines.
 [/] Spec file name must match the base package %{name}, in the format
%{name}.spec.
 [/] Package meets the Packaging Guidelines including the Perl specific items
  [-] Versioned MODULE_COMPAT_ Requires
  [-] Non-Versioned CPAN URL tag
 [/] Package successfully compiles and builds into binary rpms on at least one
supported architecture.
     Tested on: http://koji.fedoraproject.org/koji/taskinfo?taskID=2308298
 [/] Rpmlint output:
coot.src: W: strange-permission coot.in 0755
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
 [/] Package is not relocatable.
 [/] Buildroot is correct
     Buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 [/] Package is licensed with an open-source compatible license and meets other
legal requirements as defined in the legal section of Packaging Guidelines.
 [x] License field in the package spec file matches the actual license. 
     License type: "Mostly GPLv3, some GLPv2+, some LGPLv3." (from website) is
not quite the same as "GPLv3+ and LGPLv2" (from spec file)
 [-] If (and only if) the source package includes the text of the license(s) in
its own file, then that file, containing the text of the license(s) for the
package is included in %doc.
 [/] Spec file is legible and written in American English.
 [/] Sources used to build the package matches the upstream source, as provided
in the spec URL.
 [/] Package is not known to require ExcludeArch
 [/] All build dependencies are listed in BuildRequires, except for any that
are listed in the exceptions section of Packaging Guidelines.
 [/] The spec file handles locales properly.
 [/] ldconfig called in %post and %postun if required.
 [/] Package must own all directories that it creates.
 [/] Package requires other packages for directories it uses.
 [/] Package does not contain duplicates in %files.
 [/] Permissions on files are set properly.
 [/] Package has a %clean section, which contains rm -fR $RPM_BUILD_ROOT.
 [/] Package consistently uses macros.
 [/] Package contains code, or permissable content.
 [X] Large documentation files are in a -doc subpackage, if required.
 [/] Package uses nothing in %doc for runtime.
 [-] Header files in -devel subpackage, if present.
 [-] Static libraries in -static subpackage, if present.
 [-] Package requires pkgconfig, if .pc files are present.
 [/] Development .so files in -devel subpackage, if present.
 [/] Fully versioned dependency in subpackages, if present.
 [/] Package does not contain any libtool archives (.la).
 [/] Package contains a properly installed %{name}.desktop file if it is a GUI
application.
 [/] Package does not own files or directories owned by other packages.

=== SUGGESTED ITEMS ===
 [/] Latest version is packaged.
 [/] Package does not include license text files separate from upstream.
 [?] Description and summary sections in the package spec file contains
translations for supported Non-English languages, if available.
 [/] Reviewer should test that the package builds in mock.
     Tested on: http://koji.fedoraproject.org/koji/taskinfo?taskID=2308298
 [?] Package should compile and build into binary rpms on all supported
architectures.
     Tested on: fedora-rawhide-x86_64
 [/] Package functions as described.
 [/] Scriptlets must be sane, if used.
 [-] The placement of pkgconfig(.pc) files is correct.
 [/] File based requires are sane.
 [X] %check is present and the tests pass

By the way, at the moment it doesn't build for EPEL-5, but that won't stop it getting into Fedora I think.

Sorry, was away for a few days - I'll get to this within a day or two.

(In reply to comment #69)
> 
> - = N/A
>  / = Check
>  x = Problem
>  ? = Not evaluated
> 
> === REQUIRED ITEMS ===
>  [x] License field in the package spec file matches the actual license. 
>      License type: "Mostly GPLv3, some GLPv2+, some LGPLv3." (from website) is
> not quite the same as "GPLv3+ and LGPLv2" (from spec file)

I double checked the licenses on all the header/source files, and only the CCP4MG code (in ccp4mg-utils) and the libcoot-surface library (which depends on the libccp4mg library) use LGPLv2+ code. All the other code is GPLv3+ according to the headers and COPYING file. My guess is the website is slightly outdated (I pointed out to upstream the varying licenses in the source, and the code headers and files were updated a few months ago).

>  [X] Large documentation files are in a -doc subpackage, if required.

done.

>  [X] %check is present and the tests pass    

I've added a %check, but it fails (there are several errors in the test code). I'll talk with upstream and try to get this fixed for 0.6.2, but let me know if this is a show-stopper and I'll make a patch for the broken tests.

Also, you mentioned a failed build on EL5 - do you have the log?

Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
SRPM URL: 
http://www.stanford.edu/~fenn/packs/coot-0.6.1-2.20100127svn2740.fc13.src.rpm

(In reply to comment #72)
> (In reply to comment #69)
> > 
> > - = N/A
> >  / = Check
> >  x = Problem
> >  ? = Not evaluated
> > 
> > === REQUIRED ITEMS ===
> >  [x] License field in the package spec file matches the actual license. 
> >      License type: "Mostly GPLv3, some GLPv2+, some LGPLv3." (from website) is
> > not quite the same as "GPLv3+ and LGPLv2" (from spec file)
> 
> I double checked the licenses on all the header/source files, and only the
> CCP4MG code (in ccp4mg-utils) and the libcoot-surface library (which depends on
> the libccp4mg library) use LGPLv2+ code. All the other code is GPLv3+ according
> to the headers and COPYING file. My guess is the website is slightly outdated
> (I pointed out to upstream the varying licenses in the source, and the code
> headers and files were updated a few months ago).

Fair enough.  I didn't look at the code itself, assuming instead that the project website would be up to date.

> 
> >  [X] Large documentation files are in a -doc subpackage, if required.
> 
> done.
> 
> >  [X] %check is present and the tests pass    
> 
> I've added a %check, but it fails (there are several errors in the test code).
> I'll talk with upstream and try to get this fixed for 0.6.2, but let me know if
> this is a show-stopper and I'll make a patch for the broken tests.

It isn't a show-stopper but needs to either be commented out (with an appropriate comment) or patched.

> Also, you mentioned a failed build on EL5 - do you have the log?

Not to hand, but I'll through the new SRPM through koji again with EPEL as the target.

Output from the Fedora rpmlint - newer than the one on RHEL, which I used before, and also more fussy and used by everyone else:

coot.src: W: spelling-error %description -l en_US gui -> GUI, goo, gi
coot.src: W: spelling-error %description -l en_US mmdb -> mm db, mm-db, Mme
coot.src: W: spelling-error %description -l en_US modelling -> modeling, model ling, model-ling
coot.src: W: strange-permission coot.in 0755L
coot.src:9: W: macro-in-comment %files
coot.src:171: E: files-attr-not-set
coot.src: W: invalid-url Source0: coot-0.6.1-20100127svn2740.tar.gz
1 packages and 0 specfiles checked; 1 errors, 6 warnings.

The error (files-attr-not-set) will need fixing too.  The SRPM is still uploading to koji for the scratch build so I will post the results of that later.

(In reply to comment #74)
> Output from the Fedora rpmlint - newer than the one on RHEL, which I used
> before, and also more fussy and used by everyone else:
> 
> coot.src: W: spelling-error %description -l en_US gui -> GUI, goo, gi
> coot.src: W: spelling-error %description -l en_US mmdb -> mm db, mm-db, Mme
> coot.src: W: spelling-error %description -l en_US modelling -> modeling, model
> ling, model-ling

Fixed these.

> coot.src:171: E: files-attr-not-set

Oops, fixed that.

> 
> The error (files-attr-not-set) will need fixing too.  The SRPM is still
> uploading to koji for the scratch build so I will post the results of that
> later.    

I ran a koji scratch build as well on f14: 

http://koji.fedoraproject.org/koji/taskinfo?taskID=2382998

Also, I received word that upstream is working on the make check problem for 0.6.2, so once that is released I'll try again.

Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/coot-0.6.1-3.20100127svn2740.fc13.src.rpm

(In reply to comment #75)
> (In reply to comment #74)
> > Output from the Fedora rpmlint - newer than the one on RHEL, which I used
> > before, and also more fussy and used by everyone else:
> > 
> > coot.src: W: spelling-error %description -l en_US gui -> GUI, goo, gi
> > coot.src: W: spelling-error %description -l en_US mmdb -> mm db, mm-db, Mme
> > coot.src: W: spelling-error %description -l en_US modelling -> modeling, model
> > ling, model-ling
> 
> Fixed these.
> 
> > coot.src:171: E: files-attr-not-set
> 
> Oops, fixed that.
> 
> > 
> > The error (files-attr-not-set) will need fixing too.  The SRPM is still
> > uploading to koji for the scratch build so I will post the results of that
> > later.    
> 
> I ran a koji scratch build as well on f14: 
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2382998

Great.

> 
> Also, I received word that upstream is working on the make check problem for
> 0.6.2, so once that is released I'll try again.

Don't suppose you have any idea how fast they might move on this?  It's not a show-stopper anyway, but it would be good to get it sorted.

> 
> Spec URL: http://www.stanford.edu/~fenn/packs/coot.spec
> SRPM URL:
> http://www.stanford.edu/~fenn/packs/coot-0.6.1-3.20100127svn2740.fc13.src.rpm

APPROVED

(In reply to comment #76)
> (In reply to comment #75)
> > (In reply to comment #74)
> > > Output from the Fedora rpmlint - newer than the one on RHEL, which I used
> > > before, and also more fussy and used by everyone else:
> > > 
> > > coot.src: W: spelling-error %description -l en_US gui -> GUI, goo, gi
> > > coot.src: W: spelling-error %description -l en_US mmdb -> mm db, mm-db, Mme
> > > coot.src: W: spelling-error %description -l en_US modelling -> modeling, model
> > > ling, model-ling
> > 
> > Fixed these.
> > 
> > > coot.src:171: E: files-attr-not-set
> > 
> > Oops, fixed that.
> > 
> > > 
> > > The error (files-attr-not-set) will need fixing too.  The SRPM is still
> > > uploading to koji for the scratch build so I will post the results of that
> > > later.    
> > 
> > I ran a koji scratch build as well on f14: 
> > 
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=2382998
> 
> Great.
> 
> > 
> > Also, I received word that upstream is working on the make check problem for
> > 0.6.2, so once that is released I'll try again.
> 
> Don't suppose you have any idea how fast they might move on this?  It's not a
> show-stopper anyway, but it would be good to get it sorted.
> 

the make check now builds the appropriate tests, but there are still some edits required to get them to run. I've talked with upstream, but all the changes are in the unstable pre 0.6.2 branch. Once 0.6.2 is released it should be ready to go.

I ran a scratch build for EPEL6:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2391853

some of the packages required for coot aren't available or are too old:

guile-lib
refmac-dictionary
mmdb
ssm
clipper

so I'll have to leave off EPEL for the branch request.

New Package SCM Request
=======================
Package Name: coot
Short Description: crystallographic macromolecular building toolkit
Owners: timfenn
Branches: f13 f14
InitialCC: timfenn

Git done (by process-git-requests).

Package Change Request
======================
Package Name: coot
New Branches: el6
Owners: timfenn
InitialCC: timfenn

All the dependencies are available for EL6, they just need to be tagged/built, so I'd like to add the el6 branch as well for this package.

Git done (by process-git-requests).

Hi,

(and sorry if this is a wrong place for bug-report)

We have a Fedora 13:
# uname -a
Linux foo.bar 2.6.33.6-147.2.4.fc13.x86_64 #1 SMP Fri Jul 23 17:14:44 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
# > cat /proc/driver/nvidia/version 
NVRM version: NVIDIA UNIX x86_64 Kernel Module  256.44  Thu Jul 29 01:22:44 PDT 2010
GCC version:  gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) 
# rpm -q coot
coot-0.6.1-3.20100127svn2740.fc13.x86_64

... with Samsung 2233RZ and Nvidia 3D Vision glasses.

When Coot is set to show a protein molecule and electron density map,
and hardware stereo is activated, the density map is not drawn at all.
The protein is seen in stereo as expected.

For comparison, an older Coot-0.6-pre-1-rev-2334-fc10-i386-python-gtk2
(precompiled binary from upstream) does draw the map in the (quad-buffered
OpenGL) stereo-mode as expected.

I do suspect the application rather than the build; you don't miss out one wireframe and yet draw others, unless you do something special.

Unfortunately, more recent precompiled binaries as well as self-compilations
from upstream sources have failed due to missing dependencies on F13.x86_64
(so far), so I haven't verified my assumption.

git done, packages tagged/built for F13/F14 - just waiting for guile-lib to be tagged/built for EL6.

OK to close?

(In reply to comment #84)
> 
> (and sorry if this is a wrong place for bug-report)
> 

Ideally, a new bug report should be opened.

> We have a Fedora 13:
> # uname -a
> Linux foo.bar 2.6.33.6-147.2.4.fc13.x86_64 #1 SMP Fri Jul 23 17:14:44 UTC 2010
> x86_64 x86_64 x86_64 GNU/Linux
> # > cat /proc/driver/nvidia/version 
> NVRM version: NVIDIA UNIX x86_64 Kernel Module  256.44  Thu Jul 29 01:22:44 PDT
> 2010
> GCC version:  gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) 
> # rpm -q coot
> coot-0.6.1-3.20100127svn2740.fc13.x86_64
> 
> ... with Samsung 2233RZ and Nvidia 3D Vision glasses.
> 
> When Coot is set to show a protein molecule and electron density map,
> and hardware stereo is activated, the density map is not drawn at all.
> The protein is seen in stereo as expected.
> 
> For comparison, an older Coot-0.6-pre-1-rev-2334-fc10-i386-python-gtk2
> (precompiled binary from upstream) does draw the map in the (quad-buffered
> OpenGL) stereo-mode as expected.
> 
> I do suspect the application rather than the build; you don't miss out one
> wireframe and yet draw others, unless you do something special.
> 
> Unfortunately, more recent precompiled binaries as well as self-compilations
> from upstream sources have failed due to missing dependencies on F13.x86_64
> (so far), so I haven't verified my assumption.

I don't have a stereo-enabled system to test, but could you bring this up with upstream and see if there is a patch/fix available? If so, I'll be glad to apply it/backport it if need be.

I've been working on an EPEL 5 build.  If I rebuild gtkglext and clipper and disable the -doc subpackage, it does build, though there are still some problems.  For instance, the Python path in /usr/bin/coot is wrong, as is the path for refmac-dictionary.

I'll keep going on this, as time permits.

Shouldn't this be closed, given that the package has existed in Fedora for a long time now?

(In reply to Adam Huffman from comment #88)
> Shouldn't this be closed, given that the package has existed in Fedora for a
> long time now?

Yes.