From pvaneynd at mailworks.org Sat May 7 09:31:58 2005 From: pvaneynd at mailworks.org (Peter Van Eynde) Date: Sat, 07 May 2005 11:31:58 +0200 Subject: [cl-debian] cl packages repository Message-ID: <427C8B0E.3030608@mailworks.org> 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 From rm at fabula.de Sat May 7 15:56:17 2005 From: rm at fabula.de (rm at fabula.de) Date: Sat, 7 May 2005 17:56:17 +0200 Subject: [cl-debian] cl packages repository In-Reply-To: <427C8B0E.3030608@mailworks.org> References: <427C8B0E.3030608@mailworks.org> Message-ID: <20050507155617.GA3395@seid-online.de> 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. The ugly part of this: sbcl will _not_ emit any warnings about an unknown switch ... but will drop into the debugger on the first error encountered. Not too much fun for an authomated build :-/ - 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. Cheers RalfD and thanks for all that work! [1] See for example my conversation with Juho Snellman and trentbuck at http://meme.b9.com/cview.html?channel=lisp&date=050505, starting at 00:45:07 (yes, debugging sbcl eats a lot of time ;) > Groetjes, Peter > _______________________________________________ > cl-debian mailing list > cl-debian at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cl-debian From pvaneynd at mailworks.org Sat May 7 20:21:04 2005 From: pvaneynd at mailworks.org (Peter Van Eynde) Date: Sat, 07 May 2005 22:21:04 +0200 Subject: [cl-debian] cl packages repository In-Reply-To: <20050507155617.GA3395@seid-online.de> References: <427C8B0E.3030608@mailworks.org> <20050507155617.GA3395@seid-online.de> Message-ID: <427D2330.6030104@mailworks.org> rm at fabula.de 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! Thanks for finding and correcting all my numerous mistakes :-) Groetjes, Peter From rm at fabula.de Sun May 8 20:43:44 2005 From: rm at fabula.de (rm at fabula.de) Date: Sun, 8 May 2005 22:43:44 +0200 Subject: [cl-debian] cl packages repository In-Reply-To: <427D2330.6030104@mailworks.org> References: <427C8B0E.3030608@mailworks.org> <20050507155617.GA3395@seid-online.de> <427D2330.6030104@mailworks.org> Message-ID: <20050508204344.GB15304@seid-online.de> On Sat, May 07, 2005 at 10:21:04PM +0200, Peter Van Eynde wrote: > rm at fabula.de 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 -GNUMAKE=make sh -c 'cd tests && sh ./run-tests.sh > test.log 2>&1' || printf "the tests failed\n" touch build-arch-stamp The problem you refer to i part of the build of the contrib sub system. From the file 'STANDARDS' in this directory: *------------------------------------------------------------------------------ | | A contrib package must contain a Makefile. This is to have three targets | | all: # do whatever compilation is necessary | test: # run the package tests | install: # copy all necessary files into $(BUILD_ROOT)$(INSTALL_DIR) | and later on: * Tests . | You must provide a 'test' target in your package Makefile. This will | be called to test whether your package is OK for installation, so if | you have used SBCL internal interfaces or similar, this would be a | good place to test that they still exist, etc. . Soooo - hmm, looking at the file $(SBCL)/contrib/sb-bsd-sockets/test.lisp there seems to be a feature test #+internet-available -- maybe it's enough to add this to the sylog-test (even so the whole thing is rather stupid - a test for build success shouldn't just write a silly message to the system log with level _7_ ...). > > - 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. Ok, i could've sent you a patch :-) Cheers Ralf Mattes > > and thanks for all that work! > > Thanks for finding and correcting all my numerous mistakes :-) > > Groetjes, Peter > _______________________________________________ > cl-debian mailing list > cl-debian at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cl-debian From rm at mh-freiburg.de Thu May 12 15:00:17 2005 From: rm at mh-freiburg.de (R. Mattes) Date: Thu, 12 May 2005 17:00:17 +0200 Subject: [cl-debian] Vhanges in bit-bash.lisp Message-ID: 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 From rm at mh-freiburg.de Thu May 12 20:48:01 2005 From: rm at mh-freiburg.de (R. Mattes) Date: Thu, 12 May 2005 22:48:01 +0200 Subject: [cl-debian] Re: Changes in bit-bash.lisp References: Message-ID: On Thu, 12 May 2005 17:03:38 +0100, Christophe Rhodes wrote: > "R. Mattes" 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 From cl-debian at pvaneynd.mailworks.org Fri May 20 22:38:05 2005 From: cl-debian at pvaneynd.mailworks.org (Peter Van Eynde) Date: Sat, 21 May 2005 00:38:05 +0200 Subject: [cl-debian] New sbcl packages uploaded to p.d.o/~pvaneynd Message-ID: <428E66CD.2080207@pvaneynd.mailworks.org> 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| From rm at fabula.de Sat May 21 13:34:39 2005 From: rm at fabula.de (rm at fabula.de) Date: Sat, 21 May 2005 15:34:39 +0200 Subject: [cl-debian] New sbcl packages uploaded to p.d.o/~pvaneynd In-Reply-To: <428E66CD.2080207@pvaneynd.mailworks.org> References: <428E66CD.2080207@pvaneynd.mailworks.org> Message-ID: <20050521133439.GA28348@seid-online.de> 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' | //finishing /LISP/DEBS/sbcl-0.9.0.39/local-target-features.lisp-expr | //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 | | real 0m0.037s | user 0m0.018s | sys 0m0.008s | make: *** [build-arch-stamp] Error 1 | Somehow the binary and core form the first build disappear ... this is not new, it happend with all the recent builds. I'm about to debug this later today and/or tomorrow. What i currently don't understand is the fact that this seems to build fine on your box. Darn, but i think i know how to trace down the problem ... Cheers and have a nice weekend Ralf Mattes > -- > signature -at- pvaneynd.mailworks.org > http://www.livejournal.com/users/pvaneynd/ > "God, root, what is difference?" Pitr | "God is more forgiving." Dave > Aronson| > _______________________________________________ > cl-debian mailing list > cl-debian at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cl-debian From cl-debian at pvaneynd.mailworks.org Sat May 21 13:52:05 2005 From: cl-debian at pvaneynd.mailworks.org (Peter Van Eynde) Date: Sat, 21 May 2005 15:52:05 +0200 Subject: [cl-debian] New sbcl packages uploaded to p.d.o/~pvaneynd In-Reply-To: <20050521133439.GA28348@seid-online.de> References: <428E66CD.2080207@pvaneynd.mailworks.org> <20050521133439.GA28348@seid-online.de> Message-ID: <428F3D05.2080509@pvaneynd.mailworks.org> 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? 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| From rm at fabula.de Sat May 21 17:29:07 2005 From: rm at fabula.de (rm at fabula.de) Date: Sat, 21 May 2005 19:29:07 +0200 Subject: [cl-debian] New sbcl packages uploaded to p.d.o/~pvaneynd In-Reply-To: <428F3D05.2080509@pvaneynd.mailworks.org> References: <428E66CD.2080207@pvaneynd.mailworks.org> <20050521133439.GA28348@seid-online.de> <428F3D05.2080509@pvaneynd.mailworks.org> Message-ID: <20050521172907.GB28348@seid-online.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| From rvb at pro-linux.de Sun May 29 17:39:40 2005 From: rvb at pro-linux.de (=?utf-8?B?UmVuw6k=?= van Bevern) Date: Sun, 29 May 2005 19:39:40 +0200 Subject: [cl-debian] RFS: cl-fad and cl-screen-sbcl Message-ID: <20050529173939.GD3639@negoyl> Hello, I am looking for a sponsor for cl-fad (ITP #311073) and cl-screen-sbcl (ITP #311071). Package descriptions and download URLs can be found in the ITPs. I am still uncertain about the naming of cl-screen-sbcl. The thing itself is called sb-screen, but I followed the other SBCL-only package cl-clx-sbcl for the name. Regards, Ren? van Bevern -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: not available URL: From rvb at pro-linux.de Mon May 30 09:04:37 2005 From: rvb at pro-linux.de (=?utf-8?B?UmVuw6k=?= van Bevern) Date: Mon, 30 May 2005 11:04:37 +0200 Subject: [cl-debian] RFS: cl-fad and cl-screen-sbcl In-Reply-To: <429AC3A9.1030804@pvaneynd.mailworks.org> References: <20050529173939.GD3639@negoyl> <429AC3A9.1030804@pvaneynd.mailworks.org> Message-ID: <20050530090436.GA3634@negoyl> On 30.05.05, Peter Van Eynde wrote: Hi, > cl-fad looks ok, but for two things: > - it seems the current version is 0.2.0 Right, it was released right yesterday. :) > - "Depends: ${shlibs:Depends}" is not needed as we have no executables > in the package. It's gone. > I would be happy to sponsor both packages. I will wait with cl-fad until > you create an updated version. Thanks much. It is now updated, still available from deb-src ftp://progn.org/debian unstable main Regards, Ren? van Bevern -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: not available URL: From cl-debian at pvaneynd.mailworks.org Mon May 30 07:41:29 2005 From: cl-debian at pvaneynd.mailworks.org (Peter Van Eynde) Date: Mon, 30 May 2005 09:41:29 +0200 Subject: [cl-debian] RFS: cl-fad and cl-screen-sbcl In-Reply-To: <20050529173939.GD3639@negoyl> References: <20050529173939.GD3639@negoyl> Message-ID: <429AC3A9.1030804@pvaneynd.mailworks.org> Ren? van Bevern wrote: > Hello, > > I am looking for a sponsor for cl-fad (ITP #311073) and cl-screen-sbcl cl-fad looks ok, but for two things: - it seems the current version is 0.2.0 - "Depends: ${shlibs:Depends}" is not needed as we have no executables in the package. cl-screen-sbcl also looks ok. > I am still uncertain about the naming of cl-screen-sbcl. The thing > itself is called sb-screen, but I followed the other SBCL-only package > cl-clx-sbcl for the name. I would do the same. I would be happy to sponsor both packages. I will wait with cl-fad until you create an updated version. 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| From cl-debian at pvaneynd.mailworks.org Mon May 30 11:56:19 2005 From: cl-debian at pvaneynd.mailworks.org (Peter Van Eynde) Date: Mon, 30 May 2005 13:56:19 +0200 Subject: [cl-debian] RFS: cl-fad and cl-screen-sbcl In-Reply-To: <20050530090436.GA3634@negoyl> References: <20050529173939.GD3639@negoyl> <429AC3A9.1030804@pvaneynd.mailworks.org> <20050530090436.GA3634@negoyl> Message-ID: <429AFF63.2090303@pvaneynd.mailworks.org> Ren? van Bevern wrote: > Thanks much. It is now updated, still available from > deb-src ftp://progn.org/debian unstable main Ok. I will upload it to p.d.o and later (after the sarge release) to unstable. 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|