ASDF upgrade script fails on cmucl/Linux
I'm getting a failure of the ASDF upgrade tests on CMUCL since the UIOP dependencies mod: Upgrading ASDF from version 3.1.7 to version 3.3.2.13 TEST ABORTED: Error while trying to load definition for system test-asdf from pathname /var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd: don't recognize component type :MODULE This looks like the key bit of the backtrace: ``` 10: (ERROR ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR :NAME "test-asdf" :PATHNAME #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" :CONDITION #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 11: ("LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O S)" #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 12: (SIGNAL #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 13: (ERROR ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR :FORMAT-CONTROL "don't recognize component type ~S" :FORMAT-ARGUMENTS (:MODULE)) 14: (ASDF/SESSION:SYSDEF-ERROR "don't recognize component type ~S" :MODULE)[:OPTIONAL] 15: (ASDF/PARSE-DEFSYSTEM:PARSE-COMPONENT-FORM NIL (:MODULE "test-asdf" :PATHNAME NIL) :PREVIOUS-SERIAL-COMPONENT NIL)[:OPTIONAL] 16: (LISP::SLOLOAD #<Stream for file "/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd">) 17: (LISP::INTERNAL-LOAD #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" :ERROR :SOURCE :UTF-8) ``` TBH, I'm inclined to regard 3.1.7 as so old that I don't have to think about it, but I'm open to contradiction. If I don't hear any, I'll prune that from the set of origin versions to test for upgrades, and move on. Best, R
I believe this is an issue with ASDF upgrade not working on CMUCL due to CLOS issues. The workaround is to use the install-asdf.lisp script to overwrite CMUCL's builtin ASDF with a newer one. — Although I'm not sure whether the script will work if ASDF can't upgrade itself. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Every great truth begins as heresy and ends as superstition. — Thomas Henry Huxley On Tue, Feb 12, 2019 at 3:51 PM Robert Goldman <rpgoldman@sift.info> wrote:
I'm getting a failure of the ASDF upgrade tests on CMUCL since the UIOP dependencies mod:
Upgrading ASDF from version 3.1.7 to version 3.3.2.13
TEST ABORTED: Error while trying to load definition for system test-asdf from pathname /var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd: don't recognize component type :MODULE
This looks like the key bit of the backtrace:
10: (ERROR ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR :NAME "test-asdf" :PATHNAME #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" :CONDITION #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 11: ("LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O S)" #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 12: (SIGNAL #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 13: (ERROR ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR :FORMAT-CONTROL "don't recognize component type ~S" :FORMAT-ARGUMENTS (:MODULE)) 14: (ASDF/SESSION:SYSDEF-ERROR "don't recognize component type ~S" :MODULE)[:OPTIONAL] 15: (ASDF/PARSE-DEFSYSTEM:PARSE-COMPONENT-FORM NIL (:MODULE "test-asdf" :PATHNAME NIL) :PREVIOUS-SERIAL-COMPONENT NIL)[:OPTIONAL] 16: (LISP::SLOLOAD #<Stream for file "/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd">) 17: (LISP::INTERNAL-LOAD #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" :ERROR :SOURCE :UTF-8)
TBH, I'm inclined to regard 3.1.7 as so old that I don't have to think about it, but I'm open to contradiction. If I don't hear any, I'll prune that from the set of origin versions to test for upgrades, and move on.
Best,
R
On a happier note, both (Home)brew and Ubuntu have newish versions of clisp which, AFAICT, pass all the ASDF tests. Yay! On 12 Feb 2019, at 16:32, Faré wrote:
I believe this is an issue with ASDF upgrade not working on CMUCL due to CLOS issues.
The workaround is to use the install-asdf.lisp script to overwrite CMUCL's builtin ASDF with a newer one. — Although I'm not sure whether the script will work if ASDF can't upgrade itself.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Every great truth begins as heresy and ends as superstition. — Thomas Henry Huxley
On Tue, Feb 12, 2019 at 3:51 PM Robert Goldman <rpgoldman@sift.info> wrote:
I'm getting a failure of the ASDF upgrade tests on CMUCL since the UIOP dependencies mod:
Upgrading ASDF from version 3.1.7 to version 3.3.2.13
TEST ABORTED: Error while trying to load definition for system test-asdf from pathname /var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd: don't recognize component type :MODULE
This looks like the key bit of the backtrace:
10: (ERROR ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR :NAME "test-asdf" :PATHNAME #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" :CONDITION #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 11: ("LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O S)" #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 12: (SIGNAL #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 13: (ERROR ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR :FORMAT-CONTROL "don't recognize component type ~S" :FORMAT-ARGUMENTS (:MODULE)) 14: (ASDF/SESSION:SYSDEF-ERROR "don't recognize component type ~S" :MODULE)[:OPTIONAL] 15: (ASDF/PARSE-DEFSYSTEM:PARSE-COMPONENT-FORM NIL (:MODULE "test-asdf" :PATHNAME NIL) :PREVIOUS-SERIAL-COMPONENT NIL)[:OPTIONAL] 16: (LISP::SLOLOAD #<Stream for file "/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd">) 17: (LISP::INTERNAL-LOAD #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" :ERROR :SOURCE :UTF-8)
TBH, I'm inclined to regard 3.1.7 as so old that I don't have to think about it, but I'm open to contradiction. If I don't hear any, I'll prune that from the set of origin versions to test for upgrades, and move on.
Best,
R
13.02.2019, 01:44, "Robert Goldman" <rpgoldman@sift.info>:
On a happier note, both (Home)brew and Ubuntu have newish versions of clisp which, AFAICT, pass all the ASDF tests. Yay!
What newish clisp it is? I have been hoping clips will release somem "refreshment" release, maybe just the same code as the previous release but new ASDF. From time to time are check the mailing list and project page - no news. Is that OS package maintainers did anything on the package level?
On 14 Feb 2019, at 4:55, Anton Vodonosov wrote:
13.02.2019, 01:44, "Robert Goldman" <rpgoldman@sift.info>:
On a happier note, both (Home)brew and Ubuntu have newish versions of clisp which, AFAICT, pass all the ASDF tests. Yay!
What newish clisp it is? I have been hoping clips will release somem "refreshment" release, maybe just the same code as the previous release but new ASDF. From time to time are check the mailing list and project page - no news.
Is that OS package maintainers did anything on the package level?
I think it's the packaging managers, not the clisp maintainers who did this. On my Mac, with Homebrew, the version is: ``` /usr/local/Cellar/clisp/2.49_2 (64 files, 16.2MB) ``` According to GitHub, it was last updated 20 days ago. I don't really know how up-to-date it is with the clisp repo versus the ancient zip file. On my Ubuntu Box, I have a package whose version is listed as `1:2.49.20170913-4build1`. I don't know how to tell what that corresponds to in terms of the clisp source repo. Best, R
How critical is being able to upgrade? Cmucl snapshots usually provide the very latest version of asdf. Fare has reported the issues with cmucl's pcl and I've just been really lazy to dig into the hairy pcl code. On Thu, Feb 14, 2019 at 2:16 PM Robert Goldman <rpgoldman@sift.info> wrote:
On 14 Feb 2019, at 4:55, Anton Vodonosov wrote:
13.02.2019, 01:44, "Robert Goldman" rpgoldman@sift.info:
On a happier note, both (Home)brew and Ubuntu have newish versions of clisp which, AFAICT, pass all the ASDF tests. Yay!
What newish clisp it is? I have been hoping clips will release somem "refreshment" release, maybe just the same code as the previous release but new ASDF. From time to time are check the mailing list and project page - no news.
Is that OS package maintainers did anything on the package level?
I think it's the packaging managers, not the clisp maintainers who did this.
On my Mac, with Homebrew, the version is:
/usr/local/Cellar/clisp/2.49_2 (64 files, 16.2MB)
According to GitHub, it was last updated 20 days ago. I don't really know how up-to-date it is with the clisp repo versus the ancient zip file.
On my Ubuntu Box, I have a package whose version is listed as 1:2.49.20170913-4build1. I don't know how to tell what that corresponds to in terms of the clisp source repo.
Best, R
-- Ray
On Mon, Feb 18, 2019, 17:13 Raymond Toy <toy.raymond@gmail.com wrote:
How critical is being able to upgrade? Cmucl snapshots usually provide the very latest version of asdf.
CMUCL keeping a recent version of ASDF (unlike e.g. SBCL) adequately alleviates the need for upgrade. -#f
I see that 21c contains 3.3.0 Since I only test on the latest CMUCL, there is no reason for me to test upgrades from earlier versions. I will fix the test scripts; that will likely make the problem go away (it does at least on my Mac). Note that this means that we can't guarantee what happens if a user tries to load a new ASDF into an older revision of CMUCL. That's nothing new, though! We have never really been able to test more than the latest version of the lisp implementations (and sometimes not that!). Best, Robert On 18 Feb 2019, at 16:12, Raymond Toy wrote:
How critical is being able to upgrade? Cmucl snapshots usually provide the very latest version of asdf.
Fare has reported the issues with cmucl's pcl and I've just been really lazy to dig into the hairy pcl code.
On Thu, Feb 14, 2019 at 2:16 PM Robert Goldman <rpgoldman@sift.info> wrote:
On 14 Feb 2019, at 4:55, Anton Vodonosov wrote:
13.02.2019, 01:44, "Robert Goldman" rpgoldman@sift.info:
On a happier note, both (Home)brew and Ubuntu have newish versions of clisp which, AFAICT, pass all the ASDF tests. Yay!
What newish clisp it is? I have been hoping clips will release somem "refreshment" release, maybe just the same code as the previous release but new ASDF. From time to time are check the mailing list and project page - no news.
Is that OS package maintainers did anything on the package level?
I think it's the packaging managers, not the clisp maintainers who did this.
On my Mac, with Homebrew, the version is:
/usr/local/Cellar/clisp/2.49_2 (64 files, 16.2MB)
According to GitHub, it was last updated 20 days ago. I don't really know how up-to-date it is with the clisp repo versus the ancient zip file.
On my Ubuntu Box, I have a package whose version is listed as 1:2.49.20170913-4build1. I don't know how to tell what that corresponds to in terms of the clisp source repo.
Best, R
-- Ray
What's interesting is that this is a *new* failure, triggered by the new dependencies added to the UIOP system definitions. Note that this is a test run; maybe I should simply stop testing upgrade on cmucl? R On 12 Feb 2019, at 16:32, Faré wrote:
I believe this is an issue with ASDF upgrade not working on CMUCL due to CLOS issues.
The workaround is to use the install-asdf.lisp script to overwrite CMUCL's builtin ASDF with a newer one. — Although I'm not sure whether the script will work if ASDF can't upgrade itself.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Every great truth begins as heresy and ends as superstition. — Thomas Henry Huxley
On Tue, Feb 12, 2019 at 3:51 PM Robert Goldman <rpgoldman@sift.info> wrote:
I'm getting a failure of the ASDF upgrade tests on CMUCL since the UIOP dependencies mod:
Upgrading ASDF from version 3.1.7 to version 3.3.2.13
TEST ABORTED: Error while trying to load definition for system test-asdf from pathname /var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd: don't recognize component type :MODULE
This looks like the key bit of the backtrace:
10: (ERROR ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR :NAME "test-asdf" :PATHNAME #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" :CONDITION #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 11: ("LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. O S)" #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 12: (SIGNAL #<ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR {5A92F6A5}>) 13: (ERROR ASDF/SESSION:FORMATTED-SYSTEM-DEFINITION-ERROR :FORMAT-CONTROL "don't recognize component type ~S" :FORMAT-ARGUMENTS (:MODULE)) 14: (ASDF/SESSION:SYSDEF-ERROR "don't recognize component type ~S" :MODULE)[:OPTIONAL] 15: (ASDF/PARSE-DEFSYSTEM:PARSE-COMPONENT-FORM NIL (:MODULE "test-asdf" :PATHNAME NIL) :PREVIOUS-SERIAL-COMPONENT NIL)[:OPTIONAL] 16: (LISP::SLOLOAD #<Stream for file "/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd">) 17: (LISP::INTERNAL-LOAD #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" #P"/var/lib/jenkins/workspace/asdf-upgrade/test/test-asdf.asd" :ERROR :SOURCE :UTF-8)
TBH, I'm inclined to regard 3.1.7 as so old that I don't have to think about it, but I'm open to contradiction. If I don't hear any, I'll prune that from the set of origin versions to test for upgrades, and move on.
Best,
R
participants (4)
-
Anton Vodonosov -
Faré -
Raymond Toy -
Robert Goldman