The derivation for transmission_4-qt fails to build

Help
1

Like the title says.

Error log:

error: builder for '/nix/store/aimjrzvf7lbpf0jf28rwy0z8v4v8142y-transmission-4.0.6.drv' failed with exit code 2;
       last 10 log lines:
       > In member function 'tr_tracker* tr_tier::currentTracker()',
       >     inlined from 'tr_tracker* tr_tier::useNextTracker()' at /build/source/libtransmission/announcer.cc:419:30,
       >     inlined from 'void {anonymous}::on_scrape_done_helpers::on_scrape_error(const tr_session*, tr_tier*, const char*)' at /build/source/libtransmission/announcer.cc:1249:43:
       > /build/source/libtransmission/announcer.cc:357:20: warning: potential null pointer dereference [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wnull-dereference-Wnull-dereference8;;]
       >   357 |             return nullptr;
       >       |                    ^~~~~~~
       > [ 21%] Linking CXX static library libgtestall.a
       > [ 21%] Built target gtestall
       > make[1]: *** [CMakeFiles/Makefile2:422: libtransmission/CMakeFiles/transmission.dir/all] Error 2
       > make: *** [Makefile:166: all] Error 2
       For full logs, run 'nix log /nix/store/aimjrzvf7lbpf0jf28rwy0z8v4v8142y-transmission-4.0.6.drv'.
error: 1 dependencies of derivation '/nix/store/cr9padwav9nz4qhwpdcss7idb1cjngvh-system-path.drv' failed to build
error (ignored): error: cannot unlink '/tmp/nix-build-nvidia-x11-555.58.02-6.6.37.drv-0/build/NVIDIA-Linux-x86_64-555.58.02/kernel': Directory not empty
error: 1 dependencies of derivation '/nix/store/pz8vajxryxlqkghf0qbq9swg4sxcaajs-nixos-system-lear-24.11.20240709.feb2849.drv' failed to build

And a reboot later, nothing has changed except for the error related to nvidia-x11.

EDIT:
It seems like an issue with the source code itself. But that raises a question: how did this get through the build system?

I looked up when the date the Transmission derivation was last updated. That was 3 weeks ago (specifically splitting off Transmission 3), and since then I’ve had successful builds that include Transmission 4. It just fails to build now, after the nose-1.3.7 debacle.

So what’s with the Heisenbehavior?
Nix is supposed to be better than that, isn’t it?
And at the very least the same nixos-unstable input I’m using for my system flake used to be a lot more stable say 6 months, 1 year ago.
Such breakage just didn’t happen. Why now?

2

Something in its dependency tree changed and now the build is broken. nix-diff might help you find out what, if you’re interested in helping getting it fixed.

It’s not practical to successfully build every single package before advancing the channels; there’s always something broken and updates would come incredibly slowly. (Although, ironically, the GTK versions of Transmission are in the rather arbitrary list of channel blockers.)

We do a Zero Hydra Failures cycle before every stable release, so if you want to minimize the amount you ever see a broken package then it’s best to use the stable branches.

3

Thanks for the response.

I’m aware of that, but at least ATM that’s not feasible.
I need, among other things, the nvidia 555 series stable driver, which was released after 24.05.

First I’ll just try T3. All this is happening while I’m actually trying to get work done, so right now I can’t spend time on figuring out what broke.
Perhaps in the weekend.

EDIT: T3 is broken too:

error: builder for '/nix/store/mjkjzz0nmh28hzn3fjzg4k8m22c5wlww-transmission-3.00.drv' failed with exit code 2;
       last 10 log lines:
       >   197 |         if (UPNP_GetValidIGD(devlist, &handle->urls, &handle->data, handle->lanaddr,
       >       |             ^~~~~~~~~~~~~~~~
       > In file included from /build/source/libtransmission/upnp.c:12:
       > /nix/store/vmzxminj8mwfw81whay2524c4b6w321q-miniupnpc-2.2.8/include/miniupnpc/miniupnpc.h:122:1: note: declared here
       >   122 | UPNP_GetValidIGD(struct UPNPDev * devlist,
       >       | ^~~~~~~~~~~~~~~~
       > make[2]: *** [libtransmission/CMakeFiles/transmission.dir/build.make:804: libtransmission/CMakeFiles/transmission.dir/upnp.c.o] Error 1
       > make[2]: *** Waiting for unfinished jobs....
       > make[1]: *** [CMakeFiles/Makefile2:226: libtransmission/CMakeFiles/transmission.dir/all] Error 2
       > make: *** [Makefile:166: all] Error 2
       For full logs, run 'nix log /nix/store/mjkjzz0nmh28hzn3fjzg4k8m22c5wlww-transmission-3.00.drv'.
error: 1 dependencies of derivation '/nix/store/yg9v9jz1mlfzhda7ikz59hc74qhh0qrd-system-path.drv' failed to build
error: 1 dependencies of derivation '/nix/store/j7hni48m0vc3mn289bi7g8l8gl0xp1fv-nixos-system-lear-24.11.20240709.feb2849.drv' failed to build

Perhaps that’s a hint in and of itself though.

4

It’s the backwards‐incompatible miniupnpc update that has already been reverted which will hit the channel sometime soon. (By the way, you really need to run the command to get the full logs to get any useful information out of build failures most of the time.)

5

Indeed, that seems likely for T3.
But the error for T4 doesn’t mention miniupnpc, so likely has a different cause, or the same cause but much more indirectly.

To which command are you referring, exactly?

If you’re talking about nix-diff, it seems useful for looking at errors once I’ve figured out how to use it, but doing that for each system rebuild doesn’t seem all that useful TBH.

6

Your original post didn’t include any error, just an unrelated warning that happened after the error (which was probably also about miniupnpc).

1 Like
7

Yeah about that…
It’s a bit of a tangent to the topic, but why are nix errors so horrible? You’d think the nix tooling would, in the past 8 years (i.e. since it became a stable language), have taken some inspiration from the Rust tool chain (including its compiler) which is a perfect example of how errors are supposed to work, and arguably the gold standard ATM.
Any idea why the responsibility of having to figure out what is actually going wrong is still being delegated to the tool user?

1 Like
8

Nix builds projects using arbitrary third‐party build systems with no standard form of structured output. Do you have a proposal for how we could produce better error messages for failing builds other than pointing the user to the build output? Evaluation errors are pretty awful, but it’s a very hard problem to do much better with an untyped lazy language.

If you’d prefer to get tens of thousands of lines of build output on your terminal, then you can pass the -L option. nix-output-monitor may also interest you.

10

Both transmission_4-qt and transmission_3-qt build on current master. Also on nixos-unstable they both fail with basically the same error. So it should be fixed by the same PR, whenever it reaches the nixos-unstable branch (usually takes a couple of days or more).

11

Yeah that became apparent when someone suggested to me to try to run it via Nix run. Somehow the error displayed then was more to the point.
But by that same token, I can just nix run transmission from nixos 24.05 in the meantime. I haven’t needed that yet but it’s actually a pretty nice workaround, as those go.