Bug#966909: Fixed upstream
This FTBFS is caused by a change in behaviour in bison 3.7. There's a proposed fix upstream at https://github.com/verilator/verilator/pull/2505 which works by telling Bison the correct header name. Rupert
Bug#713529: [Help] FTBFS: ! LuaTeX error ./luasseq.lua:204: attempt to call field 'gfind' (a nil value)
Hi Andreas, It seems that I haven't set the BTS up correctly to let me know when there are bugs against the package. Sorry - I'll fix that in a minute. I'll try and build / fix stuff now. Thanks for letting me know. Rupert pgpW9C5Pqc2sO.pgp Description: PGP signature
Bug#723679: cmucl segfault
Paul Gevers writes: > Hi Rupert, > > On 16-11-13 10:08, Rupert Swarbrick wrote: >> This happens because of some faulty logic in the "linux >> detection". Basically, they had something hardcoded to check for new >> linuxes, which meant version 2.x.y. Linux 3.x broke it. > > Do you have any idea why then cmucl doesn't segfault on my system (yes, > multi-arch)? Maybe only the non sse code? > > paul@wollumbin ~ $ uname -a > Linux wollumbin 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux Ahah, I found the commit in question: http://trac.common-lisp.net/cmucl/changeset/f51ee9dc1f66b02f7a9a0826b70550f3bc9fb222 and I'm on Linux skate 3.11-1-amd64 #1 SMP Debian 3.11.6-2 (2013-11-01) x86_64 GNU/Linux and get the (expected) segfault. I think the point is that I don't have a ".0" patch version, unlike you. Apparently the Linux 3 thing was a bit of a red herring: I think I only hit this with a 3.x kernel, presumably because the naming scheme changed slightly. Looking at the commit message, I was presumably using 3.7-trunk at the time... Rupert pgpMf5MmlgYju.pgp Description: PGP signature
Bug#723679: cmucl segfault
This happens because of some faulty logic in the "linux detection". Basically, they had something hardcoded to check for new linuxes, which meant version 2.x.y. Linux 3.x broke it. Raymond Toy fixed this in March when I reported it to him (I crashed into it when working on Maxima build systems). Packaging the new upstream version will fix this bug in Debian. Rupert pgpNEJ2pPozDU.pgp Description: PGP signature
Bug#651992: cl-aserve: Should depend on cl-acl-compat and cl-htmlgen
Package: cl-aserve Version: 1.2.42+cvs.2010.02.08-dfsg-1 Severity: serious After installing cl-aserve (installed for cl-rss), with SBCL 2:1.0.54.0-1, loading it doesn't work because it depends on cl-acl-compat and cl-htmlgen (see line 74 of the .asd), but these weren't installed because cl-aserve doesn't depend on them. Installing cl-acl-compat and cl-htmlgen fixes the issue. Rupert -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-rc2+ (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages cl-aserve depends on: ii cl-ppcre2.0.1-2 ii cl-puri 1.5.5-1 ii common-lisp-controller 7.8 cl-aserve recommends no packages. Versions of packages cl-aserve suggests: pn cl-webactions -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620011: Core file location changed and /usr/bin/sbcl doesn't follow...
Package: sbcl Version: 1:1.0.47.0-1 Severity: grave Justification: renders package unusable It seems that the location for the core file has changed: /usr/lib/sbcl/sbcl-dist.core Fine, but the wrapper binary doesn't seem to know about it: rupert@hake:~ sbcl fatal error encountered in SBCL pid 9337(tid 3085084352): can't find core file at /usr/lib/sbcl/sbcl.core This makes sbcl unusable on my system, and I presume on everyone else's? -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-rc8+ (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages sbcl depends on: ii libc6 2.13-0exp4 Embedded GNU C Library: Shared lib Versions of packages sbcl recommends: ii binfmt-support2.0.4 Support for extra binary formats Versions of packages sbcl suggests: pn sbcl-doc (no description available) ii sbcl-source 1:1.0.47.0-1 Source code files for SBCL ii slime 1:20100722-1 Superior LISP Interaction Mode for -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578954: Doesn't create bbdb-autoloads.el, upon which bbdb-initialise depends
Package: bbdb Version: 2.36-1 Severity: grave Justification: renders package unusable As a temporary workaround, the user can go to /usr/share/emacs/site- lisp/bbdb/lisp/ and (as root) "make bbdb-autoloads.el". -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.34-rc5 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bbdb depends on: ii dpkg 1.15.5.6 Debian package management system ii emacs23 [emacsen] 23.1+1-6 The GNU Emacs editor (with GTK+ us ii install-info 4.13a.dfsg.1-5 Manage installed documentation in ii make 3.81-8 An utility for Directing compilati ii perl 5.10.1-12 Larry Wall's Practical Extraction bbdb recommends no packages. Versions of packages bbdb suggests: pn gnus | t-gnus (no description available) pn gnuserv(no description available) pn vm (no description available) ii w3m-elCVS-20081010-1 Emacs-W3m Dev version -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540816: Two .asd's installed
Package: cl-sql Version: 4.0.5-4 Severity: grave The current cl-sql package installs two copies of clsql.asd: rup...@hake:~ dpkg -L cl-sql | grep asd /usr/share/common-lisp/source/clsql/sql/clsql.asd /usr/share/common-lisp/source/clsql/clsql.asd /usr/share/common-lisp/systems/clsql.asd Only the second one should be there. Also, the symlink seems to point at the first, which doesn't work since the relative urls are wrong. They end up with the following problem: * (require :clsql) ; loading system definition from /usr/share/common-lisp/systems/uffi.asd into ; # ; registering # as UFFI debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread #: failed to find the TRUENAME of /usr/share/common-lisp/source/clsql/sql/sql/cmucl-compat.lisp: No such file or directory Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [TRY-RECOMPILING] Try recompiling cmucl-compat 1: [RETRY ] Retry performing # on #. 2: [ACCEPT ] Continue, treating # on # as having been successful. 3: [ABORT ] Exit debugger, returning to top level. (SB-IMPL::SIMPLE-FILE-PERROR "failed to find the TRUENAME of ~A" #P"/usr/share/common-lisp/source/clsql/sql/sql/cmucl-compat.lisp" 2) (I set the severity to grave since, unless the user is quite knowledgeable about asdf, they won't be able to load clsql because of this bug) Rupert pgpqfZ0zdVCuU.pgp Description: PGP signature
Bug#537194: Exports wsdl-soal-call rather than wsdl-soap-call
Package: cl-soap Version: 20060105-2 Severity: serious The defpackage for :cl-soap, which is installed into /usr/share/common-lisp/source/cl-soap/src/package.lisp exports the symbol :wsdl-soal-call rather than :wsdl-soap-call, the correct name. (The function #'wsdl-soap-call is the final function defined in wsdl.lisp) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#469058: libc6: New version of libc6 hangs SBCL
> > After upgrading to 2.7-9 of libc6 in unstable, SBCL became extremely > > prone to crashing > > randomly (i.e. 5-10 source files compiled of the SBCL CVS code before a > > 100% CPU hang which > > was only killable with -s 9. > > Could you please give a way to reproduce the bug? I know nothing about > SBCL, so a list of commands to execute or a shell script would be nice. Of course, sorry. Probably the easiest option is to get sbcl and darcs (the version control system). It doesn't appear to matter which version of sbcl - I've had the problem with 1.0.12 up to 1.0.14. Then get clbuild (which is a little shell script which can among other things get and build a new copy of sbcl, which is a project large enough to guarantee the hang on my computer at least) using darcs get http://common-lisp.net/project/clbuild/clbuild Chmod +x the clbuild script inside the folder and cd inside and run ./clbuild buildsbcl Hopefully (!) your system should hang at 100% CPU with the sbcl process ignoring SIGTERM. Sorry about the involved duplication process - it's just that you need to compile quite a bit of code before the seemingly "random" bug strikes. > Could you please try to narrow the problem to a single libc6 version? > Older versions are available on snapshot.debian.net. > Could you let me know a way to convince dpkg to let me do that? Since you have to up/downgrade a dependent package at the same time, and I'm a bit scared of using --force-all on libc6 on my only computer! (Or am I being needlessly cautious?) Incidentally, as someone pointed out in the sbcl thread I linked to, it's quite possible that your change in libc6 has thrown up a bug in sbcl rather than the other way round - we're trying (and failing) to get strace,gdb to tell us something useful about where sbcl died. However, I'd be extremely grateful if you could suggest what change you think is likely to be able to cause this sort of symptom - and I stand by my categorization: the change definitely breaks an unrelated package :P Thanks for the really prompt response! Rupert signature.asc Description: This is a digitally signed message part
Bug#469058: libc6: New version of libc6 hangs SBCL
Subject: libc6: New version of libc6 hangs SBCL Package: libc6 Version: 2.7-9 Severity: critical Justification: breaks unrelated software *** Please type your report below this line *** After upgrading to 2.7-9 of libc6 in unstable, SBCL became extremely prone to crashing randomly (i.e. 5-10 source files compiled of the SBCL CVS code before a 100% CPU hang which was only killable with -s 9. The issue was originally raised on the SBCL devel list here: http://thread.gmane.org/gmane.lisp.steel-bank.devel/10902/focus=10905 I upgraded the system from libc6 2.7-8, which seems to have caused the problem. Downgrading libc6 to the package in testing (libc 2.7-6) fixes it again: I've since compiled sbcl from CVS twice to make sure. Rupert Swarbrick P.S. The System Information below was generated with reportbug and I've currently got 2.7-6 installed. libgcc1 doesn't seem to have been up/down-graded, though, so I think the below is mostly true except for the "testing" bits, since all other libraries are at the current versions in unstable. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6 depends on: ii libgcc1 1:4.3-20080227-1 GCC support library libc6 recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
