| 11 Nov 2025 |
 ElvishJerricco | I mean | 11:26:09 |
 Grimmauld (any/all) | it inherits name and paths, it explicitly does extra outputs | 11:26:11 |
| Grimmauld (any/all) | so why do we need that at all | 11:26:24 |
| ElvishJerricco | technically, the args given to this buildEnv' are more powerful, because they become derivation attrs, not args to buildEnv | 11:26:26 |
| ElvishJerricco | so that's technically a difference | 11:26:30 |
| ElvishJerricco | but I don't know if that's actually used? | 11:26:40 |
| Grimmauld (any/all) | HUH | 11:26:49 |
| Grimmauld (any/all) | okay that is actually fair, hold on let me check | 11:27:02 |
| 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 |
 Vladimír Čunát | I don't care really. | 11:35:24 |
| Vladimír Čunát | But I'm relatively busy today. | 11:35:30 |
| Vladimír Čunát | (with work stuff) | 11:35:36 |
| Vladimír Čunát | 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 |
| Vladimír Čunát | I'd merge staging-next if cachix is fixed, as it's a channel blocker. | 12:32:10 |
