February 2006 - cl-debian@common-lisp.net

[cl-debian] Bug#330468: sbcl: Can't start sbcl with kernel 2.4.27-2-686
by Didier Verna 28 Jun '07

28 Jun '07

Package: sbcl Version: 1:0.9.4.65-1 Severity: grave Hi ! When I try to launch SBCL, I get the following message: ,---- | fatal error encountered in SBCL pid 10204(tid 16384): | This version of sbcl is compiled with threading support, but your kernel is | too old to support this. Please use a more recent kernel or a version of sbcl | without threading support. `----- ... which I consider a bug since the Debian package installed just fine, and there don't seem to be an alternative sbcl package usable for me. I don't want to use a 2.6 kernel on my machine. So what should I do ? Thanks ! -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages sbcl depends on: ii common-lisp-controller 4.18 This is a Common Lisp source and c ii libc6 2.3.5-6 GNU C Library: Shared libraries an ii sbcl-common 1:0.9.4.65-1 Architecture independent files for Versions of packages sbcl recommends: ii binfmt-support 1.2.6 Support for extra binary formats -- no debconf information

4 4

[cl-debian] Bug#347560: gclcvs: incorrect purge
by Adam Warner 29 Aug '06

29 Aug '06

Package: gclcvs Hi Camm, I purged the unstable version of gclcvs to gain some free space. Here's the console output: # apt-get remove --purge gclcvs gclcvs-doc Reading package lists... Done Building dependency tree... Done The following packages will be REMOVED: gclcvs* gclcvs-doc* 0 upgraded, 0 newly installed, 2 to remove and 242 not upgraded. Need to get 0B of archives. After unpacking 122MB disk space will be freed. Do you want to continue [Y/n]? (Reading database ... 126455 files and directories currently installed.) Removing gclcvs ... gclcvs.sh Uninstalling clc and restoring pristine orig image ... rm: cannot remove `>': Is a directory gclcvs.sh Uninstalling clc and restoring pristine orig image ... rm: cannot remove `>': Is a directory remove/gclcvs: purging byte-compiled files for emacs21 Purging configuration files for gclcvs ... dpkg - warning: while removing gclcvs, directory `/usr/lib/gcl-2.7.0-prof/unixport' not empty so not removed. dpkg - warning: while removing gclcvs, directory `/usr/lib/gcl-2.7.0-prof' not empty so not removed. dpkg - warning: while removing gclcvs, directory `/usr/lib/gcl-2.7.0/unixport' not empty so not removed. dpkg - warning: while removing gclcvs, directory `/usr/lib/gcl-2.7.0' not empty so not removed. Removing gclcvs-doc ... I suspect "rm: cannot remove `>': Is a directory" is due to incorrect escaping (/usr/lib/gcl-2.7.0/unixport and /usr/lib/gcl-2.7.0-prof both contain a file named 'saved_clc_gcl?>') Regards, Adam

2 1

[cl-debian] Bug#342967: Package explicitely build-depends on g++-3.4
by Matthias Klose 29 Aug '06

29 Aug '06

