Re: New Common Lisp wiki page

Hi! Getting into this quite old mail thread, sorry for that On Tuesday 29 August 2017 18:22:52 CET Sébastien Villemot wrote: > On Tue, Aug 29, 2017 at 03:51:08PM +0200, pvane...@debian.org wrote: > > > I took some time to fully rewrite the Common Lisp page on the Debian > > > wiki: > > > > > > h

remove libfixposix

Hi! Seems libfixposix is untouched for 6+ Years and not needed any more for other packages. Is it still usefull to someone or should we get rid of it? Christoph signature.asc Description: This is a digitally signed message part. ___ pkg-common-lisp-

Bug#847698: sbcl arm64 fixes

Hi! Just uploaded 1.3.13-2 to unstable which should include the fix and is the version I want for stretch. Can you please confirm it's now fine? Thanks! Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer signature.asc Description

Bug#837576: FWIW: patch in upstream master

Hi! FWIW upstream/master has a patch for this already: 54180430241717eca72865c918f5a2c09d6a56e2 Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer ___ pkg-common-lisp-devel mailing list

Bug#841933: slime: Please update for emacs25

Package: slime Version: 2:2.17-1 Severity: minor Hi! Please update slime for emacs25. It needs at least an update to /usr/lib/emacsen-common/packages/install/slime which allows emacs25 as a flavor. Thanks! Christoph -- System Information: Debian Release: stretch/sid APT prefers testing A

Re: Bug#819181: RFS: cl-asdf/3.1.7 - Another System Definition Facility

Hi! Kambiz Darabi writes: >> BTW the package has many uploaders, and some of them are DD. >> >> Usually it is better to ask them for uploads, instead of opening an RFS bug. >> In case they are MIA or not interested in cl-asdf anymore, better drop them >> from uploaders, and maybe open a MIA proc

Bug#805701: clisp on hurd

Control: severity -1 important Control: tag -1 +patch Hi! I'll include that in the next upload for sure .. hopefully this week. Ideally we find a arm solution untill then. Has this patch been sent upstream? Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Li

Bug#815205: sbcl: FTBFS due to TeX error

Hi! Norbert Preining writes: > I sent already a minimal example derived from the sbcl code to the ti > list, you should have gotten it cc just seen it minutes after sending the email. Thanks for the fast reaction! Christoph ___ pkg-common-lisp-deve

Bug#815205: sbcl: FTBFS due to TeX error

Norbert Preining writes: > apt-get source sbcl and build is enough to reproduce? That's what I did in a clean sid chroot yesterday. You need to actually run the build as some input files to the manual get generated during build though. Christoph ___

Bug#815205: sbcl: FTBFS due to TeX error

Hi texinfo folks! Christoph Egger writes: > Logan Rosen writes: >> I just merged sbcl 2:1.3.1-1 into Ubuntu (we have a simple chmod change in >> debian/rules), and it failed to build on all architectures [1]. I verified >> that this issue affects Debian unstable as wel

Bug#815205: sbcl: FTBFS due to TeX error

Hi! Logan Rosen writes: > I just merged sbcl 2:1.3.1-1 into Ubuntu (we have a simple chmod change in > debian/rules), and it failed to build on all architectures [1]. I verified > that this issue affects Debian unstable as well by building it in a chroot. > > It appears to be due to a TeX issue d

Bug#751005: new hg doesn't seem to be enough to build clisp for arm*

Hi! The current hg snapshot I've uploaded to experimental yesterday does not seem to build as-is on arm* still. Christoph ___ pkg-common-lisp-devel mailing list pkg-common-lisp-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/ma

Bug#801260: clisp: Clisp cannot be buit for hurd-i386

Hi! Flavio Cruz writes: > Severity: serious > Justification: fails to build from source valid for release architectures, not so much for hurd. > Clisp cannot be built under hurd-i386 since clisp does not recognize Hurd > errno values. This patches fixes that and prevents clisp to not crash whe

Re: RFS: Please upload cl-asdf package

