Unlucky-Launcher

28 Commits 2 Branches 2 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	4c1a6c54e5	fix(release): M51 r1 —— linux-arm64 改用 ubuntu-22.04-arm（与 x64 同 glibc 2.35 地板） P2-1：24.04-arm 会给出 2.39 地板，把 Debian 12 / Raspberry Pi OS Bookworm （2.36）挡在门外，且「arm64 只有 24.04 档」这句前提是错的（同段注释自己就承认 ubuntu-22.04-arm 有效）。改 os 为 ubuntu-22.04-arm，注释改成「与 x64 同地板（2.35），覆盖 Debian 12 / Ubuntu 22.04 arm64 / RPi OS Bookworm」； README §3/§4/§7.5/§9 与 release-notes 的 Downloads/Support matrix 全量订正 2.39 → 2.35+，删掉「arm64 地板高于 x64」的对比措辞。槽位名、产物名、六槽位齐全性检查与打包脚本均未变。 P2-2：rustup target add 步骤改 env TARGET + `rustup target add "$TARGET"`，并补 shell: bash（此前是全文件唯一没显式 shell 的 run，在 Windows 槽位会落进 pwsh）；Linux 图形栈依赖那步也补了 shell: bash，现在所有 run 都显式 bash、 run 块内零 `${{ }}` 直插。顺带 nit：host_slot() 报错改回原始 arch token（`riscv64` 不再显示成 None）， README §7.5 宣传的那个用例现在诊断可读。验证：yaml 结构断言（六槽位 / linux-arm64=ubuntu-22.04-arm / 齐全性循环 6 / run 块 ${{ }} 零泄漏 / run 步骤全带 shell）、全部 run 块 bash -n、grep 2.39 零残留、host_slot 7 组合注入 + freebsd/riscv64 报错含原名、image_arch 真 exe、 windows-arm64 stub 全流程、架构守卫拦截、linux-arm64 归档两次 sha256 一致（f949d0f5… 与上一轮相同）、windows-x64 原生回归（冒烟 + sha256sum -c）。	2026-11-01 14:16:29 +08:00
AskaEth	15caa1b61f	feat(release): M51 —— 发布矩阵补 Linux arm64 与 Windows arm64 两槽位（六槽位） - release.yml：加 linux-arm64（原生 ubuntu-24.04-arm runner）与 windows-arm64 （windows-latest 上交叉编译到 aarch64-pc-windows-msvc）；产物根改由 matrix.build_dir 参数化，dumpbin 自检与打包都吃矩阵路径而非硬编码 target/release；交叉槽位多两步（rustup target add + ARM64 库体检），release job 的槽位齐全性检查从四扩到六。 - make_artifacts.py：--slot / --build-dir 参数化 + 六槽位映射；打包前回读可执行文件头（PE 机器码 / ELF e_machine / Mach-O cputype）校验架构，跨槽位构建自动跳过 ull --version 冒烟并打印原因（不在 x64 上假装跑得动 arm64 二进制）。 - packaging/README.md + release-notes.md：两张支持矩阵同步加 Windows 11 ARM64 与 Linux arm64 行；arm64 glibc 地板如实写 2.39（高于 x64 的 2.35），并说明与 Termux 实验级的区别（这两个是正式发布槽位）。本地验证：宿主判定注入（七个组合 + 非法宿主 exit 1）、文件头架构识别（真 x64 exe + 合成 PE/ELF/Mach-O 头）、windows-arm64 stub 全流程、架构守卫真拦、linux-arm64 归档两次 sha256 一致、windows-x64 原生回归（冒烟 + sha256sum -c）。arm64 真机构建由 CI 补。	2026-11-01 13:48:37 +08:00
AskaEth	76d83148ff	feat(packaging): 单文件产物矩阵 + tag 触发的 Release 流水线（M46） - packaging/make_artifacts.py：本地与 CI 共用的打包脚本 —— 版本取自 cargo metadata （tag 交叉校验，不一致即失败）、按宿主判定槽位、Windows 裸 exe / UNIX tar.gz （内含 LICENSE/NOTICE/README.md）、SHA256SUMS.txt；打包前跑 `ull --version` 断言版本； tar 内 mtime/uid 归零 + gzip header mtime=0 → 同源构建 sha256 可复现 - packaging/README.md：产物矩阵与命名约定、版本唯一真相源、各平台运行时依赖、软渲染兜底、release profile 取舍、本机实测体积与冒烟证据、合规与支持矩阵 - packaging/release-notes.md：GitHub Release 说明模板（{{VERSION}}/{{SUMS}}，写清 Win10+ / macOS 12+ / Linux x64 支持矩阵） - .github/workflows/release.yml：tag v* 触发四槽位矩阵 → 产物 + 重算 SHA256SUMS → gh release create（pre-release 默认开，workflow_dispatch 只构建）；Windows 用 +crt-static 并以 dumpbin 导入表把"单文件"做成硬门禁；归档内容自检 LICENSE/NOTICE/README - Cargo.toml：release profile lto thin → fat（实测 GUI 16,366,080 → 14,595,584 B = −10.8%，ull 7,572,992 → 6,157,824 B = −18.7%）验证：cargo build --release 通过；GUI `--software-renderer --screenshot` 出 1180×760 PNG、 `ull --version` = 0.1.0；PE 导入表 33 个 DLL 全为系统库（无 VCRUNTIME/libwinpthread）； cargo deny licenses/bans/sources ok；workflow 用 python yaml 解析自检。	2026-11-01 08:33:17 +08:00

Author

SHA1

Message

Date

AskaEth

