| 4 Jan 2026 |
 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 |
| vcunat | I see a few others like that. | 17:14:56 |
| vcunat | (and I wasn't doing anything else myself during that time) | 17:15:12 |
| vcunat | In general these path shenanigans are why I prefer to run most tests after the installation step (well, on Linux). | 17:16:40 |
| vcunat | There's still no explanation about the non-determinism of this. | 17:18:20 |
| 6 Jan 2026 |
 spewdins | Hi.
I need to use wayland on macOS.
I am building a wayland compositor for macOS.
Thus, I need libwayland, and wayland scanner, protocols. This pr I recently did should likely fix macOS builds of libwayland.
https://github.com/NixOS/nixpkgs/pull/477359/files#diff-cf867da35ed61431a969f5710278d34b932bd1d61ab9e52befae6ea0f69879be
but, I am not certain I've properly made the change as others might not like it.
Can somebody help me here? | 06:14:53 |
 emily | have you tried upstreaming it? | 06:29:50 |
| emily | we don't like to carry big/invasive patches downstream like this | 06:30:03 |
| emily | they inevitably bitrot and this sort of thing should really go through upstream code review | 06:30:20 |
| spewdins | uh well, the upstream mr from gitlab is what the darwin.patch is generated from
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/481/diffs | 06:50:18 |
| spewdins | so, it will be 1:1 if the mr is merged right now, to upstream wayland in its current state | 06:50:47 |
