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.

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.

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?

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.

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…

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

Now I want a bot that will remind me next Thursday

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

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.)

@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?

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.

(...)
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!

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