Bug#916486: cl-ppcre has circular Depends on cl-unicode

The solution would be to separate the binary package for cl-ppcre in two or three: the base cl-ppcre (without unicode) and the cl-ppcre-unicode (with unicode) and perhaps a package cl-ppcre that "just" depends on the previous. —♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org

Bug#895170: desktop-file-utils: won't configure because of XDG_DATA_DIRS

On Mon, Apr 9, 2018 at 4:02 AM, Emilio Pozuelo Monfort wrote: > On 08/04/18 05:26, Francois-Rene Rideau wrote: >> Note that XDG defines several environment variables, and that >> system configuration scripts should ignore all such user variables. > > What makes you believe that?

Bug#809308: RFS: cl-asdf/3.1.6 [ITA] - Another System Definition Facility

Note that building asdf only requires a shell and cat, but testing asdf requires a lisp compiler and plenty of libraries for which there is no debian package yet. 1- which lisp compiler(s) shall be used for testing? ccl? sbcl? All of those available on the current platform? How do you even

Bug#787909: cl-asdf: breaks sbcl's included asdf.fasl

AFAIU, sbcl has already fixed its package to indicate incompatibility with asdf older than 3.1.5. There is no bug in sbcl anymore, and the issue is for asdf 3.1.5 to be released, hopefully ASAP. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Computerese Irregular

Bug#787909: sbcl: slime depends on cl-asdf

sbcl *should* declare that it breaks cl-asdf strictly earlier than 2:3.1.5-1 (i.e. 2:3.1.4-1 and earlier), and not doing so is a packaging bug. The complete solution to your issue will come when asdf releases 3.1.5, which will happen today, hopefully. —♯ƒ • François-René ÐVB Rideau

Bug#787909: cl-asdf: breaks sbcl's included asdf.fasl

This is a known issue, due to an incompatible update in SBCL. There is a fix in ASDF 3.1.4.13, but it hasn't been released yet. Workarounds: 1- remove the debian package cl-asdf OR 2- install a more recent asdf in ~/common-lisp/asdf/ — sudo apt-get install git mkdir -p ~/common-lisp/ cd

Bug#787909: cl-asdf: breaks sbcl's included asdf.fasl

I guess then that the actual bug is in sbcl, which should have been uploaded with Breaks: cl-asdf ( 3.1.5) or similar. Yes, what remains of this bug is that the packaging of sbcl needs be updated. I'll try reassigning. If this doesn't work, can you file a new bug? reassign 787909

Bug#787420: cl-alexandria: Warning on compiling without the LICENCE input file

