https://bugzilla.redhat.com/show_bug.cgi?id=804125
--- Comment #10 from Jason Tibbitts <tibbs(a)math.uh.edu> ---
So, after a fashion, this does build for me and I'll toss out a few random
comments. Without any way to test this I'm just sort of poking about, but I
guess it can't hurt.
rpmlint has just a few complaints that weren't mentioned earlier:
rdkit.src: E: specfile-error warning: bogus date in %changelog:
Wed Oct 21 2012 Gianluca Sforna <giallu(a)gmail.com> - 2012.09-1
"cal 2012" tells me that October 21st 2012 was a Sunday, not a Wednesday.
One new non-executable-script complaint:
python-rdkit.x86_64: E: non-executable-script
/usr/lib64/python2.7/site-packages/rdkit/Chem/MCS.py 0644L /usr/bin/env
and one old one:
python-rdkit.x86_64: E: non-executable-script
/usr/lib64/python2.7/site-packages/rdkit/utils/pydoc_local.py 0644L
/usr/bin/env
Not sure what you want to do with those.
Still some spurious-executable-perm complaints in the debuginfo package. Why
would cpp and header files be executable in the source tree?
rdkit-debuginfo.x86_64: W: spurious-executable-perm
/usr/src/debug/RDKit_2013_03_1/External/INCHI-API/inchi.cpp
rdkit-debuginfo.x86_64: W: spurious-executable-perm
/usr/src/debug/RDKit_2013_03_1/External/INCHI-API/Wrap/pyInchi.cpp
rdkit-debuginfo.x86_64: W: spurious-executable-perm
/usr/src/debug/RDKit_2013_03_1/External/INCHI-API/inchi.h
Could you comment on the purpose of these? Would it not be better for these to
be packaged as documentation? Actually, that pretty much goes for the rest of
the stuff in rdkit-extras; at least the Contrib stuff doesn't seem to be
terribly useful just sitting under /usr/share.
rdkit-extras.noarch: W: devel-file-in-non-devel-package
/usr/share/RDKit/Contrib/PBF/PBFRDKit.h
rdkit-extras.noarch: W: devel-file-in-non-devel-package
/usr/share/RDKit/Contrib/PBF/demo.cpp
rdkit-extras.noarch: W: devel-file-in-non-devel-package
/usr/share/RDKit/Contrib/PBF/PBFRDKit.cpp
Can you comment on the stuff in the External directory? I just want to make
sure none of it is bundled external code.
Also on the subject of the External directory, some of it is differently
licensed (cmim is GPL, pymol is "Pymol", whatever that is). Can you be certain
that none of that is included in the final package? If not, the License: tag
will need modification.
Why do all of the libraries seem to carry a "1beta1" when this is versioned as
a post-release package?
I kind of wish the masses if library files all carried a some sort of "libRD"
prefix, because there are so many of them and they appear to be rather
generically named, especially "libhc.so". I did look for conflicts, though,
and didn't find any outside of an instance of "libhc" in an obscure project
at
http://code.google.com/p/isdp/, and that library doesn't appear to have come
from the source anyway. So I don't think there's any blocker here, but it's
something to be aware of.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=84KMfh30k3&a=cc_unsubscribe