August 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#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#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#384697: cl-launch: need to modify script variables without touching the script
by Luca Capello 20 Oct '06

20 Oct '06

Package: cl-launch Version: 1.85-1 Severity: wishlist Hello, the background of this wishlist can be found on bug #384071 [1], I created a new bug because I think the discussion was becoming specific to CL-Launch and no more to StumpWM. BTW, Xavier, I Cc:ed you because you were deeply involved in the discussion, I hope you don't mind :-) On Thu, 24 Aug 2006 00:53:17 +0200, Xavier Maillard wrote: >> Moreover, I think we need to find a common way to specify cl-launch >> files. For example, stumpwm can be loaded through CMUCL or SBCL, >> thus the script in /usr/bin/stumpwm cannot have the SBCL option >> hardcoded (because files in /usr should not be edited by the >> administrator). > > You can normally pass --lisp "sbcl cmucl clisp" as an argument thus > you can easily set LISPS="list of CL implentations separated by > spaces". I'm aware of this, but the main problem here is the following. At package building time, I create the /usr/bin/stumpwm script with cl-launch --output ./stumpwm --lisp "sbcl clisp" \ --system stumpwm --init '(stumpwm:stumpwm ":0")' But with this solution, as the StumpWM maintainer I'm giving a preference to SBCL (because it's the first in the list). As by the Debian Policy not the administrator neither the end-user have the rights to modify files in /usr, but only in /etc (because only modifications done in the latter are preserved during package upgrades), if someone wants to start StumpWM through CMUCL needs to copy /usr/bin/stumpwm somewhere and modify the $LISPS variable. Thus, I think we need to find a general and user-specific solution: something like a /etc/cl-launchrc and ~/.cl-launchrc files, where for every CL-Launch binary script (e.g. /usr/bin/stumpwm) one can override variables (especially $LISPS). Thus, any maintainer that wants to provide CL-Launch binary scripts could specify every supported Common Lisp implementation, then the administrator or the end-user can adjust to his needs. Obviously, someone may prefer to copy /usr/bin/stumpwm into ~/bin, but I'm not for "polluting" $HOME with multiple copies of /usr/bin/ files which differ only for a line (yes, I'm a bit paranoid). Thx, bye, Gismo / Luca -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-rc4 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages cl-launch depends on: ii common-lisp-controller 6.2 This is a Common Lisp source and c cl-launch recommends no packages. -- no debconf information Footnotes: [1] http://bugs.debian.org/384071

4 12

[cl-debian] Bug#384071: stumpwm: Please update to a more recent cvs checkout
by Xavier Maillard 06 Oct '06

06 Oct '06

Package: stumpwm Version: 1:20060513-1 Severity: wishlist -- 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.17-zedek Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15) Versions of packages stumpwm depends on: ii cl-clx-sbcl 0.7.2-1 An X11 Common Lisp client library ii cl-port 20060408-1 Common Lisp Object Collections Por ii common-lisp-controller 6.2 This is a Common Lisp source and c stumpwm recommends no packages. -- no debconf information

4 11

[cl-debian] Bug#384457: common-lisp-controller: Reconfiguration of ASDF is too intrusive
by Christian Lynbech 30 Sep '06

30 Sep '06

Package: common-lisp-controller Version: 6.2 Severity: normal In order for CLC to store fasls in /var/cache, it adds a method to `asdf:output-files' with some dire effects on the user environment. Either the fasl root configuration should be organised to be active only when compiling from within `clc-require' or there should at least be some way to disable/reconfigure the redirection of fasl files. The problem is that when doing any normal ASDF compilation in an CLC6 enabled lisp (at least verified in CMUCL, package version 19c-release-20051115-2), the fasl files all end up in /var/cache as well. This means the annoyance of it being more difficult to remove all fasls in order to recompile compared to when the fasls appear in the local directory. More seriously, it means that some packages will fail to build. If one downloads the latest mcclim snapshot and tries to build the Listener application, it fails due to the inability to find some xpm files: ;; Loading #P"/var/cache/common-lisp-controller/416/cmucl/local/net/daphne/usr/local/home/tedchly/Tools/UPSTREAM/mcclim/Apps/Listener/icons.x86f". ; Compilation unit aborted. Error in batch processing: File-error in function LISP::FD-OPEN: Error opening #P"/var/cache/common-lisp-controller/416/cmucl/local/net/daphne/usr/local/home/tedchly/Tools/UPSTREAM/mcclim/Apps/Listener/icons/folder.xpm", No such file or directory. A problem that would not have hit if one could have compiled this in place rather than redirecting fasls to /var/cache. -- 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.5-7.151-default Locale: LANG=C, LC_CTYPE=da_DK (charmap=ISO-8859-1) Versions of packages common-lisp-controller depends on: ii bash 3.1-5 The GNU Bourne Again SHell ii cl-asdf 1.99-3 Another System Definition Facility ii debconf [debconf-2.0] 1.5.3 Debian configuration management sy ii debianutils 2.17 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.

3 2

[cl-debian] Bug#382582: common-lisp-controller: c-l-c fails to exclude /usr/lib/sbcl and such from cache
by Francois-Rene Rideau 25 Sep '06

25 Sep '06

Package: common-lisp-controller Version: 6.2 Severity: minor While compiling a program with sbcl and c-l-c, I realized that c-l-c wasn't excluding directories such as /usr/lib/sbcl from its cache, recompiling in-cache fasl's for source code instead of using the precompiled fasl's. Same applies for other lisp implementations. cl-launch fixed a similar with its function exclude-from-cache. Note: if c-l-c ends up using the very same mechanism as cl-launch, it would be nice if the interface was similar enough that cl-launch could just import the relevant symbols in a #+common-lisp-controller. In any case, you're welcome to "borrow" code from cl-launch. PS: I see you depend on a package named realpath. In debian systems, readlink --canonicalize now does the same thing. Of course, in older Linux systems, BSD systems, etc., readlink doesn't have option --canonicalize. Sigh. PPS: unrelatedly, I found more bugs in cl-launch and ECL when using a system, and the bug has a long reach when the system has dependencies. Sigh. -- 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 en_US.iso-8859-1) Versions of packages common-lisp-controller depends on: ii bash 3.1-5 The GNU Bourne Again SHell ii cl-asdf 1.99-2 Another System Definition Facility ii debconf [debconf-2.0] 1.5.2 Debian configuration management sy ii debianutils 2.16.2 Miscellaneous utilities specific t ii perl 5.8.8-6 Larry Wall's Practical Extraction ii realpath 1.10 Return the canonicalized absolute common-lisp-controller recommends no packages. -- debconf information excluded

2 1

[cl-debian] Bug#376570: libsigsegv: FTBFS on GNU/kFreeBSD
by Petr Salinger 25 Sep '06

25 Sep '06

Package: libsigsegv Severity: important Version: 2.4-1 Tags: patch Hi, the current version fails to build on GNU/kFreeBSD. It needs small tweaks to configure.ac and regenerate configure. Please find attached patch with changes to configure.ac. It would also be nice if you can ask upstream to include this changes. Thanks in advance Petr

2 2

[cl-debian] Bug#360561: So what is a user supposed to do?
by Kevin L 18 Sep '06

18 Sep '06

I just "upgraded" from Sarge to testing and CMUCL is now dead. If this is fixed upstream, when is the fix going into testing? Is an end-user just supposed to compile their own kernel in the meantime?

2 1