Skip to content

fix: apply logos-nix's fetchCargoVendor User-Agent overlay in mkPkgsWith - #220

Open
danisharora099 wants to merge 1 commit into
logos-co:masterfrom
danisharora099:fm/mb-ua-hookup
Open

fix: apply logos-nix's fetchCargoVendor User-Agent overlay in mkPkgsWith#220
danisharora099 wants to merge 1 commit into
logos-co:masterfrom
danisharora099:fm/mb-ua-hookup

Conversation

@danisharora099

Copy link
Copy Markdown

Why

Every module release's cargo vendoring dies with crates.io ... 403 (#159): the pinned nixpkgs' fetchCargoVendor helper sends no User-Agent. logos-co/logos-nix#6 carries the upstream fix (NixOS/nixpkgs#512735) as logos-nix.lib.overlays.fetchCargoVendorUserAgent on the current pin, no Qt bump — per the 2026-08-27 plan on logos-co/logos-nix#5 (logos-co/logos-nix#5 (comment)) and the 2026-08-12 maintainer ask that the fix live in logos-nix.

But logos-nix's overlay only reaches package sets built through logos-nix's own helpers. This repo does its own import nixpkgs in lib/common.nix mkPkgsWith, so it never applied here. This is the one consumer line that hooks it up.

What

lib/common.nix mkPkgsWith: prepend logos-nix.lib.overlays.fetchCargoVendorUserAgent to the native package set's overlays. Guarded with logos-nix ? lib.overlays.fetchCargoVendorUserAgent, so on the current lock (which predates the attribute) it is a no-op and evaluation is unchanged — the fix switches on with the lock bump. Not applied to the x86_64-windows set (mkWindowsPkgs owns that; nixpkgs-windows already has the upstream fix).

No flake.lock change. Merge order: after logos-co/logos-nix#6, then a nix flake update logos-nix lock bump here (separate commit/PR) — only then do module releases pick this up, via their logos-module-builder input.

Verified (aarch64-darwin, --override-input logos-nix github:logos-co/logos-nix/aac5338e = #6's head)

  • checks.aarch64-darwin.rust-native-dep instantiates; the module's own crate compile (rust_native_dep-1.0.0.drv) now resolves its toolchain through the overlayed set — its cargo-auditable/cargo-c/rav1e -vendor-staging FODs reference fetch-cargo-vendor-util-ua, whose built helper sets User-Agent: nixpkgs-fetchCargoVendor/2 (...) and fetches from static.crates.io. Without the override, every staging drv in that closure references the unpatched helper.
  • A one-crate rustPlatform.fetchCargoVendor (bitflags 2.9.4) built from this repo's common.mkPkgs "aarch64-darwin": without the overlay → Status code: 403 (reproduces Release builds broken ecosystem-wide: crates.io returns 403 to fetchCargoVendor (UA-less python fetch) #159); with it → fetches from static.crates.io and produces the cargo-deps-vendor output (bitflags-2.9.4/ + .cargo/).
  • On the current lock (no override): all checks.aarch64-darwin.* still evaluate; rust-native-dep's drvPath is unchanged (guard is a no-op).

Not proven: the rust-native-dep fixture has no external crates (its vendor dir is local), so a full run of that check does not exercise a crates.io download — hence the one-crate vendor above. Staging drvs reached via logos-lidl-gen (logos-rust-sdk's own nixpkgs set) stay unpatched; those are cache-served upstream tools, not a module's crates, and are out of this repo's hands. Linux not run.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ezs1fWormzPw9QqU89oAFU

…package sets

crates.io returns 403 to the pinned nixpkgs' UA-less fetchCargoVendor
helper, so every module release's cargo vendoring fails (logos-co#159). logos-nix#6
carries the upstream fix as lib.overlays.fetchCargoVendorUserAgent, but this
repo does its own `import nixpkgs` in mkPkgsWith, so the overlay never
reached module builds. Thread it in there, guarded so a logos-nix pin that
predates the attribute still evaluates (no-op until the lock bump).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ezs1fWormzPw9QqU89oAFU
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant