chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] manual and chicken4 infrastructure


From: felix winkelmann
Subject: Re: [Chicken-hackers] manual and chicken4 infrastructure
Date: Mon, 6 Apr 2009 00:41:57 +0200

On Mon, Mar 30, 2009 at 2:26 PM, Marijn Schouten (hkBst)
<address@hidden> wrote:
>
> 1) How would I run the tests after installation to a non-trivial DESTDIR? One
> problem here is to not use any files from a possible other chicken that is
> installed to /.

This is a bit broken, I must admit. Running the full test-suite requires
an installed chicken. But I can look into this, unless you need a solution
soon.

>
> 2) Gentoo policy requires documentation in
> /usr/share/doc/<package-name-and-version>/ so I am sed'ing this into 
> defaults.make:
> - -DOCDIR = $(DATADIR)/doc

Yup.

> 3) Our package manager (portage) complains about executable stacks and missing
> sonames. Quoting some of the output:
>
>  * QA Notice: The following files contain executable stacks
>  *  Files with executable stacks will not work properly (or at all!)
>  *  on some architectures/operating systems.
>  *  For more information, see http://hardened.gentoo.org/gnu-stack.xml
>  * RWX --- --- usr/bin/chicken-bug
>  * RWX --- --- usr/lib64/libchicken.so
>  * RWX --- --- usr/lib64/libuchicken.so
>  * !WX --- --- usr/lib64/libuchickenchicken-4.0.0.tar.gz:apply-hack.x86-64.o
>  * !WX --- --- usr/lib64/libchickenchicken-4.0.0.tar.gz:apply-hack.x86-64.o
>

I don't know the least bit what this means.

>
>  * QA Notice: The following shared libraries lack a SONAME
>  *  /var/tmp/portage/dev-scheme/chicken-4.0.0/image/usr/lib64/libchicken.so
>  *  /var/tmp/portage/dev-scheme/chicken-4.0.0/image/usr/lib64/libuchicken.so
>

Yeah, it's currently disabled. We'll put it back somehow, later.

> I don't feel very strongly about this one, but maybe you find it interesting.
>
> 4) It seems that the file you are using to release the release candidate does
> not encode the version in the URL. I would like to put the release candidate
> into our overlay (which is where we test stuff and make no guarantees) but our
> package manager will make a local copy of the tarball and if you then change 
> the
> file (without changing the name) users will be surprised. This issue will 
> cause
> me to keep my package for myself until you make a real release.

Yes, that's a mistake on my part. I should have used a different version.

But don't worry. I'll the release 4.0.0 right now at this moment.


cheers,
felix




reply via email to

[Prev in Thread] Current Thread [Next in Thread]