Reporting period: October 26, 2026 (Monday) through October 30, 2026 (Friday), 5 working days in total.

Sources: 5 issues of this publication’s daily RuyiAI update reports (2026-10-26 to 2026-10-30, each covering the window from 04:30 the previous day to 04:30 of the current day; Monday’s issue covers the past 3 days including the weekend); plus a 168-hour repository audit of three organizations — RuyiAI-Stack, ruyisdk, and buddy-compiler — full statistics on daily commits and merged PRs in the main openRuyi-Project repository (API pagination cross-check), dual-source verification against the RuyiSDK developer community and the openRuyi distribution news page, and snapshots of three pages on the official RuyiAI homepage (verification coverage extends to the afternoon of 10-31).

Editorial note: Four main threads ran in parallel this week. First, the vectorized intermediate representation VIR completed all three stages — “expression, invocation, reconciliation”: seven commits in one night filled out scalable vectors, Python bindings followed the next day, and on the third day the entire decode attention of K3 was moved onto VIR and reconciled against on-board throughput. Second, governance of the two riscv branches diverged: the llvm side stopped daily whole-branch replays in favor of a contribution guide and an automated rebase workflow, and canceled the dry-run switch; the pytorch side still does a one-shot replay after seven days of silence. Third, the main openRuyi repository saw 234 commits and 52 merged PRs this week, KDE Frameworks 6.31.0 landed 64 packages in one pass, and three reverts rolled back the “ship LLVM IR with packages” approach. Fourth, the month-end release window came up empty: neither ruyi 0.54.0 nor openRuyi 2026.10 had been released as of the end of this week. Beyond the daily-report material, this weekly adds eight newly discovered audit findings (mostly after the daily-report windows or at period boundaries), listed in the appendix.

