| 4 Jan 2026 |
 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 |
| spewdins | any other changes from mr481 could be generated again to replace darwin.patch with the updated mr changes from mr481.
and, if it does become merged, we could always just remove the patch anyway | 06:52:22 |
| spewdins | I guess, in this case, I'm fixing previous bitrot | 07:03:04 |
 raitobezarius | Is there macOS folks who could take a look at https://github.com/NixOS/nixpkgs/pull/476848 ? | 10:09:53 |
 Alyssa Ross | No it won't, it'll be 1:1 to an unmerged upstream PR | 16:05:29 |
