Repository navigation
Update Playback engine dependencies - #625
renovate[bot] wants to merge 1 commit into
Conversation
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
Documentation review of f95927c (first review): 0 new finding(s). No actionable findings remain in the reviewed scope.
Inspected full PR #625 (rust-toolchain.toml channel 1.98.1 → 1.99.0, one line, no doc edits) via both docs-sense and docs-spec subagents against the head tree; documentation impact is none — docs/development/setup.md stays version-agnostic and true, CI/build scripts consume the toolchain dynamically, vendored rust-version 1.85 floor remains satisfied, and the dated 1.98.1 measurement record correctly stays untouched; no product-contract, repository-rule, or historical-record change was declared and none was required.
- No new findings.
Coverage limits: used branch-rules, check-runs, and ci-runtime snapshots (all checks in_progress at head, no completed passing run) plus the acceptance manifest; acceptance scenarios, UI runtime report, and App installation permissions were not supplied/collected, so no build, UI, playback, permission, or performance result is claimed.
Trusted repository collaborators can rerun this review by commenting @docs-review review.
There was a problem hiding this comment.
Thermos review of f95927c (first review): 0 new finding(s). No actionable findings remain in the reviewed scope.
Inspected full PR diff (rust-toolchain.toml channel 1.98.1 → 1.99.0, one line), PR description with Rust 1.99.0 release/compat notes, head file content at f95927c, rg sweeps for compat risks, and head-matched branch rules, check runs, CI runtime and acceptance manifest via both correctness and quality auditors.
- No new findings.
Coverage limits: Source policies success at head proves only its recorded execution; macOS verification queued and Linux domain, Playback script checks, documentation-review and thermos-review in progress/queued are pending and prove nothing yet; acceptance_scenarios not supplied (no completed head-matched CI run), no UI report/screenshot manifest, and no App installation permissions collected; this toolchain-only PR declares no product-contract or scenario change so no scenario IDs verified and none required, with pending macOS verification the explicit unverified gate.
Trusted repository collaborators can rerun this review by commenting @thermos review.
f95927c to
4b001f8
Compare
renovate
Bot
changed the title
There was a problem hiding this comment.
Documentation review of 4b001f8 (history rewritten since f95927c): 0 new finding(s). No actionable findings remain in the reviewed scope.
Inspected full PR 625 diff (Backend/spotty-playback/Cargo.toml and Cargo.lock librespot 939dc5e to e023adb, rust-toolchain.toml 1.98.1 to 1.99.0; no documentation hunks) with docs-sense and docs-spec against the head, assessing documentation impact against canonical guides (docs/product/queue.md, docs/development/setup.md and playback-artifacts.md, engine-contract and playback-engine-ownership, ADR-005 and ADR-006); no version-pinned claim goes stale, the Renovate table needs no contract or rule declaration, and no undeclared contract, rule, or historical-record change was found.
- No new findings.
Coverage limits: used pr.md, pr/changes diffs at head plus branch-rules and head-matched check-runs/ci-runtime snapshots (only Source policies success at head, other jobs in progress, proving recorded execution only); acceptance scenarios and UI runtime report not supplied and App installation permissions not collected per evidence.json, so no UI, playback, permission, or performance result is claimed.
Trusted repository collaborators can rerun this review by commenting @docs-review review.
There was a problem hiding this comment.
Thermos review of 4b001f8 (history rewritten since f95927c): 1 new finding(s).
Inspected full-mode changes.diff (== pr.diff, 3 files) at head 4b001f8 with both correctness and quality auditors plus direct head verification (Cargo.toml/Cargo.lock, vendor UPSTREAM/manifests, generate-playback-notices.py, and cargo check).
- [P1]
Backend/spotty-playback/Cargo.toml:21— half-migrated librespot rev duplicateslibrespot-protocoland failscargo check(E0308 atobserved_resume.rs:450) and the retainedUPSTREAM==pinnedprovenance gate; complete the vendor rebase toe023adbwith a single lock entry or revert pins to939dc5e.
Coverage limits: acceptance manifest present (digest f835a65) but no verified scenarios (acceptance_scenarios not supplied, no completed head-matched CI run); dependency-only PR outside acceptance corpus with no declared contract/scenario changes, so no ID/version/corpus mismatch; check-runs show Source policies success with macOS verification, Linux domain, Playback script checks, documentation-review and thermos-review in_progress (run 37356282353), UI report and App permissions not supplied — pending CI proves nothing and build failure above is from executedcargo check, not source inference.
Trusted repository collaborators can rerun this review by commenting @thermos review.
| once_cell = "1.19" | ||
| serde_json = "1.0" | ||
| librespot-protocol = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-protocol = { git = "https://github.com/librespot-org/librespot", rev = "e023adbbf017ae1fc10d01531dbe50c409786f2d" } |
There was a problem hiding this comment.
[P1] Half-migrated librespot rev splits librespot-protocol into two crate identities and breaks the build plus the retained-patch provenance gate. Backend/spotty-playback/Cargo.toml pins e023adb for the direct librespot-protocol dependency, but [patch.librespot] still resolves core/connect/playback to vendor/librespot/*, whose manifests and vendor/librespot/UPSTREAM still pin 939dc5e. Evidence: head Cargo.lock carries two librespot-protocol 0.8.0 packages (old-rev source vs new-rev source) with vendored dependents on the old rev and spotty-playback on the new rev; cargo check --manifest-path Backend/spotty-playback/Cargo.toml at head fails with E0308 mismatched types at src/observed_resume.rs:450 (PlayerState from the new protocol passed to vendored connect/src/spirc.rs:transfer_observed expecting the old protocol's PlayerState); Scripts/generate-playback-notices.py:459-467 requires UPSTREAM (939dc5e) == Cargo.toml rev (e023adb) for path-patched core/connect/playback and would fail artifact publication. Fix in one PR: either complete the migration (rebase vendor/librespot/{core,connect,playback} + UPSTREAM/README/vendored manifests to e023adb and regenerate the lock to a single protocol revision) or revert the five Cargo.toml rev bumps and lock to 939dc5e.
There was a problem hiding this comment.
Persists at head e01963a: Cargo.toml pins 4a00590 while vendor manifests and UPSTREAM still pin 939dc5e, and Cargo.lock still carries two librespot-protocol 0.8.0 entries with vendored dependents on the old rev and spotty-playback on the new rev.
There was a problem hiding this comment.
Persists at head 79e67f4 with new rev 60368dd: Cargo.toml direct librespot deps pin 60368dd while vendor/librespot manifests and UPSTREAM still pin 939dc5e, Cargo.lock still carries two librespot-protocol 0.8.0 entries (new rev for spotty-playback, old rev for vendored dependents), and the notices-script provenance gates still fail. Left unresolved.
There was a problem hiding this comment.
Persists at head 710e23e: Cargo.toml pins 6212dcf while vendor manifests and UPSTREAM still pin 939dc5e, and Cargo.lock still carries two librespot-protocol 0.8.0 entries. Left unresolved.
There was a problem hiding this comment.
Persists at head 9be71ee: Cargo.toml pins 1995951 while UPSTREAM and vendored manifests still pin 939dc5e, Cargo.lock still carries two librespot-protocol 0.8.0 entries, and the observed_resume.rs transfer_observed cross-boundary site remains.
4b001f8 to
e01963a
Compare
There was a problem hiding this comment.
Documentation review of e01963a (history rewritten since 4b001f8): 1 new finding(s).
Inspected PR 625 in full mode (base 9b5d72b..head e01963a) via both subagents over changes.diff plus repo context: 3 implementation files (Backend/spotty-playback/Cargo.toml, Cargo.lock, rust-toolchain.toml) with no changed docs, so assessed documentation impact explicitly; checked canonical owners THIRD_PARTY_NOTICES.md, Backend/spotty-playback/vendor/librespot/README.md and UPSTREAM, Scripts/generate-playback-notices.py, docs/development/setup.md and verification.md, docs/product/queue.md and playback.md, and ADR-005, and found no product-contract, repository-rule, or historical-record rewrite; PR description declares only Renovate dependency bumps (librespot 939dc5e to 4a00590, rust 1.98.1 to 1.99.0, claimed tokio 1.53.1 to 1.53.2 which Cargo.lock shows did not occur, still 1.53.1) with no contract/rule declarations and none required beyond the legal-notice omission below.
- [P2] Backend/spotty-playback/Cargo.toml:14 — librespot pin now 4a00590 leaves THIRD_PARTY_NOTICES.md:32-33 singular 939dc5e claim stale and retained UPSTREAM/vendor mismatched so the notice generator invariant fails; complete the rebase sync (UPSTREAM, vendor manifests, notice) or document both revs.
Coverage limits: used branch-rules.json, check-runs.json and ci-runtime.json (all required checks in_progress, none completed at head), acceptance-manifest.json present; acceptance_scenarios and ui_runtime_report not supplied and app_installation_permissions not collected, so no UI, playback, permission, or performance result is claimed and no passing CI step is cited.
Trusted repository collaborators can rerun this review by commenting @docs-review review.
| [dependencies] | ||
| librespot-core = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-connect = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-core = { git = "https://github.com/librespot-org/librespot", rev = "4a005903e078d512456fb008aaa9ba6246881bd9" } |
There was a problem hiding this comment.
[P2] Direct librespot pin moved to 4a005903e078d512456fb008aaa9ba6246881bd9 but the canonical legal notice THIRD_PARTY_NOTICES.md:32-33 still claims a singular pin to 939dc5ee9d833e1980f9495241219d9d4868a061, and the retained base still records the old rev. Evidence: Backend/spotty-playback/Cargo.toml:14-15,17,21,42 all request 4a00590 at head while Backend/spotty-playback/vendor/librespot/UPSTREAM:1 and Backend/spotty-playback/vendor/librespot/README.md:3-5 still record 939dc5e; Backend/spotty-playback/Cargo.lock now has two librespot-protocol packages (new-rev entry at :36-43 used by spotty-playback at :2256, old-rev entries retained for vendored crates at :1164,1198,1239); Scripts/generate-playback-notices.py:459-468 fails when retained UPSTREAM != Cargo.toml pinned rev (at head 939dc5e != 4a00590), and prior bump 9737819 synchronized Cargo.toml, UPSTREAM, vendor manifests and THIRD_PARTY_NOTICES.md together per vendor README review-on-pin-update rule. Fix: complete the provenance sync as in 9737819 — rebase vendor/librespot + UPSTREAM to 4a00590, update THIRD_PARTY_NOTICES.md:33 and vendor README pin, regenerate artifact notices — or, if the split graph is intentional, replace the singular pin claim with both revisions (retained 939dc5e vs direct-protocol 4a00590).
There was a problem hiding this comment.
Verified at head 79e67f4 persists with new rev: Cargo.toml pins 60368dd while THIRD_PARTY_NOTICES.md:32-33, UPSTREAM, vendor README/preamble/overrides and retained lock entries still record 939dc5e with split librespot-protocol graph; generator fails closed per generate-playback-notices.py:459-468.
There was a problem hiding this comment.
Still open at head 710e23e: Cargo.toml:14-15,17,21,42 pin 6212dcf while THIRD_PARTY_NOTICES.md:32-33 and preamble still claim singular 939dc5e and Cargo.lock retains the split librespot-protocol graph (new rev for spotty-playback, old rev for vendored crates); UPSTREAM vs Cargo.toml mismatch still trips the generate-playback-notices.py:459-468 gate.
There was a problem hiding this comment.
Thermos review of e01963a (history rewritten since 4b001f8): 0 new finding(s). 1 earlier thread(s) remain open.
Inspected full-mode PR 625 at head e01963a (base 9b5d72b): pr.diff == changes.diff (Cargo.toml, Cargo.lock, rust-toolchain.toml), repo files, acceptance manifest, branch rules, head-matched check-runs and CI runtime via both correctness and quality audits.
- No new findings: the dual-revision librespot-protocol split remains tracked by the existing thread and is not re-reported; the absent tokio lock bump has no demonstrated defect and needs no code fix.
- Thread PRRT_kwDOUCEj686pKf4H persists (not resolved): verified Cargo.toml at 4a00590 vs vendor manifests/UPSTREAM at 939dc5e and two librespot-protocol 0.8.0 lock entries with split dependents.
- Coverage limits: Source policies success proves only its recorded execution at e01963a; macOS verification queued and Linux domain, Playback script checks, documentation-review and thermos-review still in progress so pending CI is an explicit gap; no verified acceptance scenarios (no acceptance_scenarios snapshot, no manifest or scenario change, engine rev change outside the recorded corpus assertions), description lists tokio 1.53.1→1.53.2 but the lock remains at 1.53.1; no UI report or App permission evidence supplied.
Trusted repository collaborators can rerun this review by commenting @thermos review.
| once_cell = "1.19" | ||
| serde_json = "1.0" | ||
| librespot-protocol = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-protocol = { git = "https://github.com/librespot-org/librespot", rev = "e023adbbf017ae1fc10d01531dbe50c409786f2d" } |
There was a problem hiding this comment.
Persists at head e01963a: Cargo.toml pins 4a00590 while vendor manifests and UPSTREAM still pin 939dc5e, and Cargo.lock still carries two librespot-protocol 0.8.0 entries with vendored dependents on the old rev and spotty-playback on the new rev.
e01963a to
79e67f4
Compare
There was a problem hiding this comment.
Documentation review of 79e67f4 (history rewritten since e01963a): 0 new finding(s). 1 earlier thread(s) remain open.
Inspected full PR 625 base...head 79e67f4 with docs-sense and docs-spec over changes.diff (= pr.diff, 3 implementation files: Backend/spotty-playback/Cargo.toml, Cargo.lock, rust-toolchain.toml) against head source; documentation impact is implementation-only with no changed docs but a concrete stale-provenance impact already tracked — checked canonical THIRD_PARTY_NOTICES.md, vendor/librespot UPSTREAM/README and manifests, Scripts/playback-notices-preamble.md, playback-license-overrides.json and generate-playback-notices.py, ADR-005/ADR-006, engine-contract.md, playback-engine-ownership.md, setup.md and measurements; pr.md declares no product-contract or rule change (Renovate table only) and no declared change required disposition.
- No new findings — the librespot pin split and stale legal/provenance pin duplicate the open thread below, and rust 1.99.0, setup, measurements and ADRs need no update; pr.md serde_json/tokio bumps are absent from the diff and lock with no contract impact.
Thread PRRT_kwDOUCEj686qu_w9: verified persists at head 79e67f4 (Cargo.toml 60368dd vs THIRD_PARTY_NOTICES.md:32-33, UPSTREAM, README, preamble/overrides and retained lock 939dc5e with split protocol graph), kept open.
Coverage: used pr.diff, changes.diff, pr.md, threads.json, branch-rules, check-runs, ci-runtime and acceptance-manifest at head 79e67f4; acceptance_scenarios and ui_runtime_report not supplied, app installation permissions not collected, all head checks in_progress with no passing gate, and no upstream 60368dd diff supplied — no build, UI, playback, permission or performance result claimed beyond recorded step execution at its revision.
Trusted repository collaborators can rerun this review by commenting @docs-review review.
| [dependencies] | ||
| librespot-core = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-connect = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-core = { git = "https://github.com/librespot-org/librespot", rev = "4a005903e078d512456fb008aaa9ba6246881bd9" } |
There was a problem hiding this comment.
Verified at head 79e67f4 persists with new rev: Cargo.toml pins 60368dd while THIRD_PARTY_NOTICES.md:32-33, UPSTREAM, vendor README/preamble/overrides and retained lock entries still record 939dc5e with split librespot-protocol graph; generator fails closed per generate-playback-notices.py:459-468.
There was a problem hiding this comment.
Thermos review of 79e67f4 (history rewritten since e01963a): 1 new finding(s). 1 earlier thread(s) remain open.
Inspected full PR 625 (base 9b5d72b…head 79e67f4, history rewritten) with correctness and quality auditors: Cargo.toml/Cargo.lock/toolchain diff, head vendor manifests and UPSTREAM, observed_resume.rs→vendored spirc type edge, generate-playback-notices.py gates, and head-matched branch-rule/check/CI snapshots.
- [P3] Backend/spotty-playback/Cargo.lock:2256 — advertised tokio 1.53.1→1.53.2 and serde_json 1.0.151→1.0.154 did not land: head lock still holds 1.53.1/1.0.151, identical to base; land the registry update or narrow the PR description.
- Thread PRRT_kwDOUCEj686pKf4H (Backend/spotty-playback/Cargo.toml:21 split-rev protocol graph): verified still present at head — direct deps pin 60368dd while vendor patches/UPSTREAM pin 939dc5e with two librespot-protocol identities in the lock — left unresolved, no duplicate finding filed.
- Coverage limits: used pr/changes diffs, head manifests/lock/vendor sources, notice-script gates, branch rules, and in-progress check/CI snapshots; acceptance_scenarios not supplied and all head CI checks were in_progress, so no verified scenarios (representative IDs shell.signed-out, browsing.navigation, playback.recovery unverified; holdout variations acceptance-only); no build executed and no UI/playback/permission result claimed; declaration mismatch: PR claims tokio 1.53.2/serde_json 1.0.154 but lock shows 1.53.1/1.0.151.
Trusted repository collaborators can rerun this review by commenting @thermos review.
| "librespot-core", | ||
| "librespot-playback", | ||
| "librespot-protocol", | ||
| "librespot-protocol 0.8.0 (git+https://github.com/librespot-org/librespot?rev=60368dde8362881f233880d4e8beafb4150aafbb)", |
There was a problem hiding this comment.
[P3] Claimed tokio/serde_json bumps did not land in the lockfile. The PR description advertises tokio 1.53.1 → 1.53.2 and serde_json 1.0.151 → 1.0.154, but the Cargo.lock diff contains only librespot lines and the head lock still pins tokio 1.53.1 (Cargo.lock:2555) and serde_json 1.0.151 (Cargo.lock:2106), byte-identical to base 9b5d72b (verified via git show of both revisions; the lock diff has no tokio/serde_json hunks). Reviewers will believe the registry updates applied when they did not, and the next Renovate run will re-propose them. Fix: either run the registry update into the lock (e.g. cargo update -p tokio -p serde_json) or narrow the PR title/body to the librespot-only change actually delivered.
There was a problem hiding this comment.
Persists at head 710e23e: Cargo.lock still pins tokio 1.53.1 and serde_json 1.0.151 with no tokio/serde_json hunks in the diff. Left unresolved.
There was a problem hiding this comment.
Persists at head 9be71ee: Cargo.lock still pins tokio 1.53.1 and serde_json 1.0.151 with no tokio/serde_json hunks in the diff, while the description still advertises 1.53.2/1.0.154.
| once_cell = "1.19" | ||
| serde_json = "1.0" | ||
| librespot-protocol = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-protocol = { git = "https://github.com/librespot-org/librespot", rev = "e023adbbf017ae1fc10d01531dbe50c409786f2d" } |
There was a problem hiding this comment.
Persists at head 79e67f4 with new rev 60368dd: Cargo.toml direct librespot deps pin 60368dd while vendor/librespot manifests and UPSTREAM still pin 939dc5e, Cargo.lock still carries two librespot-protocol 0.8.0 entries (new rev for spotty-playback, old rev for vendored dependents), and the notices-script provenance gates still fail. Left unresolved.
79e67f4 to
710e23e
Compare
There was a problem hiding this comment.
Thermos review of 710e23e (history rewritten since 79e67f4): 2 new finding(s). 2 earlier thread(s) remain open.
Inspected full PR diff (base 9b5d72b...head 710e23e) with both auditors, head source (Cargo.toml/lock, vendor UPSTREAM/manifests, notices/promotion/build scripts, toolchain), PR description, and head-matched CI snapshots.
- [P1] Backend/spotty-playback/Cargo.lock:1285 — split protocol identity also fails notices generation via the (name, version) ambiguity gate, and the forward fix must also update the librespot-* license override still pinning the old rev.
- [P2] Backend/spotty-playback/Cargo.toml:14 — staged provenance would claim the new rev while compiled vendored sources remain the old rev, and promotion does not check librespotRevision.
- Thread PRRT_kwDOUCEj686pKf4H (split-rev build/provenance break): unresolved, split persists at head with rev 6212dcf vs vendor 939dc5e and two lock entries.
- Thread PRRT_kwDOUCEj686tLnaA (phantom tokio/serde_json bumps): unresolved, lock still pins tokio 1.53.1 and serde_json 1.0.151.
- Coverage limits: branch rules, check-runs, CI runtime, and head acceptance manifest read; CI at head is in_progress with no completed head-matched run so acceptance_scenarios is not_supplied (no verified scenario IDs); no UI report or App permissions available; no build/playback outcome claimed beyond inspected source and lock/script evidence.
Trusted repository collaborators can rerun this review by commenting @thermos review.
| [[package]] | ||
| name = "librespot-protocol" | ||
| version = "0.8.0" | ||
| source = "git+https://github.com/librespot-org/librespot?rev=6212dcfe6ca5d81035e56fc0ef699ec233410da9#6212dcfe6ca5d81035e56fc0ef699ec233410da9" |
There was a problem hiding this comment.
[P1] Split librespot-protocol identity deterministically fails notices generation through gates the existing thread does not cover. Head Cargo.lock carries two librespot-protocol 0.8.0 packages: new rev 6212dcf (Cargo.lock:1283-1289, used by spotty-playback at Cargo.lock:2256) and old rev 939dc5e (Cargo.lock:1291-1298, used by vendored core/connect dependents at Cargo.lock:1164,1198,1239). Scripts/generate-playback-notices.py keys cargo metadata by (name, version) only and fails on duplicates ('ambiguous package identity', lines 763-768), so generation cannot succeed while the split persists; this is distinct from the UPSTREAM==pinned gate already tracked. Additionally, a forward migration must update Scripts/playback-license-overrides.json: the 'librespot-*' override still pins source_revision 939dc5e (lines 68-80), so validate_override (lines 224-232, 259-269) would report 'source revision mismatch' for the new git protocol (expected 939dc5e vs actual 6212dcf). Evidence: Cargo.lock:1285 vs :1294; Cargo.toml:14,15,17,21 pin 6212dcf while vendor/librespot/UPSTREAM and vendored manifests pin 939dc5e. Fix in one PR: either complete the migration (rebase vendor/librespot core/connect/playback + UPSTREAM + vendored manifests + license overrides to 6212dcf and regenerate the lock to a single protocol entry) or revert Cargo.toml revs and lock to 939dc5e.
There was a problem hiding this comment.
Persists at head 9be71ee: two librespot-protocol 0.8.0 lock entries still trip the (name, version) duplicate gate, and playback-license-overrides.json still pins 939dc5e for librespot-*.
| [dependencies] | ||
| librespot-core = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-connect = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-core = { git = "https://github.com/librespot-org/librespot", rev = "6212dcfe6ca5d81035e56fc0ef699ec233410da9" } |
There was a problem hiding this comment.
[P2] Published provenance misattributes the compiled librespot sources while the split persists. Backend/spotty-playback/build-xcframework.sh extracts librespot-core rev from Cargo.toml (lines 132-133) into provenance 'librespotRevision' (line 178), so head provenance would claim 6212dcf; but [patch.librespot] (Cargo.toml:35-38) redirects core/connect/playback to vendor path inputs (Cargo.lock path entries with no source) whose vendor/librespot/UPSTREAM and vendored manifests still pin 939dc5e, so the artifact is mostly old code. Scripts/playback_promotion.py validate_payload (lines 100-134) checks sourceRevision/digest/dirty only, not librespotRevision, so the misattribution would pass promotion. Evidence: Cargo.toml:14 (6212dcf) vs UPSTREAM:1 (939dc5e); build-xcframework.sh:132-133,178-179; playback_promotion.py:112-117 has no librespotRevision check. Fix: unify revs per the P1 fix so Cargo.toml rev == UPSTREAM == compiled inputs; consider adding a librespotRevision==UPSTREAM promotion/validation check.
There was a problem hiding this comment.
Persists at head 9be71ee: build-xcframework.sh still stamps librespotRevision from Cargo.toml (1995951) while [patch] compiles vendored 939dc5e sources.
| once_cell = "1.19" | ||
| serde_json = "1.0" | ||
| librespot-protocol = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-protocol = { git = "https://github.com/librespot-org/librespot", rev = "e023adbbf017ae1fc10d01531dbe50c409786f2d" } |
There was a problem hiding this comment.
Persists at head 710e23e: Cargo.toml pins 6212dcf while vendor manifests and UPSTREAM still pin 939dc5e, and Cargo.lock still carries two librespot-protocol 0.8.0 entries. Left unresolved.
| "librespot-core", | ||
| "librespot-playback", | ||
| "librespot-protocol", | ||
| "librespot-protocol 0.8.0 (git+https://github.com/librespot-org/librespot?rev=60368dde8362881f233880d4e8beafb4150aafbb)", |
There was a problem hiding this comment.
Persists at head 710e23e: Cargo.lock still pins tokio 1.53.1 and serde_json 1.0.151 with no tokio/serde_json hunks in the diff. Left unresolved.
There was a problem hiding this comment.
Documentation review of 710e23e (history rewritten since 79e67f4): 0 new finding(s). 1 earlier thread(s) remain open.
Full docs review of #625 at head 710e23e via docs-sense and docs-spec over changes.diff (= pr.diff, 96 lines across Backend/spotty-playback/Cargo.toml, Backend/spotty-playback/Cargo.lock, rust-toolchain.toml) with head-tree verification; documentation impact is indirect (no docs touched, but librespot 939dc5e→6212dcf and rust 1.98.1→1.99.0 bumps make the singular-pin legal notice stale); inspected canonical THIRD_PARTY_NOTICES.md:32-33, Scripts/playback-notices-preamble.md:32-33, vendor/librespot UPSTREAM/README/manifests, Scripts/generate-playback-notices.py:459-468 plus overrides, docs/development/setup.md, docs/product/*, engine-contract, enforcement/build-and-abi, ADR-005, and measurement records; pr.md's Renovate table names versions but no governed document or rationale so it declares nothing, and the diff touches no product contract, repository rule, or historical record, so no declared or undeclared contract/rule change.
- No new findings (the librespot pin vs legal-notice mismatch verified at head is already tracked by thread PRRT_kwDOUCEj686qu_w9 and suppressed as a duplicate).
Thread PRRT_kwDOUCEj686qu_w9: verified persists at head 710e23e (Cargo.toml pins 6212dcf vs notices/preamble singular 939dc5e with split Cargo.lock graph and UPSTREAM mismatch against the generator gate), kept open with an updated-rev reply.
Coverage limits: used pr.md, identical pr/changes diffs, threads.json, evidence.json plus branch-rules, check-runs (Source policies success, others queued/in_progress), and ci-runtime snapshots at head 710e23e; acceptance scenarios and UI runtime report not supplied and app installation permissions not collected, so no UI, playback, permission, or performance result is claimed and CI proves only recorded execution at its revision.
Trusted repository collaborators can rerun this review by commenting @docs-review review.
| [dependencies] | ||
| librespot-core = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-connect = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-core = { git = "https://github.com/librespot-org/librespot", rev = "4a005903e078d512456fb008aaa9ba6246881bd9" } |
There was a problem hiding this comment.
Still open at head 710e23e: Cargo.toml:14-15,17,21,42 pin 6212dcf while THIRD_PARTY_NOTICES.md:32-33 and preamble still claim singular 939dc5e and Cargo.lock retains the split librespot-protocol graph (new rev for spotty-playback, old rev for vendored crates); UPSTREAM vs Cargo.toml mismatch still trips the generate-playback-notices.py:459-468 gate.
710e23e to
9be71ee
Compare
There was a problem hiding this comment.
Thermos review of 9be71ee (history rewritten since 710e23e): 0 new finding(s). 4 earlier thread(s) remain open.
Inspected full Renovate playback-dependency bump at head 9be71ee (base 9b5d72b) via pr/changes diffs, head Cargo.toml/Cargo.lock/vendor UPSTREAM and manifests, notices/provenance/promotion scripts, and head-matched branch rules plus check/CI snapshots with both correctness and quality auditors.
No new findings.
Thread PRRT_kwDOUCEj686pKf4H (split-protocol build break plus UPSTREAM gate): verified persisting, left unresolved.
Thread PRRT_kwDOUCEj686tLnaA (advertised tokio/serde_json bumps absent from lock): verified persisting, left unresolved.
Thread PRRT_kwDOUCEj686tRxTl (notices duplicate-identity plus license-override mismatch): verified persisting, left unresolved.
Thread PRRT_kwDOUCEj686tRxTt (provenance misattribution): verified persisting, left unresolved.
Coverage limits: branch rules, head-matched check-runs (all in_progress except cubic neutral) and CI runtime (run 38957161072 in_progress), and acceptance manifest (shell.signed-out, browsing.navigation, playback.recovery, holdout.playback-stale-order) were read; no verified scenarios since acceptance_scenarios is not supplied and CI is still pending, the description declares no contracts or scenario IDs so the playback-engine rev change leaves playback.recovery acceptance unverified, and there is no UI report or App permission evidence.
Trusted repository collaborators can rerun this review by commenting @thermos review.
| once_cell = "1.19" | ||
| serde_json = "1.0" | ||
| librespot-protocol = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-protocol = { git = "https://github.com/librespot-org/librespot", rev = "e023adbbf017ae1fc10d01531dbe50c409786f2d" } |
There was a problem hiding this comment.
Persists at head 9be71ee: Cargo.toml pins 1995951 while UPSTREAM and vendored manifests still pin 939dc5e, Cargo.lock still carries two librespot-protocol 0.8.0 entries, and the observed_resume.rs transfer_observed cross-boundary site remains.
| "librespot-core", | ||
| "librespot-playback", | ||
| "librespot-protocol", | ||
| "librespot-protocol 0.8.0 (git+https://github.com/librespot-org/librespot?rev=60368dde8362881f233880d4e8beafb4150aafbb)", |
There was a problem hiding this comment.
Persists at head 9be71ee: Cargo.lock still pins tokio 1.53.1 and serde_json 1.0.151 with no tokio/serde_json hunks in the diff, while the description still advertises 1.53.2/1.0.154.
| [[package]] | ||
| name = "librespot-protocol" | ||
| version = "0.8.0" | ||
| source = "git+https://github.com/librespot-org/librespot?rev=6212dcfe6ca5d81035e56fc0ef699ec233410da9#6212dcfe6ca5d81035e56fc0ef699ec233410da9" |
There was a problem hiding this comment.
Persists at head 9be71ee: two librespot-protocol 0.8.0 lock entries still trip the (name, version) duplicate gate, and playback-license-overrides.json still pins 939dc5e for librespot-*.
| [dependencies] | ||
| librespot-core = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-connect = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-core = { git = "https://github.com/librespot-org/librespot", rev = "6212dcfe6ca5d81035e56fc0ef699ec233410da9" } |
There was a problem hiding this comment.
Persists at head 9be71ee: build-xcframework.sh still stamps librespotRevision from Cargo.toml (1995951) while [patch] compiles vendored 939dc5e sources.
There was a problem hiding this comment.
Documentation review of 9be71ee (history rewritten since 710e23e): 1 new finding(s). 1 earlier thread(s) remain open.
Reviewed full PR 625 at head 9be71ee with docs-sense and docs-spec over changes.diff (identical to pr.diff, 3 files: Backend/spotty-playback/Cargo.toml, Backend/spotty-playback/Cargo.lock, rust-toolchain.toml, no docs changed) plus head inspection for documentation impact; inspected canonical THIRD_PARTY_NOTICES.md, Scripts/playback-notices-preamble.md, vendor/librespot UPSTREAM/README, Scripts/generate-playback-notices.py gate, and setup/toolchain guidance; PR description declares no product-contract or rule change (Renovate boilerplate only), so the librespot pin/provenance change below is undeclared, while the rust 1.98.1→1.99.0 bump declares nothing and requires no doc update.
- [P2] Backend/spotty-playback/Cargo.toml:14 — librespot rev 939dc5e→1995951 leaves THIRD_PARTY_NOTICES/preamble singular-pin claim, UPSTREAM/vendor README, and split Cargo.lock graph stale with generator mismatch gate tripped; rebase vendor+UPSTREAM/notices or document both revs with PR declaration.
Thread PRRT_kwDOUCEj686qu_w9 remains open: verified at head 9be71ee the same singular-pin vs split-graph mismatch persists (Cargo.toml 1995951 vs notices/UPSTREAM/vendor README 939dc5e, generator gate still trips), outdated flag is history-rewrite artifact only.
Coverage limits: used pr.md, pr.diff/changes.diff, branch-rules, check-runs (in_progress except cubic neutral), ci-runtime (in_progress), acceptance-manifest; acceptance_scenarios and ui_runtime_report not supplied and app_installation_permissions not collected per evidence.json, so no UI, playback, permission, or performance result is claimed.
Trusted repository collaborators can rerun this review by commenting @docs-review review.
| [dependencies] | ||
| librespot-core = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-connect = { git = "https://github.com/librespot-org/librespot", rev = "939dc5ee9d833e1980f9495241219d9d4868a061" } | ||
| librespot-core = { git = "https://github.com/librespot-org/librespot", rev = "19959512c212cbc48a3ff64382fe204f52c659a7" } |
There was a problem hiding this comment.
[P2] Direct librespot pin moved to 1995951 without provenance/legal sync, so the checked-in singular-pin claim is false and the notice generator fails closed — undeclared in the PR description. Evidence: Backend/spotty-playback/Cargo.toml:14-15,17,21,42 at head all pin rev 19959512c212cbc48a3ff64382fe204f52c659a7 while the canonical legal notice THIRD_PARTY_NOTICES.md:32-33 (owned via Scripts/playback-notices-preamble.md:32-33) still claims singular pin to 939dc5ee9d833e1980f9495241219d9d4868a061 including its unmodified connect crate; Backend/spotty-playback/vendor/librespot/UPSTREAM:1 and vendor/librespot/README.md:3-5 still record 939dc5e; Backend/spotty-playback/Cargo.lock at head has a split librespot-protocol graph (new-rev entry at :1285 used by spotty-playback at :2256, old-rev entries retained for vendored crates at :1164,1198,1239); Scripts/generate-playback-notices.py:459-468 fails when retained UPSTREAM != Cargo.toml pinned rev (at head 939dc5e != 1995951), and vendor/librespot/README.md:53-55 requires reviewing the upstream diff when updating the pin; pr.md:1-271 is Renovate boilerplate with Rust/tokio/serde release notes and declares no THIRD_PARTY_NOTICES, UPSTREAM, vendor README, or split-graph change. Fix: complete the provenance sync — rebase vendor/librespot + UPSTREAM to 1995951, update preamble:33 (hence THIRD_PARTY_NOTICES.md:33), vendor README pin, and regenerate artifact notices — or, if the split graph is intentional, replace the singular-pin claim with both revisions plus rationale and declare it in the PR description.
d0fcb6f to
803ffb0
Compare
803ffb0 to
9f04705
Compare
This PR contains the following updates:
939dc5e→15e02e8939dc5e→15e02e8939dc5e→15e02e8939dc5e→15e02e8939dc5e→15e02e80.4.34→0.4.351.98.1→1.99.11.100.01.0.151→1.0.1541.53.1→1.54.11.53.1→1.54.1Release Notes
rust-lang/log (log)
v0.4.35Compare Source
This release doesn't include source changes. It verifies
log's new CI/CD processes.Other
rust-lang/rust (rust)
v1.99.1Compare Source
===========================
wcslenon UEFI and embedded targetsboolreturn values on x86_64libLLVMon macOSv1.99.0Compare Source
==========================
Language
raw_borrows_via_referenceslint that checks for references that decay immediately into raw borrowsunconditional_paniclint to function calls that panic when the chunks/windows size is zero#[unsafe(naked)]functions to define C-variadic functions (#![feature(c_variadic_naked_functions)]).Sized#[my_macro] mod foo;. This allows outlined modules (mod foo;) anywhere in the body of a custom attribute or derive macro.overflowing_literalslint with repeated negation. For instance, it will now no longer lint on--128_i8, which is already detected by thearithmetic_overflowlint.invalid_runtime_symbol_definitionsandsuspicious_runtime_symbol_definitionslints#[path]attributes on inline modulesunreachable_cfg_select_predicateslint as part ofunusedlint groupasm!on x86UnsafeCellcan be accessed without going throughgetinvalid_reference_castinglint was adjusted accordinglyglobal_asm!docattribute is used on a macro invocationCompiler
-Ctarget-cpuinto a target-modifier for AVR, AMDGCN and NVPTXstatic_position_independent_executableson all gnu targetsPlatform Support
riscv64-unknown-linux-muslto Tier 2 with host toolsRefer to Rust's platform support page
for more information on Rust's tiered platform support.
Libraries
RangeInclusive(a..=branges) is now optimized better in some circumstances. As a side effect of this, the behavior ofRangeInclusivevalues that has already been exhausted (as an iterator) has changed. For example, the return values ofstart()andend()on such ranges may return different values, and using such ranges as slice indexes may have different behavior. These behaviors were not guaranteed to be stable, so these changes are considered to not be breaking changes.transmute_copyto accept?Sizedtypestransmute_copyto use a non-unwinding panicescape_debug_extcore::fmt::NumBufferinalloc(andstd)Stabilized APIs
IntoIteratorforBox<[T; N]>IntoIteratorfor&Box<[T; N]>IntoIteratorfor&mut Box<[T; N]>VecDeque::retain_backcore::ffi::VaListBox::into_non_nullBox::from_non_nullVec::into_partsVec::from_partscore::mem::size_of_val_rawcore::mem::align_of_val_rawcore::alloc::Layout::for_value_rawString::from_utf8_lossy_ownedstring::FromUtf8Error::into_utf8_lossyFusedIterator for StepBy<I>std::fs::set_timesstd::fs::set_times_nofollow<LocalKey<Cell<T>>>::updateCargo
debug. This is a preparation for transitioning thedevprofile away from debugging to give a saner default for faster development iterations. Currently there is no difference betweendevanddebugprofiles. docs #17214default-featuresfield. For example,serde = { workspace = true, default-features = false }now turns off default features even when the workspace definition enables them. On earlier editions,default-features = falseis ignored with a warning. (RFC 3945) #17126See also the full Cargo changelog
Rustdoc
unused_footnote_definitionrustdoc lintCompatibility Notes
std::i32::MAXshould be accessed viai32::MAXinstead.no_mangle_generic_itemsinto hard errorPin::new_uncheckedhas had its safety invariants changed slightlyletpatterns typecheckunsupported()instead offrom_raw_os_error(22)#[repr(simd)]was accidentally allowed on macro invocations on stable RustBox::leak: tell people to avoid unleakingdoc(cfg())into account when filtering doctests'staticsemicolon_in_expressions_from_non_local_macros) even when the macro comes from another crate. Previously, such warnings only appeared for macros from the same crate, to avoid showing warnings that can't be fixed locally; however, this masked problems, as integration tests from the crate providing the macro get compiled as a separate crate, so tests often wouldn't reveal this issue. If you encounter a lint like this, please make sure to report it to the crate providing the macro so they can fix it; don't just silence it in your own crate.semicolon_in_expressions_from_macros: Lint on non-local macros toosemicolon_in_expressions_from_macrosinto a separate lintCIenvironment variable. #17220Internal Changes
These changes do not affect any public interfaces of Rust, but they represent
significant improvements to the performance or internals of rustc and related
tools.
serde-rs/json (serde_json)
v1.0.154Compare Source
v1.0.153Compare Source
v1.0.152Compare Source
-0in arbitrary_precision mode (#1346, thanks @yuxi-liu-wired)tokio-rs/tokio (tokio)
v1.54.1: Tokio v1.54.1Compare Source
1.54.1 (October 21st, 2026)
Fixed
v1.54.0: Tokio v1.54.0Compare Source
1.54.0 (October 19th, 2026)
The 1.54.0 release includes all changes up to 1.53.3.
The MSRV is increased to 1.85. (#8514)
Added
File::set_times,File::set_modified, andfs::FileTimes(#8504)Defaultfornamed_pipe::{ClientOptions, ServerOptions}(#8378)Builder::max_io_events_per_busy_tick(#8410)tokio::runtime::worker_index()(#8431)SemaphorePermit::semaphore()(#8482)blocking_acquiremethods toSemaphore(#8269)watch::Receiver::is_closed(#8481)wasm32-unknown-emscriptentarget (#8281, #8422, #8528, #8628)Changed
File::set_max_buf_size(#8449)copy_bufcooperative (#8459)BufReaderorBufStreamis created with zero capacity (#8494)copy_bidirectional_with_sizes(#8454)Sink(#8663)UnixStream::pairandUnixDatagram::pairsockets as writable (#8444)UCredon Fuchsia (#8257)mio::unix::pipefor Unix child stdio (#8603)enable_ioavailable wheneverrtis enabled (#8387)block_in_placesetup into a non-generic function (#8315)max_io_events_per_tickis zero (#8476).awaitin nestedblock_onpanic message (#8501)Notify(#8325)Fixed
Fileinternal state when op fails (#8291)copy_buf(#8424)ScheduledIotick in readiness events (#8331)ErrorKind::Interruptedin more I/O operations (#8417, #8432, #8448, #8453, #8455, #8460)spawn_mandatory_blockingfor stdout and stderr (#8506)BufReaderseeks (#8599)CreateFileWhandle onSetNamedPipeHandleStatefailure (#8418)TcpSocketandUnixSocketlisten backlog (#8511)ENOTCONNas success inUnixStream::shutdown(#8526)--all-featureswithouttokio_unstable(#8401)shutdown_timeout()(#8497)spawn_blockinghang when only scheduler workers exist (#8408)usizefor permit count inSemaphorePermit(#8405)Unstable
io_uringhas no IO driver (#8165)spawn_blockingqueue (#8337)Documented
tokio::fs(#8265)from_raw_handle(#8378)TcpStream::connectreturns only the last error (#8421)runtime::Builder(#8297)available_parallelismin worker count docs (#8625)broadcast::channel()(#8420)Semaphoredocumentation (#8521)v1.53.3: Tokio v1.53.3Compare Source
1.53.3 (October 13th, 2026)
Added
AsyncFd::registerandAsyncFd::register_with_interest(#8587)Changed
AsyncFd::{new, with_interest, try_new, try_with_interest}(#8587)Fixed
DuplexStreamwakers outside the lock (#8618)unreachable_codeinjoin!andtry_join!forInfallible(#8518)current_thread(#8595)Fixed (unstable)
io_uringop alive when submission fails after push (#8185)v1.53.2: Tokio v1.53.2Compare Source
1.53.2 (October 3rd, 2026)
Fixed
AsyncFdregistration list on deregister" (#8540)Permitbefore sending value (#8560)MAX_PERMITSinSemaphore::acquire(#8548)Sender::closedoutside mutex (#8558)JoinSet(#8554)clear_entry(#8552)Fixed (unstable)
io_uringread length tou32::MAX(#8572)current_threadtask dumps from other runtimes (#8544)io_uringcontext if a completion waker panics (#8566)Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR was generated by Mend Renovate. View the repository job log.