September 2008 - cl-debian@common-lisp.net

[cl-debian] Bug#494404: patch + comments on cl-geodesics
by Luca Capello 06 Sep '08

06 Sep '08

Hi Peter! On Tue, 26 Aug 2008 22:36:11 +0200, Peter De Wachter wrote: > On Tue, 26 Aug 2008 01:08:53 +0200 > Luca Capello <luca(a)pca.it> wrote: >> > - utilities.lisp doesn't have an IN-PACKAGE form, so it gets loaded >> > in whatever random package happens to be active. >> >> Since it's loaded by all the three subsystems, I'd say it's correct. > > Well, consider this transcript: [...] > Utilities.lisp clobbers variables and functions in whatever package the > user happened to be in, that can't be right. And re-loading the > geodesics fasls won't work if that :foo package no longer exists. OK, now I understood what you meant, fixed [1]. >> I guess the idea was to having to load only one system instead of >> three. It can also be possible to split geodesics.asd in three >> different files, one for each subsystem, still providing the old >> geodesics.asd which loads the three. > > But those three systems define functions with the exact same names: > geodesics:a > geodesics:da/dt > geodesics:adash > geodesics:n > geodesics:dn/dt > geodesics:ndash > If you load GD-STATIC-UNEQUAL after GD-STATIC-EQUAL, you'll redefine > GD-STATIC-EQUAL's functions. If you next load GD-COSMOLOGICAL, you'll > just redefine them again. A system that loads more than one of these > three is nonsensical. I committed the split [2], but I kept geodesics.asd for backward compatibility. However, we still have only one package, GEODESICS: should each system define their own package? Thx, bye, Gismo / Luca Footnotes: [1] http://git.debian.org/?p=pkg-common-lisp/cl-geodesics.git;a=commitdiff;h=09… [2] http://git.debian.org/?p=pkg-common-lisp/cl-geodesics.git;a=commitdiff;h=89…

1 0

[cl-debian] Bug#495351: [Ecls-list] ECL sigill on debian armel (lenny)
by Luca Capello 06 Sep '08

06 Sep '08

reassign 495351 libc6 found 495351 2.7-13 severity 495351 normal merge 498008 495351 thanks Hi Detlef! On Sat, 06 Sep 2008 10:32:12 +0200, D Schmicker wrote: > the problem is probably tracked down to a bug in libc6. > > Here is the bugreport: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498008 For the next time, there's no need to open another bug: the Debian BTS can reassign a specific bug to another package, like in this case. I merged both bugs, since it seems clear now that it's not at all an ECL problem. Thx, bye, Gismo / Luca

2 1

[cl-debian] Bug#495351: [Ecls-list] ECL sigill on debian armel (lenny)
by Luca Capello 04 Sep '08

04 Sep '08

Hi Detlef! For the debian-arm mailing list: this is bug Debian bug #495351: http://bugs.debian.org/495351 On Wed, 03 Sep 2008 16:16:28 +0200, Detlef Schmicker wrote: > as there is no simple well documented way to install a standard > armel-omap kernel on the N800 (at least I could not find one) I have > problems to install a more recent kernel than 2.6.21-omap1 (with maemo > patches), which is the most recent kernel nokia offers at the moment. I > will test as soon as I have a more recent kernel availible on N800. Fine with me. Please close the bug (or raise its severity) as soon as you'll have tested a more recent kernel. > As another difference between working debian and not working debian is > the processor / gcc > > Processor : ARMv6-compatible processor rev 2 (v6l) > > it might still be a processor problem, but as I understood it should be > backward compatible. Does anyone have ecl with an ARMv6 running? That's why I cc:ed the debian-arm mailing list, /proc/cpuinfo below. Thx, bye, Gismo / Luca > Full cpuinfo: > cat /proc/cpuinfo > Processor : ARMv6-compatible processor rev 2 (v6l) > BogoMIPS : 164.36 > Features : swp half thumb fastmult vfp edsp java > CPU implementer : 0x41 > CPU architecture: 6TEJ > CPU variant : 0x0 > CPU part : 0xb36 > CPU revision : 2 > Cache type : write-back > Cache clean : cp15 c7 ops > Cache lockdown : format C > Cache format : Harvard > I size : 32768 > I assoc : 4 > I line length : 32 > I sets : 256 > D size : 32768 > D assoc : 4 > D line length : 32 > D sets : 256 > > Hardware : Nokia N800 > Revision : 24202524 > Serial : 0000000000000000 > Nokia-N800-23-14:~#

1 0

[cl-debian] Bug#497680: cmucl: FTBFS in lenny: Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x10044FF0.
by Luca Capello 03 Sep '08

03 Sep '08

