!yxFWYdmeLrdzdoIrcE:maralorn.de

nix-output-monitor

93 Members
https://github.com/maralorn/nix-output-monitor30 Servers

Load older messages


SenderMessageTime
11 Nov 2025
@maralorn:maralorn.demaralorn Grimmauld (any/all): Are you able to give me more context on that? 20:06:43
@maralorn:maralorn.demaralornI guess, I can just google what it is.^^20:07:03
@maralorn:maralorn.demaralornDo you mind sharing a screenshot and an example derivation?20:16:47
@maralorn:maralorn.demaralorn* Do you mind sharing a screenshot or even an example derivation?20:16:55
@grimmauld:grapevine.grimmauld.deGrimmauld (any/all)image.png
Download image.png
20:49:01
@grimmauld:grapevine.grimmauld.deGrimmauld (any/all)it basically strips each package into its own root while building, and "disconnecting" it from the big graph20:49:29
@grimmauld:grapevine.grimmauld.deGrimmauld (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:maralorn.demaralornWhat is this witchery?^^21:20:36
@hexa:lossy.networkhexagraft-like stuff21:21:41
@grimmauld:grapevine.grimmauld.deGrimmauld (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:maralorn.demaralornBut that changes the hash of the derivation, right?21:40:28
@maralorn:maralorn.demaralorn Grimmauld (any/all): I actually suspect this to be https://github.com/maralorn/nix-output-monitor/issues/96 22:09:16
@maralorn:maralorn.demaralornThe 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:maralorn.demaralornI 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:maralorn.demaralornTo 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:maralorn.demaralornAfter 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:maralorn.demaralornI 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:maralorn.demaralornI would need to write a nix expression which I can easily build and stare at the .drv files.04:17:43
@maralorn:maralorn.demaralornGenerally 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:maralorn.demaralornWhich confuses the heck out of me, because how does nix even know then that they depend on each other?04:19:53
@maralorn:maralorn.demaralornBy reverse lookup from storepaths to derivation?04:20:06
@maralorn:maralorn.demaralorn* By reverse lookup from storepaths to derivations?04:20:09
@maralorn:maralorn.demaralorn 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:tchncs.desaygo.2 joined the room.07:25:21
@saygo.2:tchncs.desaygo.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:tchncs.desaygo.2i know there is an old issue about this but i'm not sure if its still the case07:35:15
@saygo.2:tchncs.desaygo.2* i know there is an old issue about wanting optparse-applicative but i'm not sure if its still the case07:35:58
@maralorn:maralorn.demaralornSure. Just be smart about I.e. don't reimplement the nix arguments for those we need a blind passthrough08:10:21
@inayet:matrix.orgInayet changed their display name from inayet to Inayet.12:37:09
@maralorn:maralorn.demaralorn saygo.2: And in regards to "try"-ing I’d be more than happy to help/mentor. 18:03:55

Show newer messages


Back to Room ListRoom Version: 9