seg fault: Local build setup cannot be completed

[spamwax]

this is what I get after cd'ing into workspace

[1/0/1 copied (181.8/181.8 MiB), 28.8 MiB DL] fetching source from https://cache.nixos.orgdirenv: ([/nix/store/55vva1q4lhw2m62vvzzm2z26wfkpb430-direnv-2.35.0/bin/direnv export bash]) is taking a while to execute. Use CTRL-C to give up.
error: builder for '/nix/store/m953cmzz6ky2104h5clkz6la9sllhpv0-python3.12-tree-sitter-0.23.2.drv' failed with exit code 139;
       last 25 log lines:
       > shrinking RPATHs of ELF executables and libraries in /nix/store/mcmhkdrpv0hl28ar16ki2c2a3dvc2g78-python3.12-tree-sitter-0.23.2-dist
       > checking for references to /tmp/nix-build-python3.12-tree-sitter-0.23.2.drv-0/ in /nix/store/mcmhkdrpv0hl28ar16ki2c2a3dvc2g78-python3.12-tree-sitter-0.23.2-dist...
       > patching script interpreter paths in /nix/store/mcmhkdrpv0hl28ar16ki2c2a3dvc2g78-python3.12-tree-sitter-0.23.2-dist
       > Executing pythonRemoveTestsDir
       > Finished executing pythonRemoveTestsDir
       > Running phase: installCheckPhase
       > no Makefile or custom installCheckPhase, doing nothing
       > Running phase: pythonCatchConflictsPhase
       > Running phase: pythonRemoveBinBytecodePhase
       > Running phase: pythonImportsCheckPhase
       > Executing pythonImportsCheckPhase
       > Check whether the following modules can be imported: tree_sitter
       > Running phase: pytestCheckPhase
       > Executing pytestCheckPhase
       > ============================= test session starts ==============================
       > platform linux -- Python 3.12.8, pytest-8.3.3, pluggy-1.5.0
       > rootdir: /tmp/nix-build-python3.12-tree-sitter-0.23.2.drv-0/source
       > configfile: pyproject.toml
       > collected 57 items                                                             
       >
       > tests/test_language.py .............                                     [ 22%]
       > tests/test_lookahead_iterator.py Fatal Python error: Segmentation fault
       >
       > Current thread 0x0000f1f820e4df20 (most recent call first):
       >   File "/tmp/nix-build-python3.12-tree-sitter-0.23.2.drv-0/source/tests/test_lookahead_iterator.py", line 15 in /nix/store/y0nq24jmia6ln93l7sp1br3dv2xndq7n-pytest-check-hook/nix-support/setup-hook: line 30: 12949 Segmentation fault      /nix/store/66pn6ysmvx675061xaq2vz93s9vdc5p4-python3-3.12.8/bin/python3.12 -m pytest
       For full logs, run 'nix log /nix/store/m953cmzz6ky2104h5clkz6la9sllhpv0-python3.12-tree-sitter-0.23.2.drv'.

[urob]

What system and architecture are you on?

(Someone else found that on Darwin rebooting might be necessary after the initial set up, might be worth a try even if it's a long shot and normally not necessarily)

[urob]

In either case, try commenting keymap-drawer on line 27 in the flake for now. That should get past this issue.

[spamwax]

I tried it on Debian, and Debian on Docker. Same results.
I ended up doing something similar to your suggestion, thanks

[urob]

Strange. Are you on x86_64 or on arm? Are you using the same lock file as I? I am running on x86_64-linux (also Debian but that shouldn't matter) and am building without issues...

[urob]

Instead of entirely disabling keymap-drawer you could also revert baaa607, which is where I added the build-dependency on tree-sitter.

[spamwax]

Strange. Are you on x86_64 or on arm? Are you using the same lock file as I? I am running on x86_64-linux (also Debian but that shouldn't matter) and am building without issues...

Tried it on both. arm was on the docker. x86_64 was on a Linux server and arm was on macOS

I believe I was using the same lock file since I just cloned your repo and started with direnv allow and just init

[urob]

Tried it on both. arm was on the docker. x86_64 was on a Linux server and arm was on macOS

Are you sure you tried on Intel? I added a test suite for the build environment for all systems. The tests replicate the issue you run into for aarch64-linux but successfully build on all other systems.

Notes:

• The issue on aarch64-linux seems to be an upstream bug, tracked here.

• There was another upstream bug that prevented building on aarch64-darwin, which I fixed in the latest commit to my fork of zephyr-nix. You may need to update your flake.lock to get this fix (just upgrade-sdk or download the latest flake.lock from this repo).

[urob]

As a temporary workaround I disabled keymap-drawer by default on aarch64-linux in 18720e9.

All tests are passing now for all systems (https://github.com/urob/zmk-config/actions/runs/12891474760).

[spamwax]

thanks for the updates.
yes it was on intel:

$ cat /sys/devices/cpu/caps/pmu_name
skylake
$ lscpu
Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          39 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   12
  On-line CPU(s) list:    0-11
Vendor ID:                GenuineIntel
  Model name:             Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz

I will give it another try

[spamwax]

ok, it successfully built the firmware. how do i test the keymap-drawer? or is it disabled at the moment?

[urob]

ok, it successfully built the firmware. how do i test the keymap-drawer? or is it disabled at the moment?

It's disabled on aarch64-linux but should work on all other systems including you Intel Linux. On those system, it's available anywhere in the workspace.

$ which keymap
/nix/store/20g7gk2qwy7zi2xk3kry81y9ks9vbfal-keymap-drawer-0.20.0/bin/keymap

The two main commands are keymap parse and keymap draw (see the official documentation for details). Depending on how much changes you made to the structure of my repo, you might also be able to use my just recipe:

$ just draw

This will parse base.keymap, do some custom post-processing to draw all combos on a separate layer, and then draw the svg and save it inside draw/. In either case, it might be useful to inspect my config file in draw/config.yaml to see how to make it work alongside the helper macros.

[spamwax]

ok, thanks.
BTW, does this local building support adding 'advance' options to build.yml or west.yml, such as snippets=zmk-usb-logging or cmake-args: -D... or they should be done only github actions?

[urob]

does this local building support adding 'advance' options to build.yml or west.yml, such as snippets=zmk-usb-logging or cmake-args: -D... or they should be done only github actions?

The just build recipe currently supports the shield, board and snippet properties of build.yml. The build environment itself is exactly the same used as by the Github Action runner. So adding cmake-args is just a matter of tweaking the just build recipe slightly. (Or one could run west build by hand).

In terms of west.yml, we are pulling in the ZMK and Zephyr modules exactly the same way as the Github Action runner does. So things should behave exactly the same way.