Repository navigation
Update expat to 2.8.4 - #669
Merged
Merged
Conversation
This was referenced Sep 1, 2026
The last build here completed 2026-09-01T07:01Z, a day before pkgs#671 landed. That run failed on `next`, which could not build because pnpm carried node-lts into its closure alongside the node it declares — two npm trees hardlinked per-file into one unloadable tree. #671 fixed that by narrowing pnpm to `subsetOf node ["node"]`. Re-running for honest signal.
The run on 1e59bb9 started 18:40:10 and ended 18:42:23 with conclusion 'failure' but output 'cancelled' — a fleet build takes far longer, so it was killed early rather than genuinely failing. This branch still has not had a real build since pkgs#671 landed at 16:48.
Brings in pkgs#671 (pnpm -> subsetOf node ["node"]), which fixes the `next` build failure this branch has been hitting. The branch was 7 commits behind and still carried `node-lts` in pnpm's runtime_deps, so the two earlier no-op re-runs rebuilt the same stale tree and failed identically — a no-op gives a fresh timestamp, not a fresh tree.
This branch already carries pkgs#671 (pnpm -> subsetOf node ["node"]) via the main merge in e239607, so the `next` failure it kept hitting should be gone. It has never had a completed build since then: the 16:10:31->16:29:25 run reported conclusion 'failure' with output 'cancelled'. See build-servers#292 — cancelled runs are indistinguishable from real failures in the PR UI, which is what made this look like the fix had not worked.
mitodrummer
approved these changes
Sep 14, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to no response for status checks
Sep 14, 2026
bryan-minimal
added a commit
that referenced
this pull request
Sep 16, 2026
Brings in #701 (kittyview) and #636 (AGENTS.md docs canary). Neither touches mono, so this is not expected to fix the arm64 failure on its own — the branch was BEHIND main by 2 and a re-run on a stale tree gives a fresh timestamp rather than fresh signal (the lesson from #669). Re-running to establish whether mono's arm64 SIGSEGV is deterministic. amd64 built the full closure green in the last run (7185 checks, 476 cache entries); only arm64 failed, inside mono's own AOT step. This PR touches only packages/coreutils/build.ncl. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
cvince
pushed a commit
to capysc/pkgs
that referenced
this pull request
Oct 2, 2026
…ak each other (gominimal#671) * fix(pnpm): depend on node, not node-lts — two npms in one sandbox breaks both pnpm only needs *a* node for its `#!/usr/bin/env node` shebang, but whichever one it names enters the closure of every package built with pnpm. `next` and `agent-browser` both declare `node` themselves, so each sandbox held TWO npm installs at the same paths. The sandbox hardlinks closure members first-writer-wins PER FILE, so /usr/lib/node_modules/npm came out a blend: minipass-flush/index.js from npm 11.17.0 (named `{ Minipass }` import) beside a nested minipass@3.3.6 from npm 11.11.1 (default export only). That tree never existed upstream and cannot load — `class Flush extends undefined` throws and every `npm install` dies. It broke `next` for two days and blocked gominimal#665, gominimal#667, gominimal#669 and gominimal#659. Verified: closure of next 75->74 and agent-browser 114->113 with node-lts gone, capy (the only other node-lts consumer) untouched; 8000 next, pnpm and agent-browser each build --rebuild clean and pass min check 15/15. Supersedes gominimal#670, whose fix was a no-op against node-lts's own output. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * refine: take only the node BINARY, not the whole package Review point from Bryan: pnpm should not be dictating a node version to its consumers at all. The spec language cannot express that today — RuntimeDep is BuildSpec | Subset | UpstreamPkg, all concrete, with no "consumer provides it" form — but `subsetOf` gets most of the way there. pnpm needs a node to interpret `#!/usr/bin/env node` and nothing else. Taking `subsetOf node ["node"]` instead of the whole package means pnpm can never contribute an npm tree to any closure, so the two-npms-merged-per-file failure is structurally impossible rather than merely absent from today's fleet. Residual, and worth stating: pnpm still names a version, so a future node-lts consumer adding pnpm would collide on the `node` binary. That is a much smaller failure than an unloadable module graph, and the real fix is a virtual/provided dependency in the spec language. Verified with the subset: next, pnpm and agent-browser all build --rebuild clean and pass min check, including pnpm's `missing runtime_deps` — which independently confirms the bare binary satisfies the shebang. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <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.
Update expat
2.8.3→2.8.4Source:
github:libexpat/libexpat:release-assetRelease: https://github.com/libexpat/libexpat/releases/tag/R_2_8_4
Changelog: libexpat/libexpat@2.8.3...R_2_8_4
Released: 16 hours ago (2026-08-31)
Vulnerability impact
Partition analysis at
2.8.4(uses each advisory's fixed-version, vulnerable-range, affected-ranges, and fix-commit ancestry to decide):Vulnerabilities fixed (1)
This update clears 1 vulnerabilities affecting
2.8.3:<= 2.8.3; < 2.8.3Components changed
CycloneDX component delta (declared materials — the package's own version, not a dependency-tree diff)
expat2.8.32.8.4expat-upstream2.8.32.8.4Changes
2.8.32.8.4f6256df90c906773...656ae1cc8da3b4ea...gs://minimal-staging-archives/expat-2.8.3.tar.xzgs://minimal-staging-archives/expat-2.8.4.tar.xzMIT(source: GitHub + tarball)Quality suggestions
testsblock. This package has no standalone tests, so the buildbot will only verify compilation — not functional correctness. Consider adding a minimal smoke test (e.g., a--versionor small round-trip invocation) as part of this PR so future bumps catch regressions. Seepackages/python/build.nclfor a simple example.Created by pkgmgr