| 15 Dec 2025 |
 Ihar Hrachyshka | Duration: 8s - good candidate to debug if it's also 100% reproducible | 20:36:37 |
 vcunat | Yes, it does reproduce on a different machine. | 20:37:03 |
| vcunat | Which is how I found that it's a SIGKILL. | 20:37:10 |
 Randy Eckenrode |
checking for a BSD-compatible install...
As an aside, GNU coreutils install is not actually BSD-compatible. BSD install supports -l to create symlinks. GNU install does not.
| 20:40:35 |
 emily | it looks like that package wraps Python | 20:44:42 |
| emily | perhaps it is the Python derivation that needs rebuilding 🫠 | 20:44:49 |
| emily | maybe nix run nixpkgs#bash -- -x /nix/store/a8d6nlfwqi3wzllvbxvjgx0316zxah3v-itstool-2.0.7/bin/itstool would be enlightening | 20:45:39 |
| vcunat | /nix/store/bb2dww8j5afza69c8drndbxcz6b1cf2v-python3-3.13.9/bin/python3.13 --help
This succeeds.
| 20:45:52 |
| emily | I wonder why this previously extremely rare bug now seems to be happening often | 20:46:01 |
| emily | … | 20:46:32 |
| emily | OS upgrade, I bet. | 20:46:34 |
| emily | on the builders. | 20:46:40 |
| vcunat | --help works but running with the python script does not. | 20:47:21 |
| vcunat | and that's where the SIGKILL comes. The bash parts seem to pass just fine. | 20:47:44 |
| Ihar Hrachyshka | i still have machines on 15 and 26, I could check if it makes a difference | 20:48:49 |
| Ihar Hrachyshka | (later today) | 20:48:57 |
| emily | debugging | 20:52:26 |
| emily | vcunat:
shion:~
❭ log show --last 1h --predicate 'm:"CODE SIGNING"'
…
2025-12-15 20:55:10.515462+0000 0xff72dd Default 0x0 0 0 kernel: CODE SIGNING: cs_invalid_page(0x101594000): p=73322[python3.13] final status 0x23020200, denying page sending SIGKILL
2025-12-15 20:55:10.515472+0000 0xff72dd Default 0x0 0 0 kernel: CODE SIGNING: process 73322[python3.13]: rejecting invalid page at address 0x101594000 from offset 0x0 in file "/nix/store/ia2jjsl9ggscyy6ia8rn4k6pqd2zj12l-libxml2-2.15.1-py/lib/python3.13/site-packages/libxml2mod.cpython-313-darwin.so" (cs_mtime:1.0 == mtime:1.0) (signed:1 validated:1 tainted:1 nx:0 wpmapped:0 dirty:0 depth:0)
| 20:56:38 |
| emily | so, it's libxml2. | 20:56:54 |
| emily | I'm a bit worried by seeing two of these in one cycle, though… and I expect libxml2 might throw away quite some rebuilds, if only the Python stuff is broken. | 20:57:12 |
| vcunat | libxml2 rebuilds darwin stdenv... | 20:58:39 |
| vcunat | And this is on staging-next-25.11 which I was about merge to release-25.11 in minutes. | 20:59:11 |
| emily | the earlier libxml2s do | 20:59:21 |
| emily | I think the latest libxml2 isn't part of the stdenv. | 20:59:27 |
| vcunat | These are usually not trivial to distinguish. | 20:59:59 |
| vcunat | Though it this case it would be worth a try if the alternative would be to rebuild everything. | 21:00:41 |
| emily | something like env.REBUILD_HACK = lib.optionalString (stdenv.name == "stdenv-darwin") "sigh";, I think? | 21:00:57 |
| emily | oh: | 21:01:30 |
| emily | pythonSupport ? false,
| 21:01:31 |
| emily | we can probably just condition on that. | 21:01:37 |
