AskaEth/Unlucky-Launcher
1
0 Fork 0
Code Issues Pull Requests Actions 4 Packages Projects Releases Wiki Activity
426 Commits 3 Branches 4 Tags
211e07b470fa7152ceb230e8d94b3c8fddff24b1
Commit Graph
13 Commits
Author SHA1 Message Date
AskaEth 3b3430a93e docs(termux): 对外口径升级——CPU 软渲染 + 自编 Mesa GPU 两条路径各真机验证一次（用户拍板 A，四处同步） 2026-11-07 09:33:24 +08:00
AskaEth 394faad611 docs(termux): MC 1.20.4 真机跑通结论与剩余项 
- README：MC 标 ✅（glibc JRE + arm64 natives + softpipe）；后续收敛为
  zink/DRI3、剪贴板/IME、narrator/音频
- 构建文档 §4.2 补真机启动命令、窗口尺寸与日志位置、非致命项
 2026-11-07 09:33:23 +08:00
AskaEth 7eed6c6261 feat(termux): MC 启动接线——Linux arm64 natives + softpipe 子进程环境 
- Library::native_classifier：Linux/aarch64 上把 LWJGL3 的 natives-linux
  改写成 natives-linux-arm64（Mojang 清单只有 x86_64）
- install::libraries：arm64 分类器在清单里没有下载信息时，按 Maven 相对路径
  兜底到阿里云镜像（实测 Mojang libraries 404、Aliyun 200）；
  单测覆盖 arm64 兜底与 x86_64 不变
- launch::defaults：Termux glibc 构建启动 MC 时默认带
  MESA_LOADER_DRIVER_OVERRIDE=swrast / LIBGL_ALWAYS_SOFTWARE=1（用户可覆盖）
- 文档：JRE patchelf 一次性步骤与接线现状；README 同步
- 验证：patched Temurin java 直接执行；LWJGL arm64+GLFW 探针 gl-ok
 2026-11-07 09:33:22 +08:00
AskaEth 02ed09ae49 docs(termux): 补 MC 运行时结论（glibc JRE + LWJGL arm64 + softpipe GL） 
- §4.2：Temurin 21 JRE 在 glibc 下跑通；AWT/X11 正常；
  LWJGL 3.3.3 arm64 + GLFW + GLX/softpipe 端到端探针通过（GL 3.3）
- zink 仍卡 DRI3；softpipe 可用（软件 GL）
- README 同步：MC 标 🟡（栈已验证，启动器接线待做），后续改为接线 + DRI3
 2026-11-07 09:33:22 +08:00
AskaEth 173a18b842 feat(termux): glibc 构建自动启用自编 Mesa 26 turnip ICD（GPU 打通） 
- app/boot/termux_gpu：glibc 构建 + Termux 且随附 ICD 存在时，在探测前设
  VK_ICD_FILENAMES/VK_DRIVER_FILES；用户显式设置不覆盖
- 文档：Mesa 26.2.6 + KGSL 的完整构建/安装/验证步骤（含 shebang、
  --wrap-mode=nofallback、C++/链接参数三处坑）
- 实测：wgpu 选中 Adreno 840（turnip Mesa 26.2.6），截图首帧 61 ms
- README.termux：GPU 标 ✅，MC 标 🟡（glibc JRE+AWT 已验证，GLX 待 GL 构建）
 2026-11-07 09:33:21 +08:00
AskaEth bbb316ca08 docs(termux): GPU 结论落地——glibc 侧被驱动版本挡住 
实测结论：
- glibc Vulkan loader + 自写 ICD 能加载
- Termux glibc Mesa 24.2.6 不认识 Adreno 840（chip 0x44050A31 unsupported）
- Arch vulkan-freedreno 26.2.6 能加载但 Linux/DRM 构建找不到设备（缺 KGSL，
  /dev/dri 对 untrusted_app 被 SELinux 拒绝）
- GPU 变体会打印具名错误并自动降级 tiny-skia

README.termux 同步：GPU 标 ⛔、MC 走 glibc JVM 的结论与后续路线
 2026-11-07 09:33:21 +08:00
AskaEth c434dbe335 feat(termux): 横屏自适应窗口、安装后清理 apt 工作区、补分支 README 
- app/boot/termux_window：Termux 上默认窗口按 X 屏幕等比自适应
  （横屏铺满、竖屏不溢出，最大 2×；日志 source=termux-screen），
  ULL_WINDOW_SIZE 覆盖与 1180×760 验收基准不变；5 条单测
- termux::install 成功后清理 $PREFIX/tmp/ull-java-termux（一次安装约 100 MB）
- 构建文档补 clippy/rustfmt 组件、cargo-clippy 目标被带成 android 的坑、
  门禁命令、横屏行为与 openjdk-17 实测
- 新增 README.termux.md（分支定位/已验证矩阵/快速开始/边界/路线图），
  两份主 README 的 Termux 条目链过去
 2026-11-07 09:33:21 +08:00
