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(a)fsfe.org> 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.