June 2006 - cl-debian@common-lisp.net - mailman3.common-lisp.net

[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#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#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#361275: cl-swank: swank-loader looks for a ChangeLog file that doesn't exist
by stfn.sbtn＠tiscali.it 07 Sep '06

07 Sep '06

Package: cl-swank Version: 1:20060328-2-1 Severity: critical I'm trying to run slime from emacs in the usual way with M-x slime. I get in the *inferior-lisp* buffer: [1]> ;; Loading file /usr/share/common-lisp/source/slime/swank-loader. lisp ... *** - FILE-WRITE-DATE: file #P"/usr/share/common- lisp/source/slime/ChangeLog" does not exist The following restarts are available: SKIP :R1 skip (DEFVAR *FASL-DIRECTORY* # ...) STOP :R2 stop loading file /usr/share/common- lisp/source/slime/swank-loader.lisp ABORT :R3 ABORT Then I check the ChangeLog file and verified that doesn't exist. I get this problem when upgrading from the 20060228 version to the current 20060328 of slime and cl-swank. Regards. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.15.4-06.03.21sds Locale: LANG=pt_PT.UTF-8, LC_CTYPE=pt_PT.UTF-8 (charmap=UTF-8) Versions of packages cl-swank depends on: ii common-lisp-controller 5.13 This is a Common Lisp source and c -- no debconf information Solo per te TISCALI ADSL con 2 mesi GRATIS + 30 euro di sconto! Dalla 4 MEGA alla 24 MEGA, scopri l'Adsl Tiscali adatta a te. Con Tiscali Adsl senza limiti hai GRATIS 2 mesi di canone. E oggi in più, solo per pochi giorni, 30 euro di sconto. Non perdere questa straordinaria occasione. L'offerta è valida solo da questa mail. Scopri ora! http://promozioni.tiscali.it/webmail0406/

4 3

[cl-debian] Bug#358309: FTBFS: undefined reference to 'init_gcl_cmpfun'
by Martin Michlmayr 29 Aug '06

29 Aug '06

Package: gclcvs Version: 2.7.0-54 Severity: serious Your package fails to build in unstable beause of an undefined reference to 'init_gcl_cmpfun'. > Automatic build of gclcvs_2.7.0-54 on em64t by sbuild/amd64 1.106 ... > ar rs libgcl.a ../o/alloc.o ../o/array.o ../o/assignment.o ../o/backq.o ../o/bds.o ../o/big.o ../o/bind.o ../o/bitop.o ../o/block.o ../o/catch.o ../o/cfun.o ../o/character.o ../o/clxsocket.o ../o/cmpaux.o ../o/conditional.o ../o/earith.o ../o/error.o ../o/eval.o ../o/fat_string.o ../o/file.o ../o/format.o ../o/frame.o ../o/funlink.o ../o/gbc.o ../o/gcl_readline.o ../o/gmp_wrappers.o ../o/hash.o ../o/init_pari.o ../o/iteration.o ../o/let.o ../o/lex.o ../o/list.o ../o/macros.o ../o/main.o ../o/makefun.o ../o/mapfun.o ../o/multival.o ../o/new_init.o ../o/nfunlink.o ../o/nsocket.o ../o/num_arith.o ../o/num_co.o ../o/num_comp.o ../o/num_log.o ../o/num_pred.o ../o/num_rand.o ../o/num_sfun.o ../o/number.o ../o/package.o ../o/pathname.o ../o/plt.o ../o/predicate.o ../o/print.o ../o/prog.o ../o/read.o ../o/reference.o ../o/regexpr.o ../o/run_process.o ../o/sequence.o ../o/sfasl.o ../o/sockets.o ../o/string.o ../o/structure.o ../o/symbol.o ../o/toplevel.o ../o/typespec.o ../o/unixfasl.o ../o/unixfsys.o ../o/unixsave.o ../o/unixsys.o ../o/unixtime.o ../o/usig.o ../o/usig2.o ../o/utils.o ../lsp/gcl_arraylib.o ../lsp/gcl_assert.o ../lsp/gcl_debug.o ../lsp/gcl_defmacro.o ../lsp/gcl_defstruct.o ../lsp/gcl_describe.o ../lsp/gcl_evalmacros.o ../lsp/gcl_info.o ../lsp/gcl_iolib.o ../lsp/gcl_listlib.o ../lsp/gcl_mislib.o ../lsp/gcl_module.o ../lsp/gcl_numlib.o ../lsp/gcl_packlib.o ../lsp/gcl_predlib.o ../lsp/gcl_seq.o ../lsp/gcl_seqlib.o ../lsp/gcl_serror.o ../lsp/gcl_setf.o ../lsp/gcl_sloop.o ../lsp/gcl_top.o ../lsp/gcl_trace.o ../cmpnew/gcl_cmpbind.o ../cmpnew/gcl_cmpblock.o ../cmpnew/gcl_cmpcall.o ../cmpnew/gcl_cmpcatch.o ../cmpnew/gcl_cmpenv.o ../cmpnew/gcl_cmpeval.o ../cmpnew/gcl_cmpflet.o ../cmpnew/gcl_cmpfun.o ../cmpnew/gcl_cmpif.o ../cmpnew/gcl_cmpinline.o ../cmpnew/gcl_cmplabel.o ../cmpnew/gcl_cmplam.o ../cmpnew/gcl_cmplet.o ../cmpnew/gcl_cmploc.o ../cmpnew/gcl_cmpmain.o ../cmpnew/gcl_cmpmap.o ../cmpnew/gcl_cmpmulti.o ../cmpnew/gcl_cmpspecial.o ../cmpnew/gcl_cmptag.o ../cmpnew/gcl_cmptop.o ../cmpnew/gcl_cmptype.o ../cmpnew/gcl_cmputil.o ../cmpnew/gcl_cmpvar.o ../cmpnew/gcl_cmpvs.o ../cmpnew/gcl_cmpwt.o sys_gcl.o bfd/binutils_bfd_archive.o bfd/binutils_bfd_archures.o bfd/binutils_bfd_bfdio.o bfd/binutils_bfd_bfd.o bfd/binutils_bfd_bfdwin.o bfd/binutils_bfd_cache.o bfd/binutils_bfd_coffgen.o bfd/binutils_bfd_corefile.o bfd/binutils_bfd_format.o bfd/binutils_bfd_init.o bfd/binutils_bfd_libbfd.o bfd/binutils_bfd_opncls.o bfd/binutils_bfd_reloc.o bfd/binutils_bfd_section.o bfd/binutils_bfd_syms.o bfd/binutils_bfd_stab-syms.o bfd/binutils_bfd_targets.o bfd/binutils_bfd_hash.o bfd/binutils_bfd_linker.o bfd/binutils_bfd_srec.o bfd/binutils_bfd_binary.o bfd/binutils_bfd_tekhex.o bfd/binutils_bfd_ihex.o bfd/binutils_bfd_stabs.o bfd/binutils_bfd_merge.o bfd/binutils_bfd_dwarf2.o bfd/binutils_bfd_simple.o bfd/binutils_bfd_archive64.o bfd/binutils_bfd_elf64-x86-64.o bfd/binutils_bfd_elf64.o bfd/binutils_bfd_elf.o bfd/binutils_bfd_elflink.o bfd/binutils_bfd_elf-strtab.o bfd/binutils_bfd_elf-eh-frame.o bfd/binutils_bfd_dwarf1.o bfd/binutils_bfd_elf32-i386.o bfd/binutils_bfd_elf32.o bfd/binutils_bfd_i386linux.o bfd/binutils_bfd_aout32.o bfd/binutils_bfd_efi-app-ia32.o bfd/binutils_bfd_peigen.o bfd/binutils_bfd_cofflink.o bfd/binutils_bfd_elf64-gen.o bfd/binutils_bfd_elf32-gen.o bfd/binutils_bfd_cpu-i386.o bfd/binutils_libiberty_regex.o bfd/binutils_libiberty_cplus-dem.o bfd/binutils_libiberty_cp-demangle.o bfd/binutils_libiberty_md5.o bfd/binutils_libiberty_alloca.o bfd/binutils_libiberty_argv.o bfd/binutils_libiberty_choose-temp.o bfd/binutils_libiberty_concat.o bfd/binutils_libiberty_cp-demint.o bfd/binutils_libiberty_dyn-string.o bfd/binutils_libiberty_fdmatch.o bfd/binutils_libiberty_fibheap.o bfd/binutils_libiberty_floatformat.o bfd/binutils_libiberty_fnmatch.o bfd/binutils_libiberty_getopt.o bfd/binutils_libiberty_getopt1.o bfd/binutils_libiberty_getpwd.o bfd/binutils_libiberty_getruntime.o bfd/binutils_libiberty_hashtab.o bfd/binutils_libiberty_hex.o bfd/binutils_libiberty_lbasename.o bfd/binutils_libiberty_lrealpath.o bfd/binutils_libiberty_make-relative-prefix.o bfd/binutils_libiberty_make-temp-file.o bfd/binutils_libiberty_objalloc.o bfd/binutils_libiberty_obstack.o bfd/binutils_libiberty_partition.o bfd/binutils_libiberty_physmem.o bfd/binutils_libiberty_pex-unix.o bfd/binutils_libiberty_safe-ctype.o bfd/binutils_libiberty_sort.o bfd/binutils_libiberty_spaces.o bfd/binutils_libiberty_splay-tree.o bfd/binutils_libiberty_strerror.o bfd/binutils_libiberty_strsignal.o bfd/binutils_libiberty_ternary.o bfd/binutils_libiberty_unlink-if-ordinary.o bfd/binutils_libiberty_xatexit.o bfd/binutils_libiberty_xexit.o bfd/binutils_libiberty_xmalloc.o bfd/binutils_libiberty_xmemdup.o bfd/binutils_libiberty_xstrdup.o bfd/binutils_libiberty_xstrerror.o bfd/binutils_libiberty_mkstemps.o > ar: creating libgcl.a > touch raw_gcl_map > gcc -o raw_gcl \ > -L. -Wl,-Map raw_gcl_map -lgcl -lm -lgmp -lreadline -lncurses -lc -lgclp > ./libgcl.a(sys_gcl.o): In function `gcl_init_system':sys_gcl.c:(.text+0x321c): undefined reference to `init_gcl_cmpfun' > collect2: ld returned 1 exit status > make[2]: *** [raw_gcl_map] Error 1 -- Martin Michlmayr http://www.cyrius.com/

2 1

[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#368271: No clsql_uffi64.so on amd64, but clsql_uffi.so instead.
by Chun Tian (binghe) 03 Aug '06

03 Aug '06

Package: cl-sql-uffi Version: 3.6.1-1 This bug made me cannot use cl-sql-postgresql correctly. In clsql-uffi-loader.lisp file (in cl-sql-uffi package): (defvar *clsql-uffi-library-filenames* (list #+(or 64bit x86-64) "clsql_uffi64" "clsql_uffi")) It seems that on amd64 it'll load library "clsql_uffi64.so" instead of "clsql_uffi.so", but there's no "clsql_uffi64.so" existed at /usr/lib/clsql or any other directory! So I think this is a trivial bug, should be fixed easily. Thanks very much. Package: cl-sql-uffi Priority: extra Section: devel Installed-Size: 136 Maintainer: Kevin M. Rosenberg <kmr(a)debian.org> Architecture: amd64 Source: cl-sql Version: 3.6.1-1 Depends: cl-uffi (>= 1.5.11), cl-sql (>= 3.6.1-1), libc6 (>= 2.3.5-1) Recommends: cl-sql-backend Filename: pool/main/c/cl-sql/cl-sql-uffi_3.6.1-1_amd64.deb Size: 40316 MD5sum: 6b1b4f56a7a263670dae60a9babb31f0 Description: Common UFFI functions for CLSQL database backends This package provides an interface to several UFFI functions used by multiple CLSQL database backends. CLSQL is a Common Lisp interface to SQL databases. Tag: devel::library, langdevel::lisp, made-of::lang:lisp, works-with::db:sql

2 1

[cl-debian] Bug#365106: xmls bombs on sbcl unicode strings when parsing entities
by Daniel Lakeland 28 Jul '06

28 Jul '06

Package: cl-xmls Version: 1.2-1 " in an xml file I was trying to parse caused SBCL to bomb complaining that """ is not a simple base string. The solution is probably to tell read-stream to coerce ent to 'simple-base-string instead of 'simple-string -- Daniel Lakeland dlakelan(a)street-artists.org http://www.street-artists.org/~dlakelan

2 1