alexandria.asd declares LICENCE as a static-file, therefore the file must be present or asdf3 will complain (unlike asdf2, and unlike asdf1 where most uses of static-file's were not even portable). If the issue is disk space, the debian package could replace it with a symlink to a shared version.

Bug#643080: cl-launch: FTBFS: dpkg-buildpackage: error: dpkg-source -b cl-launch-3.011 gave error exit status 2

This was fixed long ago. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Genius is one percent inspiration and ninety-nine percent perspiration. — Thomas Alva Edison On Mon, Sep 26, 2011 at 4:16 PM, Didier Raboud o...@debian.org wrote: Source:

Bug#762436: sbcl: ASDF/SOURCE-REGISTRY::DEFAULT-SOURCE-REGISTRY undefined

Oops, there's a bug in ASDF 3.1, whereby :default-registry doesn't work, and you use it in /home/exot/.config/common-lisp/source-registry.conf even though it's redundant with your :inherit-configuration. I propose you remove it, while I fix the bug in ASDF. Testing the bug in an asdf checkout:

Bug#734962: sbcl on wheezy

When you see such warnings, it is a good time to upload the packages for cl-asdf 3.1.3-1 and cl-launch 4.1-2. —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Genius is one percent inspiration and ninety-nine percent perspiration. — Thomas Alva Edison

Bug#723977: missing symlink in /usr/share/common-lisp/systems

Rideau •ReflectionCybernethics• http://fare.tunes.org Friedrich Hayek was the first object-oriented programmer. — Bill Tulloh On Mon, Sep 23, 2013 at 1:26 AM, Faré fah...@gmail.com wrote: (Adding asdf-devel to the recipients — the problem is wrong (asdf::default-source-registry) when XDG_DATA_DIRS

Bug#724208: cl-plplot: FTBFS: Component ASDF/USER::ALEXANDRIA not found, required by #SYSTEM cffi

Yes, we have a bug fix, but right now it's pending release of ASDF 3.0.3, Real Soon Now (tm). In the mean time, please use this work around: export XDG_DATA_DIRS=/usr/local/share:/usr/share —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org What's funny with equality

Bug#723977: [asdf-devel] Re: Bug#723977: missing symlink in /usr/share/common-lisp/systems

On Mon, Sep 23, 2013 at 6:29 PM, Robert Goldman rpgold...@sift.net wrote: Faré wrote: Robert: when do you [intend] to release 3.0.3 ? Otherwise, I could do a Debian package for 3.0.2.9. (PS: I took the liberty of also committing my load-systems* patch). I was waiting on those two more UIOP

Bug#723977: [asdf-devel] Re: Bug#723977: missing symlink in /usr/share/common-lisp/systems

: fahree : rpgoldman Which UIOP patches were you thinking of? I fixed a simple one regarding ensure-function. I see other portability issues with directory* and symlinks, but I am not competent to address them. I'm thinking of 120 https://bugs.launchpad.net/asdf/+bug/120 and 1205653

Bug#723977: missing symlink in /usr/share/common-lisp/systems

as a necessary evil. If it's necessary, then it cannot be evil, neither can it be good: it's a datum.— Faré On Sat, Sep 21, 2013 at 9:45 PM, Diogo F. S. Ramos diogo...@gmail.com wrote: diogo...@gmail.com (Diogo F. S. Ramos) writes: Is this still necessary? My understanding is that one

Bug#723977: missing symlink in /usr/share/common-lisp/systems

OK, so let's debug things a bit: 1- what does env return? 2- what's in your ~/.config/common-lisp/source-registry.conf ? 3- what's in your ~/.sbclrc ? 4- what does this return? HOME=/tmp sbcl --noinform --no-userinit --non-interactive --eval '(require :asdf)' --eval '(format t ~A~%~A~%~S~%~S~%

Bug#723977: missing symlink in /usr/share/common-lisp/systems

(Adding asdf-devel to the recipients — the problem is wrong (asdf::default-source-registry) when XDG_DATA_DIRS is empty.) Well, ASDF ought to have worked even in absence of XDG_DATA_DIRS, and you discovered a genuine bug in ASDF. It turns out, split-string was not designed to return correct

Bug#609047: update on CCL packaging status (resent)

tools/asdf) (quit))' —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org Laziness is mother of Intelligence. Father unknown. [Rumor has it it's Greed.] — Faré -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble

Bug#609047: update on CCL packaging status (resent)

: Faheem Mitha Please let CCL come with its own ASDF 3, or maybe ASDF 2, if you're packaging the CCL release rather than trunk. ASDF 3 is a big boy, and will upgrade itself to the version from debian, if available, and will know how NOT to downgrade itself, thank you. Hi Faré. Sorry, I

Bug#609047: update on CCL packaging status (resent)

On Wed, Sep 11, 2013 at 2:03 PM, Faheem Mitha fah...@faheem.info wrote: Sorry to put you to the trouble of having to explain this again. I'm sure you have had to do it before. No problem. In the bad old days of ASDF 1, few implementations shipped with ASDF, and those that did usually sported

Bug#609047: update on CCL packaging status (resent)

: Faheem Mitha The main outstanding thing that (probably) should be fixed before the CCL package itself is ready to be submitted to NEW is to remove the local copy of ASDF from CCL and configure CCL to look for the Debian installation of ASDF. I think at least Christoph Egger suggested this,

Bug#710730: cl-asdf: Stumpwm failing, cannot find asdf.lisp

Oh, noes! It looks like some packages depended on the precise location of asdf.lisp, rather than use the implementation's (require :asdf) — possibly because they are intended to work with ancient implementations that don't provide asdf? These packages must be fixed. I suppose I could also

Bug#606067: Unblocking cl-asdf in debian squeeze

On 6 December 2010 22:08, Desmond O. Chang doch...@gmail.com wrote: Hi Faré, I'm trying to push cl-asdf 2:2.011-1 into squeeze.  But here is a problem: 2:2.011-1 changes source format to 3.0 (quilt).  Since squeeze has been frozen, it's not suggested. Please decide that, 1. abort. 2

Bug#592768: complementary information

