- cl-debian@lists.common-lisp.net - mailman3.common-lisp.net

[cl-debian] Re: [emacs-wiki-discuss] Synchronization in Emacs
by Luca Capello 23 Sep '05

23 Sep '05

Hello! On Fri 23 Sep 2005 14:07 +0200, Chris Parsons wrote: > Luca Capello wrote: >> - parsing of the planner entries to iCalendar (planner-icalendar.el, >> to be coded) [this should skips entries already present in >> diary/todo, in order to avoid entry duplication] > > I've started this already - check out planner-ical.el. Thank you for the hint, I got it [1]. From a very early look, I saw that you require icalendar.el, so IMHO most of the code could be shared (especially for the entry formatting). BTW, I hardly patched icalendar.el to be more RFC2445 compliant: VEVENT fields DESCRIPTION, LOCATION, ORGANIZER, URL, STATUS and CLASS are correctly imported/exported. I already submitted my patch to be reviewed by Ulf (the icalendar.el author, cc: because this mail could be useful to him). My idea is to have some general functions to import/export from iCalendar and then specific functions to read/write diary/todo or planner events. This should avoid code duplication. Thx, bye, Gismo / Luca [1] http://lists.gnu.org/archive/html/emacs-wiki-discuss/2005-07/msg00261.html

1 1

[cl-debian] Bug#329675: cl-webactions: With SBCL, fails to serve pages.
by Kim Minh Kaplan 22 Sep '05

22 Sep '05

