chore(3p/lisp): Unvendor alexandria and use nixpkgs sources r/3254

Change-Id: Idee3cb18ac42bd820d87aac0c68206436c1f4691
Reviewed-on: https://cl.tvl.fyi/c/depot/+/4338
Autosubmit: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>

1 files changed, 0 insertions, 52 deletions

diff --git a/third_party/lisp/alexandria/README b/third_party/lisp/alexandria/README
deleted file mode 100644
index a5dae9ed1ac7..000000000000
--- a/third_party/lisp/alexandria/README
+++ /dev/null
@@ -1,52 +0,0 @@
-Alexandria is a collection of portable public domain utilities that
-meet the following constraints:
-
- * Utilities, not extensions: Alexandria will not contain conceptual
-   extensions to Common Lisp, instead limiting itself to tools and
-   utilities that fit well within the framework of standard ANSI
-   Common Lisp. Test-frameworks, system definitions, logging
-   facilities, serialization layers, etc. are all outside the scope of
-   Alexandria as a library, though well within the scope of Alexandria
-   as a project.
-
- * Conservative: Alexandria limits itself to what project members
-   consider conservative utilities. Alexandria does not and will not
-   include anaphoric constructs, loop-like binding macros, etc.
-
- * Portable: Alexandria limits itself to portable parts of Common
-   Lisp. Even apparently conservative and useful functions remain
-   outside the scope of Alexandria if they cannot be implemented
-   portably. Portability is here defined as portable within a
-   conforming implementation: implementation bugs are not considered
-   portability issues.
-
-Homepage:
-
-  http://common-lisp.net/project/alexandria/
-
-Mailing lists:
-
-  http://lists.common-lisp.net/mailman/listinfo/alexandria-devel
-  http://lists.common-lisp.net/mailman/listinfo/alexandria-cvs
-
-Repository:
-
-  git://gitlab.common-lisp.net/alexandria/alexandria.git
-
-Documentation:
-
-  http://common-lisp.net/project/alexandria/draft/alexandria.html
-
-  (To build docs locally: cd doc && make html pdf info)
-
-Patches:
-
-  Patches are always welcome! Please send them to the mailing list as
-  attachments, generated by "git format-patch -1".
-
-  Patches should include a commit message that explains what's being
-  done and /why/, and when fixing a bug or adding a feature you should
-  also include a test-case.
-
-  Be advised though that right now new features are unlikely to be
-  accepted until 1.0 is officially out of the door.