| 4 Jan 2026 |
 Randy Eckenrode | nix build github:NixOS/nixpkgs?ref=staging-next-25.11#man also succeeds. | 14:19:01 |
| Randy Eckenrode | $ nix-info -m
- system: `"aarch64-darwin"`
- host os: `Darwin 25.2.0, macOS 26.2`
- multi-user?: `yes`
- sandbox: `no`
- version: `nix-env (Lix, like Nix) 2.93.3
System type: aarch64-darwin
Additional system types: x86_64-darwin
Features: gc, signed-caches
System configuration file: /etc/nix/nix.conf
User configuration files: /Users/reckenrode/.config/nix/nix.conf:/Users/reckenrode/.nix-profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/reckenrode/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf
Store directory: /nix/store
State directory: /nix/var/nix
Data directory: /nix/store/5ayhl0gp33jw4vsnn5yhmk01apbvr3c4-lix-2.93.3/share`
- channels(root): `"nixpkgs"`
- nixpkgs: `/etc/nix/inputs/nixpkgs`
| 14:19:43 |
|  risson changed their profile picture. | 14:35:56 |
 emily | we'd need to see the log file if it doesn't reproduce | 15:29:56 |
| Randy Eckenrode | Is exit status 139 a segmentation fault? What could be causing man to crash? | 15:37:56 |
| Randy Eckenrode | Can we get console logs from Hydra? That might have a stack trace. | 15:38:13 |
| Randy Eckenrode | * (Just Googled it.) Is exit status 139 a segmentation fault? What could be causing man to crash? | 15:39:05 |
 vcunat | I'll log in and see what I can get. | 16:15:32 |
| vcunat | The man's log file doesn't seem helpful:
System information (uname -a): Darwin 25.2.0 Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:55 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T8103 arm64 arm
.. contents:: :depth: 2
FAIL: man1/manconv.1
====================
man -E UTF-8 -l ./man1/manconv.1 failed with exit status 139 and error output:
FAIL man1/manconv.1 (exit status: 139)
FAIL: man1/whatis.1
===================
man -E UTF-8 -l ./man1/whatis.1 failed with exit status 139 and error output:
FAIL man1/whatis.1 (exit status: 139)
FAIL: man5/manpath.5
====================
man -E UTF-8 -l ./man5/manpath.5 failed with exit status 139 and error output:
FAIL man5/manpath.5 (exit status: 139)
| 16:23:50 |
| vcunat | No code-signing logs, if I'm holding it right. | 16:26:22 |
| Randy Eckenrode | I don’t think this is code-signing. I think this is a plain crash. But why? Is the build directory still there? | 16:29:44 |
| Randy Eckenrode | Does running the command manually crash? | 16:29:55 |
|  Moraxyc changed their profile picture. | 16:41:17 |
| Moraxyc changed their profile picture. | 16:43:27 |
| vcunat | 🤔 the /nix/store path doesn't seem to have remained after --keep-failed build. | 16:43:37 |
| vcunat | And the file from the temporary directory is looking for libmandb-*.dylib on that path. | 16:44:26 |
| Randy Eckenrode | src/man is a script. It tries to set up DYLD_LIBRARY_PATH to point to the dylibs in the build. Is something not right with that? | 16:54:58 |
| Randy Eckenrode | This is what it looks like for me after I run checkPhase to generate it.
# Add our own library path to DYLD_LIBRARY_PATH
DYLD_LIBRARY_PATH="/var/folders/yf/1c0ncp6s14n1sb_87_640lsm0000gn/T/nix-shell.zQPn4f/man-db-2.13.1/libdb/.libs:/var/folders/yf/1c0ncp6s14n1sb_87_640lsm0000gn/T/nix-shell.zQPn4f/man-db-2.13.1/lib/.libs:$DYLD_LIBRARY_PATH"
# Some systems cannot cope with colon-terminated DYLD_LIBRARY_PATH
# The second colon is a workaround for a bug in BeOS R4 sed
DYLD_LIBRARY_PATH=`$ECHO "$DYLD_LIBRARY_PATH" | /nix/store/4s0iv69d8m17v0bz3y5vry5byr3ml8vb-gnused-4.9/bin/sed 's/::*$//'`
export DYLD_LIBRARY_PATH
if test "$libtool_execute_magic" != "%%%MAGIC variable%%%"; then
# Run the actual program with our arguments.
func_exec_program ${1+"$@"}
fi
| 16:55:42 |
| vcunat | Ah, src/man | 16:57:04 |
| vcunat | I was running the unwrapped binary. | 16:57:12 |
| vcunat | Had to set DYLD manually. | 16:57:17 |
| vcunat | But then it's failing to find the config file. | 16:57:29 |
| vcunat | And if I specify that, it's failing to find executables (nroff) | 16:57:46 |
| vcunat | 🤔
src/man -C ./src/man_db.conf ./man/man5/manpath.5
man: command exited with status 255: /nix/store/lkgb48k0pifhrknkmhgc1379i2aa8r9a-man-db-2.13.1/libexec/man-db/zsoelim | /nix/store/lkgb48k0pifhrknkmhgc1379i2aa8r9a-man-db-2.13.1/libexec/man-db/manconv -f UTF-8:ISO-8859-1 -t ANSI_X3.4-1968//IGNORE | tbl | nroff -mandoc -rLL=222n -rLT=222n -Tascii
| 16:58:50 |
| vcunat | * And if I specify that, it's failing to find executables (nroff) EDIT: ah no, executables get found by the wrapped one. | 16:59:40 |
| vcunat | That doesn't look like the same error, though. | 17:00:00 |
| vcunat | Also, the machine did manage to succeed the whole build once during my debugging 😅 | 17:00:42 |
| vcunat | Could it be this log line?
XprotectService: [com.apple.xprotect:xprotect] File /nix/var/nix/builds/nix-46977-2307007369/man-db-2.13.1/src/.libs/whatis failed on loadCmd /nix/store/lkgb48k0pifhrknkmhgc1379i2aa8r9a-man-db-2.13.1/lib/man-db/libmandb-2.13.1.dylib (loadCmd resolved to: (path not found), bundleURL: (null))
| 17:12:55 |
| Randy Eckenrode | That seems like DYLD_LIBRARY_PATH isn’t working. | 17:14:40 |
| vcunat | At the very least it looks like the build system is trying to run some executables incorrectly wrapped. | 17:14:48 |
