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

[cl-debian] Bug#407606: cmucl fails at initialization
by "Faré" 24 Jun '08

24 Jun '08

Package: cmucl Version: 19d-20061116-1 Severity: normal *** Please type your report below this line *** Since I last upgraded cmucl, I get the following error and backtrace whenever I start it. $ cmucl Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x10044FB8. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Skip remaining initializations. Debug (type H for help) (UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFCA7C)) Source: Error finding source: Error in function LISP::%ENUMERATE-SEARCH-LIST: Undefined search list: default 0] backtrace 0: (UNIX::SIGSEGV-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFCA7C)) 1: (UNIX::SIGSEGV-HANDLER 3 #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFCA7C))[:EXTERNAL] 2: ("call_into_lisp+#x8C [#x805560C] cmucl") 3: ("funcall3+#x32 [#x8055422] cmucl") 4: ("interrupt_handle_now+#x105 [#x8050940] cmucl") 5: (EQUAL #<Unprintable Instance {6C69663D}> #<ARRAY-TYPE SIMPLE-BASE-STRING>) 6: (EQUAL (#<Unprintable Instance {6C69663D}> . #<Unprintable Instance {682F3A65}>) (#<ARRAY-TYPE SIMPLE-BASE-STRING> #<MEMBER-TYPE NULL>)) 7: ((FLET #:G30 KERNEL::%TYPE-INTERSECTION-CACHE-LOOKUP)) 8: (KERNEL::%TYPE-INTERSECTION (#<ARRAY-TYPE SIMPLE-BASE-STRING> #<MEMBER-TYPE NULL>)) 9: (KERNEL::UNION-COMPLEX-SUBTYPEP-ARG2 #<ARRAY-TYPE SIMPLE-BASE-STRING> #<UNION-TYPE LIST>) 10: (KERNEL:CSUBTYPEP #<ARRAY-TYPE SIMPLE-BASE-STRING> #<UNION-TYPE LIST>) 11: (MAKE-SEQUENCE SIMPLE-STRING 11 :INITIAL-ELEMENT NIL) 12: (LISP::CONCAT-TO-SIMPLE* SIMPLE-STRING "/home/fare" "/") 13: (DEFAULT-DIRECTORY) 14: (LISP::ENVIRONMENT-INIT) 15: ((LABELS LISP::%RESTART-LISP SAVE-LISP)) 16: ((LABELS LISP::RESTART-LISP SAVE-LISP)) 0] (quit) $ Interestingly, if I run cmucl -noinit, I get no such error. However, I have no initialization file, as far as I can tell: neither of ~/init.lisp ~/.cmucl-init.lisp exists And strace fails on cmucl after the first memory-management-related segfault so I don't know what's going on. Also interestingly, if another user starts cmucl, it works. If same user starts with a different $HOME, it also fails. If another user with essentially the same config starts it, it works. It used to all work fine. Failure 100% reproducible in my current environment. I'm baffled. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] May your desire to be correct overcome your desire to have been correct (which you were not, anyway). -- Faré -- System Information: Debian Release: 4.0 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 en_US.iso-8859-1) Versions of packages cmucl depends on: ii common-lisp-controller 6.9 This is a Common Lisp source and c ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy Versions of packages cmucl recommends: pn binfmt-support <none> (no description available) -- debconf information: cmucl/upgradeproblems:

5 13

[cl-debian] Bug#390967: common-lisp-controller: File permission errors for .fasl files
by Rob Aagaard 10 Jun '08

10 Jun '08

Package: common-lisp-controller Version: 6.3 Severity: normal Attempting to load any library through asdf fails. It appears to attempt to no longer redirect the generated .fasl files to someplace outside of the source directory. This means that any installed packages that have not been previously compiled as root fail to load. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.12 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages common-lisp-controller depends on: ii bash 3.1-5 The GNU Bourne Again SHell ii cl-asdf 1.101-1 Another System Definition Facility ii debconf [debconf-2.0] 1.5.5 Debian configuration management sy ii debianutils 2.17.3 Miscellaneous utilities specific t ii perl 5.8.8-6.1 Larry Wall's Practical Extraction ii realpath 1.10 Return the canonicalized absolute common-lisp-controller recommends no packages. -- debconf information: * common-lisp-controller/short-site-name: zaphod * common-lisp-controller/long-site-name: zaphod.rawb.org

3 2

[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#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#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#397026: cmucl: package does not install in etch
by commi 28 Jun '07

28 Jun '07

Package: cmucl Version: 19c-release-20051115-3 Severity: normal The package fails to install with: Richte cmucl ein (19c-release-20051115-3) ... Installing Common Lisp Controller in CMU CL ... Couldn't mmap at 0xbe000000, len 1048576; got mapping at 0xa7d11000 insteadensur e_space: Failed to validate 1048576 bytes at 0xbe000000 FAILED ------------------------------------------- mimi@host1:~$ cmucl --version Couldn't mmap at 0xbe000000, len 1048576; got mapping at 0xa7d0f000 insteadensure_space: Failed to validate 1048576 bytes at 0xbe000000 -- System Information: Debian Release: testing/unstable Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages cmucl depends on: ii common-lisp-controller 6.6 This is a Common Lisp source and c ii debconf [debconf-2.0] 1.5.6 Debian configuration management sy Versions of packages cmucl recommends: ii binfmt-support 1.2.8 Support for extra binary formats -- debconf information: cmucl/upgradeproblems:

3 2

[cl-debian] Bug#360561: cmucl: CMUCL does not run under kernel version 2.6.16
by Christian Lynbech 28 Jun '07

28 Jun '07

Package: cmucl Version: 19c-release-20051115-2 Severity: normal When trying to run CMUCL under the recently released 2.6.16 kernels, it fails to start with the error: chateau:~> lisp Couldn't mmap at 0xbe000000, len 1048576; got mapping at 0xa7cc1000 insteadensure_space: Failed to validate 1048576 bytes at 0xbe000000 The problem is semi-serious in the sense that Debian unstable only really has the 2.6.16 kernels left and thus it kind of is not possible to run CMUCL together with a supported distributed kernel. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-k7 Locale: LANG=C, LC_CTYPE=da_DK (charmap=ISO-8859-1) Versions of packages cmucl depends on: ii common-lisp-controller 5.13 This is a Common Lisp source and c ii debconf [debconf-2.0] 1.4.72 Debian configuration management sy Versions of packages cmucl recommends: ii binfmt-support 1.2.7 Support for extra binary formats -- debconf information: cmucl/upgradeproblems:

4 3

[cl-debian] Bug#400240: cl-sql-tests: mysql extension testing suite, 3 out of 229 fail
by commi 22 May '07

22 May '07

Package: cl-sql-tests Version: 3.7.7-1 Severity: important Hello Kevin, this is just to let you know that (asdf:operate 'asdf:test-op 'clsql), mysql extension, 3 out of 229 total tests failed: :BASIC/TYPE/2, :BASIC/MAP/3, :BASIC/DO/2. I use sbcl and slime. Is something wrong with my config or is it that maybe the testing code needs upgrade? Regards, commi -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages cl-sql-tests depends on: ii cl-rt 20040621-2 Common Lisp regression tester from ii cl-sql 3.7.7-1 SQL Interface for Common Lisp ii cl-sql-mysql 3.7.7-1 CLSQL database backend, MySQL ii cl-sql-odbc 3.7.7-1 CLSQL database backend, ODBC ii cl-sql-postgresql 3.7.7-1 CLSQL database backend, PostgreSQL ii cl-sql-postgresql-socket 3.7.7-1 CLSQL database backend, PostgreSQL ii cl-sql-sqlite 3.7.7-1 CLSQL database backend, SQLite cl-sql-tests recommends no packages. -- no debconf information

2 1

[cl-debian] Bug#398873: cl-unit: Loading the system fails
by Pierre THIERRY 17 May '07

17 May '07

Package: cl-unit Version: 1.3.1-2 Severity: normal When trying to ASDF load the package, I got the following error: The name "REGRESSION-TEST" does not designate any package. [Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR] while loading the "clunit" ASDF source file. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (501, 'stable'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-k7 Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15) Versions of packages cl-unit depends on: ii common-lisp-controller 6.6 This is a Common Lisp source and c cl-unit recommends no packages. -- no debconf information -- nowhere.man(a)levallois.eu.org OpenPGP 0xD9D50D8A

2 1