Faré writes: > On Wed, Jul 22, 2015 at 3:13 PM, Christoph Egger > wrote: >> Christoph Egger writes: >>> There seems to be a somewhat large diff between the "upstream" release >>> and the debian package source? Is this on purpose? >> >> Then

Re: RFS: Please upload cl-asdf package

Hi! Faré writes: > It has many bug fixes, most importantly with debian Bug#787909, > an incompatibility of 3.1.4 with the latest SBCL. > > Please upload the cl-asdf package, after checking that > it works fine for you. > > The cl-asdf source package builds this binary package: > cl-asdf- Anot

Re: RFS: Please upload cl-asdf package

Hi! Christoph Egger writes: > There seems to be a somewhat large diff between the "upstream" release > and the debian package source? Is this on purpose? Then the debian package seems to be (almost) the same as the git archive but quite different from the tarball Christop

Re: Please push clisp to jessie-backports

Hi! wp mirror writes: > b) request you to push `clisp' and `clisp-module-clx' to > jessie-backports. That needs primarily help to get it build on arm* again. As soon as that problem's solved there's no reason to not have it in backports. Any help is welcome! Christoph -- 9FED 5C6C E206 B70A

Re: SBCL 2:1.2.12-1

Hi! Juan Reynoso Elias writes: > Hello I have sbcl version 2:1.2.12-1, and I have created a simple > function http://paste.lisp.org/display/149440, into the top-level > works ok, but the same function in a file when I try to redefine the > function I get an error. > > The slime command is C-c C-c

Bug#764245: sbcl: concurrency broken on powerpc (FTBFS)

Package: src:sbcl Version: 2:1.2.3-1 Severity: serious sbcl FTBFS on powerpc since threads are enabled. This is a known problem ansd we may get a patch from upstream. If not we just disable threading there again -- System Information: Debian Release: jessie/sid APT prefers testing APT policy:

Re: sbcl_1.2.2-1_armhf.changes ACCEPTED into unstable

Hi! Debian FTP Masters writes: > Checksums-Sha1: > c085566458222f2ce2b66818288babfc6728e2f4 6373200 sbcl_1.2.2-1_armhf.deb > Checksums-Sha256: > 87476e8e474f4d9aa5c33e610f169633757e367eb636e0ee859749328871 6373200 > sbcl_1.2.2-1_armhf.deb > Files: > 7c45014c71e48aa27a39ca6ac92905c0 637320

Re: stumpwm REMOVED from testing

Milan Zamazal writes: > On 26. srpna 2014 18:39:16 CEST, Debian testing watch > wrote: >>FYI: The status of the stumpwm source package >>in Debian's testing distribution has changed. >> >> Previous version: 2:0.9.8-5 >> Current version: (not in testing) >> Hint:

Bug#734962: sbcl on wheezy

Hi! Faré writes: > 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. I'm on cl-launch right now fwiw. Trying to fetch cl-asdf later. I'm really sorry I wasn't available at all the last months -- life interferred. And there are unfortu

Bug#734962: sbcl on wheezy

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

Re: sbcl build for armhf

Christoph Egger writes: > Christoph Egger writes: >> I have a sbcl installed on my armhf board here (bootstrapping sbcl is >> fortunately really fun!). Unfortunately sbcl 1.2.2 still fails the >> testsuite -- once that's fixed I'll upload a sbcl binary for ar

Re: sbcl build for armhf

Hi! Austin Hendrix writes: > I do packaging of ROS (Robot Operating System) for armhf, and over the > past few years the lack of a packaged version of SBCL for armhf has > been a bit of a pain. Until recently, I’ve worked around it because > the upstream version of SBCL didn’t have armhf support,

Re: sbcl build for armhf

Christoph Egger writes: > I have a sbcl installed on my armhf board here (bootstrapping sbcl is > fortunately really fun!). Unfortunately sbcl 1.2.2 still fails the > testsuite -- once that's fixed I'll upload a sbcl binary for armhf into > the archive getting builds start

Re: RFS: cl-launch (updated package)