unarchive 483331 forcemerge 483331 497680 severity 483331 minor thanks Hi Lucas! On Wed, 03 Sep 2008 16:24:05 +0200, Lucas Nussbaum wrote: > During a rebuild of all packages in lenny, your package failed to build on > i386. [...] >> Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x10044FF0. >> make[1]: *** [all] Error 3 This is the same as bug #483331 [1], merged. > About the archive rebuild: The rebuild was done on about 50 AMD64 nodes > of the Grid'5000 platform, using a clean chroot containing a sid i386 > environment. Internet was not accessible from the build systems. I just successfully built cmucl on a sid-i386 chroot on my ThinkPad X60 (Intel Core2 T7200 [2]): can the Grid'5000 be the problem, here? If needed I can try a native i386 build, but I don't think we need it. Thx, bye, Gismo / Luca Footnotes: [1] http://bugs.debian.org/483331 [2] http://luca.pca.it/projects/ibm/x60_1706-gmg/

3 2

[cl-debian] Bug#486376: [Ecls-list] Bug#486376: ecl: /usr/lib/libecl.so doesn't provide a SONAME
by Luca Capello 03 Sep '08

03 Sep '08

Hi Juanjo! On Sat, 30 Aug 2008 09:19:19 +0200, Juan Jose Garcia-Ripoll wrote: > On Sat, Aug 30, 2008 at 1:07 AM, Luca Capello <luca(a)pca.it> wrote: >> This bug has nothing to do with the rpath issue (now solved [1]). >> Thus, the problem remains: is there any particular reason for >> /usr/lib/libecl.so not providing a SONAME? > > That is not something ECL has to provide. It is more a configuration > option that operating systems may provide. Sorry, I'm not a skilled programmed, but I don't understand why this is not ECL task: ECL provides the libecl.so library, so who else should provide its SONAME? > You have to consider the following: with every binary release we are > adding more functions and the names of old ones change. That means > being a rapidly evolving project we are definitely going to break > binary compatibility very frequently. Isn't this the reason for SONAME existence? At least this is how I see it and it seems that others share my view [1][2]. > I should rather say with every release. This means that you need to update the SONAME for every release. And I don't see this as a stopper. > Furthermore, ECL is currently not being used as a library by any > project. It is only either a runtime for compiled files or the > interpreted environment itself. However a standalone program [3] works out of the box with just libecl.so, doesn't it? This means that while ecl (the executable) is not used as a library, libecl.so acts like a *real* library (as Gabriel Dos Reis already pointed out [4]). Thus, without a SONAME and from a simple `ldd` output, there's no way to know which ECL versions the program was built with. > Do you expect SBCL to use some kind of SONAME for its core? Not > really. SBCL doesn't provide any library which can be used *without* its core (thus they are installed into /usr/lib/sbcl/, the same being true for e.g. CLISP). Similarly, the ECL "libraries" needed for the core reside in /usr/lib/ecl/ and don't need any SONAME. In the next days I'll upload a new Debian version for ECL to solve bug #495756 [5] in time for the lenny release [6]. I'd like to solve this issue as well, is it possible? Thx, bye, Gismo / Luca Footnotes: [1] http://mail-index.netbsd.org/tech-toolchain/1998/07/17/0000.html [2] http://wiki.linuxquestions.org/wiki/Library-related_Commands_and_Files#sona… NB, not that I blindly trust random wikis... [3] New manual: "1.6.3. Example of standalone program" [4] Message-ID: <206fcf960808300836h69a9ecc5heaba09277f08b84e(a)mail.gmail.com> [5] http://bugs.debian.org/495756 [6] http://wiki.debian.org/DebianLenny

1 0

[cl-debian] Bug#495351: [Ecls-list] ECL sigill on debian armel (lenny)
by Luca Capello 03 Sep '08

03 Sep '08

severity 495351 minor thanks Hi! Please, if you deal with a Debian bug which has already been reported (and thus has a number), don't forget to always cc: the bug as well (no need to subscribe). For the record, the threads on the upstream mailing list are [1], [2] and [3]. On Sat, 30 Aug 2008 17:31:44 +0200, Martin Guy wrote: > This problem doesn't present itself on native debian systems: Maybe not this specific problem, but the Debian package misses a dependency on gcc: ===== root@ranma:~# apt-get install ecl [...] Selecting previously deselected package ecl. Unpacking ecl (from .../ecl_0.9j-20080306-4_armel.deb) ... Processing triggers for man-db ... Setting up libgc1c2 (1:6.8-1.2) ... Setting up cl-asdf (1.111-1) ... 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/cmp.fas" ;;; Loading #P"/usr/lib/ecl/sysfun.lsp" Saving to new-ecl...sh: arm-linux-gnueabi-gcc: not found ===== It happens that ranma is my Openmoko FreeRunner, powered by Debian [4]. Since we (the Debian FSO Team [5]) decided to install a very minimal Debian (cdeboostrap minimal flavour), gcc is not installed by default (Priority: optional). As soon as gcc is installed, ecl works like a charm (I tried the "hello world" example in the documentation [6]). Problem fixed [7]. FWIW, this is with Openmoko upstream 2.6.24 kernel. > I've tried it on armv54te and armv4t boxes and ecl installs and runs > fine, also under gdb. I can only think maybe some kernel difference - > for example, ecl makes use of threads. As explained by Detlef [3], this could be a kernel bug. Thus this bug should be reassigned to the kernel package, but since it could be already fixed, I'd rather close it. Detlef, what do you think? > If it would help to have ssh access to a native Debian armel box, to > help find the difference, you are welcome - just write me. You can also play with qemu/qemubuilder as explained at [4]: ECL installs and works fine with a Debian 2.6.24 kernel. Thx, bye, Gismo / Luca Footnotes: [1] http://thread.gmane.org/gmane.lisp.ecl.general/4210 [2] http://thread.gmane.org/gmane.lisp.ecl.general/4341 [3] http://thread.gmane.org/gmane.lisp.ecl.general/4372 [4] http://wiki.debian.org/DebianOnFreeRunner [5] http://wiki.debian.org/Teams/DebianFSO [6] New manual: "1.6. Compiler examples" [7] http://git.debian.org/?p=pkg-common-lisp/ecl.git;a=commitdiff;h=0f9b75fad97…

