Remove GCC 10 from the list of packages to install. by cpovirk · Pull Request #180 · jspecify/jdk

cpovirk · 2026-11-10T21:07:27Z

This should address the error that just popped up, as seen in #179:

Reading package lists...
Building dependency tree...
Reading state information...
Package g++-10 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Unable to locate package gcc-10
E: Package 'g++-10' has no installation candidate

It turns out that we haven't been using GCC 10 all this time, anyway, so it's safe to remove, Gemini explains:

Yes, this is directly caused by GitHub's ubuntu-latest migration from Ubuntu 24.04 to Ubuntu 26.04 (actions/runner-images#14748, rolling out October 19 – November 19, 2026):

Why it failed: jspecify.yml uses runs-on: ubuntu-latest and runs sudo apt-get install gcc-10 g++-10 .... Ubuntu 26.04 dropped gcc-10 and g++-10 from its APT repositories.

Why we don't even need gcc-10 / g++-10: When jspecify.yml was originally created (Build the JSpecify JDK #114), the apt-get install gcc-10 g++-10 line was copied from upstream OpenJDK's build-linux.yml—without the accompanying update-alternatives command (or CC/CXX configure arguments). As a result, ./configure in jspecify.yml has never actually used gcc-10/g++-10; it has always just used the runner's pre-installed default /usr/bin/gcc and /usr/bin/g++ (GCC 13 on Ubuntu 24.04, and GCC 15 on Ubuntu 26.04).

Recommended fix: Simply drop gcc-10 g++-10 from the apt-get install line in jspecify.yml. Current OpenJDK 28 sources in this branch already support GCC 15 (which is also what your local workstation has configured in build/linux-x86_64-server-release), and jspecify.yml already passes --disable-warnings-as-errors. (If anything else in Ubuntu 26.04 ever causes trouble, you could also pin runs-on: ubuntu-24.04 to match upstream main.yml.)