Package: cl-webactions Version: 1.2.42+cvs.2005.08.05-4 Severity: important Tags: patch When running with SBCL, the function NET.ASERVE::FILESYS-INODE does not work properly: it calls SB-UNIX:UNIX-LSTAT with a SIMPLE-STRING argument while it only works for SIMPLE-BASE-STRING. The attached patch works around the problem. It does not solve it for non ASCII filenames. Here is a sample of the bug: $ sbcl --eval '(clc:clc-require :webactions)' \ > --eval '(net.aserve:start :port 7000)' \ > --eval '(net.aserve:webaction-project "foo" :index "index")' This is SBCL 0.9.3.72, 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. STYLE-WARNING: redefining INPUT-FILES (COMPILE-OP UNIX-DSO) in DEFMETHOD STYLE-WARNING: redefining OUTPUT-FILES (COMPILE-OP UNIX-DSO) in DEFMETHOD STYLE-WARNING: redefining PERFORM :AFTER (COMPILE-OP UNIX-DSO) in DEFMETHOD STYLE-WARNING: redefining OUTPUT-FILES (COMPILE-OP C-SOURCE-FILE) in DEFMETHOD STYLE-WARNING: redefining PERFORM (COMPILE-OP C-SOURCE-FILE) in DEFMETHOD STYLE-WARNING: redefining PERFORM (LOAD-OP C-SOURCE-FILE) in DEFMETHOD STYLE-WARNING: redefining PERFORM (LOAD-OP UNIX-DSO) in DEFMETHOD STYLE-WARNING: implicitly creating new generic function URI-P STYLE-WARNING: implicitly creating new generic function URI-PARSED-PATH STYLE-WARNING: implicitly creating new generic function (SETF URI-PARSED-PATH) STYLE-WARNING: implicitly creating new generic function URI STYLE-WARNING: implicitly creating new generic function MERGE-URIS STYLE-WARNING: implicitly creating new generic function ENOUGH-URI STYLE-WARNING: implicitly creating new generic function INTERN-URI STYLE-WARNING: implicitly creating new generic function RECEIVE-FROM STYLE-WARNING: implicitly creating new generic function SEND-TO STYLE-WARNING: implicitly creating new generic function GET-REQUEST-BODY STYLE-WARNING: implicitly creating new generic function START-MULTIPART-CAPTURE STYLE-WARNING: implicitly creating new generic function GET-MULTIPART-HEADER STYLE-WARNING: implicitly creating new generic function GET-MULTIPART-SEQUENCE STYLE-WARNING: implicitly creating new generic function REQUEST-QUERY STYLE-WARNING: implicitly creating new generic function GET-BASIC-AUTHORIZATION STYLE-WARNING: implicitly creating new generic function SET-BASIC-AUTHORIZATION STYLE-WARNING: defining *HEADER-BLOCK-SIZE* as a constant, even though the name follows the usual naming convention (names like *FOO*) for special variables STYLE-WARNING: defining *HEADER-BLOCK-USED-SIZE-INDEX* as a constant, even though the name follows the usual naming convention (names like *FOO*) for special variables STYLE-WARNING: defining *HEADER-BLOCK-DATA-START-INDEX* as a constant, even though the name follows the usual naming convention (names like *FOO*) for special variables STYLE-WARNING: defining *HEADERS-COUNT* as a constant, even though the name follows the usual naming convention (names like *FOO*) for special variables STYLE-WARNING: implicitly creating new generic function LOOKUP-MIME-TYPE STYLE-WARNING: implicitly creating new generic function CONTENT-LENGTH STYLE-WARNING: implicitly creating new generic function TRANSFER-MODE STYLE-WARNING: implicitly creating new generic function PUBLISH-ENTITY STYLE-WARNING: implicitly creating new generic function UNPUBLISH-ENTITY STYLE-WARNING: implicitly creating new generic function HANDLE-REQUEST STYLE-WARNING: implicitly creating new generic function FAILED-REQUEST STYLE-WARNING: implicitly creating new generic function DENIED-REQUEST STYLE-WARNING: implicitly creating new generic function STANDARD-LOCATOR STYLE-WARNING: implicitly creating new generic function UNPUBLISH-LOCATOR STYLE-WARNING: implicitly creating new generic function MAP-ENTITIES STYLE-WARNING: implicitly creating new generic function PROCESS-ENTITY STYLE-WARNING: implicitly creating new generic function COMPUTE-STRATEGY STYLE-WARNING: implicitly creating new generic function SEND-RESPONSE-HEADERS STYLE-WARNING: implicitly creating new generic function COMPUTE-RESPONSE-STREAM STYLE-WARNING: implicitly creating new generic function SET-COOKIE-HEADER STYLE-WARNING: implicitly creating new generic function TIMEDOUT-RESPONSE STYLE-WARNING: implicitly creating new generic function AUTHORIZE STYLE-WARNING: implicitly creating new generic function LOGMESS STYLE-WARNING: implicitly creating new generic function LOGMESS-STREAM STYLE-WARNING: implicitly creating new generic function BRIEF-LOGMESS STYLE-WARNING: implicitly creating new generic function LOG-REQUEST STYLE-WARNING: implicitly creating new generic function READ-CLIENT-RESPONSE-HEADERS STYLE-WARNING: implicitly creating new generic function CLIENT-REQUEST-READ-SEQUENCE STYLE-WARNING: implicitly creating new generic function CLIENT-REQUEST-CLOSE STYLE-WARNING: implicitly creating new generic function CLIENT-RESPONSE-HEADER-VALUE STYLE-WARNING: implicitly creating new generic function SAVE-COOKIE STYLE-WARNING: implicitly creating new generic function COMPUTE-COOKIE-STRING STYLE-WARNING: defining *BROWSER-LEVEL* as a constant, even though the name follows the usual naming convention (names like *FOO*) for special variables STYLE-WARNING: implicitly creating new generic function FIND-URI-INFO STYLE-WARNING: redefining MAKE-LOAD-FORM (URI) in DEFMETHOD ;;; Please wait, recompiling library... STYLE-WARNING: implicitly creating new generic function INITIALIZE-WEBSESSION-MASTER STYLE-WARNING: implicitly creating new generic function NEXT-WEBSESSION-ID STYLE-WARNING: implicitly creating new generic function NOTE-WEBSESSION-REFERENCED STYLE-WARNING: redefining REQUEST-VARIABLE-VALUE in DEFUN STYLE-WARNING: redefining .INV-REQUEST-VARIABLE-VALUE in DEFUN * 5-aserve-worker: 09/22/05 - 18:43:52 - while processing command "GET /index HTTP/1.1" got error The value "." is not of type (SIMPLE-ARRAY BASE-CHAR (*)). In another window I did: $ telnet localhost 7000 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET /index HTTP/1.1 Host: localhost To get this error. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-k7 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages cl-webactions depends on: ii cl-aserve 1.2.42+cvs.2005.08.05-4 Portable Aserve ii common-lisp-cont 4.18 This is a Common Lisp source and c cl-webactions recommends no packages. -- no debconf information

