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.(Continue reading)
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)
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)
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
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
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|
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)
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)
Hi Peter, why are you working on a weekend?!?(Continue reading)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
RSS Feed31 | |
|---|---|
53 | |
69 | |
75 | |
103 | |
18 | |
101 | |
60 | |
117 | |
62 | |
86 | |
65 | |
42 | |
48 | |
85 | |
156 | |
138 | |
115 | |
120 | |
75 | |
131 | |
103 | |
96 | |
77 | |
85 | |
128 | |
179 | |
151 | |
98 | |
149 | |
42 | |
92 | |
14 | |
3 | |
15 |
