sbcl: 2.0.2 -> 2.0.7, eliminate risky alias scheme by purcell · Pull Request #94913 · NixOS/nixpkgs

purcell · 2020-08-08T01:23:01Z

Motivation for this change

Update to latest release
When users install sbcl, they should get the latest patched
version in the major series: the pinning of sbcl to 2.0.0 was
undesirable and potentially risky
There's no need to retain a (copy/pasted) attribute for the first
unpatched release in the current series: the derivation can
trivially be overridden by users who really require such a build

Things done

- When users install `sbcl`, they should get the latest patched version in the major series: the pinning of `sbcl` to 2.0.0 was undesirable and potentially risky - There's no need to retain a (copy/pasted) attribute for the first unpatched release in the current series: the derivation can trivially be overridden by users who really require such a build

purcell · 2020-08-08T03:41:23Z

Hmmm, this seems to cause the clwrapper.sh machinery to break, which all looks slightly brittle. Just using lisp as the FASL type seems to avoid this, the simplest demonstrable hacky version of which is:

diff --git a/pkgs/development/lisp-modules/clwrapper/cl-wrapper.sh b/pkgs/development/lisp-modules/clwrapper/cl-wrapper.sh
index 9836bbe5642..08b680c3fdc 100755
--- a/pkgs/development/lisp-modules/clwrapper/cl-wrapper.sh
+++ b/pkgs/development/lisp-modules/clwrapper/cl-wrapper.sh
@@ -123,7 +123,7 @@ eval "$NIX_LISP_PRELAUNCH_HOOK"
 
 if [ -z "$NIX_LISP_SKIP_CODE" ]; then
     "$NIX_LISP_COMMAND" $NIX_LISP_EARLY_OPTIONS \
-	                $NIX_LISP_EXEC_CODE "${NIX_LISP_ASDF_LOAD:-"(load \"$NIX_LISP_ASDF/lib/common-lisp/asdf/build/asdf.$NIX_LISP_FASL_TYPE\")"}" \
+	                $NIX_LISP_EXEC_CODE "${NIX_LISP_ASDF_LOAD:-"(load \"$NIX_LISP_ASDF/lib/common-lisp/asdf/build/asdf.lisp\")"}" \
 	                $NIX_LISP_EXEC_CODE "$NIX_LISP_ASDF_REGISTRY_CODE" \
 	                ${NIX_LISP_FINAL_PARAMETERS[*]:+"${NIX_LISP_FINAL_PARAMETERS[@]}"} \
 	                "$@"

Without this, nix-build -A lispPackage.trivia fails, but with it it passes. Any idea what's going on here, @7c6f434c?