1 0

[cl-debian] rfc2388 enters CL-Debian repository!
by Luca Capello 22 Sep '05

22 Sep '05

Hello all! Finally, I completed the process of debianizing rfc2388 and creating the darcs repository for it (thanks Peter). The Debian package created is linda- and lintian- compliant, architecture independent and uses dh_lisp (thanks Rene). The link for the darcs repository is here: http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi?r=rfc2388;a=summary Peter, can you check it and upload to Debian official when you have time, please? Thx, bye, Gismo / Luca

1 0

[cl-debian] Bug#328633: marked as done (common-lisp-controller: Security upload for CAN-2005-2657?)
by owner＠bugs.debian.org 22 Sep '05

22 Sep '05

Your message dated Thu, 22 Sep 2005 12:30:02 +0200 with message-id <20050922103002.GA8938(a)kitenet.net> and subject line er, ok has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 16 Sep 2005 14:04:24 +0000 >From micah(a)riseup.net Fri Sep 16 07:04:21 2005 Return-path: <micah(a)riseup.net> Received: from mail.riseup.net [69.90.134.155] by spohr.debian.org with esmtp (Exim 3.36 1 (Debian)) id 1EGGpB-0003tO-00; Fri, 16 Sep 2005 07:04:21 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.riseup.net (Postfix) with ESMTP id 574C6A31F7; Fri, 16 Sep 2005 07:04:14 -0700 (PDT) Received: from mail.riseup.net ([127.0.0.1]) by localhost (buffy [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31018-38; Fri, 16 Sep 2005 07:04:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.riseup.net (Postfix) with ESMTP id B290BA31EF; Fri, 16 Sep 2005 07:04:13 -0700 (PDT) Received: by pond (Postfix, from userid 1000) id D6D343A81F; Fri, 16 Sep 2005 00:36:41 -0400 (EDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Micah Anderson <micah(a)riseup.net> To: Debian Bug Tracking System <submit(a)bugs.debian.org> Subject: common-lisp-controller: Security upload for CAN-2005-2657? X-Mailer: reportbug 3.17 Date: Fri, 16 Sep 2005 00:36:41 -0400 X-Debbugs-Cc: Debian Security Team <team(a)security.debian.org> Message-Id: <20050916043641.D6D343A81F@pond> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at riseup.net Delivered-To: submit(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-10.3 required=4.0 tests=BAYES_00,DATE_IN_PAST_06_12, HAS_PACKAGE,X_DEBBUGS_CC autolearn=ham version=2.60-bugs.debian.org_2005_01_02 Package: common-lisp-controller Version: 4.16 Severity: normal Tags: security Hi, I notice that in DSA-811-1[1] that common-lisp-controller has a fix for CAN-2005-2657 uploaded into stable, and the upload that is recorded as fixing this issue in unstable is for version 4.18[2]. However, there has not been an upload to unstable since 4.16 on 8/3/05. Do you anticipate uploading a fix to unstable soon? Or is the fixed version actually 4.16 and the DSA is incorrect? Thanks, Micah 1. http://www.debian.org/security/2005/dsa-811 2. "For the unstable distribution (sid) this problem has been fixed in version 4.18." -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) --------------------------------------- Received: (at 328633-done) by bugs.debian.org; 22 Sep 2005 10:30:07 +0000 >From joey(a)kitenet.net Thu Sep 22 03:30:07 2005 Return-path: <joey(a)kitenet.net> Received: from kitenet.net [64.62.161.42] (postfix) by spohr.debian.org with esmtp (Exim 3.36 1 (Debian)) id 1EIOL9-0007Nn-00; Thu, 22 Sep 2005 03:30:07 -0700 Received: from dragon.kitenet.net (dhcp-sn38-07.hrz.uni-oldenburg.de [134.106.38.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Joey Hess", Issuer "Joey Hess" (verified OK)) by kitenet.net (Postfix) with ESMTP id A612D18596 for <328633-done(a)bugs.debian.org>; Thu, 22 Sep 2005 10:30:06 +0000 (GMT) Received: by dragon.kitenet.net (Postfix, from userid 1000) id 66D2EBEEF3; Thu, 22 Sep 2005 12:30:02 +0200 (CEST) Date: Thu, 22 Sep 2005 12:30:02 +0200 From: Joey Hess <joeyh(a)debian.org> To: 328633-done(a)bugs.debian.org Subject: er, ok Message-ID: <20050922103002.GA8938(a)kitenet.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline User-Agent: Mutt/1.5.10i Delivered-To: 328633-done(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no version=2.60-bugs.debian.org_2005_01_02 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Version: 4.18 Maintain appeared to ignore my request, oh well. --=20 see shy jo --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDMoeqd8HHehbQuO8RAmt0AKCpwPg5Bm+1i8xl7W5A0N4wFZMGHQCglQhj vNHSRwL8MWoBDofwt8AAQgo= =tVpT -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO--

1 0

[cl-debian] Bug#329347: common-lisp-controller: checking of permissions of the output directory
by Friedrich Dominicus 22 Sep '05

22 Sep '05

Package: common-lisp-controller Version: 4.18 Severity: minor Well AFAIFK is the standard policy for adding new users to the system as follows. - the user is created - a groups is created also so if I do a adduser foobar a group foobar will generated to If that is true then the following check should probably be changed (file post-sysdef-install.lisp) (unless (= 0 (logand mode #o022)) should be (unless (= 0 (logand mode #o002)) or one has to check - if the user has it's own group whether the permissions are ok then. With best regards Friedrich -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages common-lisp-controller depends on: ii bash 3.0-14 The GNU Bourne Again SHell ii cl-asdf 1.86-2 Another System Definition Facility ii debconf [debconf-2.0] 1.4.48 Debian configuration management sy ii debianutils 2.13.2 Miscellaneous utilities specific t ii perl 5.8.7-4 Larry Wall's Practical Extraction ii realpath 1.9.20 Return the canonicalized absolute common-lisp-controller recommends no packages. -- debconf information: * common-lisp-controller/long-site-name: * common-lisp-controller/short-site-name: flarge

5 6

[cl-debian] Bug#329334: marked as done (acl-alisp8: bug in alisp8.sh?)
by owner＠bugs.debian.org 21 Sep '05

21 Sep '05

Your message dated Wed, 21 Sep 2005 22:12:43 +0200 with message-id <873bnyfadg.fsf(a)diziet.irb.hr> and subject line Bug#329334: acl-alisp8: bug in alisp8.sh? has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 21 Sep 2005 08:09:01 +0000 >From frido(a)q-software-solutions.de Wed Sep 21 01:09:01 2005 Return-path: <frido(a)q-software-solutions.de> Received: from 213-239-199-47.clients.your-server.de (mail.q-software-solutions.de) [213.239.199.47] by spohr.debian.org with esmtp (Exim 3.36 1 (Debian)) id 1EHzf3-0007pi-00; Wed, 21 Sep 2005 01:09:01 -0700 Received: from p54a37765.dip.t-dialin.net ([84.163.119.101] helo=flarge.here) by mail.q-software-solutions.de with asmtp (Exim 4.34) id 1EHzeu-0004pk-3V for submit(a)bugs.debian.org; Wed, 21 Sep 2005 10:08:59 +0200 Received: from frido by flarge.here with local (Exim 4.50) id 1EHzeO-0003CK-Ds for submit(a)bugs.debian.org; Wed, 21 Sep 2005 10:08:20 +0200 To: submit(a)bugs.debian.org From: Friedrich Dominicus <frido(a)q-software-solutions.de> Organization: Q Software Solutions GmbH Date: Wed, 21 Sep 2005 10:08:20 +0200 Message-ID: <8764suetcb.fsf(a)flarge.here> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 X-SA-Exim-Connect-IP: 84.163.119.101 X-SA-Exim-Mail-From: frido(a)q-software-solutions.de Subject: acl-alisp8: bug in alisp8.sh? Content-Type: text/plain; charset=us-ascii X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on mail.q-software-solutions.de) Delivered-To: submit(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 Package: acl-alisp8 Version: 6.2.32 Severity: normal I found the following in that file case $1 in rebuild) echo $0 Rebuilding packages... shift while [ -x $acl_dir/$lisp_builder -a ! -z "$1" ] ; do echo ...rebuilding $1 /usr/bin/$lisp_target -q -batch -L $acl_dir/siteinit.cl -e " (let ((*compile-print* nil) (*compile-progress* nil) (*compile-verbose* nil) (*require-verbose* nil) (*load-verbose* nil)) with high likliness you do not want to have /usr/bin/$lisp_target but $acl_dir/$lisp_builder why should one check for an executable file in the while if one does not use it. If one installed AllegroCL. If that is still correct how should one know that there should be e.g a /usr/bin/alisp8 ? Regards Friedrich -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages acl-alisp8 depends on: ii acl-pro-installer 6.2.32 Installer for Franz' Allegro 6.2 L ii common-lisp-controller 4.18 This is a Common Lisp source and c Versions of packages acl-alisp8 recommends: ii acldoc-el 6.2.32 Display AllegroCL documentation fr -- no debconf information --------------------------------------- Received: (at 329334-done) by bugs.debian.org; 21 Sep 2005 20:12:32 +0000 >From mvela(a)irb.hr Wed Sep 21 13:12:31 2005 Return-path: <mvela(a)irb.hr> Received: from mail.irb.hr [161.53.22.8] (UNKNOWN) by spohr.debian.org with esmtp (Exim 3.36 1 (Debian)) id 1EIAxD-0003qi-00; Wed, 21 Sep 2005 13:12:31 -0700 Received: from diziet.irb.hr (diziet.irb.hr [161.53.22.31]) by mail.irb.hr (8.13.3/8.13.3/Debian-6) with ESMTP id j8LKCMXk002871 for <329334-done(a)bugs.debian.org>; Wed, 21 Sep 2005 22:12:22 +0200 Received: from diziet.irb.hr (localhost [127.0.0.1]) by diziet.irb.hr (8.13.5/8.13.5/Debian-1) with ESMTP id j8LKChps014373 for <329334-done(a)bugs.debian.org>; Wed, 21 Sep 2005 22:12:43 +0200 Received: (from mvela@localhost) by diziet.irb.hr (8.13.5/8.13.5/Submit) id j8LKCh4X014371; Wed, 21 Sep 2005 22:12:43 +0200 X-Authentication-Warning: diziet.irb.hr: mvela set sender to mvela(a)irb.hr using -f From: Matej Vela <vela(a)debian.org> To: 329334-done(a)bugs.debian.org Subject: Re: Bug#329334: acl-alisp8: bug in alisp8.sh? References: <8764suetcb.fsf(a)flarge.here> Date: Wed, 21 Sep 2005 22:12:43 +0200 In-Reply-To: <8764suetcb.fsf(a)flarge.here> (Friedrich Dominicus's message of "Wed, 21 Sep 2005 10:08:20 +0200") Message-ID: <873bnyfadg.fsf(a)diziet.irb.hr> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 161.53.22.8 Delivered-To: 329334-done(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 Hello, Unfortunately, acl-installer was removed from Debian in July because no one was interested in maintaining it (http://bugs.debian.org/317416) Thanks, Matej

1 0

[cl-debian] [resent] Re: a few bugs
by Peter Van Eynde 21 Sep '05

21 Sep '05

Hello Faré, On Tuesday 20 September 2005 13:46, Faré wrote: > your fix for Bug#328633 breaks clisp on debian ppc testing. This is not good. After searching a little I find that posix:umask is only included from version 2.34 onwards. I will change the dependency of the package. If the problem also appears in stable I should create a new version and inform the security team :-(. Does anybody else have other problems with the new version? > PPS: unrelatedly, did you get asdf to work with gclcvs? I get a weird error > from format when I try to load anything. This could be the run-shell-command to check the cache directory. Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|

2 1

[cl-debian] Bug#329334: acl-alisp8: bug in alisp8.sh?
by Friedrich Dominicus 21 Sep '05

21 Sep '05

Package: acl-alisp8 Version: 6.2.32 Severity: normal I found the following in that file case $1 in rebuild) echo $0 Rebuilding packages... shift while [ -x $acl_dir/$lisp_builder -a ! -z "$1" ] ; do echo ...rebuilding $1 /usr/bin/$lisp_target -q -batch -L $acl_dir/siteinit.cl -e " (let ((*compile-print* nil) (*compile-progress* nil) (*compile-verbose* nil) (*require-verbose* nil) (*load-verbose* nil)) with high likliness you do not want to have /usr/bin/$lisp_target but $acl_dir/$lisp_builder why should one check for an executable file in the while if one does not use it. If one installed AllegroCL. If that is still correct how should one know that there should be e.g a /usr/bin/alisp8 ? Regards Friedrich -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages acl-alisp8 depends on: ii acl-pro-installer 6.2.32 Installer for Franz' Allegro 6.2 L ii common-lisp-controller 4.18 This is a Common Lisp source and c Versions of packages acl-alisp8 recommends: ii acldoc-el 6.2.32 Display AllegroCL documentation fr -- no debconf information

1 0

[cl-debian] Bug#328633: still unfixed?
by Joey Hess 20 Sep '05

20 Sep '05

I don't see any sign of the uploaded fix. (Also, it would be helpful to close the bug in the changelog and/or manually if you do fix it.) -- see shy jo

1 0

[cl-debian] A Lisp debhelper
by René van Bevern 20 Sep '05

20 Sep '05

Hello, I've been tired of using those lengthy postinst and prerm scripts for the common-lisp-controller in all packages and linking all ASDs to the directories using dh_link. (you always have to change their names and locations in multiple places, if you need to...) So I just wrote a litte debhelper extension that generates automatically the postinst and prerm scripts and puts links appropriately. Currently it only works with Common Lisp source packages, not implementations. You can darcs get (how to [1]) from here[2] and build package a of it to test it. I hope the manpage is sufficient for testing. ;) I have converted two of my not yet released packages to dh-lisp. One [3] is rather simple and served as the minimal requirement, the other [4] has quite some ASD files inside of multiple directory layers. For how the conversion looks, look at the commitdiffs. What still needs to be tested: working on source packages that generate multiple binary packages. So feel free to get me some feedback. :) Just branch one of those nice Darcs repositories and go play with it. What's still to come: support for CL implementation registration. Good evening, good night, ... :-) [1] http://cl-debian.alioth.debian.org/ [2] http://cl-debian.alioth.debian.org/repository/rvb/dh-lisp [3] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi?r=cl-yacc;a=summary [4] http://cl-debian.alioth.debian.org/cgi-bin/darcsweb.cgi?r=clg;a=summary -- René van Bevern -- http://progn.org/

2 3