To avoid the need for two different versions of plan9port in the CI
pipeline, just move the plumbing sanity check into installCheckPhase.
For local iteration you'd have a plumber running anyways, so the short
build time of the plumb derivation isn't really a necessity.
Change-Id: Ib0ba5fa2d8107530fb7d1144cf7395f4f5a3cd12
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13035
Tested-by: BuildkiteCI
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: sterni <sternenseemann@systemli.org>
plan9port completely ignores XCompose because it has its own compose
mechanism (which is mapped to the same key). The sequences are defined
in /lib/keyboard and need to be compiled in.
Support for the BQN unicode characters is achieved by generating the
necessary lines for /lib/keyboard from the .inputrc (for GNU readline)
that is part of mlochbaum/BQN (simply because that file is somewhat
parseable and stores the sequences in ASCII, contrary to .XCompose).
This is implemented by a small BQN script which is executed in
postPatch.
All usual sequences are supported except those that map to the second
ASCII character of the sequence. These exist to keep certain characters
typeable in other input system. Thanks to the explicit compose key,
Plan 9 doesn't have this problem.
Change-Id: I590c03fd69a2aae3cbbbd39ebcbce6cec0418b50
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13034
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Autosubmit: sterni <sternenseemann@systemli.org>
This is equivalent to
<2e4032c31b>,
with the addition of patchesFromDir to assemble a list of patches.
Import into depot since I'm interested in adding some depot specific
configuration and tools to (mainly) acme that doesn't make sense to
track outside of depot. Since persisting user configuration and tooling
with plan9port is annoying, it's easier compiling it in to begin with.
Change-Id: I565a285368485c7ce1d5caa7baa87a8ca86abcb7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/13033
Tested-by: BuildkiteCI
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: sterni <sternenseemann@systemli.org>
