[asdf-devel] Re: Bug#723977: missing symlink in /usr/share/common-lisp/systems
(Adding asdf-devel to the recipients — the problem is wrong (asdf::default-source-registry) when XDG_DATA_DIRS is empty.) Well, ASDF ought to have worked even in absence of XDG_DATA_DIRS, and you discovered a genuine bug in ASDF. It turns out, split-string was not designed to return correct results when passed either NIL or "", and this caused ASDF to fail to treat the default properly for XDG_DATA_DIRS. I've pushed a fix as ASDF 3.0.2.9, but that's a pretty bad bug you've discovered, which defeats the default configuration. Robert: when do you instead to release 3.0.3 ? Otherwise, I could do a Debian package for 3.0.2.9. (PS: I took the liberty of also committing my load-systems* patch). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A competent and self-confident person is incapable of jealousy in anything. Jealousy is invariably a symptom of neurotic insecurity. — Robert Heinlein, "Time Enough For Love" On Mon, Sep 23, 2013 at 1:05 AM, Diogo F. S. Ramos <diogofsr@gmail.com> wrote:
1- what does env return?
I think the problem lies here.
My environment does not export XDG_DATA_DIRS. If I try it inside gnome, which exports it, everything works nicely.
According to the XDG Base Directory Specification[1], if XDG_DATA_DIRS is empty or not set, the defaults should be used. More specifically:
$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be seperated with a colon ':'.
If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used.
Maybe something in the stack is not implementing this characteristic of XDG.
[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Faré wrote:
Robert: when do you instead to release 3.0.3 ? Otherwise, I could do a Debian package for 3.0.2.9. (PS: I took the liberty of also committing my load-systems* patch).
I was waiting on those two more UIOP patches (see the launchpad tracker -- sorry I'm on a plane so I can't look them up myself), but I agree that this needs a new version. I'll be OOT till Friday, but will try to run the full set of tests (they run on my laptop on all officially supported platforms), and if they pass, we can release 3.0.3 then. I am afraid I still don't have the ability to test on linux, or to build the Debian package -- still without a linux platform on which to hack ASDF. I am still having mysterious problems with bundling on my tests on ABCL and ECL, but I am pretty sure that the errors on ECL have to do with its own incorrect detection of 32- vs. 64-bit. ABCL is a bit more mysterious to me. Haven't been able to get any help with either of these, so don't think they should be allowed to block progress on other implementations. -- Robert P. Goldman Principal Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN 55401 Voice: (612) 326-3934 Email: rpgoldman@SIFT.net
On Mon, Sep 23, 2013 at 6:29 PM, Robert Goldman <rpgoldman@sift.net> wrote:
Faré wrote:
Robert: when do you [intend] to release 3.0.3 ? Otherwise, I could do a Debian package for 3.0.2.9. (PS: I took the liberty of also committing my load-systems* patch).
I was waiting on those two more UIOP patches (see the launchpad tracker -- sorry I'm on a plane so I can't look them up myself), but I agree that this needs a new version.
Which UIOP patches were you thinking of? I fixed a simple one regarding ensure-function. I see other portability issues with directory* and symlinks, but I am not competent to address them.
I'll be OOT till Friday, but will try to run the full set of tests (they run on my laptop on all officially supported platforms), and if they pass, we can release 3.0.3 then.
Excellent.
I am afraid I still don't have the ability to test on linux, or to build the Debian package -- still without a linux platform on which to hack ASDF.
I can do that part, at least for the free software and proprietary implementations for which I still have a license.
I am still having mysterious problems with bundling on my tests on ABCL and ECL, but I am pretty sure that the errors on ECL have to do with its own incorrect detection of 32- vs. 64-bit. ABCL is a bit more mysterious to me. Haven't been able to get any help with either of these, so don't think they should be allowed to block progress on other implementations.
In case it means anything, tests pass on both ECL and ABCL on Linux x64. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Death is only a state of mind. Only it doesn't leave you much time to think about anything else.
Faré wrote:
On Mon, Sep 23, 2013 at 6:29 PM, Robert Goldman <rpgoldman@sift.net> wrote:
Robert: when do you [intend] to release 3.0.3 ? Otherwise, I could do a Debian package for 3.0.2.9. (PS: I took the liberty of also committing my load-systems* patch). I was waiting on those two more UIOP patches (see the launchpad tracker -- sorry I'm on a plane so I can't look them up myself), but I agree
Faré wrote: that this needs a new version.
Which UIOP patches were you thinking of? I fixed a simple one regarding ensure-function. I see other portability issues with directory* and symlinks, but I am not competent to address them.
I'm thinking of 1205555 https://bugs.launchpad.net/asdf/+bug/1205555 and 1205653 https://bugs.launchpad.net/asdf/+bug/1205653 I was hoping to get some work done on these, but that target is slipping.
I'll be OOT till Friday, but will try to run the full set of tests (they run on my laptop on all officially supported platforms), and if they pass, we can release 3.0.3 then.
Excellent.
I am afraid I still don't have the ability to test on linux, or to build the Debian package -- still without a linux platform on which to
hack ASDF.
I can do that part, at least for the free software and proprietary implementations for which I still have a license.
I just tested on an old and crufty linux box. Worked for ccl sbcl cmucl allegro allegromodern. ECL fails the test on my box. Goes into an infinite loop compiling test/file3.lisp -- gets an error in compilation, retries, gets an error .... This may be the fact that I'm trying this on an ancient OpenSUSE box, with a distro version that's been EOLed, so that may be me, not ASDF. If you could test with ECL, and it works for you, I am going to chalk this up to my ancient distro.
I am still having mysterious problems with bundling on my tests on ABCL and ECL, but I am pretty sure that the errors on ECL have to do with its own incorrect detection of 32- vs. 64-bit. ABCL is a bit more mysterious to me. Haven't been able to get any help with either of these, so don't think they should be allowed to block progress on other implementations.
In case it means anything, tests pass on both ECL and ABCL on Linux x64.
As I said, I think ECL, as packaged by Mac Ports is busted on Mac, and I can't fix it. I don't have a good way to tell if ABCL is busted on Mac or our bundle op is busted on Mac. Best, r
participants (3)
-
Faré -
Robert Goldman -
Robert P. Goldman