How to better troubleshoot build issues beyond trace

Is there a better way to troubleshoot rebuild failures? The output of --show-trace at times is just too verbose and then sometimes inconsistent. I will admit I likely do not understand something. Overall I find the process abrasive and far from intuitive.

For example, I just had an output that was 702 lines. :astonished: . Run the identical command a second time, and it is a cached failure of an attribute without any pointers.

So I guess my questions are:

  • How can I skip the cached failure so I can get back to the verbose output?
  • Any tips for digging in on the verbose output? I mean I personally do not find output like the following helpful.
 79|         vals = map (d: d.value) vdefs;
           80|         defTypes = map (x: x.type) vals;
             |                         ^
           81|         sameOrNull = x: y: if x == y then y else null;

       … from call site

When I trolled the output originally, I did not find a reference to any of my files in my repo. So I was not sure where to begin.

Well open to suggestions and education. I have to be doing something wrong here and would like to smooth it out. Tips, tricks, process?

Thanks.

2 Likes

Same issue here. ā€œcached falure of attributeā€ when trying to trace.

1 Like

Agree with sentiments expressed here.
Anyone tried putting to chat AI?
The only viable solution to me seems to be edit your script but making only small changes and reverse when you hit an error. (using git/backup increases the work) This makes progress slow and increases the frustration. Then you need to remember to remove all those generations :wink:
If this was improved I think more people would invest in looking to move to Nixos as this is I think the biggest pain point.

1 Like

I’ve done some with GitHub copilot. I would say it’s successful maybe 40% of the time. When I started this thread, I just wanted to make sure there wasn’t some nix related tooling or process that I just wasn’t aware of.

i have no solution but the same issue, but for it may help, use nixos-rebuild [...] test instead of switch. you still have to garbage-collect, but you won’t install that generation.

i sometimes do delete ~/.cache/nix/eval-cache-* to be able to reproduce the error-output. but most of the time it’s not usefull to me either.

This is essential to my flow when developing my modules.

just in case there’s as misunderstanding: nixos-rebuild [...] test will switch your running-system but it won’t install to you boot-mechanism like grub or efi.