First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 103902
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Common Lisp Herd <lisp@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Tobias C. Rittweiler <tcr@freebits.de>
Add CC:
CC:
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 103902 depends on: Show dependency tree
Show dependency graph
Bug 103902 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)







View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug

Description:   Opened: 2005-08-27 03:25 0000 
The default ebuild for dev-lisp/cl-aserve resp. dev-lisp/cl-acl-compat
uses a cvs version from 2005-08-05, the alternative would be from
2005-02-20. But as you can see in [1], in the version of the default
ebuild the new thread api of sbcl is used. However, when you look at
[2], the thread api changed in 0.9.2.9, ie. in =dev-lisp/sbcl-0.9.2 (the
default ebuild for SBCL) the old api is still used.
As a result, acl-compat / aserve as of 2005-08-05 does not work with
sbcl-0.9.2. 

Solutions: Either downgrade default ebuild for acl-compat / aserve, or
upgrade sbcl's default one (especially as a new stable version of sbcl
has just been releaed. See Bug #103899.)



[1]
http://cvs.sourceforge.net/viewcvs.py/portableaserve/portableaserve/acl-compat/sbcl/acl-mp.lisp?rev=1.15&view=markup
[2]
http://cvs.sourceforge.net/viewcvs.py/sbcl/sbcl/src/code/target-thread.lisp?rev=1.33&view=markup

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

------- Comment #1 From Matthew Kennedy (RETIRED) 2005-09-01 11:18:41 0000 ------- 
Thanks for the note.  Upon committing the new ebuild for SBCL 0.9.4, I will
mark
=dev-lisp/sbcl-0.9.3 stable for some architectures (not ppc though due to Bug
#99456, and not mips immediately due to not having direct access to it).  This
means that for the other architectures (ie. amd64, sparc and x86) the "default"
(stable) ebuild will be 0.9.3 which should solve this bug.

------- Comment #2 From Matthew Kennedy (RETIRED) 2005-09-01 11:46:44 0000 ------- 
Except for ppc and mips, the stable ebuild is now sbcl 0.9.3
First Last Prev Next    No search results available      Search page      Enter new bug