AskaEth 48d1ee6616 feat(java): Termux 上自动安装系统 openjdk（内置镜像 + 隔离 apt 状态） 
- 新增 game::java::termux：内置 SAU/TUNA/USTC/官方四个 termux-main 镜像，
  按顺序 apt-get update+install；lists/cache 隔离在 $PREFIX/tmp/ull-java-termux，
  不改用户 apt 配置；装完从 $PREFIX/lib/jvm 定位，幂等（已装则不走网络）
- JdkVendor 增加 termux（17/21/25），--vendor termux 只走系统包；
  Termux 上缺省安装先试系统包，失败再走归档链并带出每一跳原因
- standard_roots 已能扫 $PREFIX/lib/jvm（上一条提交），装完即被 java list 发现
- CLI/presenter 的 vendor 展示与帮助文案同步；设置白名单与契约测试同步
- 文档补 Termux 上的 Java 行为
 2026-11-07 09:33:19 +08:00
AskaEth 1e0fc44fed docs(packaging): 记录 Termux glibc 构建与 termux-x11 运行配方 
新增 packaging/docs/termux-glibc-build.md：glibc 工具链（Rust gnu 组件 +
patchelf + clang/lld + Debian libgcc crt）、构建环境（LD_PRELOAD/CA/USTC 镜像）、
termux-x11 运行与截图取证、GPU 现状与已知边界。
支持矩阵四处同步：Termux 行从「GUI 未验证」改为「源码自建、CPU 渲染单机验证过」，
仍标注实验级、不在发布矩阵内。
 2026-11-07 09:33:19 +08:00
AskaEth 06fe12d811 chore(release): M154 版本升到 0.2.2（第一个稳定通道版本，D51） 
- 根 Cargo.toml `[workspace.package] version` 0.2.1 → 0.2.2；`crates/{agent,app-iced,cli,palette-extract,
  presenter}` 里 9 处 intra-workspace path 依赖的 version 约束一并对齐（M137 既定做法）。`crates/app` 是
  workspace `exclude` 的 Slint 退役树，manifest 不参与解析，原样保留。
- Cargo.lock 由 cargo 再生成：只有 8 个 `unlucky-*` 成员条目从 0.2.1 变 0.2.2，第三方依赖（含版本号恰好
  也是 0.2.1 的 hexf-parse / windows-link / windows-threading / xkeysym / yazi）一字未动。这一步不是可选：
  CI 与发布流水线全走 `--locked`（ci.yml:236,274 / release-build.yml:135,142 / make_artifacts.py:50），
  lock 不跟就是「tag 一打就红」。
- packaging 文档里的**示例 tag** 跟到 v0.2.2：docs/artifacts-and-version.md 两处（命名规则示例 + 「tag 说
  X、产物里写 Y」的事故示例）、docs/build-and-ci.md 三处（`--version v…`、两次 `gh workflow run --ref v…`）、
  docs/profiles-and-measurements.md 的「同一槽位现在叫 `unlucky-launcher_0.2.2_windows_x64.exe`」、
  make_manifest.py 四处（Usage 示例 / `normalize_version` docstring / `--version` 的 argparse help）。
- **历史注记一律不动**：docs/runtime-deps.md 的「v0.2.1 首次真跑即红在工具链体检」（M140 事故记录）、
  `.github/workflows/release.yml:71` 同一事故的另一处记录、`crates/core` 更新模块测试里的样本版本串
  （`checker_cases.rs` / `version_cases.rs`，是解析器测试夹具，不是发布事实）、`microsoft.rs:224` 的
  `21.0.13.0.2.1` 负例。
- README.md / README.zh-CN.md、packaging/release-notes.md 核实后**无需改动**：三份文件里没有任何写死的
  版本号——下载表是 `<version>` / `<版本>` 占位符（M153 刚统一的口径，含非发布档位标「暂未发布」的行，
  原样保留未回退），release-notes 正文是 `{{VERSION}}` / `{{SUMS}}` 模板占位符。

验证：`cargo check -p unlucky-cli --all-targets --locked` 过（编译日志里 unlucky-core/agent/cli 均报 v0.2.2）、
`cargo test -p unlucky-cli --lib --locked` 42 passed 0 failed、`cargo metadata --locked --offline` 过（全
workspace manifest + lock 一致）、`python3 packaging/make_manifest.py --self-test` ok、
`ull --version` 实跑输出 `ull 0.2.2（unlucky-cli）`。
 2026-11-07 08:13:29 +08:00
AskaEth e3ee20bdcd feat(packaging): M151 发布流水线生成更新清单 manifest.json（D50） 
清单挂 GitHub Release 资产，固定文件名 manifest.json（D50）。字段形状的权威是 M146 的
crates/core/src/update/manifest.rs（ReleaseManifest，deny_unknown_fields + 逐字段校验），
生成器只负责把那套形状填对，不另立 schema。