Package: gclcvs Usertag: g++-3.4 This package build-depends for some reason on g++-3.4 (most likely, because it could not be built with a newer g++ version. We would like to get rid of g++-3.4 for the etch release, although currently not a hard release goal. Please (re)check, if the package can be built by g++, and if not, if it can be built using gcc-snapshot (or g++-4.1, currently found in experimental). Please keep the bug report open until you can avoid the build dependency on g++-3.4. Collect further information in this bug report (i.e. if it builds with a newer/experimental version). (Side note: PR c++/21123 is now fixed in g++-4.0, allowing many KDE related packages to build on arm/hppa/m68k with the default g++ A build-dependency on g++ (>= 4:4.0.2-2) is currently needed until all the buildds use this version.

3 2

[cl-debian] Bug#338613: The clc-dumped image's name is wrong--a bug in gclcvs.sh
by Chun Tian (binghe) 29 Aug '06

29 Aug '06

Package: gclcvs Version: 2.7.0-50.1 Severity: Normal For many days, when I've installed gclcvs, a directory named '>' will be in / or /root ... So I tracked this bug, then found a bug in /usr/lib/common-lisp/bin/gclcvs.sh (debian/in-gcl-clc.sh), because of this two line: image=$($gcl_bin -batch -eval '(princ (namestring (merge-pathnames (make-pathname :name saved_clc_gcl") (pathname si:*system-directory*))))'</dev/null) gcl_clc=$($gcl_bin -batch -eval '(princ (namestring (make-pathname :directory (append pathname-directory (pathname "/usr/lib/common-lisp/")) (last (pathname-directory (pathname si::*lib-directory*)))))))'</dev/null) I found gclcvs whith '-batch' won't auto exit when the eval end, so a '\n' and '>' will append to the $image and $gcl_clc. This makes the name of the image file which this script generate IS NOT correct, so that /usr/bin/gclcvs cannot load them. I don't know the function '-batch', but a simple solution: add a (quit) at the end of these 'eval', like that: (and I don't need a '</dev/null' any more) image=$($gcl_bin -batch -eval '(progn (princ (namestring (merge-pathnames (make-pathname :name saved_clc_gcl") (pathname si:*system-directory*)))) (quit))') gcl_clc=$($gcl_bin -batch -eval '(progn (princ (namestring (make-pathname :directory (append (pathname-directory (pathname "/usr/lib/common-lisp/")) (last (pathname-directory (pathname si::*lib-directory*))))))) (quit))') Thanks. -- GnuPG Key: 0xF7C63B10

2 1

[cl-debian] Bug#340442: cl-swank: Removing package leaves variable slime-backend set
by Nicolas Neuss 28 Jul '06

28 Jul '06

Package: cl-swank Severity: normal I encountered problems using the SLIME package with SBCL. Then I wanted to switch to CVS Slime by removing the slime and cl-swank packages. Strangely, this did not work, because even after "emacs -q" the variable slime-backend is still set to "/usr/share/common-lisp/source/slime/swank-loader.lisp" -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

4 3

[cl-debian] Bug#323274: wishlist: packaging of SBCL sources; recording of source-definitions for lisp forms
by Sean Champ 08 Jul '06

08 Jul '06

Package: sbcl Version: 1:0.9.3.0-2 Severity: wishlist [*] Introduction Today, I was trying to use SLIME's `slime-edit-definition', in order to learn a bit more about what is defined in SBCL. However, on a number of forms, when I tried to view their definitions, SBCL produced messages like Error: Source filename not recorded for ... That was so, on (DEFGENERIC STREAM-LINE-COLUMN) (METHOD STREAM-LINE-COLUMN (FUNDAMENTAL-CHARACTER-OUTPUT-STREAM)) Yet, for (METHOD STREAM-LINE-COLUMN (SWANK-BACKEND::SLIME-OUTPUT-STREAM)) SBCL is able to determine where that method is defined -- presumably, given that the sources for that method's definition are available on the local system, and given that the code would have been compiled with an DEBUG OPTIMIZE of quality 2 or greater [incidental ref: SBCL manual, Source Location Availability], and given the nature of it, a method definition, such that the source location would be recoded, for it. [*] The Request I do not mean to ask overmuch, but if there would be an opportunity that the SBCL sources would be made available in a Debian package, and if SBCL -- in its availability with Debian -- would be available as being compiled, with such an OPTIMIZE DEBUG proclamation that SBCL would record the source defintions of appropriate forms, then I am sure it would be of help, for many users of SBCL (at the very least, for our becoming acquainted with the SBCL source-code) Though I realize that I may try to address this request, directly upon the Debian source package for SBCL, yet it might take me some while, as to produce anything useful of it. Also, I would only be able to address it for x86 architectures. Regardless, I have thought that this should be addressed as a wishlist item, about the Debian SBCL release. While I realize that it would probably result in some change in the performance of SBCL, if it would be compiled with such a DEBUG quality as would be needed for it to record source locations, yet it may be of use, to who would intend to see the definition of a form, within the SBCL sources. As such, it may be of help, towards the continuing development of SBCL. [*] Addressing Attendant Concerns If it would serve to ease any concern about performance, then to have the matter brought to any reader's attention: Anyone might derive a package for a particularly optimized SBCL, deriving the package upon the Debian SBCL packages -- editing the debian/* files, as to adapt the commands for the compilation, and to adjust package-names, in order to avoid naming conflicts -- then, of course, running debuild and/or any more of the pacakge-buiding tools. Hopefully, such would not result in a bewildering array of SBCL packags, but hey, "what can one say". Thank you. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i586) Kernel: Linux 2.6.11.8 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages sbcl depends on: ii common-lisp-controller 4.12 This is a Common Lisp source and c ii libc6 2.3.5-3 GNU C Library: Shared libraries an ii sbcl-common 1:0.8.21.16-2 Architecture independent files for -- debconf information excluded

2 1

[cl-debian] Bug#344629: gcl: French debconf templates translation update
by Sylvain Archenault 27 Jun '06

27 Jun '06

Package: gcl Version: N/A Severity: wishlist Tags: patch l10n Please find attached the French debconf templates translation update, proofread by the debian-l10n-french mailing list contributors. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27-2-386 Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15)

2 1

[cl-debian] Bug#343695: gcl: [INTL:sv] Swedish debconf templates translation
by Daniel Nylander 27 Jun '06

27 Jun '06

Package: gcl Version: 2.6.7-12 Severity: wishlist Tags: patch l10n Here is an update of the debconf template for gcl. Regards, Daniel -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.2 Locale: LANG=sv_SE.ISO-8859-1, LC_CTYPE=sv_SE.ISO-8859-1 (charmap=ISO-8859-1)

4 4

[cl-debian] Bug#349495: gcl: build attempts to write to root directory
by Karsten Trulsen 20 Jun '06

20 Jun '06

Package: gcl Version: 2.6.7-14 Severity: normal Attempt to build on platform "Linux 2.6.12-i686 athlon i386 GNU/Linux" failed with the following error message: /bin/sh: line 1: /temp_emacs_default: Permission denied The error is apparently in file .../gcl-2.6.7/elisp/makefile where the variable DESTDIR appears to be empty or unassigned. This error did not occur in version 2.6.7-11. Karsten

2 1

[cl-debian] Bug#352567: cl-sql and :db-reader
by Thomas Fischbacher 16 May '06

16 May '06

Package: cl-sql Version: 3.1.2-1 There are three problems with the :db-reader argument to DEF-VIEW-CLASS: (1) Documentation bug: It is mentioned in the documentation in the example page /usr/share/doc/cl-sql/html/ch02s02.html but not in the documentation of def-view-class itself: /usr/share/doc/cl-sql/html/def-view-class.html (2) Code bug: sql/metaclasses.lisp contains a piece of code in (defmethod compute-effective-slot-definition ((class standard-db-class) #+kmr-normal-cesd slot-name direct-slots) that deals with the :db-writer slot: (setf (slot-value esd 'db-writer) (when (slot-boundp dsd 'db-writer) (delistify-dsd (view-class-slot-db-writer dsd)))) The corresponding piece of code for :db-reader is just missing. Patching in these lines will make the code work (at least that's what I observe): (setf (slot-value esd 'db-reader) (when (slot-boundp dsd 'db-reader) (delistify-dsd (view-class-slot-db-reader dsd)))) (3) Usage bug(?): Specifying a function as a reader argument is quite awkward. Right now, I am using #. syntax: (content :db-kind :base :column "ser_content" :db-constraints :not-null :accessor msg-content :db-type "text" ; postgres :db-reader #.#'_msg-deserialize-content :db-writer #.#'_msg-serialize-content :initarg :content) That is presumably not what's intended here. Maybe I just did not get the point, but somehow I seem to be unable to properly specify a function in this place. If this really is not possible, it would at least be nice if one could specify a symbol whose symbol-function is the desired de-serialization function. On a side note, the documentation could be a bit clearer on the proper way to type-map a postgresql variable-length "text" field to CLOS. I think the method I am using above should presumably be okay. -- regards, tf(a)cip.physik.uni-muenchen.de (o_ Thomas Fischbacher - http://www.cip.physik.uni-muenchen.de/~tf //\ (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y) V_/_ (if (= x 0) y (g g (- x 1) (* x y)))) n 1)) (Debian GNU)

2 1