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&Cybernethics• http://fare.tu
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?
>
When installing
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 specify
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 •Reflection&Cybernethics• http://fare.tunes.org
Computerese Irregular Ve
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 •Reflection&Cy
> 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 7879
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 ~/co
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. O
This was fixed long ago.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• 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 wrote:
> Source: cl-launch
> Versio
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:
mak
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 •Reflection&Cybernethics•
http://fare.tunes.org
Genius is one percent inspiration and ninety-nine percent perspiration.
— Thomas Alva Edison
s-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Friedrich Hayek was the first object-oriented programmer. — Bill Tulloh
On Mon, Sep 23, 2013 at 1:26 AM, Faré wrote:
> (Adding asdf-devel to the recipients — the problem is wrong
> (asdf::default-source-registry) when XD
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 •Reflection&Cybernethics• http://fare.tunes.org
What's funny with equality i
>>: 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 an
On Mon, Sep 23, 2013 at 6:29 PM, Robert Goldman 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 w
(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 result
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~%"
(a
p;Cybernethics• http://fare.tunes.org
There is no such thing 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 wrote:
>> diogo...@gmail.com (Diogo F. S.
ple want trunk instead, I could switch to trunk.
>
I don't have a strong opinion.
>> Actually, this is an issue since CCL 1.6, that will hopefully be fixed in
>> trunk soon — see http://trac.clozure.com/ccl/ticket/
>
>> So, please make sure you pre-compile
On Wed, Sep 11, 2013 at 2:03 PM, Faheem Mitha 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 an obsolete
to downgrade itself, thank you.
>
>
> Hi Faré.
>
> Sorry, I did not mean to distress you.
>
> I'm ccing Christoph and Peter in case they have comments.
>
> My reasons for suggesting this is that it is in line with Debian policy.that
> says you should not have local
>: 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 thi
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 re-packa
On 6 December 2010 22:08, Desmond O. Chang 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
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 R
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 | Reflection&Cybernethics | http://fare.tunes.org ]
The
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?
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 f
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 | Reflection&Cybernethics | http://fare.tunes.org ]
You may easily play a joke on a man who likes to argue — agree with him.
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 | Reflection&Cybernethics | 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 Schuri
On 7 April 2010 14:48, Camm Maguire 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), and of
> course I c
> 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
Austrian economics is the second law 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
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
common-lisp-controller:init-com
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
vm.mmap_min_
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
/usr/lib/gcl-2.7.0-prof//unixport/
>> 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. [...]
> ((#P"/u
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 | Reflection&Cybernethics | http://fare.tunes.org ]
The p
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
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 :wi
2010/1/20 Peter Van Eynde :
> 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
> just drop files
> 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
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
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
2010/1/12 Peter Van Eynde :
> 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
/etc/common-lisp/sour
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
/var/lib/dpkg/info/commo
t, or anything.
[ François-René ÐVB Rideau | Reflection&Cybernethics | 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 +02
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 'offi
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.
[ François-
ion -- from which, 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 deterministic
| http://fare.tunes.org ]
The program isn't debugged until 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.
>
44:'
[ François-René ÐVB Rideau | Reflection&Cybernethics | 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:
> Afte
&Cybernethics | 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é
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
TERM=s
ed 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é
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
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 | Reflection&Cybern
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 | Reflection&Cybernethics | http://fare.tunes.org ]
To say that power is
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 :spli
bert 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
*
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 stat
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
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 ti
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 imag
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 ${
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/cont
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 packag
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
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 upstr
OK, I forwarded it. Here's the upstream bugzilla entry:
https://bugs.freedesktop.org/show_bug.cgi?id=6635
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
There is no reason ever to have the same thought twice, unless you
like having that thought -- David Allen, "Ge
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
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-g
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 SB-
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 T
n makes, one of his 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 lo
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
havin
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-progr
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
78 matches
Mail list logo
