nix-du fails to build

bbjubjub2494 commented

2024-05-06 20:38:30 +00:00

Describe the bug

nix-du is broken when the Lix overlay is active and CppNix is substituted with Lix.

  running: "/nix/store/4kwk49k8rc8cg8c387kbbjcrl8i0y693-gcc-wrapper-13.2.0/bin/c++" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-4" "-fno-omit-frame-pointer" "-m64" "-I" "/nix/store/29iwwj649myf8p6cwxwf36g6xdgmbdqf-nix-2.90.0-lixpre20240506-106b959-dev/include/nix" "-Wall" "-Wextra" "-std=c++20" "-DN>
  cargo:warning=wrapper.cpp:16:10: fatal error: current-process.hh: No such file or directory

  cargo:warning=   16 | #include <current-process.hh> // restoreProcessContext

  cargo:warning=      |          ^~~~~~~~~~~~~~~~~~~~

  cargo:warning=compilation terminated.

  exit status: 1

  --- stderr
  Found nix version 2.90.0-lixpre20240506-106b959
  building with NIXVER=219

Steps To Reproduce

Build a system with the Lix module included
That system also pulls in pkgs.nix-du

Expected behavior

build success

`nix --version` output

nix (Lix, like Nix) 2.90.0-lixpre20240506-106b959

Additional context

This is due to this Nix change that isn't in Lix. Also nix-du possibly shouldn't be relying on that in the first place(?) so it's not clear to me who is responsible to fix.

## Describe the bug `nix-du` is broken when the Lix overlay is active and CppNix is substituted with Lix. ``` running: "/nix/store/4kwk49k8rc8cg8c387kbbjcrl8i0y693-gcc-wrapper-13.2.0/bin/c++" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-4" "-fno-omit-frame-pointer" "-m64" "-I" "/nix/store/29iwwj649myf8p6cwxwf36g6xdgmbdqf-nix-2.90.0-lixpre20240506-106b959-dev/include/nix" "-Wall" "-Wextra" "-std=c++20" "-DN> cargo:warning=wrapper.cpp:16:10: fatal error: current-process.hh: No such file or directory cargo:warning= 16 | #include <current-process.hh> // restoreProcessContext cargo:warning= | ^~~~~~~~~~~~~~~~~~~~ cargo:warning=compilation terminated. exit status: 1 --- stderr Found nix version 2.90.0-lixpre20240506-106b959 building with NIXVER=219 ``` ## Steps To Reproduce 1. Build a system with the Lix module included 2. That system also pulls in `pkgs.nix-du` ## Expected behavior build success ## `nix --version` output `nix (Lix, like Nix) 2.90.0-lixpre20240506-106b959` ## Additional context [This is due to this Nix change that isn't in Lix.](https://github.com/NixOS/nix/pull/8920) Also `nix-du` possibly shouldn't be relying on that in the first place(?) so it's not clear to me who is responsible to fix.

bbjubjub2494 added the

bug

label 2024-05-06 20:38:30 +00:00

qyriad added the

Downstream Dependents

label 2024-05-07 00:32:42 +00:00

arcuru commented

2024-05-07 20:37:24 +00:00

AFAICT this just needs another override added into https://git.lix.systems/lix-project/nixos-module/src/branch/main/overlay.nix

  nix-du = prev.nix-du.override {
    nix = final.nixVersions.nix_2_18_upstream;
  };

I can't test it locally right now, but I'll circle back tomorrow if this is still unresolved.

AFAICT this just needs another override added into https://git.lix.systems/lix-project/nixos-module/src/branch/main/overlay.nix ``` nix-du = prev.nix-du.override { nix = final.nixVersions.nix_2_18_upstream; }; ``` I can't test it locally right now, but I'll circle back tomorrow if this is still unresolved.

jade commented

2024-05-07 21:28:50 +00:00

Owner

hmmm. another fix for this would be to do that part of the splitting. the reason this change isn't in lix isn't that we don't want it, but because it was far too big to review.

and, also, the fact that someone is assuming that we are nix 2.20, which we aren't. shakes fist at version detection.