What version of clisp are you using? asdf 2.007 is incompatible with old clisp. asdf 2.008 includes compatibility with old clisp. Does upgrading asdf to a recent package help? Otherwise, can you use printf or dichotomy debugging to identify where precisely this script fails? [ François-René ÐVB

Bug#593179: common-lisp-controller: clbuild with ccl fails to use user-writable cache for compiled files

The problem is you're still using an old asdf 1.704. Newer c-l-c's should include a requirement of asdf 2.000 (a package for 2.005 is underway), but c-l-c 7.2 is buggy in not declaring such a version requirement. [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] The

Bug#591054: cl-asdf: circular dependency with common-lisp-controller

I tried to upload a cl-asdf that removes the dependency, but failed. 1- with the new ASDF2, do we really need to register source anymore, anyway? It should already be registered, being in the correct location that's registered by default. 2- should c-l-c depend on ASDF if ASDF depends on c-l-c?

Bug#572967: sbcl 1.0.40 works fine on debian/sid amd64

I don't see any obvious error message in either of your logs. Looks like it ends up successfully dumping a c-l-c image in both cases. (What is obvious is that c-l-c should disable compiler optimization notes by default, though - who's in charge of c-l-c? Should I file a bug?) What exactly breaks

Bug#549528: I confirm that the patch doesn't work.

The real patch is that recent CLC packages should indicate that they break compatibility with old versions of SBCL in favor of newer versions. [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] You may easily play a joke on a man who likes to argue — agree with him.

Bug#580779: cl-asdf: ecl won't install: The function SYSTEM-SOURCE-FILE is undefined

It's another case of we need to upgrade cl-asdf and the package failed to specify so. Sorry about that. [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] Living your life is a task so difficult, it has never been attempted before. On 8 May 2010 10:29, Arno Schuring

Bug#572538: gclcvs dies at startup when run by non-root user

On 7 April 2010 14:48, Camm Maguire c...@maguirefamily.org wrote: severity 572538 important thanks Greetings, and thank you for your detailed feedback.  This does appear quite kernel/platform specific, as the default /sbin/sysctl vm.mmap_min_addr on my system is 0, (default kernel, i386),

Bug#577210: tries to write FASL in wrong directory

I'll try to update clc and friends as soon as possible. Thanks a lot! 2- C-L-C needs to (asdf:clear-output-translations) and (asdf:clear-source-registry) right before it dumps images, for all implementations. ok Presumably it would implement a function (pre-image-dump-cleanups) or some

Bug#577210: tries to write FASL in wrong directory

of thermodynamics to every other economist's perpetual motion machines. — Faré -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#577210: tries to write FASL in wrong directory

Oh, I think I know: the image is dumped without having run (asdf:clear-output-translations) and (asdf:clear-source-registry). Oops. Workaround: run (asdf:initialize-output-translations) in your Lisp at the beginning, or re-dump an image with the clear-* at the end of

Bug#572538: failed to map segment from shared object: Permission denied

googling for execve sigkill, it looks like gclcvs might be trying to map things at the wrong place in its ELF header, where wrong means not allowed to casual users. As a user: $ /lib/ld-linux-x86-64.so.2 --list /usr/lib/gcl-2.7.0-prof//unixport/saved_ansi_gcl

Bug#572538: failed to map segment from shared object: Permission denied

Investigating further, I find by looking for mmap in the output of /sbin/sysctl an interesting setting called vm.mmap_min_addr. $ /sbin/sysctl vm.mmap_min_addr vm.mmap_min_addr = 4096 $ GCL_ANSI=t gclcvs [1]16794 killed GCL_ANSI=t gclcvs $ sudo /sbin/sysctl vm.mmap_min_addr=0

Bug#569841: cl-asdf: cl-asdf don't load configuration files in /etc/common-lisp

Can you give an example of a non-working setup? $/usr/bin/sbcl --eval '(progn (describe (asdf:find-system :ubf nil)) (format t ~S~%~S~% asdf::*source-registry* (asdf:asdf-version)) (sb-ext:quit))' This is SBCL 1.0.31.0.debian, an implementation of ANSI Common Lisp. [...]

Bug#569841: cl-asdf: cl-asdf don't load configuration files in /etc/common-lisp

Works for me. Can you give an example of a non-working setup? /usr/bin/sbcl --eval '(progn (describe (asdf:find-system :ubf nil)) (format t ~S~%~S~% asdf::*source-registry* (asdf:asdf-version)) (sb-ext:quit))' [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] The

Bug#568818: Verified, and workaround

