[cl-debian] UCW status, seeing the light at the end of the tunnel
Hello, even if the title is quite melodramatic, I should say that in the last 2 weeks I made a lot of progress in (better understanding and) packaging UCW for Debian. If someone wants to help, here a roadmap, with the remaining issues... Strictly speaking, to have a simply UCW server up and running you don't need the whole bunch of packages I reported in the past [1]. In fact, if you use the internal httpd backend, you don't need any external web server. ATM, the following packages are already present in Debian and can be used without modification (and with modifications I don't include upstream updates, but "strong" hacking). They are: - arnesi - yaclml - iterate - cl-ppcre - puri - split-sequence - parenscript (in the NEW queue, see bug #349607 [2]) Other packages are present in Debian, but...: - SLIME swank, which thank to Peter doesn't depends on the Emacs code, but I'm suffering of a strange bug [3] on systems without the common-lisp-controller. - rfc2388 needs to be synchronized with the BESE version, see posts at [4] and [5] for more info. - detachtty needs an upgrade, at least including bug #282641 [6], which is a better solution than bug #282640 [7]). Probably it needs also a new maintainer, as the bugs are really old. The last two packages are not present in Debian: - rfc2109 [8], I already started the packaging and I'm waiting an answer from the author for a small license clarification. - trivial-sockets [9], I'm waiting an answer from the upstream author, who turns out to be the same as detachtty and also a Debian maintainer. Moreover, I just finished to test a series of patches that render UCW highly configurable without touching the source code, starting the UCW server throught the cl-launch script [10], which is already packaged by its upstream author, but not present in Debian. That's all :-) Thx, bye, Gismo / Luca [1] http://common-lisp.net/pipermail/cl-debian/2006-January/000962.html [2] http://bugs.debian.org/349607 [3] http://common-lisp.net/pipermail/slime-devel/2006-March/004664.html [4] http://common-lisp.net/pipermail/bese-devel/2005-December/001373.html [5] http://common-lisp.net/pipermail/cl-debian/2006-February/001069.html [6] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282641 [7] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282640 [8] http://wwww.common-lisp.net/project/rfc2109/ [9] http://www.cliki.net/trivial-sockets [10] http://www.cliki.net/cl-launch
Hello! On Sat, 18 Mar 2006 18:31:59 +0100, Luca Capello wrote:
- SLIME swank, which thank to Peter doesn't depends on the Emacs code, but I'm suffering of a strange bug [3] on systems without the common-lisp-controller.
I found a possible solution reported at [1] and I'm waiting for comments.
- rfc2109 [8], I already started the packaging and I'm waiting an answer from the author for a small license clarification.
ITP #359348 [2].
- trivial-sockets [9], I'm waiting an answer from the upstream author, who turns out to be the same as detachtty and also a Debian maintainer.
ITP #359339 [3].
Moreover, I just finished to test a series of patches that render UCW highly configurable without touching the source code, starting the UCW server throught the cl-launch script [10], which is already packaged by its upstream author, but not present in Debian.
I'm cc:ing this mail to the upstream author (just to be sure he's aware, even if IIRC he's subscribed). Thx, bye, Gismo / Luca [1] http://common-lisp.net/pipermail/slime-devel/2006-March/004698.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359348 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359339
Dear Luca, dear all, On 28/03/06, Luca Capello <luca@pca.it> wrote:
Moreover, I just finished to test a series of patches that render UCW highly configurable without touching the source code, starting the UCW server throught the cl-launch script [10], which is already packaged by its upstream author, but not present in Debian.
I'm cc:ing this mail to the upstream author (just to be sure he's aware, even if IIRC he's subscribed).
I've just updated my cl-launch deb to 1.72-1, including slight modifications to play well with the newest kind of saved sbcl executables. Still lacking is support for saving images. I guess that would make for cl-launch 2.0. I don't know at this point what is needed for cl-launch to be accepted as an official debian package. I guess the main thing lacking is an official debian package maintainer. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Toleration is not about believing that stupid people are intelligent, it's about letting stupid people be victims of their own stupidity rather than being victims of yours.
On Wednesday 29 March 2006 19:21, Faré wrote:
I don't know at this point what is needed for cl-launch to be accepted as an official debian package. I guess the main thing lacking is an official debian package maintainer.
Hello Faré, Actually there is no need for an official maintainer. I had a quick look and despite some fundamental disagreements (like the cache beneath ~/) the package does look good. The only comment I can make is that it uses a dash (1.79-1) which for a native package is not good, in any case I would advice you to make it a non-native package so other people can upload fixes without increasing 'your' version needlessly. If you intend to support the package I would be happy to upload it for you. 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 29/03/06, Peter Van Eynde <pvaneynd@debian.org> wrote:
On Wednesday 29 March 2006 19:21, Faré wrote:
I don't know at this point what is needed for cl-launch to be accepted as an official debian package. I guess the main thing lacking is an official debian package maintainer.
Hello Faré, Hi Peter,
Actually there is no need for an official maintainer. I had a quick look and despite some fundamental disagreements (like the cache beneath ~/) the package does look good. Well, you must understand that at least the default, portable, non-debian version of cl-launch CANNOT assume anything like the common-lisp-controller cache hierarchy. However, if you patch cl-launch to have it share the c-l-c cache when appropriate (which supposes we properly detect the lisp version, too, because I for one use both the debian sbcl and my own compiled sbcl's on the same machine -- but I suppose that if c-l-c is in the current image then it can be assumed to be the only c-l-c image for given implementation), then I'll be glad to include it upstream.
The only comment I can make is that it uses a dash (1.79-1) which for a native package is not good, in any case I would advice you to make it a non-native package so other people can upload fixes without increasing 'your' version needlessly. Will be done shortly.
If you intend to support the package I would be happy to upload it for you. I certainly intend to support the package.
Actually, I'm eager to have opinions on how cl-launch should work with respect to saving and restoring images for faster startup. What is the right way to handle lisp invocation arguments, etc.? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] The fear of death follows from the fear of life. A man who lives fully is prepared to die at any time. -- Mark Twain
On 29/03/06, Faré <fahree@gmail.com> wrote:
On 29/03/06, Peter Van Eynde <pvaneynd@debian.org> wrote:
The only comment I can make is that it uses a dash (1.79-1) which for a native package is not good, in any case I would advice you to make it a non-native package so other people can upload fixes without increasing 'your' version needlessly. Will be done shortly. Done.
http://fare.tunes.org/files/cl-launch/ Since I used 1.72-1 previously, you'd better start any debian patch with 1.72-2. Next released version will I hope be 2.0, with some support for dumping images.
I certainly intend to support the package.
Actually, I'm eager to have opinions on how cl-launch should work with respect to saving and restoring images for faster startup. What is the right way to handle lisp invocation arguments, etc.?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You tell me what you mean by God, and I'll tell you whether I believe in him or not! -- E. O. James
Hello! On Tue, 28 Mar 2006 12:48:37 +0200, Luca Capello wrote:
- trivial-sockets [9], I'm waiting an answer from the upstream author, who turns out to be the same as detachtty and also a Debian maintainer.
ITP #359339 [3].
trivial-sockets is ready to be uploaded :-) I also prepared new checkouts for the BESE software: - arnesi - fiveam - qbook - parenscript - yaclml Peter, when you find some spare time, please. Thx, bye, Gismo / Luca
participants (3)
-
Faré -
Luca Capello -
Peter Van Eynde