hmmm. another fix for this would be to do that part of the splitting. the reason this change isn't in lix isn't that we don't want it, but because it was far too big to review. and, also, the fact that someone is assuming that we are nix 2.20, which we aren't. *shakes fist at version detection*.

arcuru commented

2024-05-08 06:13:28 +00:00

Unless the goal is to maintain header compat with Nix, there's not much point in spending the effort to try to fix if that's the only benefit.

I assume that Lix isn't trying to maintain header compat with Nix but I haven't found any docs laying out the plan for compatibility with Nix, so I don't really know.

Better to focus on things like #279 to make the break more clear, and spend effort on whatever it is that Lix is trying to work on.

Unless the goal is to maintain header compat with Nix, there's not much point in spending the effort to try to fix if that's the only benefit. I assume that Lix isn't trying to maintain header compat with Nix but I haven't found any docs laying out the plan for compatibility with Nix, so I don't really know. Better to focus on things like #279 to make the break more clear, and spend effort on whatever it is that Lix is trying to work on.

bbjubjub2494 commented

2024-05-08 07:54:56 +00:00

Author

AFAICT this just needs another override added into https://git.lix.systems/lix-project/nixos-module/src/branch/main/overlay.nix
  nix-du = prev.nix-du.override {
    nix = final.nixVersions.nix_2_18_upstream;
  };
I can't test it locally right now, but I'll circle back tomorrow if this is still unresolved.

I would expect that not to work since it seems the header reorg was done in upstream 2.19. I also think it would make more sense to conditionally patch du and avoid pulling in upstream if possible. Those seem to be transitory measures anyway though.

hmmm. another fix for this would be to do that part of the splitting. the reason this change isn't in lix isn't that we don't want it, but because it was far too big to review.

and, also, the fact that someone is assuming that we are nix 2.20, which we aren't. shakes fist at version detection.

Neutral on that. Speaking of, how do you detect Lix? Assume that 2.90+ are Lix?

Unless the goal is to maintain header compat with Nix, there's not much point in spending the effort to try to fix if that's the only benefit.

I assume that Lix isn't trying to maintain header compat with Nix but I haven't found any docs laying out the plan for compatibility with Nix, so I don't really know.

Better to focus on things like #279 to make the break more clear, and spend effort on whatever it is that Lix is trying to work on.

Agreed. This is not a boiling hot issue for me, I reported it for completeness.

> AFAICT this just needs another override added into https://git.lix.systems/lix-project/nixos-module/src/branch/main/overlay.nix > > ``` > nix-du = prev.nix-du.override { > nix = final.nixVersions.nix_2_18_upstream; > }; > ``` > > I can't test it locally right now, but I'll circle back tomorrow if this is still unresolved. I would expect that not to work since it seems the header reorg was done in upstream 2.19. I also think it would make more sense to conditionally patch du and avoid pulling in upstream if possible. Those seem to be transitory measures anyway though. > hmmm. another fix for this would be to do that part of the splitting. the reason this change isn't in lix isn't that we don't want it, but because it was far too big to review. > > and, also, the fact that someone is assuming that we are nix 2.20, which we aren't. *shakes fist at version detection*. Neutral on that. Speaking of, how do you detect Lix? Assume that 2.90+ are Lix? > Unless the goal is to maintain header compat with Nix, there's not much point in spending the effort to try to fix if that's the only benefit. > > I assume that Lix isn't trying to maintain header compat with Nix but I haven't found any docs laying out the plan for compatibility with Nix, so I don't really know. > > Better to focus on things like #279 to make the break more clear, and spend effort on whatever it is that Lix is trying to work on. Agreed. This is not a boiling hot issue for me, I reported it for completeness.

jade commented

2024-05-08 08:09:36 +00:00

Owner

we actually do want the splitting to happen, see #43, but we just haven't done it for effort reasons. it's not like, super hard to actually do it or even slightly a high risk change. we just haven't done it. if you want to help feel free; the thing that we need is having the splitting done file by file so review is tractable.

we actually do want the splitting to happen, see https://git.lix.systems/lix-project/lix/issues/43, but we just haven't done it for effort reasons. it's not like, super hard to actually do it or even slightly a high risk change. we just haven't done it. if you want to help feel free; the thing that we need is having the splitting done file by file so review is tractable.

