-
-
Notifications
You must be signed in to change notification settings - Fork 15.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sbcl: 2.0.2 -> 2.0.7, eliminate risky alias scheme #94913
Conversation
- 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
Hmmm, this seems to cause the 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,
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:
I can imagine how you don't like that alias, and I feel you. What I'd do is update the 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. |
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…
|
Are there any docs or pointers relating to how to perform such an update and evaluate its success? |
> 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…
|
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… |
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 |
Probably too late but I hope it is better than never, @7c6f434c? |
> 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!
|
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. |
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…
|
Agreed.
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 |
Motivation for this change
sbcl
, they should get the latest patchedversion in the major series: the pinning of
sbcl
to 2.0.0 wasundesirable and potentially risky
unpatched release in the current series: the derivation can
trivially be overridden by users who really require such a build
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)