chore(deps): bump smoltcp from 0.13.1 to 0.14.0 in /fuzz - #923
chore(deps): bump smoltcp from 0.13.1 to 0.14.0 in /fuzz#923dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [smoltcp](https://github.com/smoltcp-rs/smoltcp) from 0.13.1 to 0.14.0. - [Release notes](https://github.com/smoltcp-rs/smoltcp/releases) - [Changelog](https://github.com/smoltcp-rs/smoltcp/blob/main/CHANGELOG.md) - [Commits](smoltcp-rs/smoltcp@v0.13.1...v0.14.0) --- updated-dependencies: - dependency-name: smoltcp dependency-version: 0.14.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
#926) 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 declares `smoltcp` in **two manifests**. Dependabot saw one shared version-range change in the root `Cargo.toml` and opened three PRs, each regenerating exactly one lockfile: | PR | regenerates | leaves 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 therefore failed the repo's own drift gates, with two distinct signatures: ``` PIN DRIFT ... crates/thumos/Cargo.toml: smoltcp = "0.13" but workspace declares "0.14" error: cannot update the lock file ... because --locked was passed ``` 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 - Both manifests → `0.14`. `crates/aither` needs no change: it inherits via `workspace = true`. - All three lockfiles regenerated. - Drops the `RUSTSEC-2026-0173` suppression from `deny.toml`, `.cargo/audit.toml`, and `osv-scanner.toml`. That last one deserves a sentence. The advisory covers `proc-macro-error2`, which reached these graphs only through smoltcp's optional `defmt` feature. 0.14 drops that edge — `defmt v0.3.100` disappears from `crates/thumos/Cargo.lock` on the update, and `proc-macro-error2` is 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 --locked` resolves in **all three** graphs — the exact failure that killed all three original PRs. - `check-pin-parity.sh` and `check-lockfile-manifest.sh` both pass — the two gates they tripped. - `check-external-lockfile-versions.sh` passes against each of the three lockfiles individually. - All five edited TOML files parse. 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. Co-authored-by: forkwright <cody@forkwright.com>
|
Superseded by #926, now merged, which carries this bump along with the other two thirds of it. This PR could not have landed on its own. The repository has three independent lockfiles — That is a structural property of the multi-graph layout, not a defect in this PR — dependabot has no way to express a single change spanning three resolution roots. #926 verified all three graphs resolve under Closing as superseded rather than stale: the work in it landed. |
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
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>
Bumps smoltcp from 0.13.1 to 0.14.0.
Release notes
Sourced from smoltcp's releases.
Changelog
Sourced from smoltcp's changelog.
Commits
cbfe05fMerge pull request #1196 from smoltcp-rs/release-v0.14.03f001ddRelease 0.14.0.7baefa5Merge pull request #1148 from cagatay-y/segmentation-offload5393f88Merge pull request #1194 from Aditya-9-6/perf/tcp-option-fastpath2fd4550style(fmt): format options_bytes array in tcp.rsdb4cc69fix(wire/tcp): add #[non_exhaustive] attribute to TcpOptionSummary78db815perf(wire/tcp): add single-pass zero-allocation TcpOptionSummary parser888565dMerge pull request #1192 from hermit-os/defmt-v1155731fUpgradedefmtto version 1ed9acabMerge pull request #1171 from cirvladimir/build-warning-fixesDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)