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=562226 --- Comment #14 from Alexander Kahl <e-user@xxxxxxxx> 2010-11-26 11:11:24 EST --- Hey Jason, let's go: (In reply to comment #12) > ccl.x86_64: W: executable-stack /usr/lib64/ccl/lx86cl64 > This implies that there will be selinux problems. Sure? I can execute the kernel in enforcing mode without any prior policy tampering :) > ccl.x86_64: E: non-standard-executable-perm /usr/lib64/ccl/lx86cl64 0775L > I think this is due to a mock bug and is specific to some buildsystems; if it > doesn't happen for you then it should probably be ignored. Yeah, so it seems - local building doesn't seem to cause this. > ccl.x86_64: W: no-manual-page-for-binary ccl > Nice to have a manual page for command line applications. Not essential, > though. True. > ccl-contrib.x86_64: W: only-non-binary-in-usr-lib > ccl-examples.x86_64: W: only-non-binary-in-usr-lib > Why aren't these noarch, with the content in /usr/share? Because it's loadable examples / contributed code with hardwired load paths in the heap image, please see `ccl-1.5/linuxx86/ccl/l1-pathnames.lisp', global variable *module-search-path*. > Or better yet, why > are they not documentation instead? I could inject some code into the image that modifies the paths.. but loading files from %_docdir feels wrong somehow. %{_datadir}/ccl should be the way to go as %{_datadir}/common-lisp/source is CL implementation-independent. Please share your thoughts - is using ccl's home in %_libdir really that problematic? > Also, are the examples actually useful? The FFI examples, definitely. The gtk clock looks ugly but works... what do you actually mean by "useful"? :) > The cocoa stuff is apple-specific, is it not? Hmm right, I could leave that out if you want - have a note about this in >> README.Fedora? > ccl-contrib.x86_64: W: devel-file-in-non-devel-package > /usr/lib64/ccl/contrib/krueger/InterfaceProjects/Lisp > IB Plugins/LispControllerPlugin/LispControllerPlugin.h > ccl-contrib.x86_64: W: devel-file-in-non-devel-package > /usr/lib64/ccl/contrib/krueger/InterfaceProjects/Lisp > IB Plugins/LispControllerPlugin/LispControllerInspector.h > ccl-contrib.x86_64: W: devel-file-in-non-devel-package > /usr/lib64/ccl/contrib/krueger/InterfaceProjects/Lisp > IB Plugins/LispControllerPlugin/LispController.h > ccl-examples.x86_64: W: devel-file-in-non-devel-package > > /usr/lib64/ccl/examples/FFI/Allocating-foreign-data-on-the-lisp-heap/ptrtest.c > ccl-examples.x86_64: W: devel-file-in-non-devel-package > /usr/lib64/ccl/examples/FFI/Using-basic-calls-and-types/typetest.c > These are examples, so I expect this is OK, but see the previous complaint. The C source files get compiled and their results directly accessed from the lisp ones (-> FFI = Foreign Function Interface), moving them where they probably belong (%_datadir) won't make the warnings go away anyway. > ccl-contrib.x86_64: E: script-without-shebang > /usr/lib64/ccl/contrib/krueger/InterfaceProjects/Utilities/date.lisp > Why is this executable? How could it be run? The executable bit is spurious, fixed in next release. > Regarding PPC, it's still supported as a secondary arch, although I don't know > how much is happening with it currently. As a courtesy you can ExcludeArch: > the ppc stuff so they won't have to do it for you. You're right, added in next release. -- 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review