(Maybe we should find the version that upstream uses, install that, and run update-alternatives for that. But for now, I'm happy to get the build working again, and we can cross that bridge when we come to it.)

This should address the error that just popped up, as [seen](https://github.com/jspecify/jdk/actions/runs/42861855071/job/129989794061?pr=179) in #179: ``` Reading package lists... Building dependency tree... Reading state information... Package g++-10 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Unable to locate package gcc-10 E: Package 'g++-10' has no installation candidate ``` It turns out that we haven't been using GCC 10 all this time, anyway, so it's safe to remove, Gemini explains: > Yes, this is directly caused by GitHub's `ubuntu-latest` migration from Ubuntu 24.04 to Ubuntu 26.04 ([actions/runner-images#14748](actions/runner-images#14748), rolling out October 19 – November 19, 2026): > > 1. **Why it failed:** [jspecify.yml](https://github.com/jspecify/jdk/blob/main/.github/workflows/jspecify.yml#L11-L30) uses `runs-on: ubuntu-latest` and runs `sudo apt-get install gcc-10 g++-10 ...`. Ubuntu 26.04 dropped `gcc-10` and `g++-10` from its APT repositories. > 2. **Why we don't even need `gcc-10` / `g++-10`:** When [jspecify.yml](https://github.com/jspecify/jdk/blob/main/.github/workflows/jspecify.yml) was originally created (#114), the `apt-get install gcc-10 g++-10` line was copied from upstream OpenJDK's [build-linux.yml](https://github.com/jspecify/jdk/blob/main/.github/workflows/build-linux.yml#L128-L141)—**without** the accompanying `update-alternatives` command (or `CC`/`CXX` configure arguments). As a result, `./configure` in `jspecify.yml` has never actually used `gcc-10`/`g++-10`; it has always just used the runner's pre-installed default `/usr/bin/gcc` and `/usr/bin/g++` (GCC 13 on Ubuntu 24.04, and GCC 15 on Ubuntu 26.04). > 3. **Recommended fix:** Simply drop `gcc-10 g++-10` from the `apt-get install` line in [jspecify.yml](https://github.com/jspecify/jdk/blob/main/.github/workflows/jspecify.yml#L29). Current OpenJDK 28 sources in this branch already support GCC 15 (which is also what your local workstation has configured in `build/linux-x86_64-server-release`), and `jspecify.yml` already passes `--disable-warnings-as-errors`. (If anything else in Ubuntu 26.04 ever causes trouble, you could also pin `runs-on: ubuntu-24.04` to match upstream [main.yml](https://github.com/jspecify/jdk/blob/main/.github/workflows/main.yml#L60).) (Maybe we *should* find the version that upstream uses, install that, and run `update-alternatives` for that. But for now, I'm happy to get the build working again, and we can cross that bridge when we come to it.)

cpovirk · 2026-11-10T21:56:17Z

Yay, it worked. (And thanks as always for the reviews.)

There's still a red X for the "Prepare" step of "GHA Sanity Check," so I'm sending #182 for that.

They started failing recently because of a non-hermetic build, and we've never wanted them. Gemini on all that: > ### 1. Do we want this CI job? (No—it’s already half-disabled and does nothing useful) > > * The failing job (`Prepare the run`) is in [main.yml](https://github.com/jspecify/jdk/blob/main/.github/workflows/main.yml#L58-L91) (`OpenJDK GHA Sanity Checks`), which is upstream OpenJDK's CI workflow. > * Back in PR #114 (c9befbc), `WMD` disabled all of the actual build/test jobs in [main.yml](https://github.com/jspecify/jdk/blob/main/.github/workflows/main.yml#L126-L129) by making `check_platform()` output `false` when `platforms` is empty: > ```bash > # echo 'true' > # WMD: Assume empty means no platforms > echo 'false' > return > ``` > * However, `main.yml` still triggers `on: push` (both on `main` and on any branch pushed directly to `jspecify/jdk`, such as `gcc` in PR #180) and still runs the `prepare` job before checking which platform jobs to run. > * All `prepare` does is run [build-jtreg/action.yml](https://github.com/jspecify/jdk/blob/main/.github/actions/build-jtreg/action.yml) to build JTReg from source and upload a `bundles-jtreg-8.3+1` artifact, and then output `false` for every platform so all downstream jobs are skipped and nothing ever uses the artifact. (Meanwhile, JSpecify's actual CI in [jspecify.yml](https://github.com/jspecify/jdk/blob/main/.github/workflows/jspecify.yml#L31-L34) downloads prebuilt `jtreg` from `builds.shipilev.net`.) > > --- > > ### 2. Why did it start failing on PR #177? > > The `actions/setup-java` bump in PR #177 was a coincidence (`setup-java` is only used in [jspecify.yml](https://github.com/jspecify/jdk/blob/main/.github/workflows/jspecify.yml#L21), whereas [build-jtreg/action.yml](https://github.com/jspecify/jdk/blob/main/.github/actions/build-jtreg/action.yml#L56) uses the runner's preinstalled `$JAVA_HOME_17_X64`): > > 1. [build-jtreg/action.yml](https://github.com/jspecify/jdk/blob/main/.github/actions/build-jtreg/action.yml#L38-L61) caches the built JTReg directory under `key: jtreg-8.3+1` (from `JTREG_VERSION` in [github-actions.conf](https://github.com/jspecify/jdk/blob/main/make/conf/github-actions.conf#L29)) and skips downloading/building JTReg whenever there is a cache hit. > 2. When you merged upstream OpenJDK on Sep 21 (`e89cf6d97e5`), `build-jtreg` built `jtreg-8.3+1` once and populated that cache. Every push to `main` through PR #176 (`Oct 13, 18:48 EDT`) hit that cache entry and refreshed its 7-day GitHub Actions TTL. > 3. PR #177 was merged on `Oct 20, 21:01 EDT`—**7 days and ~2 hours** after PR #176—just after GitHub Actions evicted the `jtreg-8.3+1` cache entry for inactivity. > 4. On the cache miss, `build-jtreg` tried to build JTReg from source, which runs `wget https://git.openjdk.org/jtharness/archive/jt6.0-b24.zip`. `git.openjdk.org` is returning an HTTP error response (`wget` exit code 8) to GitHub Actions runner requests. Because the build fails, the cache is never repopulated, so every subsequent push fails the same way. > > --- > > ### 3. How to get rid of the red X > > There are two clean ways to stop `OpenJDK GHA Sanity Checks` from running on pushes: > > 1. **In `.github/workflows/main.yml` (recommended if you want it tracked in git):** > Comment out or remove the `push:` trigger in [main.yml](https://github.com/jspecify/jdk/blob/main/.github/workflows/main.yml#L28-L32) so only `workflow_dispatch:` remains (right next to the existing local diff at lines 36–37): > ```yaml > on: > # push: > # branches-ignore: > # - pr/* > workflow_dispatch: > ``` > 2. **In GitHub repo settings (zero diff against upstream):** > Disable the `OpenJDK GHA Sanity Checks` workflow in the GitHub Actions UI (or via `gh workflow disable "OpenJDK GHA Sanity Checks" -R jspecify/jdk`).

msridhar approved these changes Nov 10, 2026

View reviewed changes

cpovirk mentioned this pull request Nov 10, 2026

Disable OpenJDK GHA Sanity Checks. #182

Merged

cpovirk merged commit 3661cad into main Nov 10, 2026
29 of 30 checks passed

cpovirk deleted the gcc branch November 10, 2026 21:56

cpovirk added a commit that referenced this pull request Nov 10, 2026

Merge to pick up #180.

f6de3f4

Navigation Menu

Repository navigation

Remove GCC 10 from the list of packages to install. - #180

Remove GCC 10 from the list of packages to install.#180
cpovirk merged 1 commit into
mainfrom
gcc

cpovirk commented Nov 10, 2026

Uh oh!

cpovirk commented Nov 10, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

cpovirk commented Nov 10, 2026

Uh oh!

cpovirk commented Nov 10, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants