[cl-debian] New sbcl packages uploaded to p.d.o/~pvaneynd

[rm at fabula.de]

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 at fabula.de 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?

Hmm, i saw this and this was my first suspicion (and, removing clean.sh seems
to help). But i still don't see how clean.sh can actually remove files from
such a protected directory. I just quickly checked from the command line and
as soon as stage1 has 000 perms find doesn't find the files.
Actually, walking manually through these steps of the build everything works fine.
Miraculous :-/
Ok, the one other thing that's fragile: the script tests/run-tests.sh invokes 
the freshly build sbcl with the following arguments:
 
 --noinform --sysinit /dev/null --userinit /dev/null --noprint
 
 Hmm, there's definitely a --disable-debugger missing here, otherwise the build
 process will break into the debugger as soon as a test fails, and at least one
 test fails on Linux/PPC:

  debugger invoked on a SIMPLE-ERROR in thread 7520:
    The assertion (RAISES-ERROR? (SCALE-FLOAT 1.0 MOST-POSITIVE-FIXNUM)
    FLOATING-POINT-OVERFLOW) failed.
    test (pure.lisp files) failed, expected 104 return code, got 0

Nothing to worry (so i was told ...) the same test passes on the repl - i think
the test isn't stateless so other tests influnence this.

But, anyway, with a disabled clean.sh i managed to get a working sbcl Debian package :-)

 Thanks RalfD


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