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

[Faré]

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
Communism doesn't work because people like to own stuff. ― Frank Zappa

On Fri, Dec 14, 2018 at 5:15 PM Bill Allombert  wrote:
>
> Package: cl-ppcre
> Version: 20180805.git2115632-1
> Severity: important
>
> Hello Debian Common Lisp Team,
>
> There is a circular dependency between cl-ppcre and cl-unicode:
>
> cl-ppcre:Depends: cl-unicode
> cl-unicode  :Depends: cl-ppcre
>
> Circular dependencies are known to cause problems during upgrade between
> stable releases, so we should try to avoid them.
>
> See threads
> http://lists.debian.org/debian-devel/2005/06/msg02111.html
> http://lists.debian.org/debian-devel/2005/11/msg01101.html
>
> Cheers,
> --
> Bill. 
>
> Imagine a large red swirl here.
>

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

[Faré]

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 a system package, the installation should be
predictable and not depend on whatever environment variables the user
happens to export or not export at the time of installation.

—♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
The essence of libertarianism: conflict is a negative sum game.

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

[Faré]

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 the
list of these compilers? What about proprietary implementations?

2- what to use for those libraries? The automated quicklisp to debian
package converter?

—♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
Multiple instances of a same hacker with different context in his mental
cache count as multiple hackers wrt documentation and testing needs.

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

[Faré]

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 Verb Conjugation:
 I have preferences.
 You have biases.
 He/She has prejudices.

On Thu, Jul 9, 2015 at 4:25 AM, Mart van de Wege mvdw...@mail.com wrote:
 Package: sbcl
 Version: 2:1.2.12-1
 Followup-For: Bug #787909

 Please reopen this bug as sbcl+cl-asdf is still broken pending the upgrade to 
 cl-asdf
 to 3.15


 -- System Information:
 Debian Release: stretch/sid
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386

 Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores)
 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 Init: systemd (via /run/systemd/system)

 Versions of packages sbcl depends on:
 ii  libc6   2.19-18
 ii  zlib1g  1:1.2.8.dfsg-2+b1

 Versions of packages sbcl recommends:
 ii  binfmt-support  2.1.5-1

 Versions of packages sbcl suggests:
 ii  sbcl-doc 2:1.2.13-1
 ii  sbcl-source  2:1.2.13-1
 ii  slime2:2.13-1

 ___
 pkg-common-lisp-devel mailing list
 pkg-common-lisp-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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 •ReflectionCybernethics• http://fare.tunes.org
In the age of the Internet ignorance is a choice.


