| 9 Nov 2025 |
Emma [it/its] | lmao | 11:02:11 |
Emma [it/its] | you should just be able to tap the pill then | 11:02:24 |
maralorn | Sure I should. | 12:21:19 |
maralorn | Maybe the problem is also my badly maintained and 10 years old synaps. | 12:21:33 |
maralorn | * Maybe the problem is also my badly maintained and 10 years old synapse. | 12:51:41 |
| 11 Nov 2025 |
Grimmauld (any/all) | I also noticed nixos' system.replaceDependencies very much breaks noms graph building logic, the graph appears "flat" | 19:46:13 |
maralorn | Grimmauld (any/all): Are you able to give me more context on that? | 20:06:43 |
maralorn | I guess, I can just google what it is.^^ | 20:07:03 |
maralorn | Do you mind sharing a screenshot and an example derivation? | 20:16:47 |
maralorn | * Do you mind sharing a screenshot or even an example derivation? | 20:16:55 |
Grimmauld (any/all) |  Download image.png | 20:49:01 |
Grimmauld (any/all) | it basically strips each package into its own root while building, and "disconnecting" it from the big graph | 20:49:29 |
Grimmauld (any/all) | On my system, i run into this with:
system.replaceDependencies.replacements =
let
aspell' = pkgs.aspell.overrideAttrs (old: {
postFixup = (old.postFixup or "") + ''
rm $out/bin/aspell-import
'';
});
enchant' = pkgs.enchant.override {
withHspell = false;
aspell = aspell';
};
in
[
{
oldDependency = pkgs.enchant.dev;
newDependency = enchant'.dev;
}
{
oldDependency = pkgs.enchant.out;
newDependency = enchant'.out;
}
{
oldDependency = pkgs.aspell;
newDependency = aspell';
}
];
environment.systemPackages = [ pkgs.webkitgtk_6_0 ];
(well, the package isn't actually webkitgtk, but that is what pulls these deps)
| 20:51:54 |
maralorn | What is this witchery?^^ | 21:20:36 |
hexa | graft-like stuff | 21:21:41 |
Grimmauld (any/all) | In reply to @maralorn:maralorn.de What is this witchery?^^ Replacing runtime libraries without rebuilding the full tree. Because rebuilding webkitgtk and downstrem things is a little too painful. | 21:22:15 |
maralorn | But that changes the hash of the derivation, right? | 21:40:28 |
maralorn | Grimmauld (any/all): I actually suspect this to be https://github.com/maralorn/nix-output-monitor/issues/96 | 22:09:16 |
maralorn | The problem is that the fundamental internal structure of nom is a tree of derivations, where every node can have storepaths attached. But there are corner cases where this abstraction is actually insufficient because storepaths can actually depend on other storepaths without there derivations depending on each other. | 22:11:30 |
maralorn | I once had a plan on how to fix this, but then I lost traction and now I don’t remember it fully. | 22:12:18 |
maralorn | To confirm this I would have to see nix derivation show and nix path-info --json of the derivation which lost its child node. | 22:43:18 |
| 12 Nov 2025 |
maralorn | After again, not being able to sleep because I couldn’t stop thinking about this problem I think it might not be #96 after all. | 03:51:36 |
maralorn | I don’t get it. I have been staring at replace-dependencies.nix for a while now and it is apparently breaking a lot of assumptions that "normal" packages uphold but I can’t figure out which assumption of nom it is breaking. | 04:16:38 |
maralorn | I would need to write a nix expression which I can easily build and stare at the .drv files. | 04:17:43 |
maralorn | Generally I’d say: When the build tree is flat, then the build tree is actually flat. i.e. whichever derivation is waiting for freecad to be built somehow does not list the freecad derivation as one of its inputs. | 04:19:14 |
maralorn | Which confuses the heck out of me, because how does nix even know then that they depend on each other? | 04:19:53 |
maralorn | By reverse lookup from storepaths to derivation? | 04:20:06 |
maralorn | * By reverse lookup from storepaths to derivations? | 04:20:09 |
maralorn | Grimmauld (any/all): Feel free to open an issue about this. And if you can give me a minimal reproducer that would increase the likelihood of me looking into this further. | 04:21:29 |
| saygo.2 joined the room. | 07:25:21 |