Peter Van Eynde | 7 May 11:31 2005

cl packages repository

To keep the momentum in the cl packages during the freeze I created a
apt-getables repository. Add

deb http://people.debian.org/~pvaneynd/cl-packages ./

to /etc/apt/sources.list to get updates Common Lisp packages.

Groetjes, Peter
rm | 7 May 17:56 2005
Picon

Re: cl packages repository

On Sat, May 07, 2005 at 11:31:58AM +0200, Peter Van Eynde wrote:
> To keep the momentum in the cl packages during the freeze I created a
> apt-getables repository. Add
> 
> deb http://people.debian.org/~pvaneynd/cl-packages ./
> 
> to /etc/apt/sources.list to get updates Common Lisp packages.

Hi Peter,

nice idea to set up this repository. Here some more comments on my
recent sbcl on PPC/Linux experiences:

 - First of all, good idea to dissable running the tests during 
   a package build. This was one _major_ showstopper. From some
   talk om #lisp i got the impression that these tests are meant
   more as checks for the developers rather than confirmations of
   a successfull build (too bad, such a test would be fine). [1]
   Hmm, in my local setup i wasn't so radical as to disable the
   tests, i just prepended the invocation of run-tests.sh with
   a '-' in the rules file (so a failing test wouldn't stop the
   build).

 - there's another bug lurking in the build: your rukes-file invokes
   sbcl using the -noprogrammer switch. According to the NEWS file:

    * incompatible change: the --noprogrammer option, deprecated since
      version 0.7.5, has been removed.  Please use the equivalent
      --disable-debugger option instead.

(Continue reading)

Peter Van Eynde | 7 May 22:21 2005

Re: cl packages repository

rm@... wrote:
>  - First of all, good idea to dissable running the tests during 
...
>    Hmm, in my local setup i wasn't so radical as to disable the
>    tests, i just prepended the invocation of run-tests.sh with
>    a '-' in the rules file (so a failing test wouldn't stop the
>    build).

A failing test would not alone stop the build but prevent the subsystem
from getting installed. This was the sb-bsd-socket problem: there was no
/dev/log on the amd64 buildd, so the test failed, so the subsystem did not
get installed.

At least this is my understanding.

>  - there's another bug lurking in the build: your rukes-file invokes
>    sbcl using the -noprogrammer switch. According to the NEWS file:

Fixed.

>  - As for the unicode/Locale issue: your rule-file silently assumes
>    that en_US.UTF-8 is available on the build host (which _might_ be
>    true for the official build daemons but not for private setups that
>    use apt-build). I've gone the long way of following the suggestions
>    in the Debian package maintainer manual. I'll prepare a patch against
>    your new sources if you want me to.

You mean 6.7.6? I will implement it asap.

>  and thanks for all that work!
(Continue reading)

rm | 8 May 22:43 2005
Picon

Re: cl packages repository

On Sat, May 07, 2005 at 10:21:04PM +0200, Peter Van Eynde wrote:
> rm@... wrote:
> >  - First of all, good idea to dissable running the tests during 
> ...
> >    Hmm, in my local setup i wasn't so radical as to disable the
> >    tests, i just prepended the invocation of run-tests.sh with
> >    a '-' in the rules file (so a failing test wouldn't stop the
> >    build).
> 
> A failing test would not alone stop the build but prevent the subsystem
> from getting installed. This was the sb-bsd-socket problem: there was no
> /dev/log on the amd64 buildd, so the test failed, so the subsystem did not
> get installed.
> 
> At least this is my understanding.

Hmm, i'm not shure whether we are talking about the same - i was refering to
the test suit in $(SBCL)/tests. Your rules file does the following:
	
	# start running tests
        GNUMAKE=make sh -c 'cd tests && sh ./run-tests.sh' || printf "the tests failed\n"
        # see what the result is
        touch build-arch-stamp

These tests seem to be meant as checks for the developers and not as a functionality-
test for builds (BTW, the comment is missleading - there's no check for the results).
I changed this into:

 
	# start running tests
(Continue reading)

R. Mattes | 12 May 17:00 2005
Picon

Vhanges in bit-bash.lisp

Hello list(s),

between version 1.17 and 1.18 of the file src/code/bit-bash.lisp the
functions copy-to-system-area et al. got removed. Since these functions 
are used in some libraries distributed as Debian (source) packages i'd
like to ask for some advice on how to hide these chages. Ideally these
libraries should run both under sbcl 0.8.n as well as sbcl 0.9.n. What
would be the preferred way to detect the availability of these functions?
BTW, is there a place in the sources where such changes are documented
(something like a ChangeLog)? Upgrading my systems without knowing a
priory where to expect problems sometimes quickly degrades into
trial-and-error ... :-) There seem to be changes/deprecations listed in
the NEWS file. Is this the place to check (if so, maybe someone should
add the bit-bash changes to the NEWS file).

 Thanks for all the work

  Ralf Mattes

R. Mattes | 12 May 22:48 2005
Picon

Re: Changes in bit-bash.lisp

On Thu, 12 May 2005 17:03:38 +0100, Christophe Rhodes wrote:

> "R. Mattes" <rm@...> writes:
> 
>> There seem to be changes/deprecations listed in the NEWS file. Is
>> this the place to check (if so, maybe someone should add the
>> bit-bash changes to the NEWS file).
> 
> These are only listed for changes to supported interfaces; the
> bit-bashers have never been documented as supported.

Ok, that makes sense -- i'll file a bug report against the Debian
apckages then.

 Thanks, Ralf Mattes

Peter Van Eynde | 21 May 00:38 2005

New sbcl packages uploaded to p.d.o/~pvaneynd

They include some unicode fix. See the lisp-web mailing list for more
information.

Groetjes, Peter

--

-- 
signature -at- pvaneynd.mailworks.org
http://www.livejournal.com/users/pvaneynd/
"God, root, what is difference?" Pitr | "God is more forgiving." Dave
Aronson|
rm | 21 May 15:34 2005
Picon

Re: New sbcl packages uploaded to p.d.o/~pvaneynd

On Sat, May 21, 2005 at 12:38:05AM +0200, Peter Van Eynde wrote:
> They include some unicode fix. See the lisp-web mailing list for more
> information.
> 
> Groetjes, Peter

Hi Peter,

over here hte same problems as always - the first build seems to work fine, but then:

|   
|    # rebuild again with new version
|    CFLAGS="-DSBCL_HOME=/usr/lib/sbcl/ -O2" GNUMAKE=make ./make.sh "`pwd`/stage1/sbcl --core
`pwd`/stage1/sbcl.core --sysinit /dev/null --userinit /dev/null --disable-debugger"
|    //starting build: Sat May 21 14:46:24 CEST 2005
|    //SBCL_XC_HOST="/LISP/DEBS/sbcl-0.9.0.39/stage1/sbcl --core
/LISP/DEBS/sbcl-0.9.0.39/stage1/sbcl.core --sysinit /dev/null --userinit /dev/null --disable-debugger"
|    //entering make-config.sh
|    //ensuring the existence of output/ directory
|    //initializing /LISP/DEBS/sbcl-0.9.0.39/local-target-features.lisp-expr
|    //guessing default target CPU architecture from host architecture
|    //setting up CPU-architecture-dependent information
|    sbcl_arch="ppc"
|    //setting up symlink src/compiler/target
|    //setting up symlink src/assembly/target
|    //setting up symlink src/compiler/assembly
|    //setting up OS-dependent information
|    make[1]: Entering directory `/usr/local/src/LISP/DEBS/sbcl-0.9.0.39/tools-for-build'
|    cc -DSBCL_HOME=/usr/lib/sbcl/ -O2 -I../src/runtime    where-is-mcontext.c   -o where-is-mcontext
|    make[1]: Leaving directory `/usr/local/src/LISP/DEBS/sbcl-0.9.0.39/tools-for-build'
(Continue reading)

Peter Van Eynde | 21 May 15:52 2005

Re: New sbcl packages uploaded to p.d.o/~pvaneynd

rm@... wrote:
> |    //entering make-host-1.sh
> |    //building cross-compiler, and doing first genesis
> |    make-host-1.sh: line 29: /LISP/DEBS/sbcl-0.9.0.39/stage1/sbcl: No such file or directory

Damn. The clean.sh script is a little too aggressive:
...
find. \( \
...
        -name '?*.core' -o \
...
        -name 'sbcl' -o \
...
        -name 'local-target-features.lisp-expr' \) -print | xargs rm -f

So it will find the stage1/sbcl stuff and remove it. To protect against
this I do:

        mv output/sbcl.core src/runtime/sbcl stage1/
        chmod 000 stage1
        sh clean.sh || true
        chmod 700 stage1
        # rebuild again with new version

Maybe the chmod 000 is not enough to protect it? I use "debuild
--rootcmd=fakeroot  -k4B729625" to build the package. I can imagine that
if you use for example sudo it might not protect stage1?

Groetjes, Peter

(Continue reading)

rm | 21 May 19:29 2005
Picon

Re: New sbcl packages uploaded to p.d.o/~pvaneynd


Hi Peter,

why are you working on a weekend?!? ;-)
Gives me not time to help you. Ok, after writing my last mail i started another build, this
time with a deactivated clean.sh. This seems to work (at least for the problem reported, more
later). 

On Sat, May 21, 2005 at 03:52:05PM +0200, Peter Van Eynde wrote:
> rm@... wrote:
> > |    //entering make-host-1.sh
> > |    //building cross-compiler, and doing first genesis
> > |    make-host-1.sh: line 29: /LISP/DEBS/sbcl-0.9.0.39/stage1/sbcl: No such file or directory
> 
> Damn. The clean.sh script is a little too aggressive:
> ...
> find. \( \
> ...
>         -name '?*.core' -o \
> ...
>         -name 'sbcl' -o \
> ...
>         -name 'local-target-features.lisp-expr' \) -print | xargs rm -f
> 
> So it will find the stage1/sbcl stuff and remove it. To protect against
> this I do:
> 
>         mv output/sbcl.core src/runtime/sbcl stage1/
>         chmod 000 stage1
>         sh clean.sh || true
(Continue reading)


Gmane