| 11 Nov 2025 |
 Grimmauld (any/all) | oh yeah there is stuff like postBuild, meta, outputs and passthru and a whole mess of other things:
https://github.com/NixOS/nixpkgs/blob/addd85b5d06ea90d5a7923956a65baf96bcd1e9f/pkgs/tools/typesetting/tex/texlive/build-tex-env.nix#L414-L480 | 11:28:08 |
 ElvishJerricco | ok, so unless anyone wants to go sifting through all those instances and finding a better way to do them, we should just keep the override | 11:28:45 |
| Grimmauld (any/all) |
# no indent for git diff purposes
treewide nixfmt says hello
| 11:28:54 |
| ElvishJerricco | so the thing vcunat and I did is probably the best thing to do for now | 11:28:58 |
| Grimmauld (any/all) | i mean there is only 3 instances | 11:30:08 |
| Grimmauld (any/all) | its in a let...in block and not reexported | 11:30:23 |
| Grimmauld (any/all) | but yeah, do the workaround | 11:30:54 |
| ElvishJerricco | yea I mean it looks like we'd just end up doing the overrideAttrs in those 3 sites instead, so there's no real benefit to trying to get rid of it | 11:31:29 |
| Grimmauld (any/all) | or alternatively hand-roll a pseudo-buildenv using stdenv.mkDerivation that has the power to do these things | 11:32:22 |
| Grimmauld (any/all) | not sure either is better | 11:32:42 |
| ElvishJerricco | that seems like more code / effort for no benefit | 11:33:42 |
| ElvishJerricco | vcunat: you want to author the commit / PR or do you want me to? | 11:35:02 |
 vcunat | I don't care really. | 11:35:24 |
| vcunat | But I'm relatively busy today. | 11:35:30 |
| vcunat | (with work stuff) | 11:35:36 |
| vcunat | So either way I won't have capacity for longer discussion about the changes. | 11:36:53 |
| ElvishJerricco | https://github.com/NixOS/nixpkgs/pull/460639 | 11:39:43 |
 winston | I was looking into the arrow-cpp test failure on darwin, strangely the binary of the tests that fail end up with two versions of protobuf in the dynamic linker paths
v31, which is what we want in the derivation, v33 coming from somewhere else
whats stranger is that master also shows v32, but it doesn't have the same runtime error
I compiled it with -fsanitize=address and that pointed me into this direction: https://github.com/protocolbuffers/protobuf/issues/5290
https://gist.github.com/nekowinston/f6cbea976ba4605f318b9329d96a0544 | 11:52:38 |
| winston | * I was looking into the arrow-cpp test failure on darwin, strangely the binary of the tests that fail end up with two versions of protobuf in the dynamic linker paths
v31, which is what we want in the derivation, v33 coming from somewhere else
whats stranger is that master also shows v31+v32, but it doesn't have the same runtime error
I compiled it with -fsanitize=address and that pointed me into this direction: https://github.com/protocolbuffers/protobuf/issues/5290
https://gist.github.com/nekowinston/f6cbea976ba4605f318b9329d96a0544 | 11:55:11 |
 Wolfgang Walther | PostgreSQL releases are due this week, fixing two CVEs. I have currently split them up as:
- All server updates in https://github.com/NixOS/nixpkgs/pull/460644 targeting master.
libpq update in https://github.com/NixOS/nixpkgs/pull/460645 targeting staging-next. One CVE affects libpq, so not targeting staging here. Rebuild count is currently 4549 per Linux, 2167 per Darwin.
Rebuilds for the server part have increased by a few hundred over the last couple of months again, we're now at 1085 per Linux and 819 per Darwin. I can split the default attribute (postgresql) into a PR towards staging-next, too - or depending on the timing just retarget that whole PR, if any of these are preferred?
Any opinions?
| 12:12:18 |
 hexa | right now I think what goes where depends on the state of staging-next | 12:29:26 |
| vcunat | I'd merge staging-next if cachix is fixed, as it's a channel blocker. | 12:32:10 |
| Wolfgang Walther | fyi: I had already merged https://github.com/NixOS/nixpkgs/pull/460645 into staging-next, assuming the only question would be around the PR currently targeting master. | 12:37:51 |
| hexa | not a problem | 12:39:14 |
| Wolfgang Walther | Is anybody working on fixing that / aware of the problem already? I posted it in the haskell channel as a starter. | 12:48:15 |
 ivy | it looks like very odd error | 12:49:18 |
| ivy | like it’s failing to link its own compiled haskell modules | 12:49:42 |
| ivy | because the symbols its looking for are internal it seems | 12:50:25 |
| ivy | unless someone forgot to expose a c output or c import right | 12:51:00 |
| Wolfgang Walther | That doesn't look like loading haskell modules to me: dlopen(/nix/store/anfq16cq9qki033324cl26w80ngn0ska-nix-2.28.5/lib/libnixexpr.dylib, 0x0005): Symbol not found: | 12:51:59 |