2 1

[cl-debian] [ann] [cl-ppcre-announce] New release 2.0.1
by Edi Weitz 02 Sep '08

02 Sep '08

ChangeLog: Version 2.0.1 2008-09-02 Fixed faulty declaration (caught by Brent Fulgham) Download: http://weitz.de/files/cl-ppcre.tar.gz _______________________________________________ cl-ppcre-announce mailing list cl-ppcre-announce(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-ppcre-announce _______________________________________________ announcements site list announcements(a)common-lisp.net http://common-lisp.net/mailman/listinfo/announcements

1 0

[cl-debian] Accepted gcl 2.6.7-45 (source all i386)
by Camm Maguire 01 Sep '08

01 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.8 Date: Mon, 01 Sep 2008 13:48:16 +0000 Source: gcl Binary: gcl gcl-doc Architecture: source all i386 Version: 2.6.7-45 Distribution: unstable Urgency: high Maintainer: Camm Maguire <camm(a)enhanced.com> Changed-By: Camm Maguire <camm(a)enhanced.com> Description: gcl - GNU Common Lisp compiler gcl-doc - Documentation for GNU Common Lisp Changes: gcl (2.6.7-45) unstable; urgency=high . * proper word order detection macro, fixes armel Checksums-Sha1: bb3a4c913ac1d63d509b4be646cd732d633b67a7 1092 gcl_2.6.7-45.dsc e0e168fdf96261ff8bd49f7b9f112c97c853dc88 14746152 gcl_2.6.7-45.diff.gz e35eb5c313adafe8776a7c599bff781efc0577dd 577504 gcl-doc_2.6.7-45_all.deb 0023f8a9d73c50d97d24dcf78f686a12d6e80282 51365404 gcl_2.6.7-45_i386.deb Checksums-Sha256: 5a7f04490b26c06ac00a167d7700a93f38fe08d511b1d93df9ca0fc1a8d48d5a 1092 gcl_2.6.7-45.dsc 0bfb41fd3e9a15b25245079bdea4326f5c541e96f74170d26fbdf952c5d36be7 14746152 gcl_2.6.7-45.diff.gz 2bf555ff76c92c8c9a4ba2073aef41fa05784fb7e48a118e159c166bd7b64c13 577504 gcl-doc_2.6.7-45_all.deb 39d1e5e79aa9906225f0687c14107ec26be8361009b9bb7063bc8bdd25018ff9 51365404 gcl_2.6.7-45_i386.deb Files: c280a1340cf9b44ed245afaf4a42647e 1092 interpreters optional gcl_2.6.7-45.dsc 1ced8c7667e7c248bee1e99f4b432f3c 14746152 interpreters optional gcl_2.6.7-45.diff.gz 4f78e3c33c1e560a8b455953b54fe70c 577504 doc optional gcl-doc_2.6.7-45_all.deb 602ccf767d45f20781112ff487e516fe 51365404 interpreters optional gcl_2.6.7-45_i386.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFIu/k+czG1wFfwRdwRAq9nAJ0ag68f5fNUFwoNXXrgo+ImsseeKACfRwvQ Jjm6sf8h0Apq53Qb411f/80= =qNeL -----END PGP SIGNATURE----- Accepted: gcl-doc_2.6.7-45_all.deb to pool/main/g/gcl/gcl-doc_2.6.7-45_all.deb gcl_2.6.7-45.diff.gz to pool/main/g/gcl/gcl_2.6.7-45.diff.gz gcl_2.6.7-45.dsc to pool/main/g/gcl/gcl_2.6.7-45.dsc gcl_2.6.7-45_i386.deb to pool/main/g/gcl/gcl_2.6.7-45_i386.deb

1 0