[Bug 472150] Review Request: coot - crystallographic macromolecular building toolkit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]