feat(nix/buildLisp): re-enable CCL r/4546

The problem went away once again, let's see how long it'll last this time.

As it turns out, CCL has a Unicode Standard conforming string
implementation that doesn't allow the use of (lone) surrogate code
points, requiring us to disable a test in cl-json which tested the
behavior of en- and decoding of such a (technically illegal) string.

Change-Id: I8bfa482934bbf94f86cecdde02d5c3d4e77950a5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6204
Tested-by: BuildkiteCI
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: tazjin <tazjin@tvl.su>

1 files changed, 2 insertions, 2 deletions

diff --git a/third_party/lisp/cl-json.nix b/third_party/lisp/cl-json.nix
index 8dbb1567acb3..6b82fac772d4 100644
--- a/third_party/lisp/cl-json.nix
+++ b/third_party/lisp/cl-json.nix
@@ -8,8 +8,8 @@ let
   src = pkgs.fetchFromGitHub {
     owner = "sternenseemann";
     repo = "cl-json";
-    rev = "479685029c511cb2011f2f2a99ca6c63aa2e4865";
-    sha256 = "1663xlzb0wj6kd0wy2cmhafrwip7vy0wlfckc519aj9j18aak5ja";
+    rev = "c059bec94e28a11102a994d6949e2e52764f21fd";
+    sha256 = "0l07syw1b1x2zi8kj4iph3rf6vi6c16b7fk69iv7x27wrdsr1qwj";
   };
 
   getSrcs = subdir: map (f: src + ("/" + subdir + "/" + f));