ci(m184): linux-x64 进发布名单，两档 Linux 转 mode=ci，arm64 只构建不发布
发布流水线默认从 2 个槽位变 4 个：`linux-x64`（ubuntu-22.04）与 `linux-arm64` （ubuntu-22.04-arm）的 mode 由 probe 改 ci，tag 推送默认就编。 构建 ≠ 发布仍由 `PUBLISH_SLOTS` 决定，本轮只加 `linux-x64`： - `linux-x64` 有运行时证据 —— release 产物在 Linux 真机（Ubuntu 22.04 + WSLg 真窗口） 渲出一帧、[theme]/[backend] final 日志齐全、像素判定通过，真窗口 1180x760 从 Windows 侧截屏可见；`release-build.yml` 另加一条**同槽位**的 xvfb 运行时门禁（只在 `inputs.slot == 'linux-x64'` 上跑，不给没验过的 arm64 造红）。 - `linux-arm64` 只有构建证据、运行时零证据，产物照出 artifact 取证但不发布；解锁条件 （真机渲出一帧 + 主题日志）写进 release-notes 与 §9。 守卫跟着扩（`packaging/check_publish_slots.py`）： - 自测从 8 条扩到 11 条，新增「声明的 linux-x64 构建红了 ⇒ 必须红（挡住发布）」、 「linux-arm64 有产物但没声明 ⇒ 只警告」、「提前把 linux-arm64 写进名单 ⇒ 缺产物必红」； - probe 档样例从 linux-x64 换成仍是 probe 的 macos-arm64（否则该用例会从「必须红」 变成「本来该绿」）； - 新增「mode=ci 却本次没产物 ⇒ ::warning::」：红一档不能只表现为表里少一行。 文档矩阵同步（release-notes §Downloads/§Support matrix、compliance §9/§10、 artifacts §1、build-and-ci §3、README ×2），两份文档都把 Linux 写成 「已构建并发布（x64）/ 已构建未发布（arm64）」，并把新发现写实：Linux 上整窗透明 与圆角没有代码路径（hwnd=none / corner=policy=system），不是「未验」；Linux 上 `ull update apply` 会拒绝 portable-zip（清单里现在有 linux-x64 产物）。 证据账（含实测输出、CI 增量估算、未验清单）：packaging/docs/linux-evidence.md。
This commit is contained in:
AskaEth committed
1 parent
dc3fa2be87
commit
2813e2984c
14 files changed
+608
-151
No files matched your search
+78
-27
@@ -6,6 +6,11 @@ No WebView, no bundled runtime, no JRE download needed to start the launcher its
|
||||
|
||||
## What's new in {{VERSION}}
|
||||
|
||||
- **Linux x64 is a published platform.** The release workflow now builds `linux-x64` on a native `ubuntu-22.04`
|
||||
runner by default (not only in manual all-slots runs) and publishes it: `unlucky-launcher_{{VERSION}}_linux_x64.tar.gz`
|
||||
plus the bare `ull_{{VERSION}}_linux_x64`. The artifact itself was started on a Linux machine under a real display
|
||||
server, rendered a frame and logged the expected theme/backend lines before this decision, and the same check is
|
||||
now a per-slot CI gate. Linux ARM64 is built too, but stays unpublished until an ARM64 machine runs it.
|
||||
- **{{VERSION}} is the first release published as a stable release.** GitHub only points
|
||||
`releases/latest` at the newest **non-prerelease** release, so `0.2.2` — kept as a historical
|
||||
pre-release, untouched — never appeared there. A pushed tag now creates a stable release by default;
|
||||
@@ -32,6 +37,7 @@ Asset names are `<name>_<version>_<platform>_<arch>`, underscore separated — t
|
||||
| Platform | Asset | Notes |
|
||||
| --- | --- | --- |
|
||||
| Windows 10/11 x64 | `unlucky-launcher_{{VERSION}}_windows_x64.exe` | single exe, double-click to run; this is also what you run on ARM64 Windows (x64 emulation) |
|
||||
| Linux x64 | `unlucky-launcher_{{VERSION}}_linux_x64.tar.gz` | one archive, one top-level directory holding the binary plus `LICENSE` / `NOTICE` / `README.md`; needs glibc 2.35+ and the usual X11/Wayland + fontconfig stack |
|
||||
|
||||
**Windows ARM64 is not part of this release.** CI still builds it on a native `windows-11-arm` runner (Windows 11
|
||||
Arm64 with Visual Studio 2026), but the build has not delivered an artifact yet, so
|
||||
@@ -40,21 +46,25 @@ Arm64 with Visual Studio 2026), but the build has not delivered an artifact yet,
|
||||
so far happened in a **pre-build toolchain probe** that guessed whether the SDK's ARM64 import libraries were
|
||||
present and aborted before `cargo build` ever ran — the compiler and linker have not been heard from yet. That
|
||||
probe is now evidence-only (it prints what it sees and never decides the job), so the next CI run is the first
|
||||
one that can actually answer the question. `windows-x64` is the only published slot; ARM64 rejoins this table as
|
||||
soon as a run produces its artifact (one line in the workflow's `PUBLISH_SLOTS`, guarded on both sides by
|
||||
`packaging/check_publish_slots.py`).
|
||||
one that can actually answer the question. ARM64 rejoins this table as soon as a run produces its artifact (one
|
||||
line in the workflow's `PUBLISH_SLOTS`, guarded on both sides by `packaging/check_publish_slots.py`).
|
||||
|
||||
**This release ships Windows only, and CI builds Windows only.** The Linux (x64 / arm64) and macOS
|
||||
(Apple Silicon / Intel) slots are not built by the release workflow at all — they have not been verified
|
||||
on real machines yet, so nothing unverified is handed out and no build minutes are spent on them. They
|
||||
stay out of the download list and out of `SHA256SUMS.txt` until that verification happens; a manual
|
||||
workflow run can build all six slots for that purpose, but the four extra slots are never published. The
|
||||
support matrix below marks those slots accordingly.
|
||||
**Linux ARM64 is built but not published, and it has no runtime evidence yet.** `linux-arm64` joined the default
|
||||
build matrix in this release (native `ubuntu-22.04-arm`, same glibc 2.35 floor as x64), so the artifact exists as
|
||||
build evidence, but nothing has ever run it on ARM64 hardware — not one frame. It stays out of the download list
|
||||
and out of `SHA256SUMS.txt` until an ARM64 machine renders a frame and the theme/backend log lines come out as
|
||||
expected; that run is the single unlock condition, and copying a build nobody executed is exactly what this list
|
||||
is meant to prevent. The publish job prunes that artifact with an explicit "not published" warning rather than
|
||||
dropping it quietly.
|
||||
|
||||
**macOS is not built by the release workflow at all.** The Apple Silicon and Intel slots never got past a manual
|
||||
probe, so no build minutes are spent on them and nothing unverified is handed out. They stay out of the download
|
||||
list and out of `SHA256SUMS.txt`; a manual workflow run can build all six slots for evidence, but the probe slots
|
||||
are never published. The support matrix below marks those slots accordingly.
|
||||
|
||||
The Windows asset is a bare `.exe`, so `LICENSE`, `NOTICE` and `README.md` are attached to this release
|
||||
next to it: the license terms travel with every download. Slots that ship an archive (Linux / macOS, once
|
||||
published) unpack to one top-level directory of the same name holding the binary plus those three
|
||||
documents.
|
||||
next to it: the license terms travel with every download. The Linux archive unpacks to one top-level directory
|
||||
of the same name holding the binary plus those three documents.
|
||||
|
||||
## Command line
|
||||
|
||||
@@ -65,6 +75,10 @@ Each published slot also ships the command line as its own small bare asset,
|
||||
.\ull_{{VERSION}}_windows_x64.exe instances list # servers and CI: no graphics stack needed
|
||||
```
|
||||
|
||||
```bash
|
||||
./ull_{{VERSION}}_linux_x64 instances list # same binary shape on Linux, no display needed
|
||||
```
|
||||
|
||||
`ull` runs `instances`, `install`, `pack import`, `launch`, `accounts`, `sessions`, `logs`, `diag`,
|
||||
`config`, `java` and `agent`, and links no graphics library at all. The GUI binary accepts the same set
|
||||
before it ever opens a window, so a desktop machine does not need `ull`.
|
||||
@@ -84,22 +98,29 @@ Published = shipped as a download of **this** release, listed in `SHA256SUMS.txt
|
||||
| Platform | Status in this release | Level | Runtime requirements |
|
||||
| --- | --- | --- | --- |
|
||||
| Windows 10/11 x64 | **published** | first class | nothing beyond the OS (UCRT is part of Win10+) |
|
||||
| Linux x64, X11 | **published** | first class | glibc 2.35+ (`libxkbcommon`, `fontconfig`, `libGL` or the software renderer, `libxcb`) |
|
||||
| Linux x64, Wayland | **published** (same archive, Wayland path unverified) | supported | the same archive; `wayland-client` + `libxkbcommon`, plus the X11 set for XWayland apps |
|
||||
| Windows 11 ARM64 | not published (build evidence only) | first class (launcher artifact) | nothing extra; the launcher runs natively, the game itself runs through the OS x64 emulation layer with an x64 JDK |
|
||||
| Linux arm64 | built, not published (no runtime evidence) | first class (unverified) | glibc 2.35+ (native `ubuntu-22.04-arm`, same floor as x64), `libxkbcommon`, `fontconfig`, `libGL`, `libxcb` / `wayland-client` |
|
||||
| macOS 12+ Apple Silicon | not built (unverified) | first class (unverified) | nothing; unsigned build, needs the Gatekeeper workaround |
|
||||
| macOS 12+ Intel | not built (unverified) | first class (unverified) | same as above |
|
||||
| Linux x64, X11 | not built (unverified) | first class (unverified) | `libxkbcommon`, `fontconfig`, `libGL` (or software renderer), `libxcb` |
|
||||
| Linux x64, Wayland | not built (unverified) | supported (unverified) | `wayland-client`, `libxkbcommon`, plus the X11 set for XWayland apps |
|
||||
| Linux arm64, X11 | not built (unverified) | first class (unverified) | glibc 2.35+, `libxkbcommon`, `fontconfig`, `libGL`, `libxcb` |
|
||||
| Linux arm64, Wayland | not built (unverified) | supported (unverified) | the above plus `wayland-client` |
|
||||
| Windows 8.1/8/7 | not built | unsupported | the baseline is Windows 10 |
|
||||
| Android — Termux + X11 | not built (no CI slot) | experimental, not promised | CLI and GUI from source only; GUI verified on-device twice: CPU software rendering and self-built Mesa/turnip GPU acceleration (see `packaging/docs/termux-glibc-build.md` and `README.termux.md`) |
|
||||
|
||||
`windows-x64` is the only published slot this release; Windows ARM64 stays out until a CI run actually produces
|
||||
its artifact (see Downloads above — so far every ARM64 failure was the pre-build probe, never the compiler).
|
||||
Both arm64 rows are formal matrix slots, not the experimental Termux path, and Linux arm64 is not built by
|
||||
default — someone has to run it on real hardware (via a manual all-slots run) before it joins this list. The
|
||||
rows above and the matrix table in `packaging/docs/compliance-support-boundaries.md` §9 are the same list —
|
||||
change one, change the other.
|
||||
Two slots are published this release: `windows-x64` and `linux-x64`. Linux x64 is not a claim taken on faith — the
|
||||
release artifact itself was started on a Linux machine, opened a real window under a real display server, rendered a
|
||||
frame (PNG asserted non-blank) and printed the expected `[theme]` and `[backend] final=… result=started` lines, and
|
||||
the release build now carries the same check as a per-slot CI gate (`packaging/docs/linux-evidence.md` has the raw
|
||||
output). What that does **not** cover: dragging/resizing and font metrics / CJK shaping on a real desktop session.
|
||||
Whole-window transparency and rounded corners have no code path on Linux at all (transparency needs a native window
|
||||
handle the app does not get there; corners are delegated to the desktop compositor), so they are not "unverified" —
|
||||
they are not applicable. Nothing at all is known about Linux ARM64: no ARM64 machine has run the binary yet, which is
|
||||
why that row stays unpublished.
|
||||
|
||||
Both arm64 rows are formal matrix slots, not the experimental Termux path, and Linux arm64 is not published until
|
||||
someone runs it on real hardware — a manual all-slots run builds it today, and one real frame on an ARM64 machine is
|
||||
the unlock. The rows above and the matrix table in `packaging/docs/compliance-support-boundaries.md` §9 are the same
|
||||
list — change one, change the other.
|
||||
|
||||
## Install
|
||||
|
||||
@@ -108,9 +129,26 @@ release, and it is also what you run on ARM64 Windows (the OS runs it through it
|
||||
The first run creates `.ULL/` and `.minecraft/` next to the exe (portable is the default data mode); the
|
||||
per-user `%APPDATA%\ULL` plus `%APPDATA%\.minecraft`, or a custom root, are selectable instead.
|
||||
|
||||
Linux / macOS are not part of this release; their asset names are already fixed by the same rule
|
||||
(`unlucky-launcher_{{VERSION}}_linux_x64.tar.gz`, `_linux_arm64`, `_macos_arm64`, `_macos_x64`) so the
|
||||
links will not change shape when those slots open.
|
||||
**Linux x64** — unpack the archive and run the binary inside it; nothing is installed system-wide:
|
||||
|
||||
```bash
|
||||
tar -xzf unlucky-launcher_{{VERSION}}_linux_x64.tar.gz
|
||||
cd unlucky-launcher_{{VERSION}}_linux_x64
|
||||
./unlucky-launcher # X11 or Wayland; --software-renderer forces the CPU rasteriser
|
||||
```
|
||||
|
||||
It needs glibc 2.35+ (the slot is built on Ubuntu 22.04, so that is the floor), `libxkbcommon`, `fontconfig`
|
||||
and `libGL` — or `--software-renderer` if there is no usable GPU adapter. On Debian/Ubuntu:
|
||||
|
||||
```bash
|
||||
sudo apt-get install libxkbcommon0 libfontconfig1 libgl1 libx11-6 libxcursor1 libxrandr2 libxi6
|
||||
```
|
||||
|
||||
The bare `ull_{{VERSION}}_linux_x64` next to the archive runs on a machine with no display at all.
|
||||
|
||||
Linux arm64 and macOS are not part of this release; their asset names are already fixed by the same rule
|
||||
(`unlucky-launcher_{{VERSION}}_linux_arm64.tar.gz`, `_macos_arm64`, `_macos_x64`) so the links will not change
|
||||
shape when those slots open.
|
||||
|
||||
## No GPU? Software renderer
|
||||
|
||||
@@ -119,8 +157,8 @@ adapter is present; `--software-renderer` (or its equivalent `--renderer=cpu`) f
|
||||
|
||||
## Verify the download
|
||||
|
||||
`SHA256SUMS.txt` lists exactly the assets attached to this release (Windows only), and `sha256sum -c`
|
||||
checks the ones you actually downloaded:
|
||||
`SHA256SUMS.txt` lists exactly the assets attached to this release (Windows x64 and Linux x64, GUI + `ull` each), and
|
||||
`sha256sum -c` checks the ones you actually downloaded:
|
||||
|
||||
```bash
|
||||
sha256sum -c SHA256SUMS.txt --ignore-missing # Linux / WSL
|
||||
@@ -146,6 +184,19 @@ Get-FileHash .\unlucky-launcher_{{VERSION}}_windows_x64.exe -Algorithm SHA256
|
||||
id.
|
||||
- Binaries are not code-signed / notarized yet: Windows SmartScreen and macOS Gatekeeper warn on first
|
||||
launch. The checksums above are the integrity reference for now.
|
||||
- **Linux x64 is verified, not "finished".** The published archive was built on Ubuntu 22.04 and started under a
|
||||
real display server (WSLg) where it opened a window, rendered a non-blank first frame and printed its theme and
|
||||
backend lines; CI repeats that with Xvfb on every release. What nobody has looked at yet on a real desktop
|
||||
distribution: dragging and resizing, font metrics and CJK shaping. Whole-window transparency and rounded corners
|
||||
are not "unverified" on Linux — they are not code paths there: transparency needs a native window handle the app
|
||||
does not get (`hwnd=none`), and corners are delegated to the desktop compositor (`corner=policy=system`).
|
||||
- **On Linux the in-app update does not install itself.** The published Linux asset is a `.tar.gz`, and
|
||||
`ull update apply` only self-replaces the portable single-file `.exe` form — on Linux it refuses with an explicit
|
||||
message naming `portable-zip` instead of half-installing (see `crates/core/src/update/job.rs`). Updating on Linux
|
||||
means downloading the new archive and unpacking it over the old copy; the update check itself (version + channel)
|
||||
works normally.
|
||||
- **Linux ARM64 has no runtime evidence at all.** It compiles, and that is the whole story; the artifact is not
|
||||
attached to this release.
|
||||
- When the macOS slot ships it is the bare binary (single-file promise), not a `.app` bundle: no Dock
|
||||
icon or Finder double-click — launch it from a terminal.
|
||||
|
||||
|
||||
Reference in new issue
Block a user