ci: MCPP_VERSION -> 2026.8.10.2(解掉 8 个图形成员的红)+ 失败的全量 sweep 开 issue

[Sunrisepeak]

为什么 8 个图形成员是红的 —— 不是数据缺陷

xim:libglvnd@>=1.7.0.1 从 xlings 2026.8.9.2 起解析正常
(四段版本 semver 重写;fontconfig 2.15.0.1 撞过同一个洞)。
红的原因是这里钉在 mcpp 2026.8.8.2,它内带 xlings 2026.8.8.1 ——
正好落在修复之前:

MCPP_VENDORED_XLINGS: …/mcpp-2026.8.8.2-linux-x86_64/registry/bin/xlings
error: xlings install_packages failed (exit 1) for 'compat.glx-runtime@2026.08.08'
  xlings reported: E_INVALID_INPUT: package 'xim:libglvnd@>=1.7.0.1' not found

xim-pkgindex 一个字都不用改。 用刚发布的 2026.8.10.2 载荷里那个 xlings 实测:

$ mcpp-2026.8.10.2-linux-x86_64/registry/bin/xlings info "xim:libglvnd@>=1.7.0.1"
xim:libglvnd
  available: 1.7.0.1, 1.7.0
  selected version: 1.7.0.1          ← 解析成功
$ mcpp-2026.8.10.2-linux-x86_64/registry/bin/xlings --version
xlings 2026.8.10.4

2026.8.10.2 同时带两个直接影响本仓的修复:

• mcpp#405 依赖 BMI 缓存命中时,被恢复的包传递依赖的 std 没进构建图 ——
  每个图形项目的第二次构建必挂(消费方自己不 import std 时现形,
  imgui 模板生成的 main.cpp 恰好如此)。
• mcpp#407 mcpp build 会重放 mcpp test 留下的构建图。

min_mcpp / latest_mcpp 不动

需要新客户端的是图形成员的安装,不是这个索引的寻址。抬全局下限会让旧客户端
拿不到与图形无关的每一个包 —— 而索引是数据、mcpp 是程序,发布数据不得让已发布的
程序失效。

失败的全量 sweep 现在会被看见

周更 cron 已经在跑全量,但红了不拦任何东西、也不通知任何人,所以跑和不跑没有区别。
实测:8 个图形成员以同一句话失败了数周,而 main 一直显示绿 —— 因为真正会构建它们的
workspace job 在每一次 push 上都是 skipped。

「main 是绿的」和「这些包装得上」是两个不同的断言。

新增的 sweep-alert 把第二个变成一条有人看得见的 issue。单条 issue 反复 reopen +
追评,不是每周开一个新的 —— 每周开新 issue 的追踪器是会被静音的追踪器。
只对 schedule / workflow_dispatch 生效:PR 的失败在 PR 上已经看得见。

判据

本次 PR 的 diff 触到 validate.yml ⇒ 按本仓规则触发 __ALL__ 全量扫描,
所以这条 PR 自己就是判据:gui-stack / imgui-window / eui-neo ×5 八个成员
必须由 FAIL 转 ok;graphics install: no side effects 那个 job 红在同一句话上,
应当一并转绿。

[Sunrisepeak]

已 rebase 到 main(#203 之后),冲突解在 MCPP_VERSION 那一处 —— 保留了 main 那条注释,只把 pin 抬到 2026.8.10.3 并补上根因。

补的根因

main 的判断方向是对的。补一句:这不是索引的数据缺陷,是内带 xlings 的版本。
四段版本参与范围比较由 xlings 2026.8.9.2 修好;2026.8.8.2 内带 2026.8.8.1,
正好落在修复之前,所以它把一个存在的包报成 not found。xim-pkgindex 一个字都不用改。

为什么取 .3 而不是 .1

它另外带 mcpp#405(缓存命中时
每个图形项目的第二次构建必挂)与 mcpp#407。

rebase 前那一轮全量扫描的结果(12 shard 全绿)

gui-stack            130s  ok      (上次  43s FAIL)
imgui-window          88s  ok      (上次  23s FAIL)
eui-neo              161s  ok
eui-neo-app-main     123s  ok
eui-neo-markdown     128s  ok
eui-neo-sdl2         603s  ok
eui-neo-vulkan       144s  ok
eui-neo-window       133s  ok

耗时本身就是证据:上次是失败得快,这次是真的在构建。
sweep-alert 那一轮是 skipping —— sweep 没失败,正是它该有的行为。