Dear Fredrik, note that ASDF has undergone massive surgery recently. The functions that you note are present in the cl-asdf 2:1.502-1 currently in Debian, as Gary King imported ASDF-Binary-Locations into ASDF (which was generally considered an improvement upon its existence as a hard-to-configure

Bug#560781: (require :package) no longer works for CLC-managed packages

OK, the ASDF my repo now supports source-registry.conf.d as well as source-registry.conf. I'll commit it upstream by next week unless I get negative feedback, and hopefully after including some tests. Note that at least clisp seems confused when matching *.* or (make-pathname :type :wild :name

Bug#560781: (require :package) no longer works for CLC-managed packages

2010/1/20 Peter Van Eynde pvane...@mailworks.org: instead of /etc/common-lisp/source-registry.conf I would like to see /etc/common-lisp/source-registry.conf.d where instead of having one file that you might have to edit in post-installation scripts we would have a directory where packages can

Bug#560781: (require :package) no longer works for CLC-managed packages

Dear Peter, BTW, I committed my changes to ASDF, in my current development repo at http://common-lisp.net/gitweb?p=projects/xcvb/asdf.git If no one complains (and I don't suppose anyone will), this will get distributed as ASDF 1.500 next week. (I bumped the version to a round number forward, to

Bug#560781: (require :package) no longer works for CLC-managed packages

I guess my ideal debian lisp integration would be: $ apt-get install sbcl cl-cffi - I have actual FASL files on disk that sbcl can use, so that (require :cffi) just has to load them: no compilation necessary. But since that seems infeasible, second best would be: Works like today, where

Bug#560781: (require :package) no longer works for CLC-managed packages

Hi Peter, Can you make the path to those files compatible with what I'm preparing for ASDF? I've taken a look at the bug and the idea seems to be to have a place to define the locations of systems in on a system and user level. Right? For path configuration, if I get my way with ASDF, you

Bug#560781: (require :package) no longer works for CLC-managed packages

2010/1/12 Peter Van Eynde pvane...@debian.org: Just FYI I've started working on CLC v7 where this will be a system-wide setting overrideable with a user-specific configuration file. Can you make the path to those files compatible with what I'm preparing for ASDF? My current file paths are

Bug#382430: Fix to this bug

This bug should be reaffected to common-lisp-controller. Here's a patch to clc that will hush ecl. On the other hand, is it normal that /usr/lib/ecl/install-clc.lisp /usr/lib/sbcl/install-clc.lisp should be loading /etc/lisp.config instead of /etc/lisp-config.lisp whereas

Bug#407606: [cl-debian] Bug#407606: cmucl fails at initialization

, or anything. [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] Government is a disease masquerading as its own cure. -- Robert LeFevre (1911 - 1986) 2008/6/20 Luca Capello [EMAIL PROTECTED]: Hi Faré! On Wed, 20 Jun 2007 05:03:41 +0200, Faré wrote: a big TERMCAP

Bug#382430: c-l-c installation of ecl does things wrong

Dear Peter, On 03/10/2007, Peter Van Eynde [EMAIL PROTECTED] wrote: It took some time but I finally had a moment to look at the issues. Thanks! Faré wrote: (1) it uses the c-l-c version of asdf and not the ecl-provided one from I almost fixed the 'official' asdf to support all the features

Bug#315762: can reproduce here

I can reproduce this bug. If you have attempted solutions, I can test them. If you don't plan to produce any, I will work around it. (On another machine, it worked after I removed the whole TeX packages and dependencies then reinstalled them from scratch -- painful.) Please tell me. [

Bug#407606: [cl-debian] Bug#407606: cmucl fails at initialization

the last user is dead. On 08/05/07, Faré [EMAIL PROTECTED] wrote: On 04/05/07, Peter Van Eynde [EMAIL PROTECTED] wrote: Hello Faré I tried with the environment set as you gave, but still it works. Actually I cannot find serious references to TERMCAP in the cmucl sources so I fail to see where

Bug#407606: [cl-debian] Bug#407606: cmucl fails at initialization

, by induction, one can deduce that every program can be reduced to one instruction which doesn't work. On 19/06/07, Faré [EMAIL PROTECTED] wrote: OK, it gets weirder. On the zsh command-line, I can make it fail deterministically. In a sh script, it deterministically works. I traced

Bug#407606: cmucl fails at initialization

444:' [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] Majority, n.: That quality that distinguishes a crime from a law. On 03/05/07, Peter Van Eynde [EMAIL PROTECTED] wrote: Faré wrote: After some experimentation, it looks like

Bug#407606: cmucl fails at initialization

| ReflectionCybernethics | http://fare.tunes.org ] The difference between a programmer and a user, is that the programmer knows there is no difference between using and programming. -- Faré

Bug#407606: cmucl fails at initialization

Using a custom-compiled kernel 2.6.18 (has to be custom - or it won't boot on this crypto'ed machine), I have exactly the same symptoms (plus other unrelated trouble trying to resume-from-ram). I don't think it is kernel-related. Actually, I realize that it dies when I'm within screen with

Bug#407606: cmucl fails at initialization

work fine. Failure 100% reproducible in my current environment. I'm baffled. [ François-René ÐVB Rideau | ReflectionCybernethics | 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

Bug#382582: closed by Peter Van Eynde [EMAIL PROTECTED] (Bug#382582: fixed in common-lisp-controller 6.3)

Hum, the fix in c-l-c 6.3 was a bit of a throw the baby with the bath water kind of fix. Now, no program that depends on c-l-c managed library will work, unless we explicitly call common-lisp-controller:clc-require for every such library (as if it were statically decided which libraries one uses

Bug#362977: closed by Gunter Ohrner [EMAIL PROTECTED] (Re: Bug#362977: i855G support in Debian)

Note that as far as I'm concerned, upstream has a bug fix in an experimental branch of their code. It's not released by upstream yet, and thus not included in Debian yet. I hope it gets there soon! https://bugs.freedesktop.org/show_bug.cgi?id=6635 [ François-René ÐVB Rideau |

Bug#362977: closed by Gunter Ohrner [EMAIL PROTECTED] (Re: Bug#362977: i855G support in Debian)

I reopened the bug, since the original issue I reported is still here. I'm glad it works for you, but it still doesn't for me. See upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=6635 [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] To say that power is

Bug#385745: gclcvs: weird asdf method errors in c-l-c image

Subject: gclcvs: weird asdf method errors in c-l-c image Package: gclcvs Version: 2.7.0-55 Severity: important *** Please type your report below this line *** Using GCL_ANSI=t, if I ever try to use asdf (as compiled into gclcvs by c-l-c), I get the following error: (asdf:oos 'asdf:load-op

Bug#384697: cl-launch: need to modify script variables without touching the script

On 29/08/06, Luca Capello [EMAIL PROTECTED] wrote: check_lisp_variable () { test -r /etc/cl-launchrc . /etc/cl-launchrc test -r $HOME/.cl-launchrc . $HOME/.cl-launchrc test -n ${SOFTWARE_SYSTEM} LISP=${SOFTWARE_SYSTEM} } I have several issues with such a patch: (1) I took

Bug#384697: cl-launch: need to modify script variables without touching the script

Due to popular request, I am working on an optional /etc/cl-launchrc feature for cl-launch. Because I allow a --no-rc option (that is enabled by default for me, you can use --rc by default), the contents of these file will be read *after* the option processing. A cl-launchrc file may contain

Bug#384697: cl-launch: need to modify script variables without touching the script

Sewell On 29/08/06, Faré [EMAIL PROTECTED] wrote: Due to popular request, I am working on an optional /etc/cl-launchrc feature for cl-launch. Because I allow a --no-rc option (that is enabled by default for me, you can use --rc by default), the contents of these file will be read *after* the option

Bug#384697: cl-launch: need to modify script variables without touching the script

On 25/08/06, Luca Capello [EMAIL PROTECTED] wrote: Package: cl-launch Version: 1.85-1 Severity: wishlist I'm not sure we either need or want a /etc/cl-launchrc or a ~/.cl-launchrc. After all, the user (or root) may already export the variable $LISP to override things at runtime (or at dump

Bug#384071: [cl-debian] Bug#384071: stumpwm: Please update to a more recent cvs checkout

We could very well have several versions of stumpwm generated by cl-launch, and a master-script that accepts options and picks the right one depending on those options, and/or a /etc/alternatives/ thingie to select which version to pick. Personally, I when I use stumpwm, I don't usually dump

Bug#384071: [cl-debian] Bug#384071: stumpwm: Please update to a more recent cvs checkout

Will you also include a cl-launch script to make stumpwm runnable easily from the command-line? As I said in a previous mail, you should use (after testing) something like BINARY=/usr/bin/stumpwm IMAGE=/usr/lib/sbcl/stumpwm.core SYSTEMS=/usr/share/common-lisp/systems LISPS=sbcl DUMP=--dump

Bug#382430: c-l-c installation of ecl does things wrong

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

Bug#379531: cl-launch: FTBFS: ./cl-launch.sh: Permission denied

Weird. Why is your cl-launch not executable (the archive has mode 755) and/or your /bin/sh absent? I'll apply your patch in cl-launch 1.82 since it makes things more robust, but would like to know if the bug is really mine or if you actually did something wrong. PS: how should I upload my

Bug#356948: [cl-debian] Bug#356948: stumpwm: Clarify README.Debian - can't understand a thing how to start this wm

On 12/06/06, Jari Aalto [EMAIL PROTECTED] wrote: | | tags 356948 + help | retitle 356948 stumpwm: clarify how to start this WM in the README.Debian AFTER Description: a Common Lisp window manager Note: this is not and end user program; i.e. a regular window manager. Why not just

Bug#356948: [cl-debian] Re: stumpwm: Clarify README.Debian - can't understand a thing how to start this wm

On 25/05/06, Luca Capello [EMAIL PROTECTED] wrote: 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

Bug#362977: xserver-xorg-video-i810: framebuffer offset by 32k pixels

OK, I forwarded it. Here's the upstream bugzilla entry: https://bugs.freedesktop.org/show_bug.cgi?id=6635 [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] There is no reason ever to have the same thought twice, unless you like having that thought -- David Allen,

Bug#362977: xserver-xorg-video-i810: framebuffer offset by 32k pixels

Package: xserver-xorg-video-i810 Version: 1:1.5.1.0-2 Severity: important Since I upgraded my Toshiba Libretto U105 to use the new xserver-xorg from unstable, Xorg will shift the graphical display contents by about 25 lines downwards and 768 pixels rightwards, wrapping lines around. The result is

Bug#340250: [cl-debian] Bug#340250: clisp: Package contains invalid link for base/lispinit.mem

On 22/11/05, Erick Ivaan Lopez Carreon [EMAIL PROTECTED] wrote: On Tue, 2005-11-22 at 20:07 -0500, Robin wrote: What package is /usr/sbin/register-common-lisp-implementation supposed to be in? It's not in clisp or clisp-dev. dpkg -S register-common-lisp-implementation Or better, apt-get

Bug#338242: cl-clx-sbcl is not 8-bit clean in presence of SB-UNICODE

Subject: cl-clx-sbcl is not 8-bit clean in presence of SB-UNICODE Package: cl-clx-sbcl Version: 0.7.1-1 Severity: important Tags: patch *** Please type your report below this line *** cl-clx-sbcl assumes that BASE-CHAR is an 8-bit character. This isn't true with sbcl when compiled with feature

Bug#335489: [cl-debian] Bug#335489: slime: doesn't start on SBCL without cl-swank (it should depend on the latest)

Why not have: * cl-slime, that depends on cl-slime-el and cl-swank * cl-slime-el, that contains the emacs lisp code and doesn't depend on cl-swank * cl-swank, that contains the common-lisp code and doesn't depend on cl-slime-el * sch-swank, that contains the scheme code... whatever. Do the Right

Bug#329347: common-lisp-controller: checking of permissions of the output directory

Yet another reason why the only sensible thing for a per-user cache is to use ~/.cache: it is automatically safe with respect to whichever policy is defined by the administrator and/or user for access rights, disk quotas, etc, with no race condition to check for. The only possible downside is

Bug#329347: common-lisp-controller: checking of permissions of the output directory

great surprises, is to find he can do what he was afraid he couldn't do. -- Henry Ford On 9/21/05, René van Bevern [EMAIL PROTECTED] wrote: On 21.09.05, Faré wrote: Hi Faré, The only possible downside is having to walk /etc/passwd to locate all the places where to purge the cache, if you

Bug#326598: [cl-debian] Bug#326598: cmucl-source: suggests libc5-dependent package

On 07/09/05, Peter Van Eynde [EMAIL PROTECTED] wrote: Instead of disabling hemlock altogether, why not have it issue an error if it can't find any TERMCAP? Besides, you can retrieve the termcap information from current terminal with infocmp(1), so the termcap data is just a (run-program

Bug#326598: [cl-debian] Bug#326598: cmucl-source: suggests libc5-dependent package

On 06/09/05, Peter Van Eynde [EMAIL PROTECTED] wrote: You use hemlock in a terminal? Wow. Instead of disabling hemlock altogether, why not have it issue an error if it can't find any TERMCAP? Besides, you can retrieve the termcap information from current terminal with infocmp(1), so the termcap