clisp now builds on alpha and ia64

I used the more conservative flags of -D SAFETY=3 -D NO_MULTIMAP_SHM -D NO_MULTIMAP_FILE -D NO_SINGLEMAP -D NO_TRIVIALMAP for the more exotic architectures and it seems to work for alpha and itanium. The hppa buildd failed in a most strange way and I'm waiting with impatience for the results of the m68k and sparc jury :-).

telenet and proxy errors

My bother had severe problem with telenet (the local cable company) and he actually called the helpdesk while I was with him. I noticed the error they made and so could correct it. Normally they ask you to configure http://pac.telenet.be:8080 as pac file. The pack file is:

/* PAC FILE: VERSION MANAGEMENT WITH CVS
 * USE CVSWEB FOR UPDATING !!!
 *
 * Proxy autoconfig file
 *
 * $Revision: 1.29 $
 * $Date: 2004/04/01 06:58:30 $
 *
 */

function FindProxyForURL(url, host)
{
       return "DIRECT";
}

Notice that there is no proxy configured. When this did not work they asked to configure proxy.telenet.be:8080 as a proxy without disabling the pac stuff. This also did not work. After the long call on the expensive helpdesk I tried configuring the proxy and disabling the pac. That worked.

Of course as he was using an inferior operating system as a first step he had reinstalled everything, and lost some data he had forgotten to backup.

I wonder when they will fix the pac file...

Gains and losses

I've removed the hoary and hoary24 sections of the CL package repository I host on p.d.o.
On the other hand I and David D. Smith will adopt the clisp and libsigsegv packages that Will Newton took good care off up until now. We will coordinate the work through the darcs archives on cl-debian.alioth.debian.org.

Heads up: clc security problem

There is a security problem with common-lisp-controller: please read DSA-811 and upgrade as soon as possible.

The irony is that this is caused by moving to a simpler architecture because of (among other problems) security concerns :-(.

The sparc of fustration

sbcl now seems to compile on alpha and ppc again, on amd64 it already worked. sparc is leaving me in suspense already for 6 days now, on the buildd page you can see it going up and down the build queue. Highest position so far: 3. Now it is at 5 again.

Anyway, as sbcl has to wait on glibc to enter testing, which is waiting for gcc-4.0 (nice overview here), I reckon a new testing sbcl is not going to happen anytime soon.

sbcl progress

For the last few days I've been searching for obscure sbcl crashes. It seems at the end it will not only crash if the locale is not known, but also if you are running a threading-enabled sbcl on a 2.4 kernel.
I narrowed the problem down to sbcl crashing in a pretty standard libc call: nl_langinfo. This seems related to the fact that on 2.6 glibc uses futex'es to lock non-re-entrant functions, but on 2.4 it uses signals but I fail to see how this could create a simple crash. Trying to investigate it is rather difficult because the problems changes if you use ltrace or strace, actually the crash location moves sometimes.
So in the end I decided:

• To make sbcl-with-threading die on a 2.4 kernel or if NPTL is not available.
• make separate sbcl images without threading for people that are still using 2.4

.
So now we have multiple cl-debian repositories:

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

  for sarge 2.6 kernel

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

  for sarge 2.4 kernel

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

  for hoary 2.6 kernel

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

  for hoary 2.4 kernel

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

  for breezy (only 2.6 kernel)

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

  for sid (only 2.6 kernel)

Regarding my darcs repository (at http://cl-debian.alioth.debian.org/repository/pvaneynd: for now it is rather nice to work with darcs. The only problem I'm having is with large changes like moving lazy-sbcl from version 0.9.0 to 0.9.3 with all the changes involved. But going step by step also seems to work well.

3 up, 2 down

The last few days I've been buzy putting my numerous packages into darcs. So far I quite like this versioning system, there are however a few problems:

• it cannot handle epochs
• a lot of my packages' upstream seems to have gone or moved
• some of my packages are native packages, but they are not directly related to debian. I think this was just because the previous maintainer (like me) was part of the upstream team and disliked the additional problems caused by a non-native package. This is starting to bite however and when I try to reverse the situation I often see that the debian version is higher then the last official release of that project. So I need to use epochs. See point 1 :-(.

So my big plan to have all my packages in darcs and attracting a multitude of helpers seems to have fallen foul. I will still try to get this into some shape and make it available...

sbcl has run into some gcc-4 problem on some platforms and cmucl won't even build using gcc-4. A lot of work needs to be done and there is so little time, mostly because of the evil daen free library that is sucking away hours like a baby milk.