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
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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-debian
rm@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
On Sat, May 07, 2005 at 10:21:04PM +0200, Peter Van Eynde wrote:
rm@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-debian
participants (2)
-
Peter Van Eynde -
rm＠fabula.de