[linghengqian]

This pull request holds two unrelated changes: documentation on what a GraalVM needs after vfox install, and a fix for the E2E workflow.

Docs: what a GraalVM needs after vfox install

After vfox install java@25.0.2-graalce, or any other GraalVM, does the machine need sudo apt install --assume-yes build-essential zlib1g-dev? Only to build native executables with native-image. java, javac and a program run without them. The docs did not say so.

Changes

• README.md and README_CN.md: a "Native Image" section with the command.
• docs/distributions.md: a section "Native Image and the C toolchain" with what native-image prints without the packages, what other systems need, and GraalVM CE 8 to 19, which come without native-image.
• docs/troubleshooting.md: two entries, for the messages native-image stops with and for native-image: command not found.
• The Chinese pages say the same.

docs/changes.md stays as it is, as in #118.

Checked

2026-11-02, in Ubuntu 26.04 container images (x64) with no compiler, vfox 1.0.13 and this plugin:

• vfox install of each GraalVM listed below, then java -version, javac and a hello world, worked with no extra package.
• native-image Hello with no package stops within seconds: Default native-compiler executable 'gcc' not found via environment variable PATH. zlib1g-dev alone changes nothing.
• With build-essential alone it analyses and compiles first, then fails when it links: cannot find -lz: No such file or directory.
• With build-essential zlib1g-dev it builds a hello world that runs. gcc, libc6-dev and zlib1g-dev are enough too.
• All of that holds for GraalVM Community 25.0.2 and 25.4.4.1.1, Oracle GraalVM 25.0.5, Mandrel 25.0.5, Liberica NIK 25.0.4.1 and Gluon GraalVM 22.1.0.1.
• Fedora 44: gcc glibc-devel zlib-devel builds a hello world. The libstdc++-static that GraalVM lists was not needed.
• GraalVM CE 8 to 19 (grl8, grl11, grl16, grl17, grl19) ship gu and no native-image. gu install native-image worked for 22.3.3-grl11, 21.2-grl16, 22.3.3-grl17 and 22.3.1-grl19, and 22.3.3-grl17 then built a hello world with the packages. It fails for 21.3.1-grl8 with A JSONObject text must begin with '{', because the release index it reads, https://oca.opensource.oracle.com/gds/meta-data.json, is a web page now. gu -L install of the component file from the vm-21.3.1 release works, and the docs say so.

Not checked

• arm64, macOS and Windows. For those the docs point to GraalVM's prerequisites.
• That the Maven and Gradle plugins for Native Image need the same packages. That follows from GraalVM's documentation, and was not run here.

CI: a newer commit on main cancelled the E2E run of the older one

e2e.yml put every run of a branch in one concurrency group, e2e-${{ github.ref }}, with cancel-in-progress: true. For a pull request that is wanted: a new push replaces the run of the push before it. On main it costs the older commit its result. #120 and #119 were merged within two minutes of each other:

• chore: add an opencode.jsonc that allows git push, gh pr create and gh pr comment in this project #119's run cancelled the first attempt of fix: verify downloads against the checksum Foojay lists, so vfox install java@25.0.2-graalce and the like no longer end with WARNING: Checksum is not provided, skip verify... #120's run.
• Re-running fix: verify downloads against the checksum Foojay lists, so vfox install java@25.0.2-graalce and the like no longer end with WARNING: Checksum is not provided, skip verify... #120's then cancelled chore: add an opencode.jsonc that allows git push, gh pr create and gh pr comment in this project #119's.

The cancelled jobs carry the annotation Canceling since a higher priority waiting request for e2e-refs/heads/main exists. Whichever way round, one of the two commits ends without an E2E result.

Now a pull request keeps the group e2e-<ref> and still cancels the run of its previous push, while every commit on main gets a group of its own, e2e-<sha>, and nothing there is cancelled. cancel-in-progress: false alone would not do: GitHub keeps at most one pending run per group and replaces the older pending ones, so with three quick merges the middle one would still be cancelled. queue: max would line the runs up, but it cannot be combined with cancel-in-progress: true, which the pull request side needs.

Checked

• actionlint 1.7.12 with .github/actionlint.yaml: no finding before the change, none after.
• This pull request: the push of the CI commit started a run with the new expression, and it cancelled the run of the push before it (annotation ... for e2e-refs/pull/122/merge exists). So a pull request gets the group it had before.

Not checked

• main. It takes two commits landing close together, and then both E2E runs should finish.