👍 1

arcuru commented

2024-05-08 14:22:27 +00:00

I would expect that not to work since it seems the header reorg was done in upstream 2.19. I also think it would make more sense to conditionally patch du and avoid pulling in upstream if possible. Those seem to be transitory measures anyway though.

The overlay change does work, btw. nix-du detects the Nix version and handles the headers.

Eventually we can get other things to detect and use Lix, assuming that we provide equivalent header functions, but right now I think we should get out of the way to let people use Lix where it already works. We can push changes upstream once it's decided that the Lix headers are stable enough.

> I would expect that not to work since it seems the header reorg was done in upstream 2.19. I also think it would make more sense to conditionally patch du and avoid pulling in upstream if possible. Those seem to be transitory measures anyway though. The overlay change does work, btw. nix-du detects the Nix version and handles the headers. Eventually we can get other things to detect and use Lix, assuming that we provide equivalent header functions, but right now I think we should get out of the way to let people use Lix where it already works. We can push changes upstream once it's decided that the Lix headers are stable enough.

bbjubjub2494 commented

2024-05-10 11:24:32 +00:00

Author

In my personal capacity, I would support the overlay solution for now.

Now when I try to build nix-du with the nixpkgs pinned in lix, I get another error and I'm confused.

  running: "/nix/store/a9kr77jici5pfcv8hprqncnmjlsrjhi4-gcc-wrapper-12.3.0/bin/c++" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-4" "-fno-omit-frame-pointer" "-m64" "-Wall" "-Wextra" "-std=c++20" "-DNIXVER=208" "-o" "/build/source/target/x86_64-unknown-linux-gnu/release/build/nix-du-6ef083c81c5f7bff/out/wrapper.o" "-c" "wrapper.cpp"
  cargo:warning=In file included from /nix/store/jyqahs8yaq3xia9j45x3g09lnnxnljsi-nix-2.90.0pre20240509_9ae9061-dev/include/nix/shared.hh:6,

  cargo:warning=                 from wrapper.cpp:13:

  cargo:warning=/nix/store/jyqahs8yaq3xia9j45x3g09lnnxnljsi-nix-2.90.0pre20240509_9ae9061-dev/include/nix/args/root.hh:4:10: fatal error: args.hh: No such file or directory

  cargo:warning=    4 | #include "args.hh"

  cargo:warning=      |          ^~~~~~~~~

  cargo:warning=compilation terminated.

  exit status: 1

  --- stderr
  Found nix version 2.90.0pre20240509_9ae9061
  building with NIXVER=208

In my personal capacity, I would support the overlay solution for now. Now when I try to build nix-du with the nixpkgs pinned in lix, I get another error and I'm confused. ``` running: "/nix/store/a9kr77jici5pfcv8hprqncnmjlsrjhi4-gcc-wrapper-12.3.0/bin/c++" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-4" "-fno-omit-frame-pointer" "-m64" "-Wall" "-Wextra" "-std=c++20" "-DNIXVER=208" "-o" "/build/source/target/x86_64-unknown-linux-gnu/release/build/nix-du-6ef083c81c5f7bff/out/wrapper.o" "-c" "wrapper.cpp" cargo:warning=In file included from /nix/store/jyqahs8yaq3xia9j45x3g09lnnxnljsi-nix-2.90.0pre20240509_9ae9061-dev/include/nix/shared.hh:6, cargo:warning= from wrapper.cpp:13: cargo:warning=/nix/store/jyqahs8yaq3xia9j45x3g09lnnxnljsi-nix-2.90.0pre20240509_9ae9061-dev/include/nix/args/root.hh:4:10: fatal error: args.hh: No such file or directory cargo:warning= 4 | #include "args.hh" cargo:warning= | ^~~~~~~~~ cargo:warning=compilation terminated. exit status: 1 --- stderr Found nix version 2.90.0pre20240509_9ae9061 building with NIXVER=208 ```

nix-du fails to build #275

Describe the bug

Steps To Reproduce

Expected behavior

nix --version output

Additional context

`nix --version` output