chore(deps): bump smoltcp to 0.14.0 across all three dependency graphs - #926
Merged
Conversation
This repository carries three independent lockfiles -- root, crates/thumos, and fuzz -- and declares smoltcp in two manifests, so a version bump is not one edit. Dependabot opened it as three PRs (#923, #924, #925), each regenerating exactly one lockfile and leaving the other two stale against a shared root Cargo.toml change. Every one of them failed the repo's own drift gates, and none could have passed alone: merging any single PR would have left the others' graphs disagreeing with the manifest they resolve from. Consolidated here. Both manifests move to 0.14, all three lockfiles are regenerated, and crates/aither needs no change because it inherits through workspace = true. Also drops the RUSTSEC-2026-0173 suppression from deny.toml, .cargo/audit.toml and osv-scanner.toml. That advisory covers proc-macro-error2, which reached these graphs only through smoltcp's optional defmt feature; 0.14 drops that edge and the crate is now absent from all three lockfiles. Its stated reason had already gone stale -- it described "smoltcp 0.12" while the manifests were on 0.13 -- and a suppression asserting the presence of a crate no longer in any graph is a false claim the next reader has to disprove before they can act. Verified before pushing: all three graphs resolve under --locked, which is the failure that killed all three original PRs; check-pin-parity and check-lockfile-manifest both pass, which are the two gates they tripped; and check-external-lockfile-versions passes against each lockfile individually.
This was referenced Aug 24, 2026
forkwright
added a commit
that referenced
this pull request
Aug 24, 2026
The three `package-ecosystem: cargo` entries in this repo's dependabot config are why the smoltcp 0.14 bump arrived as three PRs that could not land. ## The mechanism thumos carries three independent dependency graphs with their own lockfiles — `/`, `/crates/thumos` (excluded from the workspace so it cross-compiles bare-metal to `armv7a-none-eabi`), and `/fuzz` (own empty `[workspace]`, cargo-fuzz needs nightly). A version bump declared in the **root manifest** spans all three. But three separate entries each regenerate only their own lockfile: | PR | regenerated | left stale | |---|---|---| | #925 | root `Cargo.lock` | `crates/thumos` pin + lock, `fuzz/Cargo.lock` | | #924 | `crates/thumos/Cargo.lock` | root `Cargo.lock`, `fuzz/Cargo.lock` | | #923 | `fuzz/Cargo.lock` | root `Cargo.lock`, `crates/thumos` pin | Each failed this repo's own drift gates — `PIN DRIFT` from `rustfmt`, and `error: cannot update the lock file ... because --locked was passed` from the workspace and kernel jobs. **None could pass alone**, and merging any one would have left the others' graphs disagreeing with the manifest they resolve from. They were consolidated by hand into #926. This will recur on the next bump that touches a shared dependency. It is a config property, not bad luck. ## The fix, and why I trust it `directories` (plural) watches the same three graphs from a single entry, and groups span them. Verified empirically rather than from documentation — aletheia already uses this form, and its dependabot PR #6897 is titled *"bump the patch-updates group across 2 directories"* with `Cargo.lock` **and** `fuzz/Cargo.lock` in one diff. That is exactly the shape thumos could not produce. ## What is preserved The previous comment's coverage rationale, verbatim in substance. It was right, and it was learned expensively: watching only `/` is how `fuzz/Cargo.lock` drifted nine releases with two path-dependencies missing entirely, invisible to `cargo audit` and `cargo deny` the whole time (#768). That fix was correct about *which* graphs to watch. This changes how that coverage is expressed, not how much of it there is — same three directories, one entry instead of three. ## Scope Config only. No dependency versions change here. Co-authored-by: forkwright <cody@forkwright.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Consolidates #925, #924, and #923, which cannot land individually.
Why three PRs could not work
This repository carries three independent lockfiles —
Cargo.lock,crates/thumos/Cargo.lock,fuzz/Cargo.lock— and declaressmoltcpin two manifests. Dependabot saw one shared version-range change in the rootCargo.tomland opened three PRs, each regenerating exactly one lockfile:Cargo.lockcrates/thumospin + lock,fuzz/Cargo.lockcrates/thumos/Cargo.lockCargo.lock,fuzz/Cargo.lockfuzz/Cargo.lockCargo.lock,crates/thumospinEach therefore failed the repo's own drift gates, with two distinct signatures:
No single PR could pass, and merging any one would have left the others' graphs disagreeing with the manifest they resolve from. This is a structural property of the repo's multi-graph layout, not a dependabot defect — dependabot has no way to express one change spanning three resolution roots.
What this does
0.14.crates/aitherneeds no change: it inherits viaworkspace = true.RUSTSEC-2026-0173suppression fromdeny.toml,.cargo/audit.toml, andosv-scanner.toml.That last one deserves a sentence. The advisory covers
proc-macro-error2, which reached these graphs only through smoltcp's optionaldefmtfeature. 0.14 drops that edge —defmt v0.3.100disappears fromcrates/thumos/Cargo.lockon the update, andproc-macro-error2is now absent from all three lockfiles. The suppression's stated reason had already gone stale, describing "smoltcp 0.12" while the manifests were on 0.13. A suppression asserting the presence of a crate that is in no graph is a false claim the next reader has to disprove before they can act on it, so it goes with the bump that made it untrue rather than waiting to be noticed.Verification, run before pushing
cargo metadata --lockedresolves in all three graphs — the exact failure that killed all three original PRs.check-pin-parity.shandcheck-lockfile-manifest.shboth pass — the two gates they tripped.check-external-lockfile-versions.shpasses against each of the three lockfiles individually.Full CI is the real verdict; the above is what could be established locally.
After this merges
Supersedes #925, #924 and #923. They need closing by hand once this lands: a closing keyword
would not close them in any case, since those keywords act on issues rather than pull requests.