On Tue, Jun 9, 2015 at 1:38 AM, Gijs Hillenius g...@hillenius.net wrote:
 Package: sbcl
 Version: 2:1.2.12-1
 Followup-For: Bug #787909

 It is suggested to remove cl-asdf, but that takes cl-swank 
 common-lisp-controller with it. And those are required by slime.

 -- System Information:
 Debian Release: stretch/sid
   APT prefers testing-updates
   APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing')
 Architecture: i386 (i686)

 Kernel: Linux 4.0.0-2-686-pae (SMP w/4 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 Init: sysvinit (via /sbin/init)

 Versions of packages sbcl depends on:
 ii  libc6   2.19-18
 ii  zlib1g  1:1.2.8.dfsg-2+b1

 Versions of packages sbcl recommends:
 ii  binfmt-support  2.1.5-1

 Versions of packages sbcl suggests:
 pn  sbcl-doc none
 pn  sbcl-source  none
 ii  slime2:2.13-1

 -- no debconf information

 ___
 pkg-common-lisp-devel mailing list
 pkg-common-lisp-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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 ~/common-lisp/
  git clone https://gitlab.common-lisp.net/asdf/asdf.git

This bug will be fix when we release 3.1.5 (RSN).

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Each new generation born is in effect an invasion of civilization by little
barbarians, who must be civilized before it is too late. — Thomas Sowell


On Sat, Jun 6, 2015 at 4:19 AM, Norbert Preining prein...@logic.at wrote:
 Package: cl-asdf
 Version: 2:3.1.4-1
 Severity: normal

 Dear all,

 I just found a problem due to both sbcl and cl-asdf being installed
 on my system while building cafeobj (an interpreter built on-top
 a CL interpreter, we are using sbcl).

 The warning message lists something about *POLICY and
 there is a changelog entry in sbcl that there were
 some changes.

 The build here produces the following log:
 ...
 ; compiling file /usr/share/common-lisp/source/cl-asdf/build/asdf.lisp
 (written 23 OCT 2014 05:15:20 AM):

 ; file: /usr/share/common-lisp/source/cl-asdf/build/asdf.lisp
 ; in: DEFUN GET-OPTIMIZATION-SETTINGS
 ; (ASSOC UIOP/LISP-BUILD::X SB-C::*POLICY*)
 ;
 ; caught WARNING:
 ;   Derived type of (SYMBOL-VALUE 'SB-C::*POLICY*) is
 ; (VALUES SB-C:POLICY OPTIONAL),
 ;   conflicting with its asserted type
 ; LIST.
 ;   See also:
 ; The SBCL Manual, Node Handling of Types

 ; file: /usr/share/common-lisp/source/cl-asdf/build/asdf.lisp
 ; in: DEFUN GET-OPTIMIZATION-SETTINGS
 ; (ASSOC UIOP/LISP-BUILD::X SB-C::*POLICY*)
 ;
 ; note: deleting unreachable code

 ; (LIST UIOP/LISP-BUILD::X UIOP/LISP-BUILD::Y)
 ; ==
 ;   UIOP/LISP-BUILD::X
 ;
 ; note: deleting unreachable code

 ; (ASSOC UIOP/LISP-BUILD::X SB-C::*POLICY*)
 ;
 ; caught WARNING:
 ;   Derived type of (SYMBOL-VALUE 'SB-C::*POLICY*) is
 ; (VALUES SB-C:POLICY OPTIONAL),
 ;   conflicting with its asserted type
 ; LIST.
 ;   See also:
 ; The SBCL Manual, Node Handling of Types

 ;
 /home/norbert/.cache/common-lisp/sbcl-1.2.12.debian-linux-x64/usr/share/common-l
 isp/source/cl-asdf/build/asdf-TMP.fasl written
 ; compilation finished in 0:00:04.523

 debugger invoked on a UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread
 #THREAD main thread RUNNING {1003B0E733}:
   COMPILE-FILE-ERROR while compiling #CL-SOURCE-FILE asdf build asdf

 Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

 


 I am not sure who should take some action here, but I thought I report it.

 Thanks

 Norbert


 -- System Information:
 Debian Release: stretch/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (200, 'experimental')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386

 Kernel: Linux 4.1.0-rc6 (SMP w/4 CPU cores; PREEMPT)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 Init: systemd (via /run/systemd/system)

 cl-asdf depends on no packages.

 Versions of packages cl-asdf recommends:
 ii  clisp [lisp-compiler]   1:2.49-10
 ii  cmucl [lisp-compiler]   20f-1
 pn  common-lisp-controller  none
 ii  sbcl [lisp-compiler]2:1.2.12-1

 Versions of packages cl-asdf suggests:
 pn  cl-launch  none

 ___
 pkg-common-lisp-devel mailing list
 pkg-common-lisp-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

 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 sbcl 2:1.2.12-1

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
I don't want to belong to any club that will accept me as a member — Groucho


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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. Or it could remove the static-file from the .asd file.
But the current situation is a bug.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Statists seek the solution to all human problems in arbitrary political power
and bureaucracies above society. They choose to ignore that when they are not
all too human, politicians and bureaucrats are oh so inhuman.

On Mon, Jun 1, 2015 at 10:18 AM, Diogo Ramos d...@riseup.net wrote:
 Package: cl-alexandria
 Version: 20140826-1
 Severity: minor

 Dear Maintainer,

 When loading the `cl-alexandria' ASDF system, ASDF gives the following
 warning:

   WARNING:
  compiling #STATIC-FILE alexandria LICENCE completed without
  its input file #P/usr/share/common-lisp/source/alexandria/LICENCE

 Here is a sample of the exchange that triggers this, using SBCL:

 * (require :asdf)

 (ASDF asdf UIOP uiop)
 * (asdf:load-system :alexandria)
 WARNING:
compiling #STATIC-FILE alexandria LICENCE completed without its 
 input file #P/usr/share/common-lisp/source/alexandria/LICENCE
 WARNING:
loading #STATIC-FILE alexandria LICENCE completed without its input 
 file #P/usr/share/common-lisp/source/alexandria/LICENCE



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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: cl-launch
 Version: 3.011-1
 Severity: important
 Tags: wheezy sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20110923 qa-ftbfs
 Justification: FTBFS on amd64

 Hi,

 During a rebuild of all packages in sid, your package failed to build on
 amd64.

 Relevant part:
  fakeroot debian/rules clean
 dh_testdir
 dh_testroot
 rm -f build-stamp configure-stamp
 rm -f cl-launch cl-launch.asd launcher.lisp wrapper.sh build.xcvb
 rm -f debian/cl-launch.postinst.* debian/cl-launch.prerm.*
 dh_clean
  dpkg-source -b cl-launch-3.011
 dpkg-source: info: using source format `3.0 (quilt)'
 dpkg-source: info: building cl-launch using existing 
 ./cl-launch_3.011.orig.tar.gz
 dpkg-source: info: local changes detected, the modified files are:
  cl-launch-3.011/reinstall
 dpkg-source: error: aborting due to unexpected upstream changes, see 
 /tmp/cl-launch_3.011-1.diff.rOR80t
 dpkg-source: info: you can integrate the local changes with dpkg-source 
 --commit
 dpkg-buildpackage: error: dpkg-source -b cl-launch-3.011 gave error exit 
 status 2
 
 Build finished at 20110924-0109

 The full build log is available from:

 http://people.debian.org/~lucas/logs/2011/09/23/cl-launch_3.011-1_lsid64.buildlog

 This error is due to recent dpkg changes “dpkg-source -b” on a “2.0”
 or “3.0 (quilt)” source package will fail if it detects upstream changes
 which are not managed by a quilt patch. [0]

 [0] http://lists.debian.org/debian-devel-announce/2011/09/msg1.html

 A list of current common problems and possible solutions is available at
 http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

 About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
 of the Grid'5000 platform, using a clean chroot.  Internet was not
 accessible from the build systems.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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:
make load
(initialize-source-registry '(:source-registry :default-registry
:ignore-inherited-configuration))

I'll fix it tonight in a ASDF 3.1.3.9.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Hopefully, they ban not just gay marriage, but straight marriage too,
and at last we have separation of state and marriage.


On Mon, Sep 22, 2014 at 7:08 AM, Daniel Borchmann
daniel.borchm...@mailbox.tu-dresden.de wrote:
 Package: sbcl
 Version: 2:1.2.3-1
 Severity: normal

 Dear Maintainer,

 it seems the current version of ASDF (3.1.3) causes some troubles:

   # sbcl --no-userinit --no-sysinit
   * (require 'asdf)

   (ASDF asdf UIOP uiop)
   * (asdf:load-system :asdf)

   debugger invoked on a UNDEFINED-FUNCTION in thread
   #THREAD main thread RUNNING {10039C6663}:
 The function ASDF/SOURCE-REGISTRY::DEFAULT-SOURCE-REGISTRY is undefined.

   Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

   restarts (invokable by number or by possibly-abbreviated name):
 0: [RETRY] Retry ASDF operation.
 1: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting 
 the
configuration.
 2: [ABORT] Exit debugger, returning to top level.

   (SB-KERNEL:%COERCE-CALLABLE-TO-FUN 
 ASDF/SOURCE-REGISTRY::DEFAULT-SOURCE-REGISTRY)
   0] backtrace

   Backtrace for: #SB-THREAD:THREAD main thread RUNNING {10039C6663}
   0: (SB-KERNEL:%COERCE-CALLABLE-TO-FUN 
 ASDF/SOURCE-REGISTRY::DEFAULT-SOURCE-REGISTRY)
   1: ((:METHOD ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY (SYMBOL)) 
 ASDF/SOURCE-REGISTRY::DEFAULT-SOURCE-REGISTRY :INHERIT NIL :REGISTER 
 #CLOSURE (LAMBDA (DIRECTORY KEY ASDF/SOURCE-REGISTRY::RECURSE 
 ASDF/SOURCE-REGISTRY::EXCLUDE) :IN 
 ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10055025FB}) [fast-method]
   2: (ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE 
 :DEFAULT-REGISTRY :INHERIT 
 (ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY 
 ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY 
 ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY 
 ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY 
 ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #CLOSURE 
 (LAMBDA (DIRECTORY KEY ASDF/SOURCE-REGISTRY::RECURSE 
 ASDF/SOURCE-REGISTRY::EXCLUDE) :IN 
 ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10055025FB})
   3: ((:METHOD ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY (CONS)) 
 (:SOURCE-REGISTRY (:TREE (:HOME .config/common-lisp/systems/)) 
 :DEFAULT-REGISTRY :INHERIT-CONFIGURATION) :INHERIT 
 (ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY 
 ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY 
 ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY 
 ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY 
 ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #CLOSURE 
 (LAMBDA (DIRECTORY KEY ASDF/SOURCE-REGISTRY::RECURSE 
 ASDF/SOURCE-REGISTRY::EXCLUDE) :IN 
 ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10055025FB}) [fast-method]
   4: ((:METHOD ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY (PATHNAME)) 
 #P/home/exot/.config/common-lisp/source-registry.conf :INHERIT 
 (ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY 
 ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY 
 ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY 
 ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY 
 ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #CLOSURE 
 (LAMBDA (DIRECTORY KEY ASDF/SOURCE-REGISTRY::RECURSE 
 ASDF/SOURCE-REGISTRY::EXCLUDE) :IN 
 ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10055025FB}) [fast-method]
   5: (ASDF/SOURCE-REGISTRY::PROCESS-SOURCE-REGISTRY-DIRECTIVE 
 :INHERIT-CONFIGURATION :INHERIT (NIL 
 ASDF/SOURCE-REGISTRY:ENVIRONMENT-SOURCE-REGISTRY 
 ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY 
 ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY 
 ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY 
 ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY 
 ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY-DIRECTORY 
 ASDF/SOURCE-REGISTRY:DEFAULT-SYSTEM-SOURCE-REGISTRY) :REGISTER #CLOSURE 
 (LAMBDA (DIRECTORY KEY ASDF/SOURCE-REGISTRY::RECURSE 
 ASDF/SOURCE-REGISTRY::EXCLUDE) :IN 
 ASDF/SOURCE-REGISTRY:FLATTEN-SOURCE-REGISTRY) {10055025FB})
   6: ((:METHOD ASDF/SOURCE-REGISTRY:PROCESS-SOURCE-REGISTRY (CONS)) 
 (:SOURCE-REGISTRY (:TREE #P/usr/lib/sbcl/) :INHERIT-CONFIGURATION) :INHERIT 
 (NIL ASDF/SOURCE-REGISTRY:ENVIRONMENT-SOURCE-REGISTRY 
 ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY 
 ASDF/SOURCE-REGISTRY:USER-SOURCE-REGISTRY-DIRECTORY 
 ASDF/SOURCE-REGISTRY:DEFAULT-USER-SOURCE-REGISTRY 
 ASDF/SOURCE-REGISTRY:SYSTEM-SOURCE-REGISTRY 
 

Bug#734962: sbcl on wheezy

[Faré]

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


On Sat, Aug 23, 2014 at 12:36 AM, Christoph Egger christ...@debian.org
wrote:

 Quoting from your log:

 WARNING:
You are using ASDF version 3.0.3 (probably from (require asdf) or
 loaded
by quicklisp) and have an older version of ASDF 3.0.2.4 registered at
#P/usr/share/common-lisp/source/cl-asdf/asdf.asd. Having an ASDF
 installed
and registered is the normal way of configuring ASDF to upgrade itself,
 and
having an old version registered is a configuration error. ASDF will
 ignore
this configured system rather than downgrade itself. In the future, you
 may
want to either: (a) upgrade this configured ASDF to a newer version, (b)
install a newer ASDF and register it in front of the former in your
configuration, or (c) uninstall or unregister this and any other old
 version
of ASDF from your configuration. Note that the older ASDF might be
registered implicitly through configuration inherited from your system
installation, in which case you might have to specify
:ignore-inherited-configuration in your in your
~/.config/common-lisp/source-registry.conf or other source-registry
configuration file, environment variable or lisp parameter. Indeed, a
 likely
offender is an obsolete version of the cl-asdf debian or ubuntu package,
that you might want to upgrade (if a recent enough version is
 available) or
else remove altogether (since most implementations ship with a recent
 asdf);
if you lack the system administration rights to upgrade or remove this
package, then you might indeed want to either install and register a
 more
recent version, or use :ignore-inherited-configuration to avoid
 registering
the old one. Please consult ASDF documentation and/or experts.

 ___
 pkg-common-lisp-devel mailing list
 pkg-common-lisp-de...@lists.alioth.debian.org

 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel

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

[Faré]

I have put a package for asdf 3.0.3 on mentors, that fixes this issue,
but it still hasn't been uploaded. Any Lisp DM around? It's not
actually an NMU, despite what the control file says (due to a mixup
with the new maintainer). Do you want me to repackage the thing?

—♯ƒ • François-René ÐVB 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 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 results when passed either NIL or , and
 this caused ASDF to fail to treat the default properly for XDG_DATA_DIRS.

 I've pushed a fix as ASDF 3.0.2.9, but that's a pretty bad bug you've
 discovered,
 which defeats the default configuration.

 Robert: when do you instead 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).

 —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
 A competent and self-confident person is incapable of jealousy in anything.
 Jealousy is invariably a symptom of neurotic insecurity.
 — Robert Heinlein, Time Enough For Love


 On Mon, Sep 23, 2013 at 1:05 AM, Diogo F. S. Ramos diogo...@gmail.com wrote:
 1- what does env return?

 I think the problem lies here.

 My environment does not export XDG_DATA_DIRS.  If I try it inside gnome,
 which exports it, everything works nicely.

 According to the XDG Base Directory Specification[1], if XDG_DATA_DIRS is
 empty or not set, the defaults should be used. More specifically:

   $XDG_DATA_DIRS defines the preference-ordered set of base directories
   to search for data files in addition to the $XDG_DATA_HOME base
   directory. The directories in $XDG_DATA_DIRS should be seperated with
   a colon ':'.

   If $XDG_DATA_DIRS is either not set or empty, a value equal to
   /usr/local/share/:/usr/share/ should be used.

 Maybe something in the stack is not implementing this characteristic of
 XDG.

 [1]  http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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 is how everyone has a different idea of it.  —#f

On Sat, Oct 19, 2013 at 10:20 PM, Diogo F. S. Ramos diogo...@gmail.com wrote:
 in the current cl-alexandria package the 'alexandria.asd' file is
 missing which might cause this bug.

 I think the problem is related to ASDF, as described in
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723977.

 ASDF searches for .asd files inside some directories and trees,
 including the ones described by `XDG_DATA_DIRS'.  When `XDG_DATA_DIRS'
 is empty or not set, `/usr/local/share:/usr/share/' should be used,
 which is not occurring.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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 patches (see the launchpad tracker
 -- sorry I'm on a plane so I can't look them up myself), but I agree
 that this needs a new version.

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'll be OOT till Friday, but will try to run the full set of tests (they
 run on my laptop on all officially supported platforms), and if they
 pass,  we can release 3.0.3 then.

Excellent.

 I am afraid I still don't have the ability to test on linux, or to build
 the Debian package -- still without a linux platform on which to hack ASDF.

I can do that part, at least for the free software and proprietary
implementations for which I still have a license.

 I am still having mysterious problems with bundling on my tests on ABCL
 and ECL, but I am pretty sure that the errors on ECL have to do with its
 own incorrect detection of 32- vs. 64-bit.  ABCL is a bit more
 mysterious to me.  Haven't been able to get any help with either of
 these, so don't think they should be allowed to block progress on other
 implementations.

In case it means anything, tests pass on both ECL and ABCL on Linux x64.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Death is only a state of mind.

Only it doesn't leave you much time to think about anything else.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

: 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 https://bugs.launchpad.net/asdf/+bug/1205653

 I was hoping to get some work done on these, but that target is slipping.

I was thinking about them as well. Notice how the goals are opposite:
one wants symlinks to be followed, the other not to.

I admit to trying to introducing the avoidance of recursing through
symlinks, because in some cases it could cause infinite recursion,
etc., especially when some software likes to have an uplink to a
directory full of dependencies, and the software is in the same
directory.

Although I would like there to be a semi-standard way to avoid
symlinks, I understand it might not be possible, and the anti-symlink
code might have to be removed, and such software will have to be
amended.

You're the maintainer, you get to decide.

 I just tested on an old and crufty linux box.  Worked for ccl sbcl cmucl
 allegro allegromodern.  ECL fails the test on my box.  Goes into an
 infinite loop compiling test/file3.lisp -- gets an error in compilation,
 retries, gets an error 

 This may be the fact that I'm trying this on an ancient OpenSUSE box,
 with a distro version that's been EOLed, so that may be me, not ASDF.

 If you could test with ECL, and it works for you, I am going to chalk
 this up to my ancient distro.

Which test script causes that? It's working here on
ecl-13.5.1-914ce253-linux-x64

 I don't have a good way to tell if ABCL is busted on Mac or our bundle
 op is busted on Mac.

Maybe we can convince someone on the ABCL team to run our tests?

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Procrastination is great. It gives me a lot more time
to do things that I'm never going to do.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

Diogo is correct that symlinks are (1) not needed anymore (2) frowned upon.

Indeed, unless you export XDG_DATA_DIRS or some weird shit like that,
then

(asdf::default-source-registry)

will end with

(:TREE #P/usr/share/common-lisp/source/)

So that it should find systems under there even without any symlink to systems/

And indeed when I

HOME=/tmp sbcl --noinform --non-interactive --eval '(require :asdf)'
--eval '(format t ~A~% (asdf:system-source-directory :cl-ppcre))'
/usr/share/common-lisp/source/cl-ppcre/

(The HOME=/tmp is so it won't use my personal configuration files)

I blame your misconfiguration.

If you don't use XDG_DATA_DIRS, do you have something in your configuration
that uses :ignore-inherited-configuration
then goes on to register /usr/share/common-lisp/systems ?

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• 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 diogo...@gmail.com wrote:
 diogo...@gmail.com (Diogo F. S. Ramos) writes:
 Is this still necessary?

 My understanding is that one does not need to symlink to
 `/usr/share/common-list/systems/package.asd' anymore.

 See
 http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/2012-September/003238.html.

 Well the thing is, asdf does not seem to be able to locate the systems
 and after adding the symlink it does again. So either asdf is broken in
 this regard or the symlinks are still/again needed

 Indeed.

 I tried loading alexandria and ppcre but I couldn't.

 Unfortunately I don't know enough of SBCL/ASDF/Debian to track this
 down, but I can confirm that just installing the systems is not enough
 for loading them.

 ___
 pkg-common-lisp-devel mailing list
 pkg-common-lisp-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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~%
(asdf::implementation-identifier) (asdf:asdf-version)
(asdf::default-source-registry) (asdf::flatten-source-registry))'
5- and that?
HOME=/tmp sbcl --noinform --no-userinit --non-interactive --eval
'(require :asdf)' --eval '(format t ~A~%
(asdf:system-source-directory :cl-ppcre))'

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
To a woman, a man is capital. To a man, a woman is consumer goods.
Hence the difference in attitude.


On Mon, Sep 23, 2013 at 12:37 AM, Diogo F. S. Ramos diogo...@gmail.com wrote:
 HOME=/tmp sbcl --noinform --non-interactive --eval '(require :asdf)'
 --eval '(format t ~A~% (asdf:system-source-directory :cl-ppcre))'
 /usr/share/common-lisp/source/cl-ppcre/

 (The HOME=/tmp is so it won't use my personal configuration files)

 I blame your misconfiguration.

 If you don't use XDG_DATA_DIRS, do you have something in your configuration
 that uses :ignore-inherited-configuration
 then goes on to register /usr/share/common-lisp/systems ?

 I used your exact incantation but I didn't get the same result, even
 though I have `cl-ppcre' installed at
 `/usr/share/common-lisp/source/cl-ppcre/'.

   Unhandled ASDF/FIND-SYSTEM:MISSING-COMPONENT in thread #SB-THREAD:THREAD
  main thread RUNNING
   {1002ADB373}:
   Component cl-ppcre not found

 I can have the same result if I prepend it with
 `XDG_DATA_DIRS=/usr/share/':

   XDG_DATA_DIRS=/usr/share/ HOME=/tmp sbcl --noinform --non-interactive
   --eval '(require :asdf)' --eval '(format t ~A~%
   (asdf:system-source-directory :cl-ppcre))'
   /usr/share/common-lisp/source/cl-ppcre/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

(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 results when passed either NIL or , and
this caused ASDF to fail to treat the default properly for XDG_DATA_DIRS.

I've pushed a fix as ASDF 3.0.2.9, but that's a pretty bad bug you've
discovered,
which defeats the default configuration.

Robert: when do you instead 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).

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
A competent and self-confident person is incapable of jealousy in anything.
Jealousy is invariably a symptom of neurotic insecurity.
— Robert Heinlein, Time Enough For Love


On Mon, Sep 23, 2013 at 1:05 AM, Diogo F. S. Ramos diogo...@gmail.com wrote:
 1- what does env return?

 I think the problem lies here.

 My environment does not export XDG_DATA_DIRS.  If I try it inside gnome,
 which exports it, everything works nicely.

 According to the XDG Base Directory Specification[1], if XDG_DATA_DIRS is
 empty or not set, the defaults should be used. More specifically:

   $XDG_DATA_DIRS defines the preference-ordered set of base directories
   to search for data files in addition to the $XDG_DATA_HOME base
   directory. The directories in $XDG_DATA_DIRS should be seperated with
   a colon ':'.

   If $XDG_DATA_DIRS is either not set or empty, a value equal to
   /usr/local/share/:/usr/share/ should be used.

 Maybe something in the stack is not implementing this characteristic of
 XDG.

 [1]  http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

Dear Faheem,

 But just to play devil's advocate, it is possible to have multiple
 versions of ASDF installed simultaneously, right?

 Depends what you mean by installed, but I'll take it that you mean (a)
 each installed implementation's precompiled asdf FASL. (b) the source-only
 code installation (NO precompiled FASL) from the cl-asdf package, to be
 compiled in each user's personal FASL cache with whatever implementation he
 uses (if any).

 These are different enough things that I wouldn't call them multiple
 versions of ASDF installed simultaneously. And the magic of ASDF 3 is that
 you, the debian packager, need not do any magic about it anymore, like in
 the bad old days of ASDF 1.

 Sorry if I was unclear. I meant multiple cl-asdf Debian packages installed
 simultaneously, corresponding to different ASDF versions. I.e. option (b).

You don't get it. The current, working, solution is to have *both*
(a) one precompiled copy of ASDF with *each* implementation, and
(b) optionally, *one* installed source copy of ASDF from package cl-asdf.

This is a WORKING solution. Please don't change that until and unless
you can propose another solution that actually works —
and you understand enough of the problem that you can argue why it works,
and why it assuages all existing concerns.


 Here I am imagining a world where CL implementations don't have their own
 private copy of ASDF.

Is it even possible?
We *need* a precompiled ASDF in each implementation's binary package, anyway.
And each implementation's upstream source package comes with an approved and
tested version of ASDF known to work with it.

Is what you really mean is that you believe you can improve on things by
introducing a tight coupling between implementations and asdf, by replacing
each implementation's source copy of asdf by the version from cl-asdf,
at package build time? This sounds awfully complex, for precious little gain,
and great problems introduced by this new coupling.

 If I understand you correctly, (a) corresponds the case where the
 implementations do have their private implementation.

Wrong. It's not an either/or. It's an and.
Each implementation MUST provide a precompiled asdf
for use with (require ...) and this CANNOT be done via package cl-asdf,
only via each implementation's binary package.

 And is it common (or is there even an actual known case) of an
 implementation depending on a patched ASDF? Or even being very
 sensitive to the particular ASDF version?

 It is common for an implementation to depend on a recent enough ASDF,
 whether patched or not. The ASDF maintainer (previously, me) is
 usually quick enough to merge patches upstream, though ASDF release
 can lag a month (or sometimes two) after such patch merge.

 I've read the second sentence several times, but I don't get it. Merge
 patches upstream implies there is a downstream. Are there multiple forks of
 ASDF? Do the implementations develop/modify ASDF themselves? I got the
 impression they just take some released version of ASDF and stick it in,
 often only after been told by an ASDF maintainer.

Each implementation's copy of ASDF is conceptually a fork,
and used to actually be, in the dark days of ASDF 1;
in those days, there wasn't even a good common versioning system,
and each implementation had patches over
some unspecified CVS release of the official ASDF.
Since the days of ASDF 2, the official ASDF maintainers (i.e. me)
has been responsive enough about merging implementation-specific patches
that implementations don't bother actively forking ASDF,
but instead send their patches that get immediately integrated (or
improved upon).
Therefore, most implementations at most time include
some stable release of ASDF (e.g. 3.0.2);
at times, however, some implementations eager to release
despite an incompatibility discovered in the upstream ASDF
have shipped with a development version of ASDF
(e.g. hypothetically, 3.0.2.5, still from the official version control),
or worse, a locally patched version of ASDF
(e.g. hypothetically, 3.0.2.2 plus some patch).


 Are you packaging from trunk or from the latest CCL release?
 I personally prefer trunk, but I can totally see a case for the release
 branch.

 The latest CCL release. I don't think Debian cares, but it seems the
 more natural thing to do. If it ever actually hits Debian, and enough
 people 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 ASDF as part of your installation of
 the CCL.

 Ok, but I'll need instructions on how to do this.

cd $CCL_DEFAULT_DIRECTORY
./lx86cl64 --no-init --eval '(progn (compile-file 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é

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

[Faré]

 : 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 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 copies of libraries already in the Debian
 archives.

This policy makes a lot of sense for libraries,
but does not make sense for ASDF, which is more of a library-loader,
and in this case, is tied to the implementation.

 Can you elaborate on the reasons why looking to an external ASDF is not a
 good idea? I assume that having multiple versions of ASDF in the archive is
 Ok. This is done for lots of other packages.

For the horror of ASDF1 days and its upgrade strategy, see
http://fare.livejournal.com/149264.html

The issue is: when an implementation comes with an updated version of
ASDF that it depends on, then the packager of that implementation must
update the ASDF package in debian, and make sure it works with all
other packaged implementations. Oops. Now you have an expensive
coordination problem. And if any implementation depends on patches
that didn't make it to an ASDF release yet, you're really screwed.

Also, now that ASDF 3 includes its own mechanism for self-upgrade and
avoiding self-downgrade, and will automatically look at the
debian-provided version if available (and unless told not to), you
don't gain much, if at all, by doing these complex packaging tricks.
Any time that your packaging tricks would have helped, ASDF 3 will
already bring the same benefits at the tiny cost of loading an extra
FASL for the newer ASDF. And then there are the times when the tricks
come back to bite you in the ass, so let just ASDF 3 sort it out.

In the bad old days of ASDF 1, few implementations shipped with ASDF,
and those that did usually sported an obsolete version. Special
packaging tricks for ASDF were not just useful, but necessary. These
days are happily long gone.

 In any case, the ftp masters will need to be ok with this.

I don't see why not. ASDF needn't count as a library. Plus it's
relatively small (depending on the implementation, the order of
magnitude of the installed copy is 1MB), and copied only once per
implementation, of which there are but a handful (in debian: sbcl,
clisp, ecl, now ccl, formerly gcl).

The only debian-packaged common lisp that doesn't work well with ASDF
3 is GCL, but then again, I believe GCL hasn't been re-packaged in
Debian in quite some time. And it's not like it worked that great with
ASDF 1, either. Also, it requires an old version of libgmp, if I
understand correctly, and sorely needs some re-packaging.

PS: it looks like current CCL trunk fails to pre-compile the asdf.lisp
it packages. Unless you wait for them to fix that, you may want to do
it yourself.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
If a vegetarian eats vegetables, what does a humanitarian eat? — Mark Twain


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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 an obsolete
 version. Special packaging tricks for ASDF were not just useful, but
 necessary. These days are happily long gone.

 Ok. I don't really understand the details, and I don't have a problem
 with an internal ASDF.

 But just to play devil's advocate, it is possible to have multiple
 versions of ASDF installed simultaneously, right?

Depends what you mean by installed, but I'll take it that you mean
(a) each installed implementation's precompiled asdf FASL.
(b) the source-only code installation (NO precompiled FASL) from the
cl-asdf package, to be compiled in each user's personal FASL cache
with whatever implementation he uses (if any).

These are different enough things that I wouldn't call them multiple
versions of ASDF installed simultaneously. And the magic of ASDF 3 is
that you, the debian packager, need not do any magic about it anymore,
like in the bad old days of ASDF 1.

 And is it common (or is there even an actual known case) of an
 implementation depending on a patched ASDF? Or even being very
 sensitive to the particular ASDF version?

It is common for an implementation to depend on a recent enough ASDF,
whether patched or not. The ASDF maintainer (previously, me) is
usually quick enough to merge patches upstream, though ASDF release
can lag a month (or sometimes two) after such patch merge.

 I don't see why not. ASDF needn't count as a library. Plus it's
 relatively small (depending on the implementation, the order of
 magnitude of the installed copy is 1MB), and copied only once per
 implementation, of which there are but a handful (in debian: sbcl,
 clisp, ecl, now ccl, formerly gcl).

 Ok. I don't personally care, but if the ftp masters object (assuming
 that the CCL package actually gets to the point of being reviewed by
 them), then is it Ok if I point them to you?

Of course.

 BTW, the current status as you can see on the 609047 bug thread, is
 that the ccl-ffigen package, which is used to build the interface
 databases for CCL, was rejected by the ftpmasters as it was a copy of
 GCC, or something. This happened in April, but I only just got around
 to writing a response. You can see the email in the bug thread.

I saw that. As a fallback, could you just consider the bootstrapped
.cdb files as source? Or is the issue due to your trying to build
more .cdb files than CCL usually comes with?

 If I get around to updating the package to the current CCL, would you
 be willing to test it?

Most gladly. Are you packaging from trunk or from the latest CCL
release? I personally prefer trunk, but I can totally see a case for
the release branch.

 PS: it looks like current CCL trunk fails to pre-compile the
 asdf.lisp it packages. Unless you wait for them to fix that, you may
 want to do it yourself.

 Any version of CCL that I package for Debian will be the release. So I
 guess this is not an issue.

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 ASDF as part of your installation
of the CCL.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
It has been my observation that most people get ahead during the time
that others waste. — Henry Ford


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

: 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, and it is clearly a
 good idea.

That's a totally crazy thing to do, of the kind of horror that was
necessary in the days of ASDF 1. Please don't do it. If Christoph
suggested it, he might have been traumatized in those days.

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.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
In a free market there are no market failures, only market opportunities.
In a bureaucracy there is no possible success, only a perpetual
ever-worsening crisis.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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-package
cl-asdf for increased compatibility by having a symlink from the old
location of asdf.lisp to the new location.

—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
What's funny with equality is how everyone has a different idea of it.  —#f


On Sat, Jun 1, 2013 at 10:42 PM, Chris Koehnen crkoeh...@gmail.com wrote:
 Package: cl-asdf
 Version: 2:3.0.1.2-1
 Severity: normal

 Dear Maintainer,

 With the latest update, stumpwm fails.  It seems to be expecting an asdf.lisp 
 file.

 Package: stumpwm, Version: 1:20110819.gitca08e08-2

 I apologize if this ought to be directed to stump instead.  Thank you.

 --Chris Koehnen


 ---

 X.Org X Server 1.12.4
 Release Date: 2012-08-27
 X Protocol Version 11, Revision 0
 Build Operating System: Linux 2.6.32-5-686-bigmem i686 Debian
 Current Operating System: Linux zeno 3.8-2-686-pae #1 SMP Debian 3.8.13-1 i686
 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8-2-686-pae 
 root=UUID=b8ec7d07-4b8b-4f1e-bf15-9dac4608d88c ro quiet
 Build Date: 17 April 2013  11:13:16AM
 xorg-server 2:1.12.4-6 (Julien Cristau jcris...@debian.org)
 Current version of pixman: 0.26.0
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
 Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
 (==) Log file: /var/log/Xorg.1.log, Time: Sat Jun  1 16:02:58 2013
 (==) Using config file: /etc/X11/xorg.conf
 (==) Using system config directory /usr/share/X11/xorg.conf.d
 *** - LOAD: A file with name /usr/share/common-lisp/source/cl-asdf/asdf.lisp 
 does not exist
 xinit: connection to X server lost

 waiting for X server to shut down Server terminated successfully (0). Closing 
 log file.

 ---



 -- System Information:
 Debian Release: jessie/sid
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: i386 (i686)

 Kernel: Linux 3.8-2-686-pae (SMP w/2 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages cl-asdf depends on:
 ii  dpkg  1.16.10
 ii  install-info  5.1.dfsg.1-3

 Versions of packages cl-asdf recommends:
 ii  clisp [lisp-compiler]   1:2.49-8.2
 ii  common-lisp-controller  7.10
 ii  sbcl [lisp-compiler]2:1.0.57.0-2

 cl-asdf suggests no packages.

 -- no debconf information

 ___
 pkg-common-lisp-devel mailing list
 pkg-common-lisp-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#606067: Unblocking cl-asdf in debian squeeze

[Faré]

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. make a new version to change back source format for squeeze.
 3. persuade DD to accept the new source format.

 However I hope 2.011 can be in squeeze because you've said it's sign
 of becoming mature :)

 Just reply debbugs 606067 to join our discussion.

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606067

 Thanks,
 Des

I'm the upstream maintainer, and I also support the debian packaging
in the release branch of the upstream git.

I don't understand what is the problem with a 3.0 package format, but
I will do whatever is needed to get the package in. When I last asked
debian hackers for help on IRC, I was specifically asked to move to
the latest package version 3.0, from the 1.0 version that I could
never get to work properly with the latest version of the tools. If I
remember correctly, using 1.0 dpkg-buildpackage and/or lintian was
confused by the fact that the diff was empty without the package being
native - though it's the natural consequence of the packaging being
both done upstream and stable (i.e. usually no extra packaging
activity needed after initial release). I'm reluctant to do extra work
and downgrade the format to something that was not passing lintian
last time I tried - as far as I'm concerned, the debian packaging has
been fixed and stable since August.

ASDF 2, released in late May, had major fixes in functionality and
changes in usability to ASDF. With people actually starting to use
ASDF 2 and hitting many use cases that weren't being tested before,
there have been several important bug fixes since 2.004, and 2.011
(November) is much more stable than 2.004 (July). As far as
Debian-included Lisp implementations go, GCL support in 2.004 is
mostly broken (package gclcvs), whereas it is fully functional in
2.011; small but notable stability improvements were made for CLISP,
ECL and SBCL, in use cases that some people care about. I understand
the minor API cleanups, backward compatibility fixes and much improved
performance in filesystem access are not relevant arguments for an
exception to the Debian freeze, but they are nevertheless appreciable
by users.

Even though many of the issues did in fact bother Debian users (of
which I am), the issues tended to be reported directly upstream, and
mostly haven't been reported on the Debian bug-tracking system. I've
pushed several package updates on mentors.debian.net since 2.004, that
addressed the circular dependency issue as well as the issues
mentioned above, but they never were sponsored, and that only makes it
harder now. It's partly my fault for not pushing harder for a sponsor.
Sigh.

I think it would be a disservice to the community to ship the current
not-fully-functional combination of common-lisp-controller and cl-asdf
packages.

It was suggested to me (by pabs on #debian-mentors) that at this
stage, cl-asdf would be more likely to be removed than upgraded to
2.011. That would mean that common-lisp-controller and all common-lisp
source package would likely be removed, too. That might be a much
bigger change than upgrading cl-asdf, in addition to making debian not
quick as useful for CL programmers. Or the current packages could be
left as is - in a rather unstable state, with the circular
dependencies and broken gcl support and bugs. Meh.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
...so this guy walks into a bar.
The usual, Mr. Descartes? the barman asked.
I think not, Rene replied, and promptly disappeared.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#592768: complementary information

[Faré]

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 Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Never abandon a theory that explains something until you have a theory that
explains more.  — John McCarthy



On 16 September 2010 15:57, stef louise stephane.r.lou...@gmail.com wrote:
 Hi,

 This bug seems quite quiet for a grave bug (the update manager refuse
 to work since then).
 I tried to use dpkg which seems to give more accurate messages for
 common-lisp installation:

 # LANG=C dpkg -i /var/cache/apt/archives/common-lisp-controller_7.4_all.deb
 (Reading database ... 196004 files and directories currently installed.)
 Preparing to replace common-lisp-controller 7.4 (using
 .../common-lisp-controller_7.4_all.deb) ...
 Unpacking replacement common-lisp-controller ...
 Setting up common-lisp-controller (7.4) ...
 Reinstalling for clisp
 Recompiling Common Lisp Controller for clisp
 Installing clc...
 ;; Loading file /usr/lib/clisp-2.48/install-clc.lisp ...
 ;;  Loading file
 /usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp
 ...
 ;;  Loaded file
 /usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp
 *** - handle_fault error2 ! address = 0x77dc3ba0 not in
 [0x699c60d8,0x69aa3000) !
 SIGSEGV cannot be cured. Fault address = 0x77dc3ba0.
 GC count: 0
 Space collected by GC: 0 0
 Run time: 0 42538
 Real time: 0 276550
 GC time: 0 0
 Permanently allocated: 108736 bytes.
 Currently in use: 3721376 bytes.
 Free space: 14 bytes.
 /usr/lib/common-lisp/bin/clisp.sh: line 16:  4303 Segmentation fault
   ${builder} -norc -q -M ${orig_mem} -on-error exit -x 
 (handler-case
  (progn
    (when (find-package :c-l-c) ; have to remove
      (delete-package :c-l-c))  ; for clisp workaround
    (load \$clisp_dir/install-clc.lisp\)
    (saveinitmem \${target_mem}\)
    (ext:exit 0))
  (error (e)
    (ignore-errors (format t \~install-clc error: ~A~%\ e))
    (finish-output)
    (ext:exit 1)))
 Building of new image failed!

 Done rebuilding
 Processing triggers for man-db ...

 I'd like to help further, but is there some easy way to provide more feedback?
 regards



 ___
 pkg-common-lisp-devel mailing list
 pkg-common-lisp-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-common-lisp-devel




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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 problem with socialism is that eventually you run out of
other people's money. — Margaret Thatcher



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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? How do the
configuration
 script currently resolve the dependency issue?

I believe that
a- c-l-c should be simplified with respect to the newest ASDF2, and
marked as depending on ASDF 2.004 or later.
b- dh_lisp should be simplified with respect to said new c-l-c
c- cl-asdf would then not depend on c-l-c anymore.

Who on the debian CL team is in charge of c-l-c? If no one, would
anyone upload my changes? How do I upload a -2 package on mentors with
it complaining that there is no orig tarball?

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Amateurs talk strategy. Professionals talk logistics. - old military saying

On 31 July 2010 10:03, Bill Allombert ballo...@debian.org wrote:
 Package: cl-asdf
 Version: 2:2.004-1
 Severity: important

 Hello Debian Common Lisp Team,

 There is a circular dependency between cl-asdf and common-lisp-controller:

 cl-asdf                 :Depends: common-lisp-controller (= 5.11)
 common-lisp-controller  :Depends: cl-asdf (= 1.625)

 Circular dependencies are known to cause problems during upgrade, so we
 should try to get rid of them.

 See threads
 http://lists.debian.org/debian-devel/2005/06/msg02111.html
 http://lists.debian.org/debian-devel/2005/11/msg01101.html

 Cheers,
 --
 Bill. ballo...@debian.org

 Imagine a large red swirl here.




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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 for you?

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Early in life I had to choose between honest arrogance and hypocritical
humility. I chose honest arrogance and have seen no occasion to change.
— Frank LLoyd Wright




On 22 July 2010 11:42, Alexander Reichle-Schmehl toli...@debian.org wrote:
 Hi!

 * Alexander Reichle-Schmehl toli...@debian.org [100722 17:37]:

      I've installed sbcl in a clean sid (amd64) chroot (main system is
  i386 with amd64 kern) started sbcl and (require)d some libraries
  (cl-irc) which all went well. If it's still breaking for you I'll have
  to discuss this with upstream
 I could reproduce the problem in a pure amd64 environment.  I'm waiting
 for the i386 chroot to finish upgrading to see if it makes a difference.

 That was faster than I thought.  I can reproduce the problem on in
 uptodate sid chroots on amd64 as well as i386 (on amd64 system).  Full
 logs attached.




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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.
— Edgar Waston Howe




On 17 May 2010 00:51, Antonio P. P. Almeida peru...@gmail.com wrote:
 I'm on squeeze and it had the same symptoms.

 The patch didn't work for me either.

 The fix proposed of replacing sb-impl with sb-unix solved the issue.

 Patch attached.

 Thank you,
 --- appa

 ___
 pkg-common-lisp-devel mailing list
 pkg-common-lisp-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-common-lisp-devel





--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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 aelschur...@hotmail.com wrote:
 Package: cl-asdf
 Version: 2:1.502-1
 Severity: normal

 I'm trying to install ecl, but the system won't let me:

 [...]
 Reinstalling for ecl
 Recompiling Common Lisp Controller for ecl
 /usr/lib/common-lisp/bin/ecl.sh loading and dumping clc.
 ;;; Loading /usr/lib/ecl/install-clc.lisp
 ;;; Loading #P/usr/lib/ecl-9.6.1/cmp.fas
 ;;; Loading #P/usr/lib/ecl-9.6.1/sysfun.lsp

 Saving to new-ecl...
 ;;; Loading 
 /var/cache/common-lisp-controller/0/ecl/common-lisp-controller/common-lisp-controller.fas
 ;;; Loading /var/cache/common-lisp-controller/0/ecl/cl-asdf/asdf.fas

 The function SYSTEM-SOURCE-FILE is undefined.
 Available restarts:

 1. (QUIT-DEBUGGER) Quit debugger level 1.
 2. (ABORT) ABORT

 Top level.
 ASDF


 Choosing either 1 or 2 has no effect, I have to interrupt the ecl-original
 process through kill or Ctrl-C to have the installation continue, only to
 reach the same error message further down in the configure process.

 Eventually, the installation succeeds without aptitude mentioning that
 package configuration has failed. I'm happy to ignore this error if you say
 it is harmless, but it doesn't seem that way to me. Maybe a missing
 dependency?


 -- System Information:
 Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (900, 'stable'), (300, 'squeeze'), (300, 
 'unstable'), (200, 'experimental')
 Architecture: i386 (i686)

 Kernel: Linux 2.6.34-rc4 (PREEMPT)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
 LC_ALL set to en_US.UTF-8)
 Shell: /bin/sh linked to /bin/dash

 cl-asdf depends on no packages.

 Versions of packages cl-asdf recommends:
 ii  clisp [lisp-compiler]       1:2.44.1-4.1 GNU CLISP, a Common Lisp 
 implement
 ii  common-lisp-controller      6.18         Common Lisp source and compiler 
 ma
 ii  ecl [lisp-compiler]         9.6.1-1      Embeddable Common-Lisp: has an 
 int

 cl-asdf suggests no packages.

 -- no debconf information



 ___
 pkg-common-lisp-devel mailing list
 pkg-common-lisp-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-common-lisp-devel




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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), and of
 course I cannot reproduce your problem.  My guess is that this is also
 the the default, (or the also working 65536, which probably means
 any) on the autobuilder which contructed your package.

 The gcl binary is saved via unexec from an executing state on a
 machine which successfully built the package (same as emacs).  My
 guess also is that if you built from source, you would likely get a
 working image dump.  gclcvs attempts to detect whether it can get more
 heap room by lowering its start address at configure time.  If this
 works, a linker script is constructed
 (/usr/lib/gcl-2.7.0/unixport/gcl.script) with the correct
 instructions, and perhaps 128Mb extra heap is available.  I think you
 have found a situation in which such an optimized binary is not
 portable across multiple kernel configurations.

 This is not new.  gcl must also work around sbrk randomization by the
 kernel, which it attempts to do automatically at runtime.  It tests
 segfault address recovery at first run of (si::sgc-on), and disables
 the facility if broken on the running machine.  Certain arm machines
 allowed certain assembly instructions that others simply ignored.
 Finally, if some kernel security package prohibits execution from the
 .data section, gcl will also bail.

 I think that this is best addressed by a trap statement in the wrapper
 script pointing to possible kernel settings needing adjustment.
 Perhaps an external webpage with updated info as time goes on.

 Do you agree?

I mostly agree. But additionally, I'd say it would be nice if the
optimization was careful not to go as low as zero, but stayed on the
right side of a global minimum (say 64K) as well as any detected
limitation (including checking the sysctl when available). This
matters especially if/when gcl is compiled as root, where some
limitations don't apply that will apply to the user who tries to run
same optimized binary.

Sorry for late reply, email got categorized in a folder I don't often check.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Lisp programmer available: Will write code
that writes code that writes code for food. — Rob Warnock



--
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

[Faré]

 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 such that would provide an abstraction to the
implementation-dependent scripts.

 5- Short of including such hook, the simple solution is to use
 ASDF's builtin per-user cache facility, except maybe for the root
 user.

 ok but given that we don't have the 'use the root cache for fasl files'
 yet, I guess that the simplest is just to use the build-in cache. Not?

 Just to be clear: do to this I just need to remove all the
 customizations. Right?

Right. Sorry about that.

If we want to resurrect a /var/cache/common-lisp-controller/$UID/
cache hierarchy, we'll have to be more clever and have hooks in ASDF.

 6- CLC needs to update ASDF to latest, anyway.

 What version do you suggest? 1.7xx or 1.6xxx?

In general, you should use the latest release tarball / git tag RELEASE.
Current RELEASE is 1.703. (Admittedly, wasn't so when you inquired;
I had left it at 1.679, but I bumped it to 1.703 considering I have had
positive feedback in the three days since the release.)

 Thanks for your help! Peter
Thanks a lot for the packaging!

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
If atheism is a religion, then not collecting stamps is a hobby.



--
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

[Faré]

Severity: critical

now that I look at it again,

1- if we don't fix this bug, C-L-C is unusable to whomever doesn't
configure asdf-output-translations himself.

2- C-L-C needs to (asdf:clear-output-translations) and
(asdf:clear-source-registry) right before it dumps images, for all
implementations.

3- This is NOT ENOUGH. Actually using /var/cache/$UID without doing
the permission checking, etc., will reopen the security issue with bug
328633.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=328633
http://www.debian.org/security/2005/dsa-811

4- There is no good place in ASDF currently into which to hook such
security checking. Maybe a :before method on perform for compile-op or
load-op on systems. Meh. If you have a good idea for an API for that,
or want to discuss the issue, please send a message to the asdf-devel
mailing-list.

5- Short of including such hook, the simple solution is to use
ASDF's builtin per-user cache facility, except maybe for the root
user.

6- CLC needs to update ASDF to latest, anyway.

Sigh. Sorry for the trouble. Getting there.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
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

Bug#577210: tries to write FASL in wrong directory

[Faré]

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-common-lisp-controller-v4 and/or in a new
function called by every dump script *after* the user-code in
lisp-config.lisp, because that file might be using ASDF.

While we're at it, there are other embarrassing small bugs in ASDF
1.627 (such as the failure to directorify $SBCL_HOME) that make me
recommend upgrading to 1.673 for the next C-L-C.

[ 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, Getting Things Done




On 10 April 2010 14:38, Pierre THIERRY nowhere@levallois.eu.org wrote:
 Package: common-lisp-controller
 Version: 7.1
 Severity: grave

 Although I'm not user with UID 0, CLC tries to write in
 /var/cache/c-l-c/0, which is owned by root:

 --8---8---
 pie...@pape:~$ id
 uid=1000(pierre) gid=1000(pierre) 
 groupes=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),44(video),46(plugdev),108(netdev),114(fuse),119(kvm),1000(pierre)
 pie...@pape:~$ sbcl --eval (asdf:oos 'asdf:load-op :cl-utilities)
 This is SBCL 1.0.34.0.debian, 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.
 ; loading system definition from
 ; /usr/share/common-lisp/systems/cl-utilities.asd into #PACKAGE ASDF0
 ; registering #SYSTEM CL-UTILITIES {10034BABD1} as CL-UTILITIES

 debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread #THREAD
                                                           initial thread 
 RUNNING
                                                           {10031FB1C1}:
  can't create directory /var/cache/common-lisp-controller/0/SBCL/

 Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

 restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY          ] Retry directory creation.
  1: [CONTINUE       ] Continue as if directory creation was successful.
  2: [TRY-RECOMPILING] Try recompiling package
  3: [RETRY          ] Retry performing #ASDF:COMPILE-OP NIL {1003A8B811} on
                       #ASDF:CL-SOURCE-FILE package {10034C9341}.
  4: [ACCEPT         ] Continue, treating #ASDF:COMPILE-OP NIL {1003A8B811}
                       on #ASDF:CL-SOURCE-FILE package {10034C9341} as
                       having been successful.
  5:                   Ignore runtime option --eval (asdf:oos 'asdf:load-op 
 :cl-utilities).
  6: [ABORT          ] Skip rest of --eval and --load options.
  7:                   Skip to toplevel READ/EVAL/PRINT loop.
  8: [QUIT           ] Quit SBCL (calling #'QUIT, killing the process).

 (ENSURE-DIRECTORIES-EXIST
  #P/var/cache/common-lisp-controller/0/SBCL/usr/share/common-lisp/source/cl-utilities/package.fasl)[:EXTERNAL]
 0] ;
 ; compilation unit aborted
 ;   caught 1 fatal ERROR condition
 * pie...@pape:~$
 --8---8---

 -- System Information:
 Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (900, 'stable'), (600, 'unstable'), (1, 
 'experimental')
 Architecture: amd64 (x86_64)

 Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores)
 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages common-lisp-controller depends on:
 ii  adduser                       3.112      add and remove users and groups
 ii  bash                          4.1-2      The GNU Bourne Again SHell
 ii  cl-asdf                       2:1.627-1  Another System Definition 
 Facility
 ii  debconf [debconf-2.0]         1.5.30     Debian configuration management 
 sy
 ii  debianutils                   3.2.2      Miscellaneous utilities specific 
 t
 ii  perl                          5.10.1-11  Larry Wall's Practical Extraction
 ii  realpath                      1.15       Return the canonicalized absolute

 common-lisp-controller recommends no packages.

 Versions of packages common-lisp-controller suggests:
 ii  sbcl                        1:1.0.34.0-1 A Common Lisp compiler and 
 develop

 -- debconf information:
  common-lisp-controller/short-site-name: Inconnu
  common-lisp-controller/long-site-name: Nom de site indéfini



 ___
 pkg-common-lisp-devel mailing list
 pkg-common-lisp-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-common-lisp-devel




--
To 

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

[Faré]

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/saved_ansi_gcl: error while loading
shared libraries: /usr/lib/gcl-2.7.0-prof//unixport/saved_ansi_gcl:
failed to map segment from shared object: Permission denied

As root:
# /lib/ld-linux-x86-64.so.2 --list
/usr/lib/gcl-2.7.0-prof//unixport/saved_ansi_gcl
linux-vdso.so.1 =  (0x7fffc59e7000)
libX11.so.6 = /usr/lib/libX11.so.6 (0x7fb3a213d000)
[...]

If I run a gclcvs process and cat its /proc/$pid/maps, I get:
-00812000 r-xp  fd:00 286779
  /usr/lib/gcl-2.7.0-prof/uni
xport/saved_ansi_gcl
00a11000-010a5000 rw-p 00811000 fd:00 286779
  /usr/lib/gcl-2.7.0-prof/uni
xport/saved_ansi_gcl
010a5000-031fa000 rwxp 00ea5000 fd:00 286779
  /usr/lib/gcl-2.7.0-prof/uni
xport/saved_ansi_gcl
031fa000-0444a000 rw-p  00:00 0  [heap]
760bb000-763a7000 r--p  fd:00 405172
  /usr/lib/locale/locale-arch
ive
[...]

It looks like mapping stuff to page 0 might be disabled by default for
non-root users on my linux kernel (which is the default debian linux
kernel with default configuration).

Can gcl either avoid doing that, or take steps to ensure the
configuration is correct, or at least warn the user and tell him what
configuration settings to change and how?

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
How many big company employees does it take to enact a one-liner change to a
system configuration file? At least one engineer per horizontal layer in the
organization, plus each of their managers, and then some — but in the end
everyone's ass will be covered.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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_addr = 0
$ GCL_ANSI=t gclcvs
GCL (GNU Common Lisp)  2.7.0 ANSIFeb  3 2010 05:59:20
[...]


Interestingly, this is for me on a 2.6.30-1-amd64 kernel.
Evet on #lisp says gcl works for him on 2.6.26 with his untouched
default vm.mmap_min_addr=65536.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Brain, n.:
The apparatus with which we think that we think.
— Ambrose Bierce, The Devil's Dictionary



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

 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/usr/share/common-lisp/cl-build/systems/ #P~/.clc/systems/
  #P/usr/share/common-lisp/systems/))
 1.502

This is ample evidence that your setup is, in fact, working.

Why do you complain about it not working? What doesn't work?

Just add appropriate configuration information in
~/.config/common-lisp/source-registry.conf.d/

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Backwards compatible — If it's not backwards it's not compatible
— Greg Newton gregnew...@netscape.net



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/653bea161002151053t12c20800pa8f847d132fb4...@mail.gmail.com

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

[Faré]

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 party of the first part shall be known in this contract
as the party of the first part.
— Groucho Marx




On 14 February 2010 13:11, Victor Chukhantsev victor.non...@gmail.com wrote:
 Package: cl-asdf
 Version: 2:1.502-1
 Severity: normal

 cl-asdf don't load configuration files from 
 /etc/common-lisp/source-registry.conf.d

 -- System Information:
 Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
 Architecture: i386 (x86_64)

 Kernel: Linux 2.6.32-2-amd64 (SMP w/2 CPU cores)
 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 cl-asdf depends on no packages.

 Versions of packages cl-asdf recommends:
 ii  common-lisp-controller      7.0          Common Lisp source and compiler 
 ma
 ii  sbcl [lisp-compiler]        1:1.0.31.0-2 A Common Lisp compiler and 
 develop

 cl-asdf suggests no packages.

 -- no debconf information



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/653bea161002141253s4734bd8er1ddfb10d880d4...@mail.gmail.com

Bug#568818: Verified, and workaround

[Faré]

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 add-on you had to download and install
separately). But they were removed in further versions of ASDF like
the current 1.606 release, as ASDF-Binary-Locations was replaced by a
ASDF-Output-Translations, a new system that is easier and simpler to
configure, and that further versions of Common-Lisp-Controller will
use, at which point you can use the magic function
asdf:compile-file-pathname*.

I apologize for the breakage.

Peter, can you update C-L-C to use the new ASDF? I think the API of
AOT is stable now.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Science is like sex: sometimes something useful comes out,
but that is not the reason we are doing it
— Richard Feynman



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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 :wild) by refusing to match names
without a dot in them, which is unfortunate. So it's better to have a
name in .conf or some such under that directory.

We'll probably need the same kind of thing for ABL configuration. Any
taker for the configuration language?

http://common-lisp.net/gitweb?p=projects/xcvb/asdf.git

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
The last good thing written in C was Franz Schubert's Symphony number 9.
— Erwin Dieterich er...@cvt12.verfahrenstechnik.uni-stuttgart.de



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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
 just drop files into. Just like we have /etc/crontab and /etc/cron.d/*
 on Debian.

 This would make my and I suspect others work much easier.

Makes perfect sense. I'll add that on top of my TODO list for ASDF.
Would that replace source-registry.conf altogether, or override it, or
be overridden by it?

 Since ASDF-BINARY-LOCATIONS is now part of ASDF, I suppose it could be
 similarly configured, and CLC could and should just use that. What
 do you think?

 I just noticed this in the manual and need to read it with more
 attention later. Ideally I would like it to handle also 'cached' fasl
 files from a trusted system user. Would it be able to do this too?

I probably would do it, if we coax it to our will. Definitely
possible. I admit I never looked into ABL myself, having only ever
used but my own variant (included in cl-launch) that itself is derived
from an earlier CLC and works well with CLC.
Hopefully, moving ABL into ASDF was a good move, and we should get the
configuration of it right.

 So load from
 /var/cache/common-lisp-controller/cl-builder/implementation/...
 or
 /var/cache/common-lisp-controller/userid/implementation/...
 or compile from /usr/share/common-lisp-controller/source/... to
 /var/cache/common-lisp-controller/userid/implementation/...

Yes. All the while, the default might be something like
~/.cache/common-lisp/same-tag-as-slime/...

 Related: I might go for a business trip to Boston in the near future and
 would love to have a chat!
I would love to see you again!

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
He who refuses to do arithmetic is doomed to talk nonsense.
— John McCarthy, in his webpage on Progress and Sustainability



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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 signal change.)
You can already try out this version by checking out of my repository.

The documentation about the new source-registry feature is in
README.source-registry.

I recommend you package a proper /etc/common-lisp/source-registry.conf with CLC.

Since ASDF-BINARY-LOCATIONS is now part of ASDF, I suppose it could be
similarly configured, and CLC could and should just use that. What
do you think?

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
To avoid criticism, do nothing, say nothing, and be nothing. – Elbert Hubbard



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

 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 it gets compiled separately for every user, unless
 admin first runs a shell command like:

 $ clc-precompile sbcl cl-cffi

 At which point, the fasls are compiled for sbcl and usable by all users. An
 upgrade of cl-cffi would have to make sure to delete that cache, so that the
 per-user cache can be populated for the new version.

 But anyways, this is all incremental improvements. What's most important to
 me is that, by default, without additional configuration, installing sbcl
 and the cl-cffi packages actually makes cffi usable, in the normal way
 (require :cffi), on the system sbcl.

If ASDF-BINARY-LOCATIONS had a /etc/common-lisp/asdf-binary-locations.conf
that itself included a file /var/common-lisp/clc-binary-locations.conf
then the latter file could get updated to point binaries for CLC
packages either to
/var/cache/common-lisp/0/...
for specific precompiled packages or to
/var/cache/common-lisp/$UID/...
by default (or perhaps even ~/.cache/common-lisp/...).

--#f
There is only one thing more harmful to society than an elected official
forgetting the promises he made in order to get elected; that's when he
doesn't forget them.  — John McCarthy



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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 could just
include an updated ASDF with a proper
/etc/common-lisp/source-registry.conf with the CLC installation. See
http://common-lisp.net/pipermail/asdf-devel/2009-December/000580.html

 - - make the inclusion of the CLC directory configurable
What about making it configurable through a normal ASDF-wide
configuration file? i.e. my proposed change above.

 - - add clbuild support to the package:
cl-build integration sounds great. I haven't thought about the
details, but you should probably send a pre-announce to the clbuild
mailing-list.

 What other changes would people like to see?

I'd like the patch that fixes this bug to be merged in next CLC:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=382430

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
The party of the first part shall be known in this contract
as the party of the first part.
— Groucho Marx



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Faré]

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
/etc/common-lisp/source-registry.conf
~/.config/common-lisp/source-registry.conf

If you can use the same directory, that's great.

If what you're configuring is a set of paths, then we should get in
touch and agree on the syntax. I need to update the relevant ASDF bug
with my latest plans.
https://bugs.launchpad.net/asdf/+bug/485918

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
The common argument that crime is caused by poverty
is a kind of slander on the poor.
— H. L. Mencken



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#382430: Fix to this bug

[Faré]

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/common-lisp-controller.postinst
and
/var/lib/dpkg/info/common-lisp-controller.postrm
do something about a /etc/lisp-config.lisp ???
Probably another bug...

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Necessity is the mother of invention is a silly proverb.  Necessity
is the mother of futile dodges is much nearer the truth.
-- Alfred North Whitehead
--- /usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp	2009-09-03 00:10:55.0 -0400
+++ /usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp.new	2009-09-24 20:00:57.0 -0400
@@ -3,9 +3,19 @@
 ;;; Copyright (C) 2000,2004  Peter Van Eynde and Kevin M. Rosenberg
 ;;; Licensed under the LLGPL, see debian/copyright file
 
-
 (in-package #:cl-user)
 
+#+ecl ;; Hush ECL
+(setf *load-verbose* nil
+  *load-print* nil)
+
+;; use the implementation-provided asdf version for increased
+;; compatibility with the normal sbcl or ecl
+
+#+(or sbcl ecl)
+(require :asdf)
+
+
 (defpackage #:common-lisp-controller
   (:use #:common-lisp)
   (:export #:init-common-lisp-controller
@@ -18,11 +28,11 @@
 	   #:calculate-fasl-root
 	   #:list-systems
 	   #:*redirect-fasl-files-to-cache*
-	   ;; depricated:
+	   ;; deprecated:
 	   #:make-clc-send-command-string
 	   #:send-clc-command)
   (:nicknames #:clc
-	; depricated:
+	; deprecated:
 	  #:c-l-c))
 
 (in-package #:common-lisp-controller)
@@ -58,7 +68,7 @@
 (defun init-common-lisp-controller-v5 (implementation-name)
   ;; register the systems root:
   (setf *implementation-name* implementation-name)
-  
+
   (pushnew :common-lisp-controller *features*)
   (pushnew :clc-os-debian *features*))
 
@@ -89,7 +99,7 @@
 	   ;; this is complex because ecl
 	   ;; should produce system fasls,
 	   ;; and they have .o extension
-	   (merge-pathnames 
+	   (merge-pathnames
 		(make-pathname :type o)
 		(fasl-filename package-name filename)))
 	 (fasl-filename (package-name filename)
@@ -125,13 +135,13 @@
 		 ;; return fasl filename
 		 compiled-file-pathname
 		 ;; now for ecl: make the system file
-		 #+ecl 
+		 #+ecl
 		 (compile-file file-path
 			   :output-file
 			   (system-fasl-filename package-name filename)
 			   :print nil
 			   :verbose nil
-			   ;; make 'linkable object files' 
+			   ;; make 'linkable object files'
 			   :system-p t
 
   ;; then asdf:
@@ -139,12 +149,6 @@
   #+sbcl
   (when (boundp 'sb-ext::*module-provider-functions*)
 	(pushnew :sbcl-hooks-require cl:*features*))
-  
-  ;; use the sbcl asdf version for increased
-  ;; compatibility with the normal sbcl
-  
-  #+sbcl
-  (require :asdf)
 
   ;; return a list
   (prog1
@@ -155,11 +159,11 @@
 	(compile-and-load  common-lisp-controller
 			   common-lisp-controller.lisp)
 	;; asdf
-	#-sbcl
+	#-(or sbcl ecl)
 	(compile-and-load  cl-asdf asdf.lisp)
-	
+
 	(compile-and-load  cl-asdf wild-modules.lisp)
-	
+
 	;; now patch it::
 	(compile-and-load common-lisp-controller
 			  post-sysdef-install.lisp))

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

[Faré]

I cannot reproduce at this time.

When I tried to reproduce earlier, the bug was very sensitive to some
unidentified parameters. While in a given shell, changing the TERMCAP
variable as shown would trigger the bug, in another shell it wouldn't.
It could be some buffer overflow of some sort, 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 and an ARGV0 of length = 7 reveals the bug.

 I cannot reproduce it on etch nor on a clean sid chroot:

 =
 $ export TERM=screen.linux
 $ export TERMCAP='SC|screen.linux|VT 100/ANSI X3.64 virtual terminal:\
   :hs:ts=\E_:fs=\E\\:ds=\E_\E\\:\
   :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\
   :cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\
   :do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\
   :le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\
   :li#27:co#100:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\
   :cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\
   :im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\
   :ke=\E[?1l\E:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\
   :ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E[24m:so=\E[3m:\
   :se=\E[23m:mb=\E[5m:md=\E[1m:mh=\E[2m:mr=\E[7m:\
   :me=\E[m:ms:\
   :Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\
   :vb=\Eg:as=\E(0:ae=\E(B:\
   
 :ac=\140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\
   :k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:\
   :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:\
   :F1=\E[23~:F2=\E[24~:F3=\E[25~:F4=\E[26~:F5=\E[28~:\
   :F6=\E[29~:F7=\E[31~:F8=\E[32~:F9=\E[33~:FA=\E[34~:kb=:\
   :K2=\E[G:kB=\E[Z:kh=\E[1~:@1=\E[1~:kH=\E[4~:@7=\E[4~:\
   :kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:\
   :kr=\EOC:kl=\EOD:'
 $ ARGV0=cmucl /usr/bin/cmucl
 =

 I also tried the second TERMCAP setting you gave at [1], but still
 without success in reproducing the bug, both with bash or dash.

 Can you confirm you still experience this bug, please?

 Thx, bye,
 Gismo / Luca

 Footnotes:
 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407606#30



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[Faré]

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 the ecl
 provided one has. I think having a 'special' asdf for ecl is asking for
 compatibility problems.

That's a valid fix indeed. Now introducing maintenance problems instead :-)

 (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

 This after some searching turns out to be caused because
 common-lisp-controller.lisp uses the function 'compile-file'. As the clc
 enabled ecl includes this it causes these messages:

  ;;; Loading #P/usr/lib/ecl/cmp.fas
  ;;; Loading #P/usr/lib/ecl/sysfun.lsp

 I'm currently investigation how to fix this.

Can't you use a :verbose nil option when loading these files, and/or
set *load-verbose* to nil?

  (3) compiling configuration files everytime can be a performance issue,
  in addition to requiring to load the compiler.

 I'm not so certain what configuration files you're referring to here.

I admit I don't remember anymore :-(
Maybe I was thinking of sysfun.lsp.
Maybe tracing compile-file will tell you.

subliminalcl-launch/subliminal

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
To this, I shall add one more example: the victim controls the torturer,
becauses if the victim screams very loudly at a particular method of torture,
this is the method the torturer will select to use.
-- Ayn Rand, expounding behaviorist pseudo-psychology,
in Philosophy: Who Needs It?, The Stimulus and the Response

Bug#315762: can reproduce here

[Faré]

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-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Being really good at C++ is like being really good at using rocks
to sharpen sticks.
-- Thant Tessman

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

[Faré]

OK, it gets weirder.

On the zsh command-line, I can make it fail deterministically. In a sh
script, it deterministically works. I traced that to the argv[0].
Using zsh, I can explicitly call
#!/bin/zsh -f
ARGV0=cmucl /usr/bin/cmucl
and have it fail deterministically (given the appropriately long
TERMCAP and TERM -- otherwise it still works).

Note that in the backtrace, those frames are fishy:
10: (KERNEL:CSUBTYPEP #ARRAY-TYPE SIMPLE-BASE-STRING #UNION-TYPE LIST)
11: (MAKE-SEQUENCE SIMPLE-STRING 15 :INITIAL-ELEMENT NIL)
12: (LISP::CONCAT-TO-SIMPLE* SIMPLE-STRING /home/fare/bug /)

The initial-element NIL is undefined behaviour when a BASE-CHAR is
otherwise wanted. This is in CONCAT-TO-SIMPLE* from code/seq.lisp. The
compiler might be confused between inferred types and producing
something fishy.

When I start cmucl and get it in buggy mode, then trying to
(LISP::CONCAT-TO-SIMPLE* 'SIMPLE-STRING /home/fare/bug /)
or
(MAKE-SEQUENCE 'SIMPLE-STRING 15 :INITIAL-ELEMENT NIL)
from the debugger's REPL consistently cause the same SIGSEGV. Whereas
when I start it in non-buggy mode, the former gives the expected
result /home/fare/bug/ (the current directory) and the latter
correctly gives a Type-error in
KERNEL::OBJECT-NOT-BASE-CHAR-ERROR-HANDLER:
  NIL is not of type BASE-CHAR
This suggests an issue with low-safety evaluation. How do I check the
current safety settings?

[ François-René ÐVB Rideau | ReflectionCybernethics | 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.
 Actually I cannot find serious references to TERMCAP in the cmucl
 sources so I fail to see where it could crash the image...
There is a hemlock/termcap.lisp and a hemlock/rompsite.lisp, where the
environment variable is used. Maybe it would help if these were
compiled with a better debugging setting?

 What does strace say?
strace and ltrace output attached.
Not very informative to me.

NB: regarding the suggestion by Pierre Thierry, I wouldn't know what to ask GDB.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
The main difference between a computer salesman and a used car salesman is
that the used car salesman can probably drive and knows when he's lying.
- Peter da Silva

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

[Faré]

a big TERMCAP and an ARGV0 of length = 7 reveals the bug.
It looks like the overall size and/or alignment of the environment in
general may contribute to revealing the bug or not.

Indeed, trying to reproduce the bug with a different environment
causes a very different pattern in when the bug is triggered.
Sometimes, I don't even need to change TERM or TERMCAP.

If you can suggest other things to try, I'll be glad.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Every program has at least one bug and can be shortened by at least one
instruction -- 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 deterministically works. I traced that to the argv[0].
Using zsh, I can explicitly call
#!/bin/zsh -f
ARGV0=cmucl /usr/bin/cmucl
and have it fail deterministically (given the appropriately long
TERMCAP and TERM -- otherwise it still works).

Note that in the backtrace, those frames are fishy:
10: (KERNEL:CSUBTYPEP #ARRAY-TYPE SIMPLE-BASE-STRING #UNION-TYPE LIST)
11: (MAKE-SEQUENCE SIMPLE-STRING 15 :INITIAL-ELEMENT NIL)
12: (LISP::CONCAT-TO-SIMPLE* SIMPLE-STRING /home/fare/bug /)

The initial-element NIL is undefined behaviour when a BASE-CHAR is
otherwise wanted. This is in CONCAT-TO-SIMPLE* from code/seq.lisp. The
compiler might be confused between inferred types and producing
something fishy.

When I start cmucl and get it in buggy mode, then trying to
(LISP::CONCAT-TO-SIMPLE* 'SIMPLE-STRING /home/fare/bug /)
or
(MAKE-SEQUENCE 'SIMPLE-STRING 15 :INITIAL-ELEMENT NIL)
from the debugger's REPL consistently cause the same SIGSEGV. Whereas
when I start it in non-buggy mode, the former gives the expected
result /home/fare/bug/ (the current directory) and the latter
correctly gives a Type-error in
KERNEL::OBJECT-NOT-BASE-CHAR-ERROR-HANDLER:
   NIL is not of type BASE-CHAR
This suggests an issue with low-safety evaluation. How do I check the
current safety settings?

[ François-René ÐVB Rideau | ReflectionCybernethics | 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.
  Actually I cannot find serious references to TERMCAP in the cmucl
  sources so I fail to see where it could crash the image...
 There is a hemlock/termcap.lisp and a hemlock/rompsite.lisp, where the
 environment variable is used. Maybe it would help if these were
 compiled with a better debugging setting?

  What does strace say?
 strace and ltrace output attached.
 Not very informative to me.

 NB: regarding the suggestion by Pierre Thierry, I wouldn't know what to ask 
GDB.

 [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
 The main difference between a computer salesman and a used car salesman is
 that the used car salesman can probably drive and knows when he's lying.
 - Peter da Silva

Bug#407606: cmucl fails at initialization

[Faré]

It's pretty reproducible here, with cmucl 19d-20061116-1, which is the
latest I find in unstable. When you test it, does your $TERM match
your $TERMCAP ? Otherwise, cmucl might not be trying to use it.

TERM=screen.linux
TERMCAP='SC|screen.linux|VT 100/ANSI X3.64 virtual terminal:\
   :hs:ts=\E_:fs=\E\\:ds=\E_\E\\:\
   :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\
   :cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\
   :do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\
   :le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\
   :li#27:co#100:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\
   :cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\
   :im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\
   :ke=\E[?1l\E:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\
   :ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E[24m:so=\E[3m:\
   :se=\E[23m:mb=\E[5m:md=\E[1m:mh=\E[2m:mr=\E[7m:\
   :me=\E[m:ms:\
   :Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\
   :vb=\Eg:as=\E(0:ae=\E(B:\
   
:ac=\140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\
   :k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:\
   :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:\
   :F1=\E[23~:F2=\E[24~:F3=\E[25~:F4=\E[26~:F5=\E[28~:\
   :F6=\E[29~:F7=\E[31~:F8=\E[32~:F9=\E[33~:FA=\E[34~:kb=:\
   :K2=\E[G:kB=\E[Z:kh=\E[1~:@1=\E[1~:kH=\E[4~:@7=\E[4~:\
   :kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:\
   :kr=\EOC:kl=\EOD:'

or
TERMCAP='SC|screen.linux|VT 100/ANSI X3.64 virtual terminal:\
   
:kr=\EOC11:kl=\EOD22:ku=\EOA111:kd=\EOB444:'

[ 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 the problem is a buffer
 overflow (of all things!) when variable $TERMCAP is too big.

Interesting. And dangerous.

But I cannot reproduce it:

$ echo $TERMCAP | wc -c
11448
$ cmucl
CMU Common Lisp CVS 19d 19d-release (19D), running on frost
With core: /usr/lib/cmucl/lisp.core
Dumped on: Sat, 2006-12-30 21:27:55+01:00 on frost
For support see http://www.cons.org/cmucl/support.html Send bug reports
to the debian BTS.
or to [EMAIL PROTECTED]
type (help) for help, (quit) to exit, and (demo) to see the demos

Loaded subsystems:
 Python 1.1, target Intel x86
 CLOS based on Gerd's PCL 2004/04/14 03:32:47

Bug#407606: cmucl fails at initialization

[Faré]

After some experimentation, it looks like the problem is a buffer
overflow (of all things!) when variable $TERMCAP is too big.

Removing an entry from $TERMCAP makes cmucl happy. Making one
lengthier again makes it unhappy again.

PS: subliminalcl-launch/subliminal

[ François-René ÐVB Rideau | 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

[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=screen.linux as fare, but not when I am in a session outside of
screen, when I override TERM with screen or linux, or run as root
or a different user in screen. Note that screen.linux is defined in
$TERMCAP (that is the same in both working and non-working sessions).

Something is fishy, possibly in cmucl's TERM handling.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Wealth, like happiness, is never attained when sought after directly. It comes
as a by-product of providing a useful service. -- Henry Ford

Bug#407606: cmucl fails at initialization

[Faré]

Package: cmucl
Version: 19d-20061116-1
Severity: normal

*** Please type your report below this line ***
Since I last upgraded cmucl, I get the following error and backtrace
whenever I start it.

$ cmucl


Error in function UNIX::SIGSEGV-HANDLER:  Segmentation Violation at #x10044FB8.
  [Condition of type SIMPLE-ERROR]

Restarts:
 0: [ABORT] Skip remaining initializations.

Debug  (type H for help)

(UNIX::SIGSEGV-HANDLER #unused-arg
  #unused-arg
  #.(SYSTEM:INT-SAP #x3FFFCA7C))
Source: Error finding source:
Error in function LISP::%ENUMERATE-SEARCH-LIST:  Undefined search list: default
0] backtrace

0: (UNIX::SIGSEGV-HANDLER #unused-arg
 #unused-arg
 #.(SYSTEM:INT-SAP #x3FFFCA7C))
1: (UNIX::SIGSEGV-HANDLER 3
 #unused-arg
 #unused-arg
 #.(SYSTEM:INT-SAP #x3FFFCA7C))[:EXTERNAL]
2: (call_into_lisp+#x8C [#x805560C] cmucl)
3: (funcall3+#x32 [#x8055422] cmucl)
4: (interrupt_handle_now+#x105 [#x8050940] cmucl)
5: (EQUAL #Unprintable Instance {6C69663D} #ARRAY-TYPE SIMPLE-BASE-STRING)
6: (EQUAL
   (#Unprintable Instance {6C69663D} . #Unprintable Instance {682F3A65})
   (#ARRAY-TYPE SIMPLE-BASE-STRING #MEMBER-TYPE NULL))
7: ((FLET #:G30 KERNEL::%TYPE-INTERSECTION-CACHE-LOOKUP))
8: (KERNEL::%TYPE-INTERSECTION
   (#ARRAY-TYPE SIMPLE-BASE-STRING #MEMBER-TYPE NULL))
9: (KERNEL::UNION-COMPLEX-SUBTYPEP-ARG2 #ARRAY-TYPE SIMPLE-BASE-STRING
   #UNION-TYPE LIST)
10: (KERNEL:CSUBTYPEP #ARRAY-TYPE SIMPLE-BASE-STRING #UNION-TYPE LIST)
11: (MAKE-SEQUENCE SIMPLE-STRING 11 :INITIAL-ELEMENT NIL)
12: (LISP::CONCAT-TO-SIMPLE* SIMPLE-STRING /home/fare /)
13: (DEFAULT-DIRECTORY)
14: (LISP::ENVIRONMENT-INIT)
15: ((LABELS LISP::%RESTART-LISP SAVE-LISP))
16: ((LABELS LISP::RESTART-LISP SAVE-LISP))

0] (quit)
$


Interestingly, if I run cmucl -noinit, I get no such error.
However, I have no initialization file, as far as I can tell: neither of
 ~/init.lisp
 ~/.cmucl-init.lisp
exists
And strace fails on cmucl after the first memory-management-related segfault
so I don't know what's going on.

Also interestingly, if another user starts cmucl, it works.
If same user starts with a different $HOME, it also fails.
If another user with essentially the same config starts it, it works.
It used to all 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:
Debian Release: 4.0
 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 cmucl depends on:
ii  common-lisp-controller6.9This is a Common Lisp source and c
ii  debconf [debconf-2.0] 1.5.11 Debian configuration management sy

Versions of packages cmucl recommends:
pn  binfmt-supportnone (no description available)

-- debconf information:
 cmucl/upgradeproblems:

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

[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 from c-l-c and which
one has a private hacking copy of).

My take is:
* always enable a wrapper.
* the wrapper may only do a reduced mapping (restricted to
/usr/share/common-lisp/source) or an extended mapping depending on
some various runtime variable
* the wrapper may export a mechanism such as
cl-launch::exclude-from-cache to enable users to explicitly exclude
some directory trees from their magic caches.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
No woman ever falls in love with a man unless she has
a better opinion of him than he deserves.   -- Edgar Watson Howe

On 25/09/06, Debian Bug Tracking System [EMAIL PROTECTED] wrote:

This is an automatic notification regarding your Bug report
#382582: common-lisp-controller: c-l-c fails to exclude /usr/lib/sbcl and such 
from cache,
which was filed against the common-lisp-controller package.

It has been closed by Peter Van Eynde [EMAIL PROTECTED].

Their explanation is attached below.  If this explanation is
unsatisfactory and you have not received a better one in a separate
message then please contact Peter Van Eynde [EMAIL PROTECTED] by replying
to this email.

Debian bug tracking system administrator
(administrator, Debian Bugs database)




-- Forwarded message --
From: Peter Van Eynde [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Mon, 25 Sep 2006 06:02:08 -0700
Subject: Bug#382582: fixed in common-lisp-controller 6.3
Source: common-lisp-controller
Source-Version: 6.3

We believe that the bug you reported is fixed in the latest version of
common-lisp-controller, which is due to be installed in the Debian FTP archive:

common-lisp-controller_6.3.dsc
  to pool/main/c/common-lisp-controller/common-lisp-controller_6.3.dsc
common-lisp-controller_6.3.tar.gz
  to pool/main/c/common-lisp-controller/common-lisp-controller_6.3.tar.gz
common-lisp-controller_6.3_all.deb
  to pool/main/c/common-lisp-controller/common-lisp-controller_6.3_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Peter Van Eynde [EMAIL PROTECTED] (supplier of updated common-lisp-controller 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Mon, 25 Sep 2006 09:38:52 +0200
Source: common-lisp-controller
Binary: common-lisp-controller
Architecture: source all
Version: 6.3
Distribution: unstable
Urgency: low
Maintainer: Peter Van Eynde [EMAIL PROTECTED]
Changed-By: Peter Van Eynde [EMAIL PROTECTED]
Description:
 common-lisp-controller - This is a Common Lisp source and compiler manager
Closes: 382582 384457
Changes:
 common-lisp-controller (6.3) unstable; urgency=low
 .
   * Ignore source files beneath /usr/lib/
 (Closes: #382582)
   * Introduce the *redirect-fasl-files-to-cache* variable.
 If the value of this variable is true we redirect fasl files
 to the /var/cache directory. By default we will only redirect
 when compiling as the result of a clc-require call.
 (Closes: #384457)
   * Added po-debconf Build-Depends
   * Added XS-X-Vcs-Darcs header
Files:
 26368838973747b9c7fab7330f0e468a 689 devel optional 
common-lisp-controller_6.3.dsc
 e3143ee551485ba54cae6a9d689ae33f 31331 devel optional 
common-lisp-controller_6.3.tar.gz
 a686816b8906187fbdfd2e03cb767894 30760 devel optional 
common-lisp-controller_6.3_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFF6pl11ldN0tyliURAp1jAJ9aca6Zmz+SafBlGyjgm0kLviFf/ACfd94r
jlF7TxtCfiS/mrLhyJrRkjU=
=gNIF
-END PGP SIGNATURE-

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

[Faré]

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 | ReflectionCybernethics | http://fare.tunes.org ]
You may easily play a joke on a man who likes to argue -- agree with him.
   -- Edgar Waston Howe

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

[Faré]

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 corrupted is like saying that water is wet.

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

[Faré]

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 :split-sequence)


No matching method for the generic-function #compiled-closure
ASDF::VERSION-SATISFIES,
when called with arguments (:SPLIT-SEQUENCE NIL).

Apparently, the (find-system :split-sequence) (see the source for operate)
returned :split-sequence, which is erroneous. But when you try to

(find-system :split-sequence)

at the REPL, you also get

No matching method for the generic-function #compiled-closure
ASDF:COMPONENT-NAME,
when called with arguments (:SPLIT-SEQUENCE).


It looks like there is a bug in the way CLOS methods are compiled
by GCL 2.7.0 and/or in the way that c-l-c builds its gcl image,
because when you reload asdf.lisp (and re-define run-shell-command as in
/usr/lib/common-lisp/bin/gclcvs.sh), then everything works much better.

-- 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 gclcvs depends on:
ii  debconf [debconf-2.0] 1.5.2  Debian configuration management sy
ii  gcc   4:4.1.1-5  The GNU C compiler
ii  libc6 2.3.6-16   GNU C Library: Shared libraries
ii  libgmp3c2 2:4.2.1+dfsg-3 Multiprecision arithmetic library
ii  libice6   1:1.0.0-3  X11 Inter-Client Exchange library
ii  libncurses5   5.5-2  Shared libraries for terminal hand
ii  libreadline5  5.1-7  GNU readline and history libraries
ii  libsm61:1.0.0-4  X11 Session Management library
ii  libx11-6  2:1.0.0-7  X11 client-side library
ii  libxaw7   1:1.0.1-5  X11 Athena Widget library
ii  libxext6  1:1.0.0-4  X11 miscellaneous extension librar
ii  libxmu6   1:1.0.1-3  X11 miscellaneous utility library
ii  libxt61:1.0.0-5  X11 toolkit intrinsics library
ii  tcl8.48.4.12-1.1 Tcl (the Tool Command Language) v8
ii  tk8.4 8.4.12-1   Tk toolkit for Tcl and X11, v8.4 -

gclcvs recommends no packages.

-- debconf information:
 gclcvs/default_gcl_prof:
 gclcvs/default_gcl_ansi:


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[Faré]

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 enough pain to get cl-launch running on a wide variety of
shells (bash, zsh, posh, dash...) and I won't accept any bash-ism.
Eval is OK.

(2) since we're using eval I'd rather the variable be named
LISP_stumpwm or something like that.

(3) this patch just won't work when we're in --dump mode, since it
very wrongly overrides the $LISP from the dumped image. A script
generated with --dump should NOT read any kind of cl-launchrc.

(4) If you hack cl-launch, you might want to run cl-launch -l clisp
sbcl cmucl gcl -B tests from a temporary directory (complete with all
installed and supported implementations). This will run the self-test.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Amateurs talk strategy. Professionals talk logistics. - old military saying

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

[Faré]

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 statements such as:
system_preferred_lisps stumpwm cmucl sbcl clisp
system_preferred_lisps exscribe clisp cmucl

Then remains the question of whether or not the statements should
override a user-specified --lisps option. My current feeling is yes,
but issue a warning on stderr.

Also, the preferrence happens at script-creation time. At runtime, the
variable $LISP is still all that matters -- should it not?

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Clairvoyant, n.:
   A person, commonly a woman, who has the power of seeing that
which is invisible to her patron -- namely, that he is a blockhead.
   -- Ambrose Bierce

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

[Faré]

I put on my site a cl-launch 1.87 deb that I believe fixes 384697.
Testers: Please test.
Uploaders: please upload.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
If Java had true garbage collection, most programs would delete themselves
upon execution. -- Robert 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 processing.

A cl-launchrc file may contain statements such as:
system_preferred_lisps stumpwm cmucl sbcl clisp
system_preferred_lisps exscribe clisp cmucl

Then remains the question of whether or not the statements should
override a user-specified --lisps option. My current feeling is yes,
but issue a warning on stderr.

Also, the preferrence happens at script-creation time. At runtime, the
variable $LISP is still all that matters -- should it not?

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Clairvoyant, n.:
A person, commonly a woman, who has the power of seeing that
which is invisible to her patron -- namely, that he is a blockhead.
-- Ambrose Bierce

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

[Faré]

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 time),
whatever the --lisp or $LISPS variable be, unless explicitly prevented
with a --wrap argument (or a resetting of $LISP), and I think that's
all we need.

As for stumpwm, note that I prefer the more versatile --init argument:
  '(stumpwm:stumpwm (cl-launch:getenv DISPLAY))'
to a hardcoded :0.

If multiple dumped versions are wanted, they should each have a
different name, and the main script would select amongst them.

Finally, there are embarassing bugs in cl-launch 1.85, and I'd
appreciate it if one of my sponsors would have the time upload 1.86 to
unstable.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
You're currently going through a difficult transition period called Life.

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

[Faré]

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 image, because
I re-launch it with twiddled sources more often than I start it from
stable sources.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Merely having an open mind is nothing; the object of opening the mind,
as of opening the mouth, is to shut it again on something solid.
   -- G.K. Chesterton


On 24/08/06, Xavier Maillard [EMAIL PROTECTED] wrote:

Yo Luca,

   From: Luca Capello [EMAIL PROTECTED]

Is not this too long each time ? I was quite sceptic about dumping
an image too but it really speeds things up (a lot) at startup.

   Well, I never tested a dumped image and in my case I don't care at
   all about the startup speed, because as I'm a massive user of
   suspend-to-disk (sometime suspend-to-ram, too), I don't reboot my
   laptop (and consequently my X) so often.

Lucky you. Here too I massively use s2d but stumpwm (or lisp
implementation) often freezes here ;)

[snip]

   As I already stated, IMHO we should provide both solutions, maybe
   triggered by a command-line option ?  Far=C3=A9, what do you think about
   it?

I am not against that idea. Maybe just adding this information into
README.Debian can be enough or just display something when installing
the Debian package ?

Oh and by the way, do you maintaint a Debian repository where we could
apt-get stumpwm beta package ?

Xavier

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

[Faré]

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 ${IMAGE}

  cl-launch --lisp ${LISPS} \
  --path ${SYSTEMS} --no-include \
  --system stumpwm \
  --init '(stumpwm:stumpwm (cl-launch:getenv DISPLAY))' \
  --wrap 'LISP=sbcl SBCL=/usr/bin/sbcl SBCL_OPTIONS=  STY=' \
  --output ${BINARY} \
  ${DUMP}

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Mathematics is the Queen of Science but she isn't very Pure; she keeps
having babies by handsome young upstarts and various frog princes.
 --Donald Kingsbury (In psychohistorical crisis, 2001)



On 23/08/06, Luca Capello [EMAIL PROTECTED] wrote:

I was waiting for the upload of 1:20060513-2, which corrects small
Debian-related issues and the I'd upload a new CVS checkout, which is
necessary because of the (long-awaited) support for modifiers other
than Ctrl.

I'm testing on my Debian a checkout made 2 days ago and I'm planning
to ask to my sponsor to upload it next week (thus the pending tag).

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

[Faré]

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-controller6.1This is a Common Lisp source and c
ii  gcc-4.1   4.1.1-9The GNU C compiler
ii  libc6 2.3.6-16   GNU C Library: Shared libraries
ii  libgc-dev 1:6.7-2conservative garbage collector for
ii  libgc1c2  1:6.7-2conservative 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


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[Faré]

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 packages to debian?

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
The trouble with opportunity is that it always comes disguised as hard work.
   -- Herbert V. Prochnow



On 24/07/06, Andreas Jochens [EMAIL PROTECTED] wrote:

Package: cl-launch
Version: 1.80-1
Severity: serious
Tags: patch

When building 'cl-launch' on unstable,
I get the following error:

dh_testdir
# Add here commands to compile the package.
./cl-launch.sh -I /usr/share/common-lisp/cl-launch -B generate_install_files
make: execvp: ./cl-launch.sh: Permission denied
make: *** [build-stamp] Error 127



-   ./cl-launch.sh -I /${include_dir} -B generate_install_files
+   sh ./cl-launch.sh -I /${include_dir} -B generate_install_files

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

[Faré]

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 use cl-launch to make it an end user program too???


That leaves open how to generally resolve similar cases in other
packages.


IMNSHO, by using cl-launch.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
We know how syntax is prefix in LISP, whereas FORTH has a postfix syntax and
C's syntax is braindeadfix; well, the syntax of XML is a syntax that is a
hardcorepornfix syntax: it does it in the all places at the same time.

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

[Faré]

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 README.
Moreover, this package is not intended for common end-user, but for
users that have a specific background.


I run stumpwm using cl-launch, and there's no problem with that. You
might also want to use detachtty -- or then again you might prefer to
make it non-interactive. Or offer the alternative.

Note: I packaged cl-launch, but it's not yet included. Is lack of
signature on the latest package the issue?

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Men, it has been well said, think in herds; it will be seen that they go mad
in herds, while they only recover their senses slowly, and one by one.
   -- Charles Mackay

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

[Faré]

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, Getting Things Done

On 17/04/06, tomas pospisek [EMAIL PROTECTED] wrote:
 Maybe it's wiser to report this directly to upstream too. Since Debian's X
 team has currently a lot to do due to the transition to the new X server.
 *t

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

[Faré]

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 not quite usable.

All in all that's 32768 pixels, at 4 bytes per pixel, a 128KiB offset.
This upper section of the screen is originally filled with contents of
the previous VT, and slowly being filled by regular patterns, about
26 pixels at a time, about one burst per second.

In the X log, I see notably:

(--) PCI:*(0:2:0) Intel Corporation 82852/855GM Integrated Graphics
Device rev 2, Mem @ 0xd800/27, 0xd000/19, I/O @ 0xeff8/3
(--) PCI: (0:2:1) Intel Corporation 82852/855GM Integrated Graphics
Device rev 2, Mem @ 0x2000/27, 0x2a00/19
...
(--) I810(0): Virtual size is 1280x768 (pitch 1280)
(**) I810(0): *Built-in mode 1280x768
...
(II) I810(0): Attempting to use 61.11Hz refresh for mode 1280x768 (862)
...
(==) Depth 24 pixmap format is 32 bpp
(II) I810(0): Rotating to 0 degrees
(II) I810(0): initializing int10
(II) I810(0): Primary V_BIOS segment is: 0xc000
(II) I810(0): VESA BIOS detected
(II) I810(0): Allocated 128 kB for the ring buffer at 0x0
(II) I810(0): Allocating at least 256 scanlines for pixmap cache
(II) I810(0): Initial framebuffer allocation size: 7680 kByte
(II) I810(0): Allocated 4 kB for Overlay registers at 0x7fff000 (0x1491b000).
(II) I810(0): Allocated 64 kB for the scratch buffer at 0x7fef000
(II) I810(0): 0x82070d0: Memory at offset 0x0002, size 7680 kBytes
(II) I810(0): 0x820b748: Memory at offset 0x, size 0 kBytes
(II) I810(0): 0x820b940: Memory at offset 0x, size 0 kBytes
(II) I810(0): 0x820b5fc: Memory at offset 0x, size 128 kBytes
(II) I810(0): 0x8207110: Memory at offset 0x07fef000, size 64 kBytes
(II) I810(0): 0x820b998: Memory at offset 0x07fff000, size 4 kBytes
(WW) I810(0): PRB0_CTL (0xf001) indicates ring buffer enabled

As far as I can tell, mode switching happens only through the BIOS,
and the attempt to offset the framebuffer away from the start of the
video memory may well be ill-fated. In any case, this ring buffer
allocation seems to me as being premature and causing the bug.

I haven't kept logs from previous working versions of the server;
if the information may help you, I'll send it when I have successfully
downgraded my xserver (ouch, a whole lot of stuff needs to be co-downgraded).

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
The risk is that if, one day, machines become intelligent,
we mightn't be mentally equipped to notice they are.
-- Tirésias, in J.-P. Petit, A quoi rêvent les robots?

-- 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.15.3-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 xserver-xorg-video-i810 depends on:
ii  libc6 2.3.6-7GNU C Library: Shared libraries
ii  xserver-xorg-core 1:1.0.2-4  X.Org X server -- core server

xserver-xorg-video-i810 recommends no packages.

-- no debconf information

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

[Faré]

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 install dlocate
  dlocate register-common-lisp-implementation

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Dost thou love life? Then do not squander time, for that's the stuff
life is made of. -- Benjamin Franklin

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

[Faré]

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-UNICODE (which is
the default for sbcl in general and the case for debian's sbcl package).
Thus, cl-clx-sbcl applications (such as stumpwm) will crash when X communicates
8-bit-unclean strings to it (such as 7-bit-unclean window titles).
The attached patch solves this issue by using CHARACTER and asserting
that the code-char is 8-bit instead of using BASE-CHAR.

-- 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.13-xanadu
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages cl-clx-sbcl depends on:
ii  cl-asdf   1.86-5 Another System Definition Facility
ii  common-lisp-controller4.20   This is a Common Lisp source and c

Versions of packages cl-clx-sbcl recommends:
ii  sbcl 1:0.9.6.0-2 A development environment for Comm

-- no debconf information

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
-- Question authority!
-- Yeah, says who?
diff -urN /home/fare/clx.orig/clx.lisp clx/clx.lisp
--- /home/fare/clx.orig/clx.lisp	2005-07-14 09:24:45.0 -0400
+++ clx/clx.lisp	2005-11-08 17:23:31.0 -0500
@@ -173,6 +173,12 @@
 (deftype base-char ()
   'string-char)
 
+#-(and sbcl sb-unicode)
+(deftype char8 () 'base-char)
+#+(and sbcl sb-unicode)
+(deftype char8 () 'character) ;;; could be `(member ,@(loop for i below 256 collect (code-char i)))
+
+
 ; Note that we are explicitly using a different rgb representation than what
 ; is actually transmitted in the protocol.
 
diff -urN /home/fare/clx.orig/dependent.lisp clx/dependent.lisp
--- /home/fare/clx.orig/dependent.lisp	2005-10-04 04:01:12.0 -0400
+++ clx/dependent.lisp	2005-11-08 17:27:22.0 -0500
@@ -800,15 +800,16 @@
 			 #-Genera
 			 (progn
   			   (defun char-card8 (char)
-			 (declare (type base-char char))
+			 (declare (type char8 char))
 			 #.(declare-buffun)
+			 (assert ( 256 (char-code char)))
 			 (the card8 (aref (the (simple-array card8 (*))
 		   *char-to-card8-translation-table*)
 	  (the array-index (char-code char)
 			   (defun card8-char (card8)
 			 (declare (type card8 card8))
 			 #.(declare-buffun)
-			 (the base-char
+			 (the char8
   (or (aref (the simple-vector *card8-to-char-translation-table*)
 	card8)
   (error Invalid CHAR code ~D. card8
@@ -842,13 +843,13 @@
 		 (t
 		  `(progn
 			 (defun char-card8 (char)
-			   (declare (type base-char char))
+			   (declare (type char8 char))
 			   #.(declare-buffun)
 			   (the card8 (char-code char)))
 			 (defun card8-char (card8)
 			   (declare (type card8 card8))
 			   #.(declare-buffun)
-			   (the base-char (code-char card8)))
+			   (the char8 (code-char card8)))
 			 ))
   (char-translators))
 
@@ -1180,7 +1181,7 @@
   (declare (ignore whostate))
   (declare (type function predicate))
   (let* ((pid (current-process))
-	 (last (gethash  pid *process-conditions*))
+	 (last (gethash pid *process-conditions*))
 	 (lock
 	  (or (car last)
 	  (sb-thread:make-mutex :name (format nil lock ~A pid
@@ -2959,7 +2960,7 @@
 ;;;
 ;;; [the following isn't implemented (should it be?)]
 ;;; If object is a list, it is an alist with entries:
-;;; (base-char [modifiers] [mask-modifiers])
+;;; (char8 [modifiers] [mask-modifiers])
 ;;; When MODIFIERS are specified, this character translation
 ;;; will only take effect when the specified modifiers are pressed.
 ;;; MASK-MODIFIERS can be used to specify a set of modifiers to ignore.
diff -urN /home/fare/clx.orig/resource.lisp clx/resource.lisp
--- /home/fare/clx.orig/resource.lisp	2005-07-14 09:24:43.0 -0400
+++ clx/resource.lisp	2005-11-08 17:30:03.0 -0500
@@ -455,7 +455,7 @@
 
 (defun char-memq (key char)
   ;; Used as a test function for POSITION
-  (declare (type base-char char))
+  (declare (type char8 char))
   (member char key))
 
 (defmacro resource-with-open-file ((stream pathname rest options) body body)
diff -urN /home/fare/clx.orig/translate.lisp clx/translate.lisp
--- /home/fare/clx.orig/translate.lisp	2005-07-14 09:24:44.0 -0400
+++ clx/translate.lisp	2005-11-08 17:30:26.0 -0500
@@ -141,7 +141,7 @@
   ;;  when mask and modifiers aren't lists of keysyms]
   ;; The default is #'default-keysym-translate
   ;;
-  (declare (type (or base-char t) object)
+  (declare (type (or char8 t) object)
 	   (type keysym keysym)
 	   (type (or null mask16 (clx-list (or keysym state-mask-key)))
 	 modifiers)
@@ -191,7 

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

[Faré]

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 Thing(tm).

On 24/10/05, Luca Capello [EMAIL PROTECTED] wrote:
 The severity is important, because you could want SLIME to connect to
 a remote swank and in this case you don't need a local cl-swank.

 At the same time, however, I think that depending on cl-swank by
 default is the best thing to do (cl-swank it's just 1.2MB), especially
 for newbies.

 Attached a patch versus the darcs repository [1].

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
I'd give my right arm to be ambidextrous.

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

[Faré]

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
having to walk /etc/passwd to locate all the places where to purge the cache,
if you wish to do such thing.

 ii  realpath  1.9.20 Return the canonicalized
PS: Oh, instead of using realpath, could we be using readlink -f ?
It's part of the GNU coreutils, so that's one less bizarre package to
depend upon.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
If six billion people have both more food and more forest than their three
billion parents did; if the prices of copper, wheat and natural gas are going
down, not up; if there are 20 times more carcinogens in three cups of organic
coffee than in daily dietary exposure to the worst pesticide both before and
after the DDT ban; if renewable resources such as whales are more easily
exhausted than non-renewables such as coal; if lower infant mortality leads
to falling populations, not rising ones, then perhaps we need to think
differently about what sustainability means. Perhaps the most sustainable
thing we can do is develop new technology, increase trade and spread affluence.
-- Matt Ridley

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

[Faré]

A lot of packages install stuff in the user directory.
Mozilla, Gimp, OpenOffice, KDE, GNOME, etc., will all create their
own directories under ~/.foo and install a shitload of crap.
Sometimes, their offer to upgrade from a previous version,
and optionally offer to delete cruft from previous versions.

Modifying users' directories is something done casually.
The only problem is when it's done in unexpected, undocumented
and/or unpredictable ways. Creating a well-defined ~/.cache/ hierarchy
for such things as erasable caches is a generally good idea,
and we should encourage more packages rather than less to do use it.
I'm sure you can also invent a configuration file for users to specify
their preferences regarding automatic administration of his home.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
One of the greatest discoveries a man 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 locate
  all the places where to purge the cache, if you wish to do such
  thing.
 
 No, it is the plain and true evil for package maintainer scripts to
 delete or modify files in users' home directories. It's the user's
 personal space and you never know what he uses ~/.cache for. The
 system should never modify the home directory and I do not know of one
 single package that does.
 
   René

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

[Faré]

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 infocmp (list (getenv TERM))
 
 This I did not know. I'm hacking a working hemlock up...

I would recommend making several attempts at getting the TERMCAP,
starting with $TERMCAP, then $(infocmp -C), then /etc/termcap. Also,
infocmp already uses $TERM by default so no need to pass it as an
argument. If I read the manual correctly, you need option -C.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
Mathematics is as little a science as grammar is a language. -- Ernst Mayr

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

[Faré]

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 data is just a (run-program infocmp (list (getenv TERM))
:input nil ...) away (instead of (open /etc/termcap). I don't use
hemlock, but I'd hate to see it disappear for a wrong reason.

 I'm not happy about it either, but I lack the time to fix it properly.
At least, have proper error message rather than a discouraging one.

[ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ]
The ultimate result of shielding men from the effects of folly is
to fill the world with fools. -- Herbert Spencer