| 11 Nov 2025 |
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 |
saygo.2 | @maralorn:maralorn.de: I want to try moving argument parsing to the optparse-applicative library. Is this something you want in nom?
(Emphasis on try) | 07:33:46 |
saygo.2 | i know there is an old issue about this but i'm not sure if its still the case | 07:35:15 |
saygo.2 | * i know there is an old issue about wanting optparse-applicative but i'm not sure if its still the case | 07:35:58 |
maralorn | Sure. Just be smart about I.e. don't reimplement the nix arguments for those we need a blind passthrough | 08:10:21 |
| Inayet changed their display name from inayet to Inayet. | 12:37:09 |
maralorn | saygo.2: And in regards to "try"-ing I’d be more than happy to help/mentor. | 18:03:55 |