Repository navigation
Retry failed packages, faster --devel source sync (3.5.0-F23, B144) - #10
Merged
Merged
Conversation
…nd (3.5.0-F23) An unattended update's review refusals lived only in its summary, so there was nothing to retry them from, and retrying build failures took `sysforge build $(sysforge state failed --names)`. - build_core._record_review_refusal records every review-gate refusal (a target's own change, or a refused dependency) in build_state.toml's [failures] table with kind = "review". It clears on the next successful build or on removal, as build failures do. - `sysforge build --failed` adds every recorded entry to the targets (deduplicated, after any named ones). With nothing recorded it is a clean no-op (exit 0); with neither packages nor --failed, `build` now refuses with exit 2. - state failed marks review entries and points at build --failed; the doctor state axis words them as refusals, not build failures; the update summary suggests build --failed under Failed: and Refused at review:. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…r its own checkout (3.5.0-B144) update --devel force-fetched every VCS package's AUR packaging repo even when the AUR RPC reported it unchanged. --devel asks whether upstream moved, which the version check answers itself (ls-remote, pkgver()), so VCS packages now go through the RPC short-circuit like any other and the scheduler loses its unused force_devel. The short-circuit matched the RPC entry by name only. It now also needs source_sync._rpc_vouches: the checkout's origin, read strictly by the new aur.aur_origin_pkgbase, must be that pkgbase's own AUR repo (the entry's PackageBase). A fork, another package's repo or a missing origin always fetches. RPC fields are cached only when the entry vouches (_record_rpc), else cleared by the new SourceMetaCache.forget_rpc, so a checkout moved from a fork back to the AUR fetches once first. Under the source freeze a VCS package that would short-circuit returns STATUS_FROZEN, since its version check needs upstream; without that, update --devel --frozen reported DEVEL_EVAL_FAILED and exited 0. Reviewed by the pkgbuild-reviewer agent; its findings F1 and C1-C4 are addressed here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…(3.5.0-B144) An upstream commit leaves the AUR PKGBUILD untouched, so since B144 source sync short-circuits on the unchanged RPC and fetches nothing. Pins that the version check still resolves pkgver() against upstream and rebuilds. The existing --devel rebuild tests run offline and never went through source sync, so none of them covered this. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…144) _rpc_vouches already returns False for a missing entry, but pyright cannot see through the helper, so the gates job's typecheck failed with reportOptionalMemberAccess on the three rpc_entry.get calls. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4 tasks done
KeithRaghubar
added a commit
that referenced
this pull request
Oct 25, 2026
…drift (3.5.0-B145) In the sandbox a package that pulls Arch's rust builds with the repo LLVM that rust links, and build_sandbox.recorded_toolchain records it as stock_llvm with a sandbox| fingerprint. Phase 4.25 compared that with the host's sysforge-built toolchain, so every such package (all the COSMIC -git packages, mesa) drifted on every run and, under rebuild_on_drift, was rebuilt only to record the same stamp again. The drift loop now skips a sandbox-stamped record while flag_drift.builds_with_repo_compiler says the next build would do the same (current_sandboxed for its profile and needs_repo_rust), the B125 rule applied within one family. Turning the sandbox off for the package, or it no longer needing repo rust, reports it as before. A repo LLVM update is not detected for these packages: the sandbox's working copy is shared by every build, so its compiler identity at update time reflects the last build, not this package's next one. ID note: make next-id offered B144 on this branch, which the fix in #10 already uses, so this takes B145. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
KeithRaghubar
added a commit
that referenced
this pull request
Oct 25, 2026
…-B145) (#11) ## Summary - **Bug:** in the sandbox, a package that pulls Arch's `rust` builds with the repo LLVM that rust links, so `build_sandbox.recorded_toolchain` stamps it `stock_llvm` with a `sandbox|` fingerprint. Phase 4.25 compared that stamp with the host's sysforge-built toolchain. Every such package (all COSMIC `-git` packages, `mesa`) therefore drifted on every run and, under `rebuild_on_drift`, was rebuilt only to record the same stamp again. - **Fix:** the drift loop skips a sandbox-stamped record while the new `flag_drift.builds_with_repo_compiler` says the next build would do the same (`current_sandboxed` for its profile and `needs_repo_rust`). This is the B125 family exemption applied within one family. A package taken out of the sandbox, or one that no longer needs repo rust, is reported as before. - **Known limitation (documented in §Reconverge and §makepkg wrapper):** a repo LLVM update is not detected for these packages, because the sandbox's working copy is shared by every build. ## Merge note PR #10 adds B144 to the same `## Fixed` section of `docs/release-notes/unreleased.md`. Whichever of the two merges second needs that conflict resolved with B144 before B145. ## Test plan - [x] `make test`: 7666 passed - [x] New tests: `test_toolchain_drift_phase_skips_a_repo_compiler_sandbox_build` (5 cases) and `test_builds_with_repo_compiler` (4 cases) - [x] lint, typecheck, check-design, check-standards, check-shipped, check-surface - [x] Against live state: none of the 30 sandbox-stamped package bases is reported as drifted any more 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.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
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.
Summary
Two follow-ups to #9: retrying what an unattended run leaves behind, and a faster
update --devel.3.5.0-F23—sysforge build --failed. Rebuilds only what the last runs could not finish: packages whose build failed, and packages refused at the review gate.build_core._record_review_refusalnow saves them in build_state.toml's[failures]table withkind = "review", for a target's own change and for a refused dependency. Each entry clears on the next successful build or on removal, like build failures already did.state failedmarks review entries and points atbuild --failed.stateaxis reports them as refusals, not build failures.build --failedunderFailed:andRefused at review:.build --failedexits 0.sysforge buildwith neither packages nor--failedexits 2.3.5.0-B144—update --develno longer re-fetches every unchanged-gitAUR repo.--develasks whether upstream moved, and the version check answers that itself (ls-remote/pkgver()). So VCS packages now go through the RPC short-circuit like any other package, and the scheduler'sforce_develis gone. Fixed along the way:originto be that pkgbase's own AUR repo (_rpc_vouches, read strictly by the newaur.aur_origin_pkgbase). A fork, another package's repo or a missing origin always fetches._record_rpc). Otherwise the newSourceMetaCache.forget_rpcclears them, so a checkout moved from a fork back to the AUR fetches once first.STATUS_FROZEN, since its version check needs upstream. This keepsupdate --devel --frozenexiting 1 instead of reportingDEVEL_EVAL_FAILEDand exiting 0.-gitpackage still rebuilds when only upstream moved. The existing--develrebuild tests ran offline and never went through source sync.Review
The B144 change was reviewed by the
pkgbuild-revieweragent before commit. Its findings are all addressed in776fd354:--devel --frozen, a skipped VCS package ended up asDEVEL_EVAL_FAILEDand the run exited 0.update.mdtext.Test plan
make test: full suite green (7681 at the fix commit;test_update.pygreen with the added regression test)make lint,check-design,check-shipped,check-standards,check-surface,check-roadmap-table(re-run after rebasing onto the squashed Unattended runs, noconfirm policy and kernel config review (3.5.0-F20, F21, F22, DOC16) #9)git initcheckouts in the origin tests:aur@aur.archlinux.org:origins skip the fetch;STATUS_FROZEN, and--thawlets the package through.sysforge update --develon the dev machine: source sync should drop to seconds when nothing changed on the AURmake e2e(CIe2ejob)🤖 Generated with Claude Code