同源，不双写：packaging/make_manifest.py 的每个 sha256 直接读 Release 自己的
SHA256SUMS.txt，size 取自同一批文件的 stat()；产物名里的版本段必须等于 --version，
tag 与 Cargo.toml 漂了就没有产物可对，当场失败。CI 在「裁剪发布白名单后重算
SHA256SUMS」之后调它，所以清单描述的是真正要发的资产，不是构建出来的全部。
make_artifacts.py 只加 --manifest 开关，用子进程调同一份脚本（本地跑也产出
manifest.json），本文件继续是产物命名的唯一真相源。

只放启动器产物：DTO 的 Artifact 没有角色字段，Release::artifact_for() 取第一个
target 命中的产物，把 ull 并列写进去会让「覆盖哪个文件」取决于数组顺序；ull 照旧进
SHA256SUMS.txt 与 Release。

url 两种形态：默认裸文件名（DirSource 口径，本地/内网用）；CI 传 --asset-base-url
拼绝对地址并钉 tag（不是 latest），清单里每条都指向与它自报版本相符的字节。

自验：--self-test 用 packaging/tests/manifest.golden.json 逐字节对拍（覆盖裸 exe 与
tar.gz 两种形态，并钉住「ull 不进清单」），再跑 14 条负例证明严格解析不是摆设；
发布步会先跑它再产文件。真 DTO 对拍已在本机用 M146 的 ReleaseManifest 实测：
golden 解析通过（2 个产物、min_supported、force 均正确落位），14 条篡改全部被拒。

未决（报告带利弊，未自行改发布默认值）：releases/latest/download/* 只指向非 prerelease
的最新 Release，而发布默认 prerelease=true。

Refs: D50, M146
 2026-11-06 22:15:58 +08:00
AskaEth 5597a4cc18 feat(release,docs): M149 发布构建烘入微软登录 id（仓库 Secret），文档改为「官方构建开箱即用」 
构建侧：release-build.yml 声明 on.workflow_call.secrets.ULL_MSA_CLIENT_ID（required: false），
cargo build 步以 env 注入它，option_env! 把它烘进二进制；release.yml 的 build job 按名显式透传
（与 PUBLISH_TOKEN 同一模式，不用 inherit）。真值放仓库 Secret，不进任何 git 文件；Secret 未录入
或 Actions 之外求值为空串时，client_id.rs 的 blank_env_value_counts_as_missing 保证「空白=没配」，
不会拿空 id 去联网。

文档：README 两版 / help.rs 的 accounts topic / packaging/release-notes.md /
packaging/docs/build-and-ci.md 统一成「官方构建已内置登录所需配置、开箱即用，仍可用环境变量
ULL_MSA_CLIENT_ID 覆盖；自建想自带就构建时注入」的功能性口径 —— 不出现 id 本身，也不出现归属描述。
client_id.rs 的模块注释与测试注释同步（原文写「id 不进仓库（用户定案）」，已随 Secret 方案改写），
并记下「别把 ULL_MSA_CLIENT_ID 导出到跑 cargo test 的 shell」——presenter 的 M132 入口锚会在
已烘焙 id 的构建里故意红。

实测：ULL_MSA_CLIENT_ID=<id> cargo build --bin ull 后，清空 env 跑 ull accounts add msa 打出
用户码与链接（无「未配置」提示）；同二进制设一个假 env id 则 AADSTS700016 点名该假 id（env 覆盖生效）。
单测：core auth 28、unlucky-cli 全套、i18n 30、presenter 222 全绿；M132 锚在烘焙构建里按设计红、
在不带 id 的构建里绿。cargo fmt --all --check 通过。
 2026-11-06 21:08:53 +08:00
AskaEth 374e168334 docs(packaging): M145 按主题拆分 README（索引 + docs/，节号不变） 
packaging/README.md 也是 400 行整，且安装包与自动更新马上要动发布线。按主题分成
「索引 + 5 份承载文件」，每份 ≤124 行：

- README.md 只留真相源声明、§1–§12 的索引表、§11、§12
- docs/artifacts-and-version.md：§1 产物矩阵 + §2 版本来源
- docs/build-and-ci.md：§3 怎么构建
- docs/runtime-deps.md：§4 运行时依赖 + §5 软渲染兜底
- docs/profiles-and-measurements.md：§6 构建档位 + §7 实测
- docs/compliance-support-boundaries.md：§8 合规 + §9 支持矩阵 + §10 已知边界

节号沿用原编号，所以全仓「packaging/README.md §N」式引用（根 README / README.zh-CN /
make_artifacts.py / release-notes.md / ci-runtime-smoke.md / release*.yml 注释）都不用改。
搬家由脚本按原文件切片生成，逐行可查：旧 README 400 行全部出现在新位置，唯一改写的
旧行是 §12 清单里那两行（文件清单必须反映拆分后实况）。新增行 15 条：索引段、§3 的
M145 说明、§12 的 5 份新文件行。
 2026-11-06 19:29:47 +08:00