I. Weekly Highlights

  • VIR completes “express—invoke—reconcile” in three days: scalable vectors, Python bindings, and K3 decode attention land in sequence: From 10-26 22:48 to 10-27 03:22, the same author made seven consecutive commits to buddy-mlir (#1002 through #1008), filling in strip-mining stepping by vscale, vector size computed as VLEN/64, vir.set_vl with results lowered to scalable vectors, and dynamic vector row permutation and indexing conventions all at once; on 10-27 22:42, #1009 was merged (12 files, +614/−1), adding a buddy_mlir.dialects.vir module to VIR so that this dialect, previously runnable only in buddy-opt, can now be constructed and lowered directly from Python; on 10-28 09:36, #1014 was merged (4 files, +476/−14), moving the entire K3 w4g32 decode attention into VIR. Sources: #1002 vscale stepping, #1009 Python bindings, #1014 K3 decode attention

  • All three reconciliation checks on K3 hold firm: bit-exact numerics, 178 vector instructions each, overlapping throughput ranges: The #1014 kernel segments by 64 lanes, with a single head as one 128-f32 LMUL 4 vector group; the lowering target changed from vector-width=128 to rvv-vlen=1024 with scalable vectors disabled. Both with and without q/k normalization, results are bit-exact against the old _attn_decode_fn; the machine code has 178 vector instructions in each of the two parallel bodies, the key-value loop matches the old version’s instructions, with only two spill-reload positions changed; on K3, all three greedy-decoding throughput tiers overlap—after 63 tokens, 28.26~28.49 vs. 28.10~28.58; after 458 tokens, 26.82~27.13 vs. 27.02~27.04; after 900 tokens, 25.37~25.41 vs. 25.29~25.77. The author notes that two builds of the same code can differ by 2%. Sources: #1014, K3 docs

  • llvm riscv branch shifts from “daily full-branch replay” to “writing rules”: a 244-line auto-rebase workflow plus a contribution guide, with dry-run removed: For the first two days of the week the branch was still being rebased (221 commits advanced on 10-26, 237 on 10-27); starting 10-28, .github/workflows/autorebase.yml was added (+244/−0), and on 10-29 RISCV_CONTRIBUTING.md landed (+82/−8) with the workflow’s dry_run input removed—on success it pushes straight back to the author’s branch, with no preview. The guide offers two contribution paths: maintainers cut a work/issue-NNN working branch, or submit a PR directly to riscv and then manually trigger the rebase. Workflow conflicts always take the riscv side, equivalent patches are dropped automatically, and PR code is never executed or built. Sources: autorebase.yml, RISCV_CONTRIBUTING.md, commit faf4def312

  • triton-riscv merges three lowering fixes within 80 minutes, all motivated by FlagGems operator migration: From 10-29 15:38 to 16:58, #82 (unique target indices for scatter tests, 1 file +23/−3), #83 (masked loads support tensor padding values, 4 files +160/−16), and #58 (preserve loop-carried gather offsets, 2 files +125/−0) were merged in sequence. #83 was verified on a riscv64 machine: all three new regression RUN/FileCheck tests pass, the full lit suite has 291 passes, 9 expected failures, 0 unexpected failures, and 18 runtime checks pass. The three had waited 82, 43, and 44 days respectively before merging, while the migration PR #56 that needed them was still stuck at 09-16. Sources: PR #83, PR #58, PR #82

  • openRuyi sees 234 commits and 52 merged PRs this week; KDE Frameworks 6.31.0 rolls out 64 packages in one minute: Counting daily by Beijing time, 10-26 through 10-30 saw 80, 36, 36, 73, and 9 commits respectively, led by Leetfs (87), KiritakeKumi (65), and misaka00251 (17). At 15:11 on 10-29, 64 kf6-* packages landed in the same minute, essentially covering the full set of frameworks Plasma 6 depends on; the week also brought a one-shot Samba family bump to 4.25.1 (including tevent 0.17.2, tdb 1.4.15, talloc 2.5.0, plus switching jack2 and rpm-config-openruyi to Waf builds), and two backports for qemu 11.1.2 and libvirt. Sources: openRuyi commit list, PR #1513 KDE, PR #1428 Samba

  • RuyiAI trio packaging moves from “roadmap debate” to “spec rework,” with build cost quantified at 2.81x: PR #1350 submits three specs at once—buddy-mlir, python-triton-ruyiai, and python-tilelang-ruyiai—opened 9-21 and stalled for nearly a month; on 10-27 the author responded point by point to three review comments, on 10-28 measured “switch to GCC build” at 8814 seconds becoming 24798 seconds (about 2h27m vs. 6h53m, and that run failed at the link stage), and on 10-29 received a first round of 18 code-level review comments, all about spec style (missing BuildRequires, Provides alignment with package names, patches must be generated with git format-patch, empty %check needs a comment). As of week’s end it remains open, at 10 files, +838/−0. Sources: PR #1350, PR #1352 PyTorch package

  • Month-end promises unmet: ruyi 0.54.0 still only has the 09-18 alpha, openRuyi 2026.10 unreleased: Biweekly progress issue 079 moved package manager 0.54.0 to end of October due to a release-cycle adjustment; as of the afternoon of 10-31, the tag list still stops at 0.54.0-alpha.20260918, and the latest stable is 0.53.0 from 09-24; the openRuyi repo’s tags end at 2026.09-experimental, and the news page has no 2026.10 release announcement. The main repo’s last two commits this week were a vendor naming list document on 10-29 and merged #508 on 10-30, neither a release action. Sources: ruyi Releases, ruyi tags, openRuyi tags

  • pytorch riscv branch replays in one shot after seven silent days; SyncBots raises the baseline to upstream 3afdbd3; tilelang-riscv still has no commits by day fourteen: The pytorch riscv branch had zero commits for seven consecutive days starting 10-22; on 10-29 14:06 it rewrote the committer timestamps of 11 existing patches uniformly to complete a replay, and at 20:48 the sync bot added [SyncBots] Integrate PyTorch at 3afdbd3 (changing only the FORCE on one line of cmake/Dependencies.cmake). tilelang-riscv’s main branch last commit remains 10-16 10:52, open PR #4 has been idle since 09-28, and its only presence this week came from the distro’s python-tilelang-ruyiai spec. Sources: pytorch riscv branch, SyncBots commit 5a29c201, tilelang-riscv

II. RuyiAI Stack Progress (PyTorch / Triton / TileLang RISC-V Adaptation)

Window Overview: The RuyiAI-Stack organization (18 repositories) this week concentrated its activity on llvm-project (two rebases in the first two days, then a shift to governance assets and full-branch replay in the following three days), pytorch (replay after seven days of silence), triton-riscv (three regression fixes plus two anchor updates), ruyiai-daily (five consecutive issues), and the site repository (contributor data bot refresh); tilelang-riscv, FBGEMM, cpuinfo, VecIntrinBench, IntrinTrans, torq-tile, pytorch-ci, and dsh-osc had no commits all week.

llvm-project riscv branch: five rebases in five days, then stops; governance assets take over

Date: 2026-10-26 to 10-30　Source: riscv branch commit list, autorebase workflow, RISCV_CONTRIBUTING.md

This week’s rebase sequence was 474 commits on 10-25, 221 on 10-26, and 237 on 10-27. All three replays share the same characteristics: the head commit title remains “[RISCV] Add A100 HP/SP and pack/unpack lowering with calibrated scheduling (#31)”, the 26-commit lag exactly equals the number of local patches, and a commit-by-commit comparison shows titles and order unchanged; in the 10-27 run, 20 local commits were rewritten and force-pushed within the same minute (committer timestamps clustered between 15:00:29 and 15:00:31), while author timestamps ranged from July 1 to October 3. In other words, these three days’ work consisted of moving the existing patch set onto a new baseline; all functional increments came from upstream.

The pace changed starting 10-28. The branch advanced by only one commit, cf00909d, containing .github/workflows/autorebase.yml (+244/−0): installed on the author’s source repository default branch, triggered by workflow_dispatch, with two inputs — PR number and “dry-run only, no push” (enabled by default); running on ubuntu-24.04 with a 90-minute timeout; comments explicitly require never executing PR code, hooks, builds, or submodules while holding write permissions, and the git config points hooksPath, attributesFile, and fsmonitor all to /dev/null; conflict handling walks ls-files --unmerged for cases -Xours cannot cover, taking the local side when stage 2 exists and deleting otherwise, and can identify “equivalent patches” to discard duplicate old-baseline patches.

In the 10-29 23:00 full-branch replay, the genuinely new commit was [workflows] Push rebased PRs directly and document contribution options (author time 10-29 09:59): autorebase.yml lost 8 lines (removing the dry_run input and dry-run branch) and gained an 82-line RISCV_CONTRIBUTING.md. The guide offers two paths — open an issue first, have a maintainer cut a work/issue-NNN working branch from the current riscv, and submit PRs to the working branch; or submit a PR directly to riscv and manually trigger the rebase, with the workflow pushing back to the source branch using --force-with-lease with an explicit expected SHA. The document also notes that pushes using GITHUB_TOKEN typically do not trigger subsequent push/PR workflows, so whether CI ran on the updated SHA must be confirmed manually.

Assessment: this branch’s routine activity had already become purely “following the baseline” — five rebases in five days with zero local patch changes. This week’s new information is a change in governance: separating the cost of external contributors “always being one step behind” from maintainer manual judgment, turning it into a dispatch with explicit boundaries (no PR code execution, no rewriting of riscv itself, no auto-merge). Removing the dry-run lowers friction while shifting the risk of “pushing the wrong history” forward to contributors; the effect will only be verifiable after one or two external PRs.

llvm-project upstream: 17 RISC-V passes migrated to NewPM in one hour

Date: 2026-10-26　Source: InsertVSETVLI migration, PreAllocZilsdOpt migration, DeadRegisterDefinitions migration

Among the 221 upstream commits brought in by the 10-26 rebase, 21 are RISC-V related, of which 17 are NewPM ports, all authored by Aiden Grossman, clustered between 12:59 and 13:55 (Beijing time) — under one hour. The list covers the backend’s main passes: post-instruction-selection VSETVLI insertion, CSR read/write and VXRM writes, VMV0 elimination, compressed instruction generation, prologue/epilogue optimization, base address merging, LoadStore optimization, Zilsd pre-allocation, branch optimization and QCRelax marking, plus dead register definition elimination, redundant copy elimination, indirect jump tracking, landing pad setup, and constant hoisting.

The remaining four fall into three directions: the vxrm-pipeline-flush attribute restricts speculative VXRM writes to loops with flush guarantees; LSR prefers equality comparisons as loop exits on Zibi targets; GlobalISel adds legalization for G_FPTOSI_SAT and G_FPTOUI_SAT, making saturating float-to-int conversions available on the global instruction selection path. Another commit changes the gather/scatter lowering and VL optimizer’s use analysis to lazy requests.

The significance is not in any single change but in pipeline ownership: these passes long lived under LegacyPM, and migrating to NewPM aligns them with the new pass manager’s analysis cache, pass ordering, and debugging interfaces. The direct impact on downstream forks is that every rebase carries this set of changes, and -passes= names and pipeline composition shift accordingly — this is one of the few places where actual content changed this week even as the riscv branch “rebased without patch changes.”

pytorch: full-branch replay after seven days of silence; SyncBots raises baseline to 3afdbd3

Date: 2026-10-29　Source: pytorch riscv branch, SyncBots commit 5a29c201, open PR list

The riscv branch head was unchanged for seven consecutive days after 10-22 03:00, and the seven open PRs (#23, #35, #36, #38, #43, #46, #48) had zero hits by update time all week; among them #46 “RISC-V Vector Extension support for ATen” and #48 “Add RISC-V Vector CPU capability” are the two main proposals for upstreaming RVV capability, with status unchanged from three weeks ago.

At 10-29 14:06 the branch underwent a full-branch replay: committer timestamps of 11 existing patches were uniformly rewritten to 14:06:44–14:06:45, author timestamps preserved, and the patch set retained the riscv64 local mirror (#51), the bytes_to_scalar floating-point fix (#44), the inductor opinfo blocklist (#50), the ULP tolerance for linear cross entropy (#42), and the CI series. The 20:48 [SyncBots] Integrate PyTorch at 3afdbd3 changed only one line: adding FORCE to the KINETO_SOURCE_DIR cache variable, meaning the branch baseline now advances automatically with the upstream sync bot.

The main branch’s roughly 20 commits per day at 20:00 were all upstream syncs this week, concentrated on Dynamo’s VariableTracker construction convergence (#200473, #200472, #199832, #199831, #199830, #199829 batch), CUDA’s max_pool3d 64-bit index fix, and online softmax merging switching to exact exponentials — none touch RISC-V.

Worth reading alongside is a distribution-side mismatch: openRuyi’s #1352 is packaging this branch’s artifacts as python-torch-ruyiai, but that PR has been stalled since 10-27 while the branch head has moved to a new baseline. If the package is built from branch artifacts, the source revision pinned inside the package needs realignment once — and no PR is currently doing this.

triton-riscv: three regression fixes merged in 80 minutes; anchor jumps two levels

Date: 2026-10-27 to 10-29　Source: PR #90 anchor update, PR #83, PR #58

Three threads converged on the same day. First, dependencies: at 10-27 19:43, renovate’s #90 was merged (+2/−2), jumping the buddy-mlir anchor from nightly/v0.1.1.dev20261017 straight to nightly/v0.1.3.dev20261027, skipping the 0.1.2 release and two nightly builds — meaning the seven VIR scalable-vector changes from the night of 10-26 enter the downstream build chain starting this issue. The 10-28 18:51 #91 then raised the anchor to dev20261028, but was not merged that day because three riscv64 CI jobs were still queued.

Second, code: the three regression fixes on 10-29, detailed in “This Week’s Highlights.” Verification depth across the three is uneven — #83 ran the full lit suite plus 18 runtime checks, #58 ran only targeted regressions, and #82 ran a single file (21 passed).

Third, a status mismatch: the three fixes landed first, but the migration PR #56 “Migrate additional FlagGems operators” that needs them remains stalled since 09-16, unmerged all week; among open PRs, #55 (the asin operator frontend patch) merged at 10-30 20:14, and #85 “softmax and matmul optimization” has had no updates since 10-18. Anchor updates only solve “can it be used,” not “it is being used”: the 10-28 nightly build predates the three merges that morning, so downstream needs another nightly build plus a dependency update to get #1014 and #1015.

tilelang-riscv: fourteenth day of silence, only the distribution path remains

Date: 2026-10-30 (status)　Source: tilelang-riscv commit list, open PR #4, openRuyi PR #1350

The main branch’s last commit remains 10-16 10:52’s “Build Python extension in Buddy CI,” with no commits for fourteen consecutive days as of 10-30; two open PRs: #2 stalled since 06-16 and #4 “RVV vector mask and max reduction lowering” stalled since 09-28, neither updated this week. This contrasts directly with triton-riscv’s three merges in the same period: same organization, same timeframe, one is systematically clearing regression defects while the other shows no activity at all.

The only downstream presence comes from openRuyi’s python-tilelang-ruyiai spec (4 patches in #1350: relax Apache TVM FFI 0.1.10, switch to system build dependencies, discover the buddy-mlir toolchain, skip z3 soname rewriting). The state of “distribution artifacts substituting for repository iteration” has now lasted three weeks; recovery signals for this line should be watched in two places: when the repository gets new commits, and when that package merges.

III. RuyiSDK Toolchain and Distributions (Package Manager, Distributions, Mirrors, and Support Matrix)

openRuyi Main Repo: 234 Commits, 52 Merged, 64 KDE Framework Packages Landed at Once

Date: 2026-10-26 to 10-30　Source: openRuyi commit list, PR #1513 KDE Frameworks 6.31.0, merged PR list

Counting by committer date, 10-26 through 10-30 saw 80, 36, 36, 73, and 9 commits respectively, for a total of 234; 52 PRs were merged over the same period, and the open queue dropped from 71 last week to 58. Top authors were Leetfs (87 commits), KiritakeKumi (65), misaka00251 (17), Jingwiw (12), and KimmyXYC (11).

The character of each day differs markedly. 10-26 was a security sweep: 31 security fixes (nearly 40%), 18 new Rust crates, and 14 version bumps, touching 48 packages. The security line raised nats-server to 2.15.1, moby to 29.9.2, fzf to 0.74.5, etcd to 3.7.2, and containerd to 2.4.2; openjdk-latest moved to 27.0.1.0.2.1 with refreshed source checksums. The full sequoia OpenPGP toolset, fwupd-efi, and the Cloudmux dependency set also entered the repo. On the same day, #1512 backported Zvk SHA-2 support to the Go mainline — the week’s only distribution change directly tied to the RISC-V instruction set.

10-27 was a coordinated upgrade: the entire Samba family was aligned at a single point in time (samba 4.25.1, tevent 0.17.2, tdb 1.4.15, talloc 2.5.0, cmocka 2.0.2), and every package depending on those three ABIs had to be rebuilt. The security line came in one shot via #1506 with 12 packages (sysrepo 5.2.27, libzip 1.12.1, libyang 6.4.13, libical 4.0.7, vim 9.2.1201, squashfuse 0.6.5, simdutf 9.3.2, pcre2 10.49, libheif 1.23.6, imagemagick 7.1.2.34, cups 2.4.20, cpp-httplib 0.63.0). The 13 new packages were mostly Go ecosystem (three go-git packages, goldmark-highlighting-v2, go-udev, go-evdev, gonetworkmanager-v2, ghw, go-pinyin, kustomize, etc.) — two sides of the same effort as dms-shell replacing its embedded vendor bundle with packaged Go dependencies.

10-28 turned to virtualization: qemu went from 11.1.x to 11.1.2, libvirt received two backports (shipping /var/lib/libvirt/secrets with the package, and fixing rbd pool failure after Ceph 21 removed auth_supported), and the %toolchain_major_version macro was merged, allowing switching among gcc-15, gcc-16, clang-22, and clang-23. There was also a batch of Python package build fixes, among which scikit-build-core 1.1.1 and cmake’s Python distribution metadata directly affect the wheel build paths for CMake extensions such as triton and tilelang.

10-29 was the cycle’s peak: of 76 commits, 64 were KDE Frameworks 6.31.0, all landing in the same minute at 15:11, from kf6-kcoreaddons and kf6-kconfig to kf6-kio, kf6-ksvg, and kf6-kwallet — essentially the full set of frameworks Plasma 6 depends on. The rest comprised Gradio 6.31.0, python-pyvex 10.0.5, an epoch fix for graphql-core’s provides, the new vkpeak (Vulkan peak-performance and device-capability probing), a cmake module path fix for ecbuild, a daily clang-wrap update, and three Go dependency-graph cleanups (removing duplicate packages, adding import path provides).

openRuyi Packaging Direction: Samba Coordinated Upgrade and the LLVM IR Distribution Path Reverted

Date: 2026-10-27　Source: PR #1509 Revert llvm ir, PR #1428 Samba, PR #1511 dms-shell

In past issues, openRuyi’s keyword was “add”: add packages, add security, add Rust crates. This week saw the first clear subtraction — #1509, merged at 15:15, contains just three commits with a net deletion of 105 lines (+5/−105), reverting three experimental packaging changes: the llvmir feature for gsl, building pixman with clang and shipping IR with the package, and distributing LLVM IR with libjpeg-turbo.

The PR description gives no rationale; from the content, the direction was to compile libraries to LLVM IR and ship it with packages, leaving an interface for re-optimization or deferred code generation. The entire line was withdrawn before release, indicating that the cascading costs of this approach — package size, ABI and debug-symbol consistency, and infrastructure coordination — were hard to turn into gains in the short term. For a RISC-V distribution this is a trade-off worth recording: IR distribution could in theory reuse upstream optimizations, but without a matching toolchain it merely shifts the cost onto users.

The addition on the other side was the “coordinated upgrade”: Samba and its three dependency libraries changed versions together, and every package depending on the tevent/tdb/talloc ABIs had to be rebuilt — the most typical bulk action in a distribution. In the same week there was both the addition of “rebuilding a whole swath of packages for consistency” and the subtraction of “cutting an experimental path for maintainability,” showing that maintenance focus is shifting from “covering more packages” to “holding the quality boundary of existing packages.”

RuyiAI Trio Packaging: #1350 Moves from Direction Debate to Spec Cleanup

Date: 2026-10-27 to 10-29　Source: PR #1350, PR #1350 review comments

#1350 is the week’s most important item at the distribution layer: a single PR adding three packages at once — buddy-mlir, python-triton-ruyiai, and python-tilelang-ruyiai. The timeline: PR opened 9-21 (three commits between 09:46 and 09:48), maintainer Z572 raised three change requests on 9-24, the author fixed two on 9-28, then it stalled for nearly a month; on 10-27 between 17:55 and 18:54 three replies addressed each point in turn; on 10-28 at 16:22 the three commits were rebased onto the latest main branch in the same minute; on 10-29 between 16:19 and 16:24 the first round of five code-level review comments arrived.

The focus of the debate is shifting. Before 10-27 it was “should buddy-mlir’s bundled LLVM be externalized” — the author’s rationale being that these packages always pin a specific LLVM commit and LLVM is used only inside the package, so keeping it bundled is what makes builds reproducible; also, triton’s upstream setup.py hard-checks whether git is executable, so one must either add a git build dependency or patch setup.py (the latter breaking on triton upgrades). On 10-28 the author quantified the cost of “switching to a GCC build”: on riscv64, 8814 seconds became 24798 seconds, 2.81×, and that build failed at the link stage without completing. That number turned the debate from a technical preference into build-farm scheduling arithmetic: 2.81× means machine occupancy, timeout policy, and release windows all have to be recalculated.

The 10-29 review turned to mechanical conventions: no blank lines needed between BuildOption(xxx) entries; python-triton-ruyiai is missing BuildRequires: python3dist(wheel); Provides must align with actual package names; the necessity of Conflicts: python-%{srcname} needs justification; patches must be generated with git format-patch, and there is an unreferenced patch in the same directory; an empty %check needs a comment explaining why. Such comments typically appear at the stage where “the direction is accepted and it’s time to wrap up.” As of week’s end the PR stands at 10 files, +838/−0, with 18 review comments, still open.

PyTorch as a Separate Package: #1352’s Patch List and RVV Gating

Date: 2026-10-27 (status)　Source: PR #1352, python-torch-ruyiai spec

#1352 packages RuyiAI-Stack/pytorch separately as python-torch-ruyiai (8 files, +783/−0), opened and updated the same day as #1350; its only commit dates to 9-21 11:22 and it did not move all week.

The patch set reads like a complete distribution adaptation checklist: 2001 forces OpenBLAS to use cblas complex dot products, 2003 switches to system fmt, 2005 switches to system cmake dependencies, 2006 skips a useless submodule pre-build check, 2011 gates RVV kernels on target vector capability, 2012 embeds scikit-build-core; plus a pytorch-smoke-test.py, so installation only passes after a smoke test runs. 2011 is the most valuable of the batch: changing the RVV kernel enablement condition from “assume support at compile time” to “gate on target vector capability” directly addresses the old problem on targets like RVA20 that lack vector extensions, where “the package installs but crashes on run.” Such fixes usually wait until users hit them on a board; here they entered the packaging patches in advance.

The risks are equally clear: the branch was only rebased onto a new baseline this week, so the source pin inside the package needs realignment; #1352 has been idle since 10-27, two days before the branch replay (10-29).

ruyi Package Manager: 0.54.0’s End-of-Month Promise Unfulfilled

Date: 2026-10-30 (status)　Source: ruyi Releases, ruyi tag list, ruyi commit list

Biweekly Progress 079 stated that “due to a release-cycle adjustment, 0.54.0 is expected to be released at the end of October.” As of the afternoon of 10-31, the tag list still shows nothing after 0.54.0-alpha.20260918, with the latest stable release being 0.53.0 from 09-24; main saw only two commits this week: “docs: update vendor naming list” on 10-29 and the merge of #508 on 10-30, neither a release action. Following the previous cycle’s cadence (beta on 09-17, stable on 09-24), 0.54.0 would need a beta first and then enter the release process to ship on time — there is no room left this week.

Two proposals and documents from the period are worth noting: #507, submitted 10-28, adds the ability for ruyi to “probe host ABI compatibility for a given software package” (43 files, +4023/−716). It uses in-package ELF ABI sidecars as a query plan, comparing architecture, ELF class, interpreter, shared libraries, symbol versions, and architecture attributes, with results in three states — compatible, incompatible, undeterminable — and adds a ruyi admin check-abi subcommand. #508’s vendor naming list update and ruyi-imager’s change of the UI label from “manufacturer” to “vendor” are two ends of the same thing, avoiding inconsistent naming in two places. The former turns “can this prebuilt RISC-V package install on this machine” from trial-and-error into an explainable check — worth more to the binary-distribution-centric RuyiSDK ecosystem than any single package version bump. It remains unmerged.

ruyi-imager 1.1.0-rc.1, packages-index, and the Support Matrix

Date: 2026-10-26 to 10-29　Source: ruyi-imager v1.1.0-rc.1, support-matrix K3 Pico-ITX commit, packages-index

ruyi-imager released v1.1.0-rc.1 at 16:02 on 10-29, about seven weeks after 1.0.0 (09-10). All four changes are usability polish: a download action added to the image selection step (#12), CLI output aligned to the terminal character set with JSON kept UTF-8 (#14), double-click to confirm in selection dialogs (#19), and selection dialogs requiring an explicit choice (#21); “double-click to confirm” and “must choose explicitly” are complementary constraints — the former speeds things up, the latter prevents mis-selection. The release notes credit a first-time contributor, with three of the four changes from the same person. This week also brought K3 UFS and UEFI flashing support (10-23, within Monday’s window), double-click and keyboard confirmation in selection dialogs, and the UI term change from “manufacturer” to “vendor” as earlier groundwork.

packages-index saw only one commit this week: on 10-26, revyos’s Milk-V Meles image and related uboot were bumped to 20260504. The low volume matches what issue 079 noted — the ISCAS software source has had data synchronization problems for the past two weeks, and built packages have not been refreshed to the public network, so naturally there are no bulk updates on the package list side. This creates a predictable mismatch: if 0.54.0 ships while the software source is unrecovered, what users see via ruyi update will lag behind the actual repository state.

The support matrix had three reports this week, by the same author with different conclusions: Milk-V Jupiter2 with Bianbu 4.0.1 (factory-preinstalled image, USB-PD 65W or ATX 2-pin 12V power, first boot through the setup wizard); SpacemiT K3 Pico-ITX with Bianbu 4.0.8 (LXQt variant, status good, desktop fully functional with no blockers); StarFive VisionFive 2 Lite with Ubuntu 24.04.5 (official preinstalled server image, SFFB into fastboot flashing, USB-to-TTL serial, status only basic). The latter two were merged the same day by the same author, and the rating gap precisely illustrates that the practical usability of RISC-V distributions today depends on the depth of vendor image adaptation, not on kernel support alone.

Biweekly Progress 079: Release-Cycle Adjustment and Three In-Progress Items

Date: 2026-10-26　Source: Biweekly Progress 079, issue 079 file

Issue 079 was posted to the community forum at 18:02 on 10-26, with a reporting period ending 10-22 — four days after the period closed. The package manager statement changed most directly: 0.54.0 moved to end of October due to a release-cycle adjustment, the current stable release remains 0.53.0, and the community software source stays under routine maintenance with a compatibility commitment covering the last three stable versions.

Three in-progress items: detecting ABI compatibility between software packages and the current system, macOS packaging for more officially maintained software packages, and toolchain adaptation for SpacemiT K1/K3. On the base-component side, glibc ported sinh, sinhf, and sinpi into the libmvec vector math framework, and newlib added six vector math functions — acosf, logf, asinf, asinhf, asinpif, and atanf; GCC added baseline Zvdota/Zvbdota support, Md support for the Ztt extension, and updated P extension support to version 0.6. The three in-progress items together with the 0.54.0 timeline form the watch list for the next issue: ABI detection already has proposal #507, K1/K3 adaptation depends on the shape of the toolchain packages, and macOS packaging bears on usability on non-RISC-V hosts.

IV. Vector Extensions and Operator Optimization (VecIntrinBench / IntrinTrans / FBGEMM)

All four vector repos in this stack silent for the full week; benchmark-side gap highlighted by three fixes

Date: 2026-10-30 (status)　Sources: VecIntrinBench, IntrinTrans, FBGEMM, cpuinfo

All four vector-related repositories had zero commits for the week, and the silence continues to lengthen: VecIntrinBench last active 02-13, cpuinfo 05-20, IntrinTrans 06-25, FBGEMM 07-13; torq-tile last active 04-09, dsh-osc 09-15, pytorch-ci has no commit history, harness 10-27 (Monday’s plugin split).

This week the need for benchmarks surfaced exactly where it matters most: all three triton-riscv fixes were validated using “lit pass counts + runtime test-case pass counts,” and none provided comparable numbers on vectorization quality (instruction counts, LMUL occupancy, register spill counts); the performance reconciliation in #1014 also explicitly acknowledges a 2% difference between two builds of the same code. Drawing conclusions from on-board throughput is already tight; if the benchmark side remains idle, future questions of “did the optimization actually help” will long depend on manual reconciliation. This is not a new problem this week, but three merges and one performance reconciliation have cast it in sharper relief.

FlagGems migration has become triton-riscv’s defect-discovery mechanism

Date: 2026-10-29　Sources: PR #83, PR #58, PR #56 FlagGems migration

Looking at the motivations behind the three fixes, the common source is not the test suite but the very act of “porting PyTorch operators onto triton-riscv batch by batch”: the tl.load with real tensor fill values in unique_dim, the loop-carried offset in broadcast_to, and the duplicate-index comparison in the scatter operator—none of these sit at the RISC-V instruction level; all fall on the boundary between the lowering layer and the validation layer. Such defects are hard to grow naturally in unit tests—it takes a real operator library pushing upward in batch fashion to expose them.

The methodological value exceeds the three fixes themselves: for a RISC-V AI stack entering through Triton, the FlagGems migration effectively serves as an end-to-end acceptance set, closer to real workloads than the compiler’s lit suite. Conversely, this week also exposed the mechanism’s single-point dependency—#56 has not been updated since 09-16, and the acceptance process stalled after the three fixes merged; if it remains stalled long-term, the next batch of defects will only be found when other users run into them. A positive signal appeared at the end of the period: #56 had an update at 10-30 20:50 (see appendix), but it is still not merged.

Vector width specification: 1024 bits, one LMUL 4 group per head

Date: 2026-10-28　Sources: buddy-mlir PR #1014, llvm commit 1811501f, llvm commit ed439f3e

#1014 sets the target vector length for kernel lowering at 1024 bits and requires that scalable vectors not be used, so each head (128 f32) occupies exactly one LMUL 4 vector group, and the vir.shuffle in the region also completes within the group—size, grouping, and instruction are all constrained by the same set of parameters. This is a technical specification worth recording this week.

This specification is two ends of the same thing as the upstream backend: the #30 merged into the llvm riscv branch in the previous window lowers IME builtins to SpacemiT A100 dot-product instructions, and #31 adds HP/SP and pack/unpack lowering paths for A100 along with scheduling calibration. One is the backend performing instruction selection and scheduling by register; the other is the kernel expression layer fixing vector size by register. Currently no documentation states whether the two sets of parameters constrain each other, nor has cross-validation been done on K3; when the next stage switches to scalable vectors (the author has stated this is the next commit), the LMUL 4 grouping assumption will loosen, and whether this specification adjusts accordingly is the most worth watching.

Upstream validation and papers: 30 commits after arch-test relocation, no new arXiv entries all week

Date: 2026-10-23 to 10-30　Sources: riscv/riscv-arch-test commit list, Sv suite merge #2981, arXiv search

This week’s check found that the original riscv-arch-test/riscv-arch-test address now returns 404; the repository has moved to riscv/riscv-arch-test. The relocated repository had 30 commits in the Monday window (10-23 to 10-25), making it one of the most active upstreams of the full window: one line of work merges scattered suites into one (PMP #2996, Exceptions groups merged into a unified suite, Sv with SvSm, SvZicbo, ExceptionsSv merged into the unified Sv suite #2981), while also changing the CI exclusion list to one entry per line; another line fills gaps in privilege levels and virtualization (H extension CSR and instruction suites #2982, hypervisor M-mode tests merged into the Sm group #2983, VS/VU/VS-level interrupts in S and H modes #2911, Svinval’s H and SmH groups #2997, H_Zicntr and Sm_Zicntr_H counter enable and htimedelta #2998, plus six S-state constraints such as Shcounterenw and four Zic base constraints). Merging and filling gaps simultaneously shows the reorganization goal is to straighten out the structure first, then fill content into it. RuyiSDK support-matrix and per-chip compliance judgments are all based on this test suite, so the relocation itself is worth remembering.

On the arXiv side, there were no new RISC-V AI preprints all week. The latest two are 10-27’s SecDMP (a provably secure scheme for data-access-correlated prefetching) and a lightweight C code generator for heterogeneous TinyML; the two from 10-23 are a comparison of open-ISA supercomputing routes and LLM-assisted repair of RISC-V processor defects; the most relevant to this topic remains 10-21’s “Reorienting the Vector Axis: Restructuring FlashAttention for Long-Vector Processors,” which discusses segmenting by 64 lanes and restructuring the vector axis on long-vector processors—the same class of problem as #1014, though unfortunately there was no follow-up within the window.

V. Buddy Compiler Updates (buddy-mlir Commits and Releases)

VIR: Seven Scalable Vector Commits in One Night, Python Bindings the Next Day

Date: 2026-10-26 to 10-27　Source: #1002 step by vscale, #1007 unify index convention, #1009 Python bindings

From 22:48 on 10-26 to 03:22 on 10-27, the same author landed seven commits in a row (#1002 through #1008), all prefixed [midend][VIR], all revolving around the same switch use-scalable, and divisible into three layers. Loop and size layer: #1002 fixed the strip-mining step — previously, when vir.set_vl had no result, it lowered to a main loop stepping by a constant vector-width, yet each iteration accessed memory at N times vscale lanes, so iterations overlapped when vscale was greater than 1; #1003 made size selection compute vscale = VLEN/64 on RVV, so that N and SEW determine LMUL instead of falling back to fixed-length vectors; #1008 fixed an assertion crash when the index vector had no explicit width. vir.set_vl with a result: #1004 allowed it to lower to scalable vectors, and #1005 further supported multi-dimensional dynamic vectors. Memory access and permutation: #1006 added vir.shuffle for row-wise permutation of dynamic vectors, and #1007 unified the index convention of vir.load and vir.store.

The motivation was not a generalized vectorization overhaul but pressure from a concrete operator: in decode attention, RoPE’s rotate_half must swap the two halves of a 128-element head and negate one (i.e. [-x[1], x[0]]), which is essentially a row-wise permutation, and VIR previously could not express row-wise permutation of dynamic vectors — the outer layer had to compute with fixed-length vectors and then carry the query into the region. So #1006 added permutation, #1005 added multi-dimensional dynamic vectors, and #1007 added the index entry point; together the three form a single path that “keeps the whole decode attention inside VIR.”

#1009, merged at 22:42 the next day (12 files, +614/−1), added Python bindings: previously VIR had neither an operator-construction entry point nor a type-construction entry point on the Python side — operator names and type descriptions had to be hand-assembled in strings, and the entire lowering could only run inside the single buddy-opt executable; the implementation uses ODS-defined operators plus a C API plus a nanobind extension, isomorphic to dialects in the repo that ship their own types such as quant, split into Ops, Types, and pass registration. The significance lies in composability — operator descriptions, shape inference, and test cases can all be written on the Python side, and frontend-to-VIR integration no longer depends on adding hooks on the C++ side.

K3 Decode Attention Ported to VIR: Bit-Exact Numerics, Identical Instruction Count, Overlapping Throughput Ranges

Date: 2026-10-28　Source: PR #1014, K3 doc changes, test file

#1014 was merged at 09:36 (4 files, +476/−14, of which 264 lines are kernel, 152 lines tests, 10 lines lowering pipeline, 50 lines docs), moving the entire decode attention of the K3 w4g32 kernel onto the VIR dialect. This is the first reconciliation against a real model’s kernel — the previously hand-written RVV vector kernel on one side, the VIR kernel assembled in Python on the other, comparing numerics, instruction counts, and on-board throughput.

The implementation has four layers: the construction layer no longer hand-assembles operators and types but goes through buddy_mlir.dialects.vir’s SetVLOp, load, shuffle, fma, reduce, where one work item is a vir.set_vl region of length half the head dimension (64 lanes) returning that head’s (max, sum); the rotation layer loads, rotates, and scales q inside the region, with rotate_half becoming a single vir.shuffle and cos/sin stored as two rows of equal-length data, no longer needing vir.from_vector; the memory-view layer uses memref.expand_shape to split q, the KV cache, the output, and q’s normalization weights into 2×64 along the last dimension; the normalization layer opens a separate one-dimensional vir.set_vl region for Qwen3’s q/k norm. Pipeline parameters changed to rvv-vlen=1024, use-scalable=false, with the old _attn_decode_fn retained for the A210 kernel.

Three lines of validation: the test does bit-level comparison against _attn_decode_fn, covering with and without threads, start offsets 0/15/16/37/70, and 0/37 with q/k normalization; the qk_norm path of test_k3_w4_moe.py also runs the VIR kernel; check-buddy 239 plus 401 all pass. In machine code, the two parallel bodies each have 178 vector instructions, the key-value loop is identical to the old version, with only two spill-reload positions changed, and q’s rotation goes from operations on two LMUL 2 half-groups to a vfneg plus one register move; on K3, greedy-decoding throughput at all three sequence lengths has fully overlapping ranges (numbers in “This Week’s Highlights”). The PR explicitly states this redoes the closed #998, and the redo rests on the four subsequent commits (#1000, #1005, #1006, #1009), so it is not an independent optimization but a one-shot stress test of the foundation laid by those four.

Restraint is needed: this “performance parity” was obtained on a single K3 board, with greedy decoding, at three sequence lengths, and the author notes that two builds of the same code can differ by 2%. What it proves is that VIR no longer introduces a performance penalty, not that VIR already beats hand-written kernels; coverage is also just one kernel, A210 still uses the old function, and the MoE, quantization, and prefill paths are untouched.

buddy-server’s New ABI: 56 Files Consolidate Modality Plugins into a Unified Interface

Date: 2026-10-29　Source: PR #1015, commit 7d2ce844, RAX packaging and loading analysis

#1015, merged at 15:08 (56 files, +3934/−1661), is the largest change in the whole stack this week. The PR description states only one intent: to update the ABI interface buddy-server uses when parsing RAX files, with the new interface making it easier to support more models in the future.

Structurally, it replaces “one set of plugin handles per modality” with “one unified interface”: it adds ServerModelABI.h (392 lines), ServerModelABIConversion.h (179 lines), ServerModelPluginAdapters.h (742 lines), and ModelError.h (57 lines), deletes the four modality-split implementations AudioTranscription, Embedding, MaskedLM, and Resident along with ModelPluginDiscovery, and replaces them with a 350-line ServerModelPluginHandle plus a 102-line header, with an adapter layer wiring each modality’s old entry points back to the new ABI; BuddyServerApp.cpp alone is +446/−225. On the model side, the Model and Plugin pairs in six directories — bge_m3, deepseek_r1, llama31_tt, proteinglm, qwen3_vl, whisper — are adjusted in tandem.

Most notable on the test side: it adds ServerModelPluginHandleTest.cpp (325 lines) plus four classes of integration tests for ABI errors, capabilities, concurrency, and dependencies, and deletes four sets of modality-specific unit tests (about 226 lines) — the testing focus shifts from “test each modality once” to “the cross-cutting behavior of the unified ABI,” actually broadening coverage. Restraint is needed: this is an interface refactor, the PR gives no performance data and no proof of support for new models, and “making it easier to support more models” will only be delivered once the next model is integrated under the new ABI.

Release Cadence: Five Nightlies in a Row After 0.1.2, Downstream Anchors Keep Rising

Date: 2026-10-25 to 10-30　Source: Releases list, nightly v0.1.3.dev20261030, BUDDY MLIR 0.1.2

The 0.1.2 official release came out at 06:18 on 10-25 (release notes empty, generated by automation, so changes must be inferred from commit history), ending a five-period pause; the seven-day gap is closer to the normal cadence than the two-day gap between 0.1.0 and 0.1.1. Nightlies since then have returned to one per day: dev20261026 at 06:37 on 10-26 (first build of the 0.1.3 line), dev20261027 at 08:26 on 10-27, dev20261028 at 07:56 on 10-28, dev20261029 at 08:21 on 10-29, and dev20261030 at 08:49 on 10-30 — five in total, all marked pre-release.

The lag between build and merge deserves separate note, because it is this stack’s fixed latency structure: buddy-mlir merge → next-day nightly build → renovate proposes dependency update → triton-riscv merge, three hops typically taking one to two days. dev20261028 predates that morning’s three merges (#1010 at 08:54, #1014 at 09:36, #1012 at 09:55), so it does not include the K3 decode attention; dev20261029 predates #1015 by seven hours, so it does not include the new ABI; only dev20261030 carries both #1014 and #1015. The 0.1.3 line has gone five nightlies without an official release, and the latest official release is still 0.1.2 — an interface change on the scale of #1015 would have to wait another round to make it into an official version.

VI. Community, Events, and Official Website

Biweekly Progress Issue 079 and Five Forum Posts

Date: 2026-10-26 to 10-29　Source: Biweekly Progress Issue 079, RuyiAI Summit Recap #2899, XiangShan Ruyi Ecosystem Conference Reprint #2898

Five new forum posts this week. #2895 at 18:02 on 10-26 is Biweekly Progress Issue 079 (reporting period through 10-22) and the only formal report this week; the next issue, on the two-week cadence, should land around early November. #2896 “lpi4a UEFI” at 10:45 on 10-27 was posted by a user with three 1366×768 system screenshots and three 1920×1440 photos; the body says the update was spotted on September 26 and the user held off for a month before flashing, and although no RevyOS build matching the UEFI is available yet, “at least there’s hope”—the post records a real blocker in the LPi4A firmware ecosystem: the UEFI firmware can be flashed, but the matching distro image has yet to follow.

The three posts on 10-29 center on the summit aftermath. #2899 “RuyiAI Appears at the 6th RISC-V China Summit, Sharing AI System Software Stack Practice from RVV to Matrix” recaps the Shenzhen summit of 10-18 to 10-20: the team introduced the stack’s architecture and ways to get involved through a Tutorial session, poster display, and booth discussions, and also took part in the concurrent AME technical workshop and the 10-21 RISC-V Hong Kong Day, with themes centered on matrix extensions and software support; the post body is thin, with substantive content linked out to a WeChat article. #2898 reprints coverage of the afternoon session of the XiangShan Ruyi Open Source Ecosystem Forum: on 10-20, “oriented toward the agent era” RISC-V full-stack hardware and software results were released together, covering server-class chips, an AI-native software stack, processor multithreading architecture, an AI-CPU agile development kit, memory consistency optimization, and EDA verification tool adaptation—for RuyiAI, this post supplies its ecosystem coordinates, with the “AI-native software stack” being one of the results released side by side at the same forum. There is also #2897, a reprint of Bao Yungang’s summit talk “Twelve Years of Understanding, Ten Years of Outlook,” which the daily briefs did not cover this week and is added here.

Official Website: Three Pages Unchanged, the Engineering–Communications Gap Keeps Widening

Date: 2026-10-30 (status)　Source: RuyiAI Official Website, Blog, Docs

The sha256 of the homepage, blog, and docs pages match the previous issue: the homepage indexes 3 items, the blog has 2 posts (Triton’s RISC-V adaptation, PyTorch RISC-V CI practice), and the docs have 23 chapters. No new blog posts or chapters have been added for several consecutive windows.

There is no shortage of material this week that could become technical blog posts: the full chain from VIR’s scalable vectors to Python bindings to K3 performance reconciliation, the refactoring approach behind buddy-server’s unified ABI, the interaction overhaul in ruyi-imager 1.1, and the ruyi host ABI detection proposal—all remain confined to PR descriptions and repository docs, and the three data points in #1014 (on-board throughput, instruction count, and bit-level consistency) are themselves a ready-made article. The only entry points presenting this stack to the outside world are still the two September articles, which does not match the cadence of “commits daily, merges weekly.”

External News: Targeted Queries Hit Zero All Week

Date: 2026-10-30 (status)　Source: Google News RSS, openRuyi Distro News Page

Targeted Chinese and English queries for RuyiSDK, RuyiAI, Ruyi RISC-V, Ruyi Community Compiler, and openRuyi (including when:3d) returned zero hits across all five issues this week. RISC-V-related news captured during the same period is unrelated to the Ruyi community and is logged day by day as: MIPS’s RISC-V platform description, coverage of DAMO XuanTie C950, S2C’s verification and prototyping display at the RISC-V China Summit, Zhongke Tongliang’s dataflow intelligent computing products, deepin’s desktop ecosystem progress at the summit, Pharo 14’s RISC-V JIT, Tenstorrent closing a $1.5 billion Series E, and Microchip PIC64-HPSC aerospace computing progress. These items are off-topic and are not included this week, serving only as external reference.

openRuyi News Page: Two October Posts Live, 2026.10 Release Still Missing

Date: 2026-10-31 (verification)　Source: openRuyi News Page, Ruyi Firmware Announcement, Ecosystem Infrastructure Article

Rechecking the distro news page this week turned up a correction: the previous five daily briefs all stated that “the latest post on the news page is still the 2026.09 release announcement (9-30),” but the page actually has two October posts live, both dated October 19, 2026—”openRuyi-Project: Public Infrastructure for the RISC-V Software Ecosystem” and “openRuyi Releases Ruyi Firmware: Providing an Open UEFI Firmware Solution for RISC-V Platforms.” Both predate this week and are not part of this cycle’s content, but they show that the distro’s content side has not gone fully dormant; the earlier judgment should be corrected to “no monthly release announcement, but two feature articles already published in October.”

The conclusion on the release side is unchanged: repository tags stop at 2026.09-experimental, and no 2026.10 release announcement has appeared; given the monthly cadence of 6-30, 7-23, 8-27, and 9-30, the October release has missed the month-end window and becomes the top item to watch in the next cycle.

VII. Trend Observations

VIR has completed “expression—invocation—reconciliation,” but the conclusion can only be “no introduced loss”

Over the past three weeks this mainline has been continuously filling in expressiveness: on 10-26, seven commits in one night brought in scalable vectors; on 10-27, Python bindings were added; on 10-28, the entire decode attention of K3 was ported over and reconciled against on-board throughput. The meaning of this week lies in the three numbers taken together—bit-level numerical consistency, identical vector instruction counts (178 each), and overlapping throughput ranges. Homegrown dialects most easily get stuck at the “runs but slow” stage; this week at least proves that this stage has been passed for now.

But reading this as “VIR has caught up with hand-written kernels” goes too far. The accurate statement is “no introduced loss in this segment of K3 decode attention, at a fixed vector length.” Two gaps are clear: coverage is limited to decode attention—the A210 kernel, MoE, quantization, and prefill paths are all untouched; and scalable vectors are explicitly disabled (use-scalable=false). Once the next commit enables them, vector size will no longer be determined at compile time, the LMUL 4 grouping assumption will loosen, and whether numerics and instruction counts can hold will need to be reconciled again. The author himself noted in the PR a 2% difference between two builds of the same code—a magnitude that precisely illustrates the boundary of the “on par” conclusion.

Branch governance diverges: llvm writes rules and drops dry-runs; pytorch relies on replay and a sync bot

Within the same month, two branches gave two different answers. The llvm riscv branch has a large patch set (26 commits) and many external contributions, with conflicts and history drift as the main cost, so it is worth writing documentation (RISCV_CONTRIBUTING.md) and configuring workflows (autorebase.yml), and removing the “dry-run” step—push on success, minimizing friction and shifting risk forward to contributors, with --force-with-lease and SHA re-checks as the safety net. The pytorch riscv branch has a small patch set (11 commits); the cost of the maintainer replaying it once is lower than the cost of maintaining a process, so it continues daily or every-other-day whole-branch replays, plus a sync bot that raises the baseline to the latest upstream.

What both share is “a long-term stable local patch set”: llvm’s 26 commits and pytorch’s 11 commits saw no new features this week. The right way to track these two branches is not to look at SHAs or commit counts—replays rewrite committer timestamps uniformly and commit counts inflate with upstream—but to look at the set of patch titles and at what upstream has brought in (this week, 17 passes migrated to NewPM and isel completion for the P extension).

To judge whether a branch governance approach is working, look at two verifiable signals: on the llvm side, whether external PRs actually increase after the workflow goes live (if no one submits against the new baseline within two weeks, the bottleneck is not the rebase tooling); on the pytorch side, whether replays stabilize back to daily (this week was a single catch-up after seven days of silence—scheduled rather than routine).

Packaging becomes the real bottleneck of the RuyiAI stack, and the debate starts to have a price

#1350 has been debated for nearly a month, with the core disagreement being whether the LLVM bundled with buddy-mlir should be externalized. Last week’s position was still “GCC can be used, but takes at least 1.5x the time”; this week the author provides measurements: on riscv64, 8814 seconds becomes 24798 seconds, 2.81x, and the GCC run failed at the link stage. The nature of the debate thus shifts from technical preference to build-farm scheduling arithmetic—2.81x means machine occupancy, timeout policies, and release windows all need recalculation.

The lesson for the whole stack is methodological rather than conclusive: many disagreements in RISC-V distribution packaging (whether to vendor, whether to externalize the toolchain, whether to ship IR with the package) ultimately come down to three measurable numbers—build time, image size, and reproducibility. In the same week, openRuyi withdrew the “ship LLVM IR with the package” approach (#1509), while #1350 used 2.81x to defend “keep LLVM in the package”—two opposite directions of judgment based on the same kind of cost accounting.

Looking further, this week’s review comments on #1350 have shifted from design approach to spec writing (missing BuildRequires, Provides alignment, patch format, empty %check comments), indicating that the question of “whether it can be swallowed by the distribution” has become “whether the package itself is conventional enough.” Three unconventional points—buddy-mlir bundling LLVM, triton depending on the git executable, and tilelang needing to discover the buddy-mlir toolchain—each require patches and explanations, and each explanation costs maintainers time to judge. If the three-piece suite is to enter the monthly release cadence, converging them into one or two clear packaging conventions (e.g., the toolchain uniformly provided by buddy-mlir, patches uniformly stacked via git format-patch) would be less work than responding to review comments one by one.

Month-end commitments collectively slip: the distribution shifts into a “monthly volume, weekly sweep” rhythm

This week two month-end commitments both fell through: ruyi 0.54.0 still only has the 09-18 alpha, and openRuyi 2026.10 was not released. Correspondingly, among the 234 commits in the openRuyi main repo this week: KDE frameworks at 64 packages in one go, a full Samba family linkage, qemu 11.1.2 and libvirt backports, and 12 C/C++ security updates—a classic “volume and sweep in parallel” rather than a “freeze before version cut.”

The rhythm difference between the two pipelines is also worth noting: KDE packages have upstream specs to reference and an established version cadence, so repackaging is mechanical and 64 packages can be done in a day; whereas the RuyiAI three-piece suite is written from scratch, requiring explanations of both “why keep LLVM in the package” and “why %check is empty,” and has been reworked since 09-21 opened. A distribution’s capacity for “monthly volume” and the cost of “absorbing new packages” are asymmetric—the latter depends on how conventional the package itself is.

The practical implication for readers: ruyi users will still get 0.53.0 at the end of October; if 0.54.0 is released in early November, it also depends on whether the ISCAS software source recovers—otherwise the package list seen by ruyi update will lag behind the actual repository state. These two matters are the top verification items for the next cycle.

Defect discovery relies on a single entry point; the acceptance chain is more fragile than the fix chain

The common source of this week’s three triton-riscv fixes is not the test suite but the very act of “porting FlagGems operators onto triton-riscv”: masked loads for tensor fill values, loop-carried gather offsets, and duplicate-index comparison in scatter operators—all three fall on the boundary between the lowering layer and the validation layer. Such defects cannot grow in the compiler’s own lit suite; they require a real operator library pressing upward in batch.

The ordering problem then surfaces: the fixes landed first, but migration PR #56, which needs them, has been stalled since 09-16. A batch of “fixes prepared for a certain usage” temporarily has no corresponding usage running; if #56 resumes after several more rounds of upstream Triton changes, whether the three fixes remain compatible with the new baseline needs re-verification; if it does not resume for a long time, this end-to-end validation set is effectively stalled, and the next batch of defects will wait for external users to hit them. At the end of the cycle #56 had one update (10-30 20:50) but is still not merged—this is the spot most worth watching next cycle.

The inference is actionable: for a stack aiming to “run real models,” making migration a standing regression (even just a few dozen operators, run nightly) is more valuable than merging a few more fixes. Evidence at the toolchain level also appeared the same week—the validation of #83 is the hardest of this week’s three (291 lit passes, 18 runtime checks), and it happens to be the one most deeply integrated with real operators.

Long-term gaps on the benchmark side make “whether optimization works” unanswerable

VecIntrinBench stalled at 02-13, cpuinfo at 05-20, IntrinTrans at 06-25, FBGEMM at 07-13—all four vector-related repositories had zero commits all week, with staleness measured in months. Meanwhile, this week’s performance conclusions can only rely on the throughput range on the K3 board, and the author explicitly notes that two builds of the same code can differ by 2%; the validation of the three fixes also gives only pass counts, with no metrics on vectorization quality (instruction counts, LMUL occupancy, register spill counts).

This is not a new problem this week, but three merges and one performance reconciliation cast it in sharper relief: for a stack aiming at “rising vector capability,” the absence of a continuously scored vector intrinsic benchmark makes it hard to tell whether subsequent optimizations are real gains or fluctuations. What really needs to be added next is not more lowering but a benchmark that runs nightly and reports instruction counts and LMUL—otherwise “performance on par” and “performance improvement” cannot be distinguished under 2% noise.

Appendix: Source Materials and Verification Notes

Source Material List

  • 2026-10-26 issue: window 10-23 04:30 to 10-26 04:30 (past 3 days, covering Saturday and Sunday).
  • 2026-10-27 issue: window 10-26 04:30 to 10-27 04:30.
  • 2026-10-28 issue: window 10-27 04:30 to 10-28 04:30.
  • 2026-10-29 issue: window 10-28 04:30 to 10-29 04:30.
  • 2026-10-30 issue: window 10-29 04:30 to 10-30 04:30.
  • Activity outside the cycle boundary (daytime 10-30 through afternoon 10-31) was verified via organization repositories, release pages, and community sources, and added below in “Items Added This Week Beyond the Daily Reports.”

Verification Methods and Conventions

  • Organization verification (168-hour window): covers commits, PRs, and releases across three organizations—RuyiAI-Stack, ruyisdk, and buddy-compiler—via both Atom feeds and web pages, without relying on API rate limits; commits from upstream forks (PyTorch riscv, LLVM riscv, LLVM main) were filtered by RISC-V, RVV, vector extension, and XuanTie-related keywords before inclusion.
  • openRuyi main repo statistics: fully paginated and re-verified via API, with the window starting at Beijing time 10-26 00:00 (UTC 10-25 16:00) and ending 10-30 24:00, yielding 234 commits; counts by natural day in Beijing time (based on committer time) are 80, 36, 36, 73, 9. Merged PRs retrieved with is:merged merged:>= total 52, with 58 in the open queue. This convention differs from the 24-hour windows of the daily reports, so the numbers do not correspond exactly to those in individual daily issues.
  • Supplementary verification of key repositories: openRuyi-Project’s openRuyi (daily commits, PRs, tags) and homepage; ruyisdk’s qemu (p-dev, ame-0.6), llvm-project (AME), linux-xuantie-kernel, riscv-gcc, wechat-articles, ruyi, ruyi-imager, packages-index, support-matrix, and AME-operator; buddy-compiler’s buddy-mlir; RuyiAI-Stack’s pytorch (riscv branch), triton-riscv, tilelang-riscv, ruyiai-daily, and ruyiai-stack.github.io.
  • Dual community sources: the RuyiSDK developer community forum (latest topic list, five posts this week) and the openRuyi distribution news page (including date re-verification of the two October feature articles).
  • Official homepage: three-page snapshots of www.ruyiai.org—homepage, blog page, and docs page—compared by sha256, with blog and docs index entries attached (2 blog posts, 23 doc chapters).
  • Time conventions: repository commits are converted to Beijing time based on committer time; “daily” descriptions follow consecutive calendar days; the weekly cycle is the five working days from 2026-10-26 to 2026-10-30.

Items Added This Week Beyond the Daily Reports

  1. 10-30 20:14, triton-riscv merged #55 “Support asin op via frontend patch” (asin operator implemented via frontend patch), after the 10-30 daily report window.
  2. 10-30 20:50, triton-riscv’s migration PR #56 “Migrate additional FlagGems operators” resumed updates (still open), its first activity since 09-16.
  3. 10-30 08:49, buddy-mlir released nightly build v0.1.3.dev20261030, the first to include both #1014 (K3 decode attention) and #1015 (new ABI).
  4. 10-31 13:15, triton-riscv’s #91 merged, raising the anchor to nightly/v0.1.3.dev20261030—the three-hop chain (merge, nightly build, downstream anchor update) completed on the last day of the week.
  5. 10-30 23:00, the llvm-project riscv branch was rebased and replayed once more (25 commits, committer times clustered between 23:00:40 and 23:00:44); 10-31 03:00, the pytorch riscv branch was rebased and replayed once more, with the head still containing [SyncBots] Integrate PyTorch at 3afdbd3.
  6. 10-30 09:54, ruyisdk/ruyi merged #508 “docs: update vendor naming list”; the main repo had two commits this week and still no new release.
  7. 10-30 12:39, openRuyi’s #1514 “ollama: Update to 0.40.7” merged with the security-fixes label; the same day also saw clang-wrap 20261030 (#1545) and others, for a total of 234 commits this cycle.
  8. Forum #2897 “[Repost] Twelve Years of Understanding, Ten Years of Outlook: Bao Yungang Discusses the Chinese Path for Open-Source Chips at the 2026 RISC-V China Summit” (published 10-29), not covered by this week’s daily reports, is added here.
  9. Correction to the openRuyi news page: two feature articles have gone live in October (both marked as published 10-19); the earlier statement that “the latest is still the 2026.09 release announcement” was incorrect; the 2026.10 monthly release announcement has still not appeared.

Source Verification Table

Source Verification Result
RuyiAI-Stack organization (all repos) pytorch: riscv branch silent for seven days (10-22 to 10-28), rebased and replayed 11 commits at 10-29 14:06, SyncBots bumped to upstream 3afdbd3 at 20:48; main branch has about 20 commits daily, all upstream; llvm-project: riscv branch rebased twice on 10-26 and 10-27 (baseline advanced by 221 and 237 commits), autorebase workflow added on 10-28, replayed on 10-29 with a new contribution guide added, 17 upstream RISC-V passes migrated to NewPM; triton-riscv: three regression-fix merges, two anchor updates (#90 merged, #91 not merged that day); tilelang-riscv silent for the fourteenth day; ruyiai-daily five issues; no commits in FBGEMM, cpuinfo, VecIntrinBench, IntrinTrans, torq-tile, pytorch-ci, dsh-osc
ruyisdk organization (all repos) ruyi-imager: v1.1.0-rc.1 pre-release (10-29), plus earlier commits this week on UFS/UEFI, dialog interaction, and terminology unification; ruyi main repo two commits (vendor naming list docs, merge of #508), no new release, 0.54.0 has only an alpha tag; packages-index one commit (revyos Milk-V Meles image and uboot bumped to 20260504); support-matrix three board reports (Jupiter2 Bianbu 4.0.1, K3 Pico-ITX Bianbu 4.0.8 rated good, VisionFive 2 Lite Ubuntu 24.04.5 rated basic); no in-window commits in wechat-articles, ruyisdk-website, docs, AME-operator
openRuyi-Project organization Main repo 234 commits, 52 merged PRs, 58 open; categories include the KDE Frameworks 6.31.0 batch of 64 commits, a full Samba dependency chain update, 12 security package updates, qemu 11.1.2, two libvirt commits, three reverts (withdrawing LLVM IR distribution), 13 new Go ecosystem packages, and vkpeak inclusion; tags stop at 2026.09-experimental, 2026.10 not released
buddy-compiler organization buddy-mlir: seven VIR commits (#1002 to #1008), Python bindings #1009, buddy-server source reorganization #1010, Whisper x64 CI #1012, K3 decode attention #1014, new ABI #1015; official release 0.1.2 and five nightly builds (dev20261026 to dev20261030); three open PRs stalled since 10-28 (#1011, #1013, #994)
riscv/riscv-arch-test The original riscv-arch-test organization path now returns 404; the repo has moved to the riscv organization; 30 commits in the Monday window (10-23 to 10-25), mainly suite merges and H extension completions
RuyiSDK developer community forum Five posts this week: issue 079 (10-26), lpi4a UEFI (10-27), RuyiAI summit recap and XiangShan-Ruyi ecosystem conference repost, Bao Yungang talk repost (all 10-29); issue 080 not yet published
openRuyi distribution news page Two October feature articles (both marked as published 10-19); monthly release announcement still 2026.09 (9-30), 2026.10 not released; repo tags stop at 2026.09-experimental
ruyi package manager / tags 0.53.0 maintained; 0.54.0 has only the 09-18 alpha; two commits on main this week; the “end-of-October release” commitment was not fulfilled as of 10-31
ruyi-imager / Releases v1.1.0-rc.1 released 10-29 16:02 (pre-release), with four interaction and CLI changes
Official homepage (ruyiai.org) Three pages unchanged: homepage index 3 entries, 2 blog posts, 23 doc chapters; sha256 matches the previous issue
IREE upstream No RISC-V-specific changes in window commits
arXiv (RISC-V) No new entries all week; latest are SecDMP and a TinyML C code generator on 10-27; the 10-21 long-vector FlashAttention remains the closest fit to RVV
Google News RSS (multiple Chinese and English queries) Targeted queries for RuyiSDK, RuyiAI, Ruyi RISC-V, and openRuyi returned zero hits across all five issues this week; contemporaneous RISC-V news unrelated to the Ruyi community was not included

Complete Source List

Data sources: daily RuyiAI activity reports (5 issues, 2026-10-26 to 2026-10-30) and this week’s supplementary verification (organization repositories, dual community sources, official homepage); reporting period is 2026-10-26 to 2026-10-30.