July 2007 - cl-debian@common-lisp.net - mailman3.common-lisp.net

[cl-debian] Bug#423708: gclcvs: [INTL:es] Spanish translation for the debconf template
by Rudy Godoy 12 Nov '07

12 Nov '07

Package: gclcvs Severity: wishlist Tags: patch l10n Please find attached the Spanish translation for the debconf template. thanks -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-k7 (SMP w/1 CPU core) Locale: LANG=es_PE.UTF-8, LC_CTYPE=es_PE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash

2 1

[cl-debian] Re: stumpwm: Clarify README.Debian - can't understand a thing how to start this wm
by Jari Aalto 07 Oct '07

07 Oct '07

| > This is too technical. What is "boot up lisp"? How it's being done? | > What command to run, packages to install. Etc. | | I would say that it's not too technical at all. If you know what | Common Lisp is, you should be able to understand the upstream README. | Moreover, this package is not intended for common end-user, but for | users that have a specific background. | | > Please provide step by stem intruction how to start this window | > system, otherwise README.Debian doe snot reflect the needs of | > regular Debian user. | | As I said, it wasn't README.Debian, but the upstream README. In the | package version 1:20060513-1, I added a README.Debian to explain how | to use the SLIME swank together with StumpWM The debian/control::Description reads: Description: a Common Lisp window manager StumpWM is a window manager written entirely in Common Lisp. It attempts to be highly customizable while relying entirely on the keyboard for input. You will not find buttons, icons, title bars, tool bars, or any of the other conventional GUI widgets. >From "StumpWM is a window manager written entirely in Common Lisp" it suggests, that is is just another window manager only that the host language is common lisp. Something is not connecting here. - Aa per you explanation, the the sescription string should differentiate stumpwm from the other regular "window managers" by saing that this one is for only people that understand how to use it with common lisp. Without this, the "joe", like me, expects after download to read /ysr/share/doc/<package>/README.* files in order to see what steps are needed to make the <program> work unless it's setting itself up initially at install. | I'm not inclined to add specific information about how to start | StumpWM to the README.Debian, as the upstream README is quite | self-explanatory. I cc:ed this mail to the Common Lisp in Debian | mailing list [1], in order to have other comments/suggestions about | this bug. In case of no activity for 7 days, I'll tag this bug as | wont-fix. Currently - Description does not suggest anything to be different from standard WM - README* lacks information for anyone else but CL-knowledgeable. Please don't go away, before we can improve this :-) Jari

4 7

[cl-debian] Bug#382430: c-l-c installation of ecl does things wrong
by "Faré" 03 Oct '07

03 Oct '07