Faré writes: > Dear Debian Mentors and Debian Lispers, > > I am looking for a sponsor for the new version 4.0.4-1 > of my package "cl-launch". > > It builds these binary packages: > cl-launch - uniform frontend to running Common Lisp code from the shell > > The package appears to be lintian clean

Re: RFS: cl-launch (updated package)

Hi! Faré writes: > - dget > http://mentors.debian.net/debian/pool/main/c/cl-launch/cl-launch_4.0.3-1.dsc On the way Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer ___ pkg-common-li

Re: RFS: cl-launch (updated package)

Hi! Faré writes: > you did well to procrastinate on my cl-launch 4.0.0-1, > for after a round of bug fixes, here is 4.0.1-1. Thus, > > I am looking for a sponsor for the new version 4.0.1-1 > of my package "cl-launch". > > It builds these binary packages: > cl-launch - uniform frontend to runnin

Bug#668843: Only hurd nowadays

Control: severity -1 normal kfreebsd is now fine (at least since 12.12) so not RC any more. Suggestions/Patches from hurd people welcome ;-) Christoph pgpG9c5Wb60fI.pgp Description: PGP signature ___ pkg-common-lisp-devel mailing list pkg-common-lis

Re: RFS: please upload cl-asdf package

Hi Faré Faré writes: > I'm still doing the debian packaging for ASDF at this point in time > for the new upstream maintainer Robert Goldman. > > This brand new ASDF release received a lot of testing, and > fixes a shameful bug in previous recent releases > that affects usability under debian (#72

Bug#727368: ecl: update config.{sub,guess} for the AArch64 port

Hi Matthias! Matthias Klose writes: > The package fails to build on arm64 (aarch64-linux-gnu), because the > config.{guess,sub} files are out of date, and are not updated during > the build. If possible, please do not update these files directly, > but build-depend on autotools-dev instead, and

Re: Fwd: RFS: cl-launch (updated package)

Hi! Faré writes: > I am looking for a sponsor for the new version 3.22.1-1 > of my package "cl-launch". > > It builds these binary packages: > cl-launch - uniform frontend to running Common Lisp code from the shell > > The package appears to be lintian clean. > > The package can be found on ment

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

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/.asd' anymore. > > See > . Well the th

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

Package: cl-swank Version: 1:20130626-1 Severity: important cl-swank does not contain the symlink in /usr/share/common-lisp/systems so it can't be loaded from asdf: > % sbcl > This is SBCL 1.1.11.debian, an implementation of ANSI Common Lisp. > More information about SBCL is available at

Bug#723679: cmucl: segfault

leo.but...@member.fsf.org writes: > The current binary segmentation faults on startup > > $ /usr/bin/cmucl > Segmentation fault Indeed, same here: (gdb) run Starting program: /usr/bin/cmucl warning: Could not load shared library symbols for linux-gate.so.1. Do you need "set solib-search-path" or

Re: RFS: please upload cl-asdf package

Hi! Faré writes: > On Thu, Jul 4, 2013 at 11:25 AM, Robert Goldman wrote: > - dget > http://mentors.debian.net/debian/pool/main/c/cl-asdf/cl-asdf_3.0.2-1.dsc Upstream tarbal is 6f78cb311f9b8756ebed5924a6bd7302e283ccbf The dsc mentions 7987d33bafe5a1f0fa91a7380a3594206a5a0cdb Is this intenti

Bug#696757: ecl: FTBFS: hang in sigsuspend

Hi! Steven Chamberlain writes: > Would it be an option to configure ecl with --enable-threads=no on > kfreebsd-* and hurd-* for wheezy? Would any functionality be lost or > would it only affect performance? The version in squeeze didn't have > threads enabled, and there don't seem to be any rde

Bug#696757: ecl and SIGNALS

Christoph Egger writes: > As suggested by Michael Banck on IRC I've been looking at Signals used > by both parts to see if they e.g. battle over SIGUSR?. However libgc > seems to use 32+{5,6} as signals on x86 FREEBSD __GLIBC__ at > least. Petr, Steven: any idea why this is?

Bug#696757: ecl and SIGNALS

Hi! As suggested by Michael Banck on IRC I've been looking at Signals used by both parts to see if they e.g. battle over SIGUSR?. However libgc seems to use 32+{5,6} as signals on x86 FREEBSD __GLIBC__ at least. Petr, Steven: any idea why this is? Are these signals fine for kfreebsd glibc (signa

Bug#696757: ecl hang: SIGNAL problem

Hi! As 12.12.1 in experimental builds while the unstable/testing one doesn't I've bisected down the changes in upstream git. It seems to work since c7953cc0f54281c3de6a845f3599544afba20b2a. The patch doesn't simply apply to unstable so I haven't tested jet if that'd simply work. Also it's a bit

Bug#696757: ecl hang: SIGNAL problem

Hi all! I guess ecl has never ever worked with libgc and enabled threads on kfreebsd (seems to be a header-only thing and libgc added thread support for kfreebsd *after* the last successfull ecl build). It still seems to be waiting in GC_stop_world() for all other processes to finish and probably

Bug#696757: ecl hang: SIGNAL problem

Hi all! Thanks to the help of Jeff Epler I'm now having a "working" gdb again: % gdb ./ecl_min GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change a

Bug#696757: ecl hang: SIGNAL problem

My current guess is that ecl seems to block some signals it shouldn't be able to. However I'm somehow no longer able to run ecl_min in gdb in a usefull way it seems ___ pkg-common-lisp-devel mailing list pkg-common-lisp-devel@lists.alioth.debian.org http

Bug#676979: sbcl: file nik.lisp for reproduction is included below

Hi! Faheem Mitha writes: > On Wed, 9 Jan 2013, Christoph Egger wrote: >> So actually it either needs to actually dfail to allocate the memory >> or it's platform-specific. I think I get the problem on a amd64 with >> few enough memory to trigger the Heap e

Bug#676979: sbcl: file nik.lisp for reproduction is included below

Hi! So actually it either needs to actually dfail to allocate the memory or it's platform-specific. I think I get the problem on a amd64 with few enough memory to trigger the Heap exhaustion Regards Christoph ___ pkg-common-lisp-devel mailin

Bug#676979: Testing on 1.1.3

Hi! I've been running (main 1) on 1.1.3 (kfreebsd-amd64) debian package, it ends with: --- Dynamic space usage is: 524,455,600 bytes. Read-only space usage is: 5,200 bytes. Static space usage is: 3,088 bytes. Control stack usage is:2,656 bytes. Binding stack usage is:

Bug#696757: ecl: FTBFS: hang in sigsuspend

signal_code); } } } } CL_CATCH_ALL_END; RETURN: @(return) } #endif Christoph Egger writes: > Package: src:ecl > Version: 11.1.1+dfsg1-1 > Severity: serious > Tags: sid wheezy > User: debian-.

Bug#696757: ecl: FTBFS: hang in sigsuspend

Package: src:ecl Version: 11.1.1+dfsg1-1 Severity: serious Tags: sid wheezy User: debian-...@lists.debian.org Usertags: kfreebsd X-Debbugs-Cc: debian-...@lists.debian.org Justification: fails to build from source (but built successfully in the past) Hi! ECL build hangs early in ecl_min compile. I

Bug#695718: ecl DFSG

Hi! A fix for unstable is currently building. Hopefully it's still building everywhere ecl tends to be a bit nasty there ;-) Regards Christoph ___ pkg-common-lisp-devel mailing list pkg-common-lisp-devel@lists.alioth.debian.org http://lists.al

Bug#693682: Core compression

Hi! Found the problem.The makefiles aren't handling binary-arch only builds correct so it only works on the architecture the binary was uploaded originally. Fixing in a minute. Thanks for the report! Regards Christoph ___ pkg-common-lisp-devel m

Bug#693682: Core compression

Hi! This is really strange: > % sbcl > This is SBCL 1.1.1.0.debian, an implementation of ANSI Common Lisp. > More information about SBCL is available at . > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some porti

moving cl-alexandria to git?

Hi Peter, hi Team! does anyone have an (strong) opinion about moving cl-alexandria packaging to git (upstream changed to git as well)? Regards Christoph ___ pkg-common-lisp-devel mailing list pkg-common-lisp-devel@lists.alioth.debian.org http://

Bug#671752: Pinged packaging team's mailing list

Hi! Rupert Swarbrick writes: > (1) Does it seem sensible to package the manual as ecl-doc? I do think so, yes > (2) If so, since the manual is in a different upstream archive, should > the source package be split? (At the moment, the "ecl" source > package builds both the ecl and

Re: adding an apt repository to the web space for pkg-common-lisp on Alioth (wagner)

Hi Faheem! Faheem Mitha writes: > Currently alioth does not have reprepro. Do you think the admins would > install it if I asked? If so, what is the procedure? I asked on > #alioth. You can always ask them. The easiest alternative would be to have a local reprepro on your machine and rsync the

Re: dh_lisp usage

Hi! diogo...@gmail.com (Diogo F. S. Ramos) writes: > I'm trying to use dh_lisp as stated at the manual [1] but without > success. As far as I remember dh_lisp went away together with common-lisp-controller and is not needed any more. I'm Cc-ing Desmond because IIRC he was the one doing this reo

Re: Preliminary Debian packaging for Clozure Common Lisp (ccl.clozure.com)

Hi again Faheem Mitha writes: >>> 2) The main outstanding issue is how to handle the bootstrapping >>> issue, namely that CCL is not in Debian, but requires CCL to compile. >> >> For sbcl I do bootstrapping with a crossbuild from another >> architecture .. building just a non-packaged version an

Re: Preliminary Debian packaging for Clozure Common Lisp (ccl.clozure.com)

Hi! Please Send any mail also directly to me if you're interested in my Input as I'm not reading -mentors regularly and pkg-common-lisp-devel@ is -- it appears -- not getting enough of my attention to see your messages in time. Faheem Mitha writes: > 1) I'd like to take over the outstanding IT

Bug#681808: Enable powerpc build

Hi! Ben Collins writes: > I'm definitely here to stay for powerpc. I've fixed ghci and worked on > several other compilers that were broken on powerpc (just in the past few > weeks). > > I've confirmed this working on Ubuntu powerpc. Adam Conrad is > currently looking to bootstrap for Ubuntu qu

Bug#681808: Enable powerpc build

Hi! Ben Collins writes: > Package: sbcl > Version: 2:1.0.57.0-2 > > I was able to bootstrap powerpc without problems using the binaries > downloaded from sbcl.org for linux-ppc. Please bootstrap this and enable > powerpc builds. Building on !x86 was disabled due to noone being around who is

Bug#666648: slime: FTBFS: mkdir: cannot create directory `././sbuild-nonexistent': Permission denied

Milan Zamazal writes: > >> mkdir: cannot create directory `././sbuild-nonexistent': Permission > denied This one looks like writing to $HOME which is not allowed and will not fail in a cowbuilder environment normally. Would be easy to test building with HOME=/something-not-existing Regards

Bug#668843: ecl/experimental: FTBFS[!linux]: testsuite hangs

Robert Millan writes: > El 15 d’abril de 2012 16:09, Christoph Egger >>> ;;; About to load > lsp/load.lsp >>>> E: Caught signal 'Terminated': terminating immediately >>>> make[2]: *** [bin/ecl] Terminated >>>> make[1]: ***

Bug#668843: ecl/experimental: FTBFS[!linux]: testsuite hangs

Christoph Egger writes: > Hi all! > > Christoph Egger writes: >> Package: src:ecl >> Version: 12.2.1-1 >> >> Your package failed to build on the kfreebsd-* buildds: >> >> if [ -f CROSS-COMPILER ]; then \ >> touch ecl_min; \ >&

Bug#668843: ecl/experimental: FTBFS[!linux]: testsuite hangs

Hi all! Christoph Egger writes: > Package: src:ecl > Version: 12.2.1-1 > > Your package failed to build on the kfreebsd-* buildds: > > if [ -f CROSS-COMPILER ]; then \ > touch ecl_min; \ > else \ > gcc -o ecl_min cinit.o c/all

Bug#668843: ecl/experimental: FTBFS[!linux]: testsuite hangs

Package: src:ecl Version: 12.2.1-1 Severity: serious Tags: sid wheezy User: debian-...@lists.debian.org, debian-h...@lists.debian.org Usertags: kfreebsd X-Debbugs-Cc: debian-...@lists.debian.org Justification: fails to build from source (but built successfully in the past) Hi! Your package failed

Bug#665747: Bug#613484: /usr/bin/ecl missing in 11.1.1-4

Christoph Egger writes: > Aron Xu writes: >> On Mon, Mar 26, 2012 at 00:34, Christoph Egger wrote: >>> clone 613484 -1 >>> found -1 11.1.1-4 >>> tags -1 - pending >>> retitle -1 testing's /usr/bin/ecl removed from stables maintscript dur

Bug#665747: Bug#613484: /usr/bin/ecl missing in 11.1.1-4

Aron Xu writes: > On Mon, Mar 26, 2012 at 00:34, Christoph Egger wrote: >> clone 613484 -1 >> found -1 11.1.1-4 >> tags -1 - pending >> retitle -1 testing's /usr/bin/ecl removed from stables maintscript during >> upgrade >> stop >> >>>

Bug#613484: /usr/bin/ecl missing in 11.1.1-4

clone 613484 -1 found -1 11.1.1-4 tags -1 - pending retitle -1 testing's /usr/bin/ecl removed from stables maintscript during upgrade stop > Should I file a separate bug, clone this bug or something else? Cloning away. -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Li

Bug#613484: /usr/bin/ecl missing in 11.1.1-4

Hi! Faheem Mitha writes: > I just installed 11.1.1-4 on unstable, and /usr/bin/ecl is missing, > though dpkg thinks it is there. Should I reopen this bug or create a > new bug? > >Regards, Faheem > > orwell:/home/faheem# dpkg -l ecl > |

sbcl double build

Hi! Does anyone still remember why sbcl is built twice when building the debian package? sbcl's build system itself does 3 builds to get from something compile with an arbitrary common lisp to a sbcl binary built with the same version of sbcl and I'm not sure whether the double-build in the debi

Debconf

Hi! Just wondering whether anyone from the Debian Common Lisp Folks going to DebConf as well? Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer A. Because it breaks the logical sequence of discussion Q. Why is top p

Bug#623633: sbcl not loading asdf on startup

. To get the old behaviour put `(require 'asdf)` in /etc/sbclrc -- Christoph Egger Tue, 10 May 2011 22:50:18 +0200 This is the exactly same behaviour you will get when installing sbcl from upstream or in gentoo or arch linux. Of course the require could be installed by sbcl into the g

Re: participating in debian lisp team

Hi! "Azamat S. Kalimoulline" writes: > Hi! I maintain my own lisp repository http://packages.bazon.ru/, where I > build > more or less fresh lisp packages. I want to see it in debian iself. Can I be > member of debian lisp team? We'd be glad to accept your help. For adding you to the pkg-

Bug#617501: works fine here (amd64)

Hi Agustin! Just tried in a clean unstable chroot environment and on my desktop system. Both of them don't seem to exhibit the problem you describe. Which architecture did you run for this test? Regards Christoph (unstable-amd64-sbuild)root@hepworth:/home/christoph# apt-get install cli

SIGSTKSZ-adjust.patch in libsigsegv breaks clisp build on kfreebsd-i386

Hi! With SIGSTKSZ-adjust.patch applied in libsigsegv clisp does not build (it dies with an unhandled SIGBUS). Does anyone know what this patch is supposed to fix (clisp -3 build fine basically everywhere with this patch missing by accident from the then actual libsigsegv). May I safely remove

Bug#617806: s390 fixed

severity 617806 important kthxbye 2.9-3 builds now on s390 only hppa left (waiting on input from porters here) pgpA4K6f9NJhR.pgp Description: PGP signature ___ pkg-common-lisp-devel mailing list pkg-common-lisp-devel@lists.alioth.debian.org http://list

Re: sigsegv on s390 only giving start address of page in segv handler

Hi! Bruno Haible writes: >> I guess it's >> preferred to just accepting a inexact address? Considering how to best >> build a fixed package. The 2 patches I'd consider attached. I'd prefer >> the first one at the moment. >> ... >> Now I'm wondering of software depending on libsigsegv won't work o

request for help: libsigsegv failure

Hi there! libsigsegv seems to fail 2 of the tests on hppa. Unfortunately the debian porter box seems to be down and the gcc compile farm hppa seems to suffer from different issues. Maybe someone with hardware access and insight can give me some help here? Thanks Christoph -- 9FED 5C6C

Re: sigsegv on s390 only giving start address of page in segv handler

Bruno Haible writes: > When you wrote to you didn't remove > the "antispam" words from the address. Jep normally I copy&paste from the website and don't loko at the result but expect it to just work >> Now I'm wondering of software depending on libsigsegv won't work on s390 >> or maybe the corr

Re: sigsegv on s390 only giving start address of page in segv handler

Hi all! Bruno Haible writes: >> libsigsegv doesn't cope well with s390 at the moment. This is caused >> by the fact, that linux masks the address for sigsegv: >> >> mm/fault.c:#define __FAIL_ADDR_MASK 0x7000 >> >> So the last 12 bit of information are lost. > > Thanks for the analysis

remove n-f-u of clisp

Hi! clisp builds/works just fine on armel now so maybe the N-F-U should be dropped? Regards Christoph pgpoqR02cKPTs.pgp Description: PGP signature ___ pkg-common-lisp-devel mailing list pkg-common-lisp-devel@lists.alioth.debian.org http://lis

clisp "crossbuild" 32bit userland, 64bit kernel broken

Hi! I'm having trouble getting clisp to build on my mipsel box, a fuloong mini-PC. Problem is the 64bit kernel causes arimips64.c to be created but the 32bit compiler (it's a whole 32bit userland) is trying to build arimips.c which isn't there. If I pass --build=mipsel-linux-gnu it fails

Re: sigsegv on s390 only giving start address of page in segv handler

Hi! Bruno Haible writes: > When you wrote to you didn't remove > the "antispam" words from the address. > >> libsigsegv doesn't cope well with s390 at the moment. This is caused >> by the fact, that linux masks the address for sigsegv: >> >> mm/fault.c:#define __FAIL_ADDR_MASK 0x7000

Bug#616676: dh-lisp: Variable $implementation needs a declaration/initialization

"Desmond O. Chang" writes: > dh_lisp doesn't work in 0.7.0. The error message is: > > Global symbol "$implementation" requires explicit package name at > /usr/bin/dh_lisp line 158. > Global symbol "$implementation" requires explicit package name at > /usr/bin/dh_lisp line 158. > Execution of /u

sigsegv on s390 only giving start address of page in segv handler

Hi! libsigsegv doesn't cope well with s390 at the moment. This is caused by the fact, that linux masks the address for sigsegv: mm/fault.c:#define __FAIL_ADDR_MASK 0x7000 So the last 12 bit of information are lost. Forcing libsigsegv to use POSIX signal handlers othewise makes a librar

Bug#614343: sbcl-doc is still 1.0.39.0

"Ph. Marek" writes: > Version: 1:1.0.45.0-1 > > sbcl-doc is version 1.0.46.0, 1.0.45 or 1.0.46 ? > but the HTML is still of 1.0.39.0: > > # head /usr/share/doc/sbcl-doc/html/sbcl/index.html 1.0.39.0-1 was the last version shipping sbcl/ as a directory. It was changed to ship as a single html (s

