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.

New Common Lisp based repositories

I've expanded my repositories on people.debian.org. Add to /etc/apt/sources.list:

• for sarge (aka stable):

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

• for unstable (for packages still in the NEW queue and pre-release stuff):

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

• and finally (upon great request) for ubuntu/hoary:

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

I also subscribed the cl-debian mailing list to most Common Lisp packages in debian, so members will see traffic when people upload new versions etc. Feel free to suggest new packages by subscribing them to the pts@qa.

I'm also planning to upload an experimental lazy allocating sbcl to those repositories, but will not upload it into debian proper unless there is popular demand for it.

19b-pre1 as debian package

in the p.d.o/~pvaneynd repository and directly here.

created a MOTU Common Lisp team for ubuntu

I created a Common Lisp MOTU team for ubuntu. As the entry requirements for membership are quite a bit lower for ubuntu then for debian I hope that more people will want to co-maintain packages.
To this end I should investigate version control systems that can handle 'upstream' in CVS or darcs. Maybe the debian directory in darcs and then use dpatch to patch the original source.
In related news I got the lazy allocation patch for sbcl. In the end it gets pretty nice I only need to use the sigsegv handler for static, read-only and linkage-table space. For the dynamic space the lisp uses the C alloc function to allocate memory, and using this function you can mmap memory on the fly. This patch opens the way for having a bigger on-demand dynamic space or a dynamic space with holes. But reception to the patch has been rather cold. I'll try to create a sbcl-lazy package for debian anyway, but only on the p.d.o repository, not in unstable unless people demand it.

ubuntu too?

A user asked if the p.d.o repository would work with ubuntu. A quick check showed that it would not work (libc version conflict), but I guess this is just a false dependency and a quick rebuild should solve it. But I would rather not keep up with 2 build systems and 2 bts. So googling for 'debian developers faq to ubuntu' got me nothing.
I fear I will have to start listening to Queen and talk to the MOTU :-).

Repository for cl packages

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.

To slime or not to slime

I have mutilated the slime package of Sean Champ with the current CVS HEAD of slime, changed the version number to something without epoch and I'm actually pretty happy with it.

The moral problem now is to upload it, or not. There is a dire need for slime in debian and the package seems to work correctly. The problem is that the packager seems unresponsive to email already for quite a while and I don't want to hijack his package. Should I just bite the bullet and upload or wait a little more... Sigh.