Kernel build issue

[LoganBarnett]

I'm running into an issue building my own kernel. I'm on 26d6ba2a91e6384252bfea5e94c3364e7f8879f2 (latest master at time of writing). The patches don't appear to be applying due to conflicts.

@nix { "action": "setPhase", "phase": "unpackPhase" }
Running phase: unpackPhase
unpacking source archive /nix/store/hdh0igwg2rj6zk6xmf8kdn7kzrv9i91h-source
source root is source
@nix { "action": "setPhase", "phase": "patchPhase" }
Running phase: patchPhase
applying patch /nix/store/mnlqwys9dxznjcvq4w3s0435s9ql8qv8-bridge-stp-helper.patch
patching file net/bridge/br_private.h
Hunk #1 succeeded at 51 with fuzz 2 (offset 12 lines).
applying patch /nix/store/mbz5gln1q4swlzmqs2399br98qjif9kn-request-key-helper.patch
patching file security/keys/request_key.c
Hunk #1 succeeded at 117 (offset 3 lines).
applying patch /nix/store/831w9jjwfspn3wc2h3mlks980v3zm2qz-6de0bb51929cd3ad4fa27b2a421a2af12e6468f5.patch
patching file drivers/gpu/drm/rp1/rp1-dpi/Kconfig
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/gpu/drm/rp1/rp1-dpi/Kconfig.rej
patching file drivers/gpu/drm/rp1/rp1-dsi/Kconfig
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/gpu/drm/rp1/rp1-dsi/Kconfig.rej
patching file drivers/gpu/drm/rp1/rp1-vec/Kconfig
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/gpu/drm/rp1/rp1-vec/Kconfig.rej

I've tried moving back some commits and trying out the cachix substituter. When moving back I get an error with a missing nixpkgs (which I can see is later corrected), and the substituter doesn't seem to be picking anything up. I think that might be due to the substituter only containing an older kernel?

So I'm thinking some potential avenues to try out:

1. Try an older commit but fix branch + fix the nixpkgs issue separately from kernel upgrades, then use the older kernel (I can do this, just haven't gotten to it yet).
2. We get a working, patched kernel uploaded. I can supply my exact nix.conf when I'm back on my home network later this evening so we know I'm actually using the substituter. Near as I can tell nix build will not just tell me.
3. See what's up with getting the kernel built at its current version. I am building it from x86-linux but I would think this would make no difference when applying patches.
4. We reveal some idiocy on my part. If history is an indicator of future behavior, this is the most likely of these :)

Thanks for your work on this! I came across this wanting to build a completely ready Pi image (which was working back on the Pi 3s) and couldn't figure out how to do it via modern nixpkgs et. al.

[tstat]

Hey @LoganBarnett -- I'm happy to try to help. I would guess your kernel derivation is different for some reason. Can you share the output of:nix derivation show .#nixosConfigurations.<your config key>.config.boot.kernelPackages.kernel?

[LoganBarnett]

Thanks for getting back to me so quickly! I'm having trouble reproducing it now. I've made some adjustments to my follows for my inputs (I have a lot of inputs now), so I'm thinking maybe that's the cause. My build hasn't completed but I believe it's getting well past the patching phase.

Let's close this for now and I can reopen (or ask to reopen) if I run into something I can minimally reproduce. Thanks again!