Bug#616621: nmu: for libsigsegv transition

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu libsigsegv in unstable changes soname for the library so all depending packages need to be rebuild. The depwait is needed as 2.9-1 misses the actual shared library by accident (#616576) so pa

Re: ECL

Peter Van Eynde writes: > On 04/03/11 23:52, Christoph Egger wrote: >> Would be fine. I have experimented with disabling gengc on ia64 as >> bilding with that option enabled won't work -- removing it selectively >> would fix that. What's your opinion about that? T

Re: ECL

Hi! Peter Van Eynde writes: > On 03/03/11 16:53, Christoph Egger wrote: >> I've been struggling a bit with ecl but going forward with getting a >> 11.1.1 to work. Just now I noticed some activity by Peter -- are you >> also working on it? Just to avoid doing stu

ECL

Hi! I've been struggling a bit with ecl but going forward with getting a 11.1.1 to work. Just now I noticed some activity by Peter -- are you also working on it? Just to avoid doing stuff twice ;) I had to add 2 tiny patches to get it building without the embedded libatomic-ops but building do

Re: RFS: abcl, new upstream release 0.24.0

Hi! Darren Hoo writes: > A new version of abcl 0.24.0 has been released upstream. > This is the updated package, the URL of my package is at > >http://mentors.debian.net/debian/pool/main/a/abcl > > The respective dsc file can be found at: > > http://mentors.debian.net/debian/pool/ma

Re: Leaving the team, Uploaders: to be fixed

Luca Capello writes: > On Tue, 04 Jan 2011 21:23:29 +0100, Christoph Egger wrote: >> Luca Capello writes: >>>>> - ecl >>>> >>>> The Git repository on Alioth is not up-to-date: Christoph, can you push >>>> your last changes, please? >

Re: RFS: abcl

Darren Hoo writes: > dget http://mentors.debian.net/debian/pool/main/a/abcl/abcl_0.23.1-2.dsc lintian -IE --pedantic ~~ P: abcl source: debian-control-has-unusual-field-spacing line 11 P: abcl source: debian-control-has-unusual-field-spacing line 27 Extra spaces at the b

Re: RFS: abcl

Hi! Darren Hoo writes: > I am looking for a sponsor for my package "abcl". > > * Package name: abcl > Version : 0.23.1 > Upstream Author : ABCL development team and contributors > * URL : http://common-lisp.net/project/armedbear/ > * License : GPL > Programm

Re: Leaving the team, Uploaders: to be fixed

Hi! Luca Capello writes: >>> - ecl >> >> The Git repository on Alioth is not up-to-date: Christoph, can you push >> your last changes, please? > > Ping (this time cc:ing Christoph). I'll take a look when I'm back at my workstation. It *should* be there -- guess I have grown a bit of a bad ha

Re: UNS: Mailing list administration (was: On the use of Git)

Hi! Luca Capello writes: > On Wed, 08 Sep 2010 08:31:11 +0200, Peter Van Eynde wrote: >> PS: maybe we also need more 'admin' people for the mailing lists. Is >> someone a volunteer to do this? > > We need more, yes, especially given the fact that I am slowly fading > away from CL-related stuf

Re: RFS: common-lisp-controller (updated package)

Hi! "Desmond O. Chang" writes: > On Sun, Aug 22, 2010 at 00:57, Christoph Egger wrote: >>    I guess this is targeted at squeeze? Have you contacted the release >> team already? If not please mail them and explain why you should get a >> freeze exception (looks li

Re: Impossible to install CLISP onto ARM running Debian

Hi! Jean Marangos writes: > Dear Sir or Madam, > though present in the lenny(stable) repositories, it is not possible > to install CLISP onto an ARM processor running Debian via either > "aptitude" or "synaptic" as suggested in the "Download Page for > clisp_2.44.1-4.1_arm.deb on ARM machines". B

Re: RFS: common-lisp-controller (updated package)

Hi! "Desmond O. Chang" writes: > I am looking for a sponsor for the new version 7.4 > of my package "common-lisp-controller". > > It builds these binary packages: > common-lisp-controller - Common Lisp source and compiler manager > > The package appears to be lintian clean. > > The upload would f

Re: libgc + the ecl situation

Julien Cristau writes: > On Mon, Aug 16, 2010 at 22:06:08 +0200, Christoph Egger wrote: >> Hi all! >> >> The ecl package currently is still affected by [0] -- RC bug caused >> by a build failure / embedded copy of libgc. The upload to experimental, >> wh

  1   2   >