Do you have failure logs I can inspect?
I build each of the hundreds of Quicklisp systems in alphabetical
order. Perhaps some state created by that mechanism is triggering the
problem in a way that doesn't happen when building a system in
isolation.
I'll try to create an easy-to-reproduce
Faré fah...@gmail.com writes:
Dear Zach,
: Faré
OK, so 2.26.45 is my new release candidate for ASDF 2.27.
Please grab it and test it.
: Zach Beane
It still breaks gbbopen and fset.
It still seems to trigger the package-at-variance issue in weblocks and
other projects.
Did you actually
Faré fah...@gmail.com writes:
OK, so 2.26.45 is my new release candidate for ASDF 2.27.
Please grab it and test it.
It still breaks gbbopen and fset.
It still seems to trigger the package-at-variance issue in weblocks and
other projects.
If the new ASDF isn't backwards-compatible with
On Fri, Dec 28, 2012 at 10:55 AM, Zach Beane x...@xach.com wrote:
Faré fah...@gmail.com writes:
OK, so 2.26.45 is my new release candidate for ASDF 2.27.
Please grab it and test it.
It still breaks gbbopen and fset.
Ouch. I will work with the authors to resolve these issues.
FSet clearly
GBBopen from svn trunk r1168 works fine for me using ASDF 2.26.45,
with or without the attached cleanup patch.
rlwrap sbcl --eval '(quote(#.(require asdf)#.(in-package
:asdf)#.(upgrade-asdf)#.(load
/home/tunes/quicklisp/setup.lisp)#.(progn(load-system
:gbbopen))#.(cl-user::gbbopen-test)))'
rlwrap
OK, so 2.26.45 is my new release candidate for ASDF 2.27.
Please grab it and test it.
Since last release candidate 2.26.24,
* lots of work was done towards backwards compatibility,
fixing bugs introduced or uncovered
during the previous fixing of essential conceptual bugs
through massive