Unhandled SB-INT:SIMPLE-FILE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING
                                                {10008B8083}>:
  Couldn't load
  "/nix/store/35qlvb1dgvcjljh2v7i4m5nzk6abd5bv-cl-wrapper-script/lib/common-lisp/asdf/build/asdf.fasl":
  file does not exist.

Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {10008B8083}>
0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<SB-INT:SIMPLE-FILE-ERROR "~@<Couldn't load ~S: file does not exist.~@:>" {10015AC663}> #<unused argument> :QUIT T)
1: (SB-DEBUG::RUN-HOOK *INVOKE-DEBUGGER-HOOK* #<SB-INT:SIMPLE-FILE-ERROR "~@<Couldn't load ~S: file does not exist.~@:>" {10015AC663}>)
2: (INVOKE-DEBUGGER #<SB-INT:SIMPLE-FILE-ERROR "~@<Couldn't load ~S: file does not exist.~@:>" {10015AC663}>)
3: (ERROR SB-INT:SIMPLE-FILE-ERROR :PATHNAME "/nix/store/35qlvb1dgvcjljh2v7i4m5nzk6abd5bv-cl-wrapper-script/lib/common-lisp/asdf/build/asdf.fasl" :FORMAT-CONTROL "~@<Couldn't load ~S: file does not exist.~@:>" :FORMAT-ARGUMENTS ("/nix/store/35qlvb1dgvcjljh2v7i4m5nzk6abd5bv-cl-wrapper-script/lib/common-lisp/asdf/build/asdf.fasl"))
4: (LOAD "/nix/store/35qlvb1dgvcjljh2v7i4m5nzk6abd5bv-cl-wrapper-script/lib/common-lisp/asdf/build/asdf.fasl" :VERBOSE NIL :PRINT NIL :IF-DOES-NOT-EXIST T :EXTERNAL-FORMAT :DEFAULT)
5: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LOAD "/nix/store/35qlvb1dgvcjljh2v7i4m5nzk6abd5bv-cl-wrapper-script/lib/common-lisp/asdf/build/asdf.fasl") #<NULL-LEXENV>)
6: (EVAL (LOAD "/nix/store/35qlvb1dgvcjljh2v7i4m5nzk6abd5bv-cl-wrapper-script/lib/common-lisp/asdf/build/asdf.fasl"))
7: (SB-IMPL::PROCESS-EVAL/LOAD-OPTIONS ((:EVAL . "(load \"/nix/store/35qlvb1dgvcjljh2v7i4m5nzk6abd5bv-cl-wrapper-script/lib/common-lisp/asdf/build/asdf.fasl\")") (:EVAL . #<(SIMPLE-ARRAY CHARACTER (273))
  (progn
    (setf asdf:*source-registry-parameter*
      '(:source-registry
        (:tree "/nix/store/nh9ybjfrg3xwjhl79nkqslkppds3scfm-lisp-closer-mop-20191227-git/lib/common-lisp/closer-mop")
    ... {100157848F}>) (:EVAL . #<(SIMPLE-ARRAY CHARACTER (216)) (progn
      (asdf:compile-system :closer-mop)
(asdf:load-system :closer-mop)
(asdf:operate (quote asdf::compile-bundle-op) :closer-mop)
(ignore-errors (asdf:operate (quote asdf::deploy-asd-op) :close... {100157891F}>) (:EVAL . "(quit)") (:QUIT)))
8: (SB-IMPL::TOPLEVEL-INIT)
9: ((FLET SB-UNIX::BODY :IN SAVE-LISP-AND-DIE))

The fasl file is indeed absent.

To be clear, I tested this on Darwin, which involved applying #94919 too, but I expect the failure to be the same on Linux.

doronbehar · 2020-09-24T19:49:08Z

I'm all up to discarding old aliases (#89264 & #88714). But, I think in this case you don't have a choice but keep some kind of alias, to keep packages from failing to build. Quoting @7c6f434c 's commit message:

sbcl: reinstate 2.0.0; add sbcl_2_0_1 for 2.0.1

2.0.1 is too fresh for current Quicklisp (for example, CFFI fails)

1f0b4b1

I can imagine how you don't like that alias, and I feel you. What I'd do is update the sbcl_2_0_2 alias, and make all packages that need the old version use it explicitly - make the packages that need the old sbcl "the exception". Just like in https://github.com/NixOS/nixpkgs/pull/89731/commits. You probably don't have a choice, but test the build of every package using sbcl directly.

As a bonus, I would also discard the almost copy pasted 2.0.0.nix file in favor of an override to the latest version.

7c6f434c · 2020-09-24T20:14:23Z

I'm all up to discarding old aliases (#89264 & #88714). But, I think in this case you don't have a choice but keep some kind of alias, to keep packages from failing to build. Quoting @7c6f434c 's commit message: ``` sbcl: reinstate 2.0.0; add sbcl_2_0_1 for 2.0.1 2.0.1 is too fresh for current Quicklisp (for example, CFFI fails) ```

To be fair, maybe rerunning full Quicklisp update will give us versions that survive 2.0.7 no worse than the current ones work with 2.0.1. I hope so, but I fail to get around to checking it…

purcell · 2020-10-17T01:24:04Z

To be fair, maybe rerunning full Quicklisp update will give us versions that survive 2.0.7 no worse than the current ones work with 2.0.1. I hope so, but I fail to get around to checking it…

Are there any docs or pointers relating to how to perform such an update and evaluate its success?

7c6f434c · 2020-10-17T08:34:09Z

> To be fair, maybe rerunning full Quicklisp update will give us versions that survive 2.0.7 no worse than the current ones work with 2.0.1. I hope so, but I fail to get around to checking it… Are there any docs or pointers relating to how to perform such an update and evaluate its success?

lisp-modules directory contains a minimalistic readme; the list of systems in the txt file can be edited to pick what is packaged. I would recommend updating the version of quicklisp package and using SBCL 2.0.7, as 2.0.8 has enabled a check that some systems failed and might still fail (specifically promoted :type integer :initform nil to a full warning) Dunno, maybe if I have already written off a block of time as «mainly NixCon» I should declare a breakout room for Finally Doing This at NixCon Hackday tomorrow… are you interested to chat about this in that format (and hopefully get the things to converge in the process)? I guess this, Nyxt, and checking Aarch64 status of SBCL could be done…

purcell · 2020-10-17T23:55:56Z

Doing This at NixCon Hackday tomorrow… are you interested to chat about this in that format

Yes, generally keen to chat/collaborate, but I'm in New Zealand and that will be Monday for me, a work day.

7c6f434c · 2020-10-18T07:29:04Z

Now I want a bot that will remind me next Thursday, after three more talks at non-Nix-related places, to try to see if we have a bit of time next weekend that is also timezone-compatible…

bqv · 2020-10-18T15:16:16Z

lisp-modules directory contains a minimalistic readme; the list of systems in the txt file can be edited to pick what is packaged.

I wonder if anyone has even tried that recently? Every attempt I've had, that readme's instructions simply don't work, one way or another

omasanori · 2020-10-23T14:39:45Z

Now I want a bot that will remind me next Thursday

Probably too late but I hope it is better than never, @7c6f434c?

7c6f434c · 2020-10-23T15:19:19Z

> Now I want a bot that will remind me next Thursday Probably too late but I hope it is better than never, @7c6f434c?

Hmm, what is your local time now again? It is not too late to agree to some slot that is still in the future this weekend!

omasanori · 2020-10-23T15:48:11Z

Ah, I see, you meant Thursday == before the weekend anywhere on earth, did you?

(Off-topic: I am in Japan (+9:00) BTW, so relatively near NZ, actually.)

7c6f434c · 2020-10-23T17:28:46Z

@omasanori Yes, to plan for some times which is Friday evening in one of the places or just full weekend in both

So, @omasanori or @purcell — are you interested this weekend?

omasanori · 2020-10-23T18:02:10Z

Yes, better Lisp support is definitely desired to me, though I am not sure I can help you much.
I will be available from next (Saturday in Japan) 10:00 JST (1:00 UTC; Friday 17:00 PST) to 12:00 JST (3:00 UTC; 19:00 PST) and/or from 17:00 (8:00 UTC; Saturday 0:00 PST) to 19:00 JST (10:00 UTC; 2:00 PST) at #nix channel.
Also I can allocate some hours in Sunday if preferred.

7c6f434c · 2020-10-23T18:21:12Z

Yes, better Lisp support is definitely desired to me, though I am not sure I can help you much.

Mainly need someone to keep me accountable to actually complete that thing, and to say (and write down) that I am doing not the things described in the docs. I assume you have reasonable knowledge of Common Lisp and at least regular user knowledge of Nix, not knowing the specifics of Lisp packaging and sincere annoyance by difference is a plus, actually. I guess it works best if we join a call so I can share the window with the update work going on.

I will be available from next (Saturday in Japan) 10:00 JST (1:00 UTC; Friday 17:00 PST) to 12:00 JST (3:00 UTC; 19:00 PST) and/or from 17:00 (8:00 UTC; Saturday 0:00 PST) to 19:00 JST (10:00 UTC; 2:00 PST) at #nix channel.

#nixos I assume? 01:00 to 03:00 UTC sounds not exactly like the time I want to push to Nixpkgs (I am in Germany, so this time is when I planned to sleep); I will try to ping you for the 08:00 UTC slot then.

Also I can allocate some hours in Sunday if preferred.

I guess if everything goes well it shouldn't be needed, and if it doesn't we'll see…

omasanori · 2020-10-23T19:52:24Z

(...)
I guess it works best if we join a call so I can share the window with the update work going on.

Agreed.

#nixos I assume? 01:00 to 03:00 UTC sounds not exactly like the time I want to push to Nixpkgs (I am in Germany, so this time is when I planned to sleep); I will try to ping you for the 08:00 UTC slot then.

OK, see you then!

7c6f434c · 2020-10-24T13:21:21Z

Sorry, maybe a bit unfriendly of me to ignore this then doing the same stuff in a slightly different way, but I ended up doing an integrated bump-all with exactly the changes needed.

Fixed via #101544

ofborg bot added the 8.has: clean-up This PR removes packages or removes other cruft label Aug 8, 2020

ofborg bot requested a review from 7c6f434c August 8, 2020 02:10

ofborg bot added 10.rebuild-darwin: 1-10 This PR causes between 1 and 10 packages to rebuild on Darwin. 10.rebuild-linux: 101-500 This PR causes between 101 and 500 packages to rebuild on Linux. labels Aug 8, 2020

7c6f434c mentioned this pull request Oct 18, 2020

Add several missing lisp packages for nyxt-browser #92763

Closed

7c6f434c mentioned this pull request Oct 24, 2020

sbcl: 2.0.0 -> 2.0.8; add 2.0.9; lispPackages: regenerate #101544

Merged

10 tasks

7c6f434c closed this Oct 24, 2020

Uh oh!

Conversation

purcell commented Aug 8, 2020

Motivation for this change

Things done

Uh oh!

purcell commented Aug 8, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

doronbehar commented Sep 24, 2020

Uh oh!

7c6f434c commented Sep 24, 2020 via email

Uh oh!

purcell commented Oct 17, 2020

Uh oh!

7c6f434c commented Oct 17, 2020 via email

Uh oh!

purcell commented Oct 17, 2020

Uh oh!

7c6f434c commented Oct 18, 2020

Uh oh!

bqv commented Oct 18, 2020

Uh oh!

omasanori commented Oct 23, 2020

Uh oh!

7c6f434c commented Oct 23, 2020 via email

Uh oh!

omasanori commented Oct 23, 2020

Uh oh!

7c6f434c commented Oct 23, 2020

Uh oh!

omasanori commented Oct 23, 2020

Uh oh!

7c6f434c commented Oct 23, 2020 via email

Uh oh!

omasanori commented Oct 23, 2020

Uh oh!

7c6f434c commented Oct 24, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

purcell commented Aug 8, 2020 •

edited

Loading