[Bug 562226] Review Request: ccl - Free Common Lisp implementation

[bugzilla at redhat.com]

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 at 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.