Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=472150 --- Comment #16 from Tim Fenn <fenn@xxxxxxxxxxxx> 2009-03-25 04:02:31 EDT --- (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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review