Package: ecl Version: 0.9i-2 Severity: normal the c-l-c installation of ecl does a few wrong things: (1) it uses the c-l-c version of asdf and not the ecl-provided one from /usr/lib/ecl/asdf.fas as a result it fails to include the make-build extension from ECL sources ecl-0.9i/contrib/asdf/asdf-ecl.lisp Solution (a) would be to (require 'asdf) from the c-l-c compiled image and not compile it in the c-l-c binary for ecl. Solution (b) would be to include asdf-ecl.lisp in the ecl package, and recompile it together with c-l-c's asdf.lisp when installing c-l-c. (2) it somehow gets cmp.fas and sysfun.lsp to systematically load verbosely in a way that isn't hushed up by flag -q resulting in an unremovable banner ;;; Loading #P"/usr/lib/ecl/cmp.fas" ;;; Loading #P"/usr/lib/ecl/sysfun.lsp" which is quite annoying for programs that need produce controlled output. This is probably caused by the runtime loading of /etc/lispconfig.lisp by c-l-c. This banner should not be printed by quiet ecl scripts. Solution (2a) is to explicitly bind *load-verbose* to nil when loading /etc/lispconfig.lisp. Solution (2b) is to modify the c-l-c ecl startup to somehow hook the value of *load-verbose* on the -q flag. However, this requires modifying or overriding code from ecl-0.9i/src/lsp/cmdline.lsp and maintaining the result. Ouch. Solution (2c) is to hook into ecl's loading of a user resource file and replace it with the loading of a system resource file, say /etc/ecl/rc.lisp that in turn loads /etc/lispconfig.lisp then the user resource file. We would just prepend that path to *lisp-init-file-list* from install-clc.lisp, and writing the proper default code in /etc/ecl/rc.lisp Thus the usual parsing of -q and -norc applies to clc's ecl. (3) compiling configuration files everytime can be a performance issue, in addition to requiring to load the compiler. We could instead have a mechanism such as cl-launch's compile-and-load-file to only recompile when needed (SLIME's doesn't try hard enough for ECL), and put c-l-c cached .fas variants of the files in *lisp-init-file-list* before the source variants. Also, we want it to not require users to do anything special for the fasl to remain in synch with their lisp configuration. Any hackish code should come precompiled as part of install-clc.lisp so as to avoid requiring costly recompilation at runtime when things change. Solution (3a) would be to only do that for the system-wide file, and have that system-wide file include provisions for recompiling itself and then loading the compiled contents, and do the same for lispconfig.lisp and user files. A bit of a hack. Solution (3b) would be to modify or override cmdline.lsp to do the compile-and-load instead of load. Costly to maintain. (4) If we use a compile-and-load-file strategy for (3), then we might share code with cl-launch. This would mean having a dependency on cl-launch. It also means I should change cl-launch to install its file in /usr/share/common-lisp/source/cl-launch instead of /usr/share/common-lisp/cl-launch and produce a cl-launch.asd. I'll do that for cl-launch 1.85. In any cases, problems (1) and (2) both interact badly with cl-launch, and although cl-launch 1.84 now fully supports ECL, debian users need export ECL=/usr/lib/ecl/ecl-original so as to use cl-launch with ECL. I should probably include detection of that executable in cl-launch as a workaround to current breakage, since I already kluge a lot of my way to supporting ECL in cl-launch. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.9-blefuscu Locale: LANG=en_US.iso-8859-1, LC_CTYPE=en_US.iso-8859-1 (charmap=ISO-8859-1) (ignored: LC_ALL set to e n_US.iso-8859-1) Versions of packages ecl depends on: ii common-lisp-controller 6.1 This is a Common Lisp source and c ii gcc-4.1 4.1.1-9 The GNU C compiler ii libc6 2.3.6-16 GNU C Library: Shared libraries ii libgc-dev 1:6.7-2 conservative garbage collector for ii libgc1c2 1:6.7-2 conservative garbage collector for ii libgmp3-dev 2:4.2.1+dfsg-3 Multiprecision arithmetic library ii libgmp3c2 2:4.2.1+dfsg-3 Multiprecision arithmetic library ii libncurses5-dev 5.5-2 Developer's libraries and docs for ecl recommends no packages. -- no debconf information

2 2

[cl-debian] Bug#433802: cl-swank: Slime crashes CMUCL on disconnect
by Mark Wooding 03 Oct '07

03 Oct '07

Package: cl-swank Version: 1:20070409-3 Severity: normal Tags: patch To demonstrate: * Start cmucl in a window. * Say to Lisp: (load "/usr/share/common-lisp/source/slime/swank-loader.lisp") * Say to Lisp `(create-server)'. * Start Emacs. * Say to Emacs `M-x slime-connect RET RET RET'. * Play about in both to show they've connected. * Say to Emacs `, disconnect RET'. * Lisp says: Help! 12 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded. Debug (type H for help) (LISP::DO-OUTPUT #<Stream for descriptor 6> #.(SYSTEM:INT-SAP #xB7F8A000) 0 3055 ...) and refuses to cooperate further. It won't listen to C-c, C-z, C-\ or any other obvious signals; saying `killall lisp' in another shell works OK. This is obviously hopeless for connecting Slime to some long-running server, fixing something, and disconnecting again. To fix the problem (apparently): --- /usr/share/common-lisp/source/slime/swank.lisp 2007-05-31 21:49:06.000000000 +0100 +++ /tmp/mwooding/swank.lisp 2007-07-19 14:46:46.000000000 +0100 @@ -617,7 +617,7 @@ (connection.socket-io *emacs-connection*)) (defun close-connection (c &optional condition backtrace) - (format *debug-io* "~&;; swank:close-connection: ~A~%" condition) +;; (format *debug-io* "~&;; swank:close-connection: ~A~%" condition) (let ((cleanup (connection.cleanup c))) (when cleanup (funcall cleanup c))) In case it's interesting, I'm using cmucl 19d-20061116-2. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages cl-swank depends on: ii common-lisp-controller 6.10 This is a Common Lisp source and c cl-swank recommends no packages. -- no debconf information

2 1

[cl-debian] Bug#434122: libsigsegv: please add shared library
by Thomas Girard 23 Sep '07

23 Sep '07

Package: libsigsegv Version: 2.4-3 Severity: wishlist Tags: patch Hi, Please generate the shared library when compiling libsigsegv. GNU Smalltalk 3.0 will need this shared library. The attached patch enables the shared library compilation and adds a libsigsegv0 package. (It also removes the `dirs' file which is not needed and causes empty dirs to be included in every package). Thanks, Thomas

2 1

[cl-debian] Bug#394775: Sparc64 install fails: 'sbcl.sh install-clc' segfaults
by J.P. Larocque 17 Sep '07

17 Sep '07

Package: sbcl Version: 1:0.8.16-1 Severity: important I cannot install sbcl on a Sun Ultra 1. sbcl crashes during package configuration. The package isn't even marked as broken. --->8--->8--- Selecting previously deselected package common-lisp-controller. (Reading database ... 43010 files and directories currently installed.) Unpacking common-lisp-controller (from .../common-lisp-controller_4.15sarge3_all.deb) ... Setting up common-lisp-controller (4.15sarge3) ... Selecting previously deselected package sbcl. (Reading database ... 43034 files and directories currently installed.) Unpacking sbcl (from .../sbcl_1%3a0.8.16-1_sparc.deb) ... Setting up sbcl (0.8.16-1) ... /usr/lib/common-lisp/bin/sbcl.sh loading and dumping clc. /usr/lib/common-lisp/bin/sbcl.sh: line 58: 12442 Segmentation fault (core dumped) sbcl --core /usr/lib/sbcl/sbcl-dist.core --noinform --sysinit /etc/sbcl.rc --userinit /dev/null --load "/usr/lib/sbcl/install-clc.lisp" 2>/dev/null mv: cannot stat `sbcl-new.core': No such file or directory FAILED Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done ---8<---8<--- I read some old bug report leading me to believe that my locale could be a problem for SBCL. The above output is with LC_ALL=C and LANG=C on the environment. The stack trace produced below probably doesn't convey any meaningful information. --->8--->8--- $ sudo gdb sbcl /usr/lib/sbcl/core GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-linux"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `sbcl --core /usr/lib/sbcl/sbcl-dist.core --noinform --sysinit /etc/sbcl.rc --us'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x000189f8 in handle_control_stack_guard_triggered () (gdb) bt #0 0x000189f8 in handle_control_stack_guard_triggered () #1 0x0001da80 in os_install_interrupt_handlers () #2 0x0001da80 in os_install_interrupt_handlers () Previous frame identical to this frame (corrupt stack?) ---8<---8<--- Attempts to use sbcl: --->8--->8--- $ sbcl This is SBCL 0.8.16, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Segmentation fault (core dumped) ---8<---8<--- --->8--->8--- $ gdb sbcl GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-linux"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/bin/sbcl (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) This is SBCL 0.8.16, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Program received signal SIGSEGV, Segmentation fault. 0x0001516c in alloc_base_string () (gdb) bt #0 0x0001516c in alloc_base_string () #1 0x0001abb8 in main () ---8<---8<--- Please let me know if I can be of any help. -- System Information: Debian Release: 3.1 Architecture: sparc (sparc64) Kernel: Linux 2.6.18 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages sbcl depends on: ii common-lisp-controlle 4.15sarge3 This is a Common Lisp source and c ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an -- no debconf information -- J.P. Larocque is <piranha(a)thoughtcrime.us> and <piranha(a)ely.ath.cx> Encrypted/signed e-mail preferred; http://ely.ath.cx/~piranha/pgp Fpr 5612 10A8 4986 2D85 A995 252B 4C02 5E02 F61D 2E61; ID 0xF61D2E61

5 6

[cl-debian] Bug#430988: cmucl: [INTL:pt] Portuguese translation for debconf messages
by Traduz - Portuguese Translation Team 17 Sep '07

17 Sep '07

Package: cmucl Version: 19d-20061116-2 Tags: l10n, patch Severity: wishlist Portuguese translation for cmucl's debconf messages. Translator: Pedro Ribeiro <p.m42.ribeiro(a)gmail.com> Feel free to use it. For translation updates please contact 'Last Translator' or the Portuguese Translation Team <traduz _at_ debianpt.org>. -- Best regards, Miguel Figueiredo "Traduz" - Portuguese Translation Team http://www.DebianPT.org # Portuguese translation for cmucl debconf messages. # Copyright (C) 2007 Pedro Ribeiro <p.m42.ribeiro(a)gmail.com> # This file is distributed under the same license as the cmucl package. # Pedro Ribeiro <p.m42.ribeiro(a)gmail.com>, 2007 # msgid "" msgstr "" "Project-Id-Version: cmucl_19d-20061116-2\n" "Report-Msgid-Bugs-To: pvaneynd(a)debian.org\n" "POT-Creation-Date: 2006-12-05 07:46+0100\n" "PO-Revision-Date: 2007-06-25 22:08+0100\n" "Last-Translator: Pedro Ribeiro <p.m42.ribeiro(a)gmail.com>\n" "Language-Team: Portuguese <traduz(a)debianpt.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: note #. Description #: ../templates:1001 msgid "Config file changed incompatibly" msgstr "O ficheiro de configuração mudou de forma incompatível" #. Type: note #. Description #: ../templates:1001 msgid "" "The config file /etc/common-lisp/cmucl/site-init.lisp changed in an " "incompatible way, please upgrade the file or if you are not even asked, move " "the /etc/common-lisp/cmucl/site-init.lisp.dpkg-new file to /etc/common-lisp/" "cmucl/site-init.lisp." msgstr "" "O ficheiro de configuração /etc/common-lisp/cmucl/site-init.lisp mudou de " "forma incompatível, por favor actualize o ficheiro ou se nem sequer for " "questionado, mova o ficheiro /etc/commom-lisp/cmucl/site-init.lisp.dpkg-new " "para /etc/common-lisp/cmucl/site-init.lisp." #. Type: note #. Description #: ../templates:1001 msgid "Failure to do this will result in a broken installation." msgstr "Se não o fizer ficará com uma instalação falhada."

2 1

[cl-debian] Bug#433466: Copyright of cl-typesetting 139-1 incorrect
by bdowning＠lavos.net 17 Sep '07

17 Sep '07

Package: cl-typesetting Version: 139-1 It looks like the copyright for the Debian package of cl-typesetting is no longer correct. The "debian/copyright" file in the version 139-1 source package still has the license with the slightly crazy advertising clauses, whereas "license.txt" has changed to a simple two-clause BSD license. (The author still recommends the advertising as a way to help publicize services using Common Lisp, but it is not part of the license text.) I think this also means it should move out of non-free. -bcd

2 1

[cl-debian] Bug#409827: Please support hurd-i386
by Chun Tian (binghe) 17 Sep '07

17 Sep '07

Package: clisp Version: 1:2.41-1 Severity: wishlist Tags: sid It seems that there isn't any Common Lisp platform in Debian GNU/Hurd now. Fortunately, CLISP can build directly on hurd-i386, just add hurd-i386 to clisp's control file is OK, I've tried this and succeed, this is totally done by the great autoconf and gcc, and the GNU/Hurd is much like UNIX through FSF say it's not UNIX. This CLISP on hurd-i386 can easily build something like asdf, common-lisp-controller, and araneida (cl-ppcre, cl-parenscript, ...) which already in debian's hurd-i386 port. A running CLISP can also be used to port SBCL to hurd-i386 (I'm trying working on this)... So, for Common Lisp, hopes more CL-platform can be run on GNU/Hurd! Thank you very much. Chun Tian (binghe)

2 1

[cl-debian] Bug#414682: cl-swank: trying to connect to new SBCL from Emacs throws a CL error
by Drake Wilson 16 Sep '07

16 Sep '07

Package: cl-swank Version: 1:20061201-2 Severity: important Trying to start SBCL using M-x slime-start from GNU Emacs fails with an error on the Common Lisp side. "important" because inferior-lisp is a big part of SLIME by my understanding. Here's the transcript from my *inferior-lisp* buffer: ---------------------------------------------------------------------- (load "/usr/share/common-lisp/source/slime/swank-loader.lisp" :verbose t) (swank:start-server "/tmp/slime.1772" :external-format :iso-latin-1-unix) This is SBCL 1.0, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * ; loading #P"/usr/share/common-lisp/source/slime/swank-loader.lisp" ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/swank-backend.fasl" ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/nregex.fasl" ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/swank-sbcl.fasl" ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/swank-source-path-parser.fasl" ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/swank-source-file-cache.fasl" ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/swank-gray.fasl" STYLE-WARNING: implicitly creating new generic function STREAM-READ-CHAR-WILL-HANG-P ;; loading #P"/var/cache/common-lisp-controller/1000/sbcl/swank/fasl/sbcl-1.0-linux-x86-64/swank.fasl" STYLE-WARNING: implicitly creating new generic function INSPECT-BIGGER-PIECE-ACTIONS STYLE-WARNING: implicitly creating new generic function INSPECT-WHOLE-THING-ACTION STYLE-WARNING: implicitly creating new generic function INSPECT-SHOW-MORE-ACTION STYLE-WARNING: implicitly creating new generic function MENU-CHOICES-FOR-PRESENTATION WARNING: These Swank interfaces are unimplemented: (CALLS-WHO DISASSEMBLE-FRAME SLDB-BREAK-AT-START SLDB-BREAK-ON-RETURN WHO-BINDS WHO-CALLS WHO-MACROEXPANDS WHO-REFERENCES WHO-SETS WHO-SPECIALIZES) T * debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread #<THREAD "initial thread" {10025EFA81}>: unknown &KEY argument: :EXTERNAL-FORMAT Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SWANK:START-SERVER "/tmp/slime.1772" :EXTERNAL-FORMAT :ISO-LATIN-1-UNIX) 0] ---------------------------------------------------------------------- Here's the installed versions of a few other packages, just in case: ii sbcl 1.0.0.0-1 A Common Lisp compiler and development system ii slime 20061201-2 Superior LISP Interaction Mode for Emacs ii emacs21 21.4a+1-5 The GNU Emacs editor ii emacs21-bin-common 21.4a+1-5 The GNU Emacs editor's shared, architecture ii emacs21-common 21.4a+1-5 The GNU Emacs editor's shared, architecture ii emacs21-el 21.4a+1-5 GNU Emacs LISP (.el) files ii emacsen-common 1.4.17 Common facilities for all emacsen Hope this helps. ---> Drake Wilson -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20.1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages cl-swank depends on: ii common-lisp-controller 6.9 This is a Common Lisp source and c cl-swank recommends no packages. -- no debconf information

4 5