4c1a6c54e5

fix(release): M51 r1 —— linux-arm64 改用 ubuntu-22.04-arm（与 x64 同 glibc 2.35 地板）

P2-1：24.04-arm 会给出 2.39 地板，把 Debian 12 / Raspberry Pi OS Bookworm
（2.36）挡在门外，且「arm64 只有 24.04 档」这句前提是错的（同段注释自己就承认
ubuntu-22.04-arm 有效）。改 os 为 ubuntu-22.04-arm，注释改成「与 x64 同地板
（2.35），覆盖 Debian 12 / Ubuntu 22.04 arm64 / RPi OS Bookworm」；
README §3/§4/§7.5/§9 与 release-notes 的 Downloads/Support matrix 全量订正
2.39 → 2.35+，删掉「arm64 地板高于 x64」的对比措辞。槽位名、产物名、六槽位
齐全性检查与打包脚本均未变。

P2-2：rustup target add 步骤改 env TARGET + `rustup target add "$TARGET"`，
并补 shell: bash（此前是全文件唯一没显式 shell 的 run，在 Windows 槽位会落进
pwsh）；Linux 图形栈依赖那步也补了 shell: bash，现在所有 run 都显式 bash、
run 块内零 `${{ }}` 直插。

顺带 nit：host_slot() 报错改回原始 arch token（`riscv64` 不再显示成 None），
README §7.5 宣传的那个用例现在诊断可读。

验证：yaml 结构断言（六槽位 / linux-arm64=ubuntu-22.04-arm / 齐全性循环 6 /
run 块 ${{ }} 零泄漏 / run 步骤全带 shell）、全部 run 块 bash -n、grep 2.39
零残留、host_slot 7 组合注入 + freebsd/riscv64 报错含原名、image_arch 真 exe、
windows-arm64 stub 全流程、架构守卫拦截、linux-arm64 归档两次 sha256 一致
（f949d0f5… 与上一轮相同）、windows-x64 原生回归（冒烟 + sha256sum -c）。

2026-11-01 14:16:29 +08:00

AskaEth

15caa1b61f

feat(release): M51 —— 发布矩阵补 Linux arm64 与 Windows arm64 两槽位（六槽位）

- release.yml：加 linux-arm64（原生 ubuntu-24.04-arm runner）与 windows-arm64
  （windows-latest 上交叉编译到 aarch64-pc-windows-msvc）；产物根改由
  matrix.build_dir 参数化，dumpbin 自检与打包都吃矩阵路径而非硬编码 target/release；
  交叉槽位多两步（rustup target add + ARM64 库体检），release job 的槽位齐全性
  检查从四扩到六。
- make_artifacts.py：--slot / --build-dir 参数化 + 六槽位映射；打包前回读可执行文件头
  （PE 机器码 / ELF e_machine / Mach-O cputype）校验架构，跨槽位构建自动跳过
  ull --version 冒烟并打印原因（不在 x64 上假装跑得动 arm64 二进制）。
- packaging/README.md + release-notes.md：两张支持矩阵同步加 Windows 11 ARM64 与
  Linux arm64 行；arm64 glibc 地板如实写 2.39（高于 x64 的 2.35），并说明与 Termux
  实验级的区别（这两个是正式发布槽位）。

本地验证：宿主判定注入（七个组合 + 非法宿主 exit 1）、文件头架构识别（真 x64 exe +
合成 PE/ELF/Mach-O 头）、windows-arm64 stub 全流程、架构守卫真拦、linux-arm64 归档
两次 sha256 一致、windows-x64 原生回归（冒烟 + sha256sum -c）。arm64 真机构建由 CI 补。

2026-11-01 13:48:37 +08:00

AskaEth

76d83148ff

feat(packaging): 单文件产物矩阵 + tag 触发的 Release 流水线（M46）

- packaging/make_artifacts.py：本地与 CI 共用的打包脚本 —— 版本取自 cargo metadata
  （tag 交叉校验，不一致即失败）、按宿主判定槽位、Windows 裸 exe / UNIX tar.gz
  （内含 LICENSE/NOTICE/README.md）、SHA256SUMS.txt；打包前跑 `ull --version` 断言版本；
  tar 内 mtime/uid 归零 + gzip header mtime=0 → 同源构建 sha256 可复现
- packaging/README.md：产物矩阵与命名约定、版本唯一真相源、各平台运行时依赖、
  软渲染兜底、release profile 取舍、**本机实测**体积与冒烟证据、合规与支持矩阵
- packaging/release-notes.md：GitHub Release 说明模板（{{VERSION}}/{{SUMS}}，
  写清 Win10+ / macOS 12+ / Linux x64 支持矩阵）
- .github/workflows/release.yml：tag v* 触发四槽位矩阵 → 产物 + 重算 SHA256SUMS →
  gh release create（pre-release 默认开，workflow_dispatch 只构建）；Windows 用
  +crt-static 并以 dumpbin 导入表把"单文件"做成硬门禁；归档内容自检 LICENSE/NOTICE/README
- Cargo.toml：release profile lto thin → fat（实测 GUI 16,366,080 → 14,595,584 B
  = −10.8%，ull 7,572,992 → 6,157,824 B = −18.7%）

验证：cargo build --release 通过；GUI `--software-renderer --screenshot` 出 1180×760 PNG、
`ull --version` = 0.1.0；PE 导入表 33 个 DLL 全为系统库（无 VCRUNTIME/libwinpthread）；
cargo deny licenses/bans/sources ok；workflow 用 python yaml 解析自检。

2026-11-01 08:33:17 +08:00