https://bugzilla.redhat.com/show_bug.cgi?id=804125
--- Comment #11 from Gianluca Sforna <giallu(a)gmail.com> ---
(In reply to Jason Tibbitts from comment #10)
"cal 2012" tells me that October 21st 2012 was a Sunday,
not a Wednesday.
Fixed
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.
The first one is really a python module, so I removed the shebang.
The second I am not sure, asked upstream.
Still some spurious-executable-perm complaints in the debuginfo package.
Why would cpp and header files be executable in the source tree?
not intentional I guess, reported upstream
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
The extras are examples of actual rdkit usage. I am not sure where it is best
to put them in the filesystem, but if consensus is they should go in docs I can
surely move them.
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.
That is supposed to contain glue code to USE external code. For instance, inchi
is pulled as a dep and linked as usual.
pymol is code from upstream, I asked to put there a proper license.
I also asked upstream about cmim, it seems from the build logs it is using just
a couple modules from that, maybe it can be replaced or disabled.
Why do all of the libraries seem to carry a "1beta1" when this is versioned
as a post-release package?
not sure why it was there, but the suffix looks correct in the latest 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".
Yeah, I can propose upstream to add a prefix on all, nice to see no conflicts
were found though.
http://giallu.fedorapeople.org/rdkit.spec
http://giallu.fedorapeople.org/rdkit-2013.03.2-1.fc18.src.rpm
--
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=EQXr2PQ4JE&a=cc_unsubscribe