https://bugzilla.redhat.com/show_bug.cgi?id=804125 --- Comment #10 from Jason Tibbitts <tibbs@xxxxxxxxxxx> --- 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@xxxxxxxxx> - 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 _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review