Build failure: Cargo packages

Mikilio commented 1 year ago

Steps To Reproduce

Steps to reproduce the behavior:

Set nixpkgs channel to unstable

In nix repl run:

nix-repl> pkgs = import <nixpkgs> {}
nix-repl> pkgs.cargo-component
nix-repl> pkgs.cargo-about
nix-repl> pkgs.pods
nix-repl> pkgs.pot
nix-repl> pkgs.asusctl
nix-repl> pkgs.owmods-cli
nix-repl> pkgs.wezterm
nix-repl> pkgs.windmill
nix-repl> pkgs.popsicle
nix-repl> pkgs.rtz
nix-repl> pkgs.catfs

Build log

Please run yourself in nix repl to see all builds fail because of error messages like this:

       error: opening file '/nix/store/d0k9saw4m810b34jjbdfflfpjmg0vs92-nodrop-0.1.14.drv': No such file or directory
       error: opening file '/nix/store/cgsklvcykkss33zka0b046gf1nl4y553-rustix-0.38.4.drv': No such file or directory
       error: opening file '/nix/store/mkhxrm2j8sxg0a71s85bnz57ldbyxmcq-proc-macro-crate-1.3.1.drv': No such file or directory
       error: opening file '/nix/store/llm3qd9rrp1win5zrnrfp46bmpm8njvr-line_drawing-0.8.1.drv': No such file or directory
       error: opening file '/nix/store/hk97smz5w5xbbxqi3qz278ym1k0f6qg1-systemd-zbus-0.1.0.drv': No such file or directory
       error: opening file '/nix/store/94i4s24lp31id1sdxyp7i2866yv7qr1m-time-0.3.23.drv': No such file or directory

Additional context

I first noticed the problem when trying to rebuild my configuration. Possibly a lot more packages than the ones I've listed are affected, so this should be marked as high priority. It seems the hashes are not calculated properly because it seems I can build the packages manually in the same versions:

nix-repl> :b pkgs.time.overrideAttrs(o: {version = "0.3.23";})

This derivation produced the following outputs:
  out -> /nix/store/5ni93b9cd306q9vm0rjgqgldsjg2hf2h-time-0.3.23

nix-repl> pkgs.time.overrideAttrs(o: {version = "0.3.23";})
«derivation /nix/store/zzh8g66q00gcjvbqpjkbw7q1nz75vibk-time-0.3.23.drv»

Notify maintainers

Since this probably involves the rustPlatform builders I am notifying the rust team:

@figsoda @mic92 @tjni @winter @zowoq

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.4.7-xanmod1, NixOS, 23.11 (Tapir), 23.11.20230804.18036c0`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.15.1`
 - channels(root): `"nixos, nur"`
 - nixpkgs: `/nix/store/d42v5grfq77vr10r336kks0qjp0wij8d-source`

figsoda commented 1 year ago

I can't reproduce the errors, and hydra doesn't seem to either. I would appreciate it if you provided more information, e.g., the full log of the error and whether you have user overlays or config for nixpkgs.

Mikilio commented 1 year ago

All errors usually have the same start:

error:
       … while calling the 'derivationStrict' builtin

         at //builtin/derivation.nix:9:12: (source not available)

       … while evaluating derivation 'windmill-1.100.1'
         whose name attribute is located at /nix/store/d42v5grfq77vr10r336kks0qjp0wij8d-source/pkgs/stdenv/generic/make-derivation.nix:300:7

       … while evaluating attribute 'cargoDeps' of derivation 'windmill-1.100.1'

         at /nix/store/d42v5grfq77vr10r336kks0qjp0wij8d-source/pkgs/build-support/rust/build-rust-package/default.nix:107:10:

          106| } // {
          107|   inherit buildAndTestSubdir cargoDeps;
             |          ^
          108|

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: opening file '/nix/store/mkhxrm2j8sxg0a71s85bnz57ldbyxmcq-proc-macro-crate-1.3.1.drv': No such file or directory

As for my nixpkgs configuration and overlays here are the relevant files in my configuration:

EDIT: Additional Info (formatted for better readability)

nix-repl> pkgs.wezterm.drvAttrs
{ 
   NIX_LDFLAGS = "";
   PKG_CONFIG_ALLOW_CROSS = 0;
   __ignoreNulls = true;
   __structuredAttrs = false;
   args = [ ... ];
   buildAndTestSubdir = null;
   buildFeatures = [ ... ];
   buildInputs = [ ... ];
   builder = "/nix/store/ir0j7zqlw9dc49grmwplppc7gh0s40yf-bash-5.2-p15/bin/bash";
   cargoBuildFeatures = «repeated»;
   cargoBuildNoDefaultFeatures = false;
   cargoBuildType = "release";
   cargoCheckFeatures = «repeated»;
   cargoCheckNoDefaultFeatures = false;
   cargoCheckType = "release";
   cargoDeps = error: opening file '/nix/store/94i4s24lp31id1sdxyp7i2866yv7qr1m-time-0.3.23.drv': No such file or directory «derivation
nix-repl>

Mikilio commented 1 year ago

I just performed a bisect and found the first bad commit. Upon the first look I'm really confused why this breaks cargo packages, but here it is b511178745c2b8bf8c65247d7e3851de38dffcd5

Mikilio commented 1 year ago

I can confirm that reverting the commit on master indeed solves the issue for me. However since it is a security patch I shouldn't just revert it. Any help would be appreciated as I have no idea how cargoDeps and openssl are connected.

Mikilio commented 1 year ago

TL;DR: I can't reproduce the bug anymore so I give up trying to solve it.

The above fix worked for building the cargo packages however when I rebuilt my nixos-configuration it threw an error about not being able to build openssh. So, with the power of nix I decided to change my nixpkgs input to version 23.05. It builds successfully. After a few days I do a test for another project and realise I just built a package with unstable nixpkgs that I wasn't supposed to be able to build. Suspicious of that I change my configuration back to nixos-unstable and for some reason it built without issues. Since then it has been working as expected but my "corrupted?" generations where causing issues just by existing so I removed them and did a garbage collect. This whole experience was baffling as I was expecting "reproducibility" but felt like I was on Arch linux again.

If this issue ever becomes relevant again I would like to leave the record that it might have happened because I had a lot of packages pulled from cachix but I removed a some substituters from my configuration, so I could imagine that this was kind of messing up dependencies because they suddenly had different hashes when the original cachix packages were expected. In other words I believe my some packages didn't receive the directive to rebuild so they were expecting the cached dependencies but instead received bleeding edge versions with hotfixes.

NixOS / nixpkgs