Cannot install wheels stable release from apt repository. Packages file empty.

[teleotic]

Describe the bug
Wheels stable release versions cannot be installed from the apt repository. Running sudo apt install wheels results in an error:

Error: Unable to locate package wheels

To Reproduce
Steps to reproduce the behavior:

1. Follow documentation to add wheels repository
2. sudo apt update
3. sudo apt install wheels
4. See error

Expected behavior
Wheels cli should download and install correctly.

Desktop (please complete the following information):

• OS: Ubuntu 26.04 LTS

Additional context
The apt repository's Packages list is empty. This seems to be a repeat of the behavior reported in #2838 and addressed by wheels-dev/apt-wheels#3

Wheels bleeding-edge repo works properly.

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report describes observable wrong behavior with a clear "what happened" (apt install wheels -> Unable to locate package wheels) and "what I expected" (CLI installs), plus a root-cause observation: "The apt repository's Packages list is empty." It explicitly notes this is a recurrence of #2838 (fixed by wheels-dev/apt-wheels#3) on the stable channel, while bleeding-edge works.

Suspected layer

cli -- see .ai/wheels/cli/ for canonical patterns. Note this is a release/distribution-infrastructure bug rather than an MVC-runtime defect; cli is the closest documented layer (it governs how the wheels binary is distributed and installed).

Fix sketch

The in-repo surface is tools/distribution-drafts/apt-repo/ -- specifically scripts/regenerate-apt-metadata.sh (whose own comments describe this exact failure: "regenerating a channel whose pool isn't present would scan an empty dir, emit an empty Packages, and the upload would clobber that channel's index", citing #2838) and workflows/wheels-released.yml -- plus the Dispatch Linux repo buckets step in .github/workflows/release.yml (~line 636) that fires repository_dispatch to wheels-dev/apt-wheels with channel=stable. The most likely operational fix lives in the external wheels-dev/apt-wheels repo (its wheels-released handler not syncing pool/stable/ before regen, or the stable dispatch never firing/landing the .deb), mirroring apt-wheels#3. Verifying requires the actual apt repo + R2 bucket state, which is outside this codebase.

Confidence: low

The symptom is environment-/infrastructure-specific and the concrete fix almost certainly lives in the external wheels-dev/apt-wheels repo (and/or release-pipeline secrets/dispatch state), so no mechanical in-repo code change is determinable from the issue body alone -- auto-fire is intentionally withheld for human investigation of the apt bucket.

<!-- wheels-bot:triage:3218 -->
<!-- wheels-bot:triage-class:bug -->

[bpamiri]

Fixed and verified — apt install wheels resolves again on both amd64 and arm64. Thanks for the persistence in reporting this; there were two independent root causes stacked on top of each other, which is why it kept coming back.

Root cause 1 — the index got clobbered at the origin

The apt publish pipeline regenerated both channels (stable + bleeding-edge) on every run, but only synced the published channel's package pool first. So every bleeding-edge snapshot publish (several a day) regenerated stable against an empty local pool, produced an empty Packages index, and overwrote the good one. The .deb was always present in storage — only the index was empty. Fixed in apt-wheels#5: regeneration is now scoped to the channel being published.

Root cause 2 — the CDN served a stale index

Even after the origin was correct, apt-get update still failed with:

File has unexpected size (29 != 1404). Mirror sync in progress?

Cloudflare auto-caches by file extension, so a published Packages.gz was edge-cached and kept being served after the next publish rewrote it — its hash no longer matched the freshly regenerated Release, so apt rejected it. (The uncompressed Packages/Release are extension-less and were never cached, which is why only the .gz broke.) Fixed in apt-wheels#6: apt metadata is now published with Cache-Control: no-store so the edge never serves a stale index, while the .deb files keep a long immutable cache.

Prevention

A daily CI guardian (#3234) now fetches the same plain URLs apt/dnf use and verifies the served Packages.gz hash matches Release (the exact check apt-get update performs), on both architectures. If either failure mode ever recurs it goes red within a day with a message that names it. The rpm side (yum-wheels#6) got the same no-store hardening preventively.

Please run sudo apt update && sudo apt install wheels and confirm you get 4.0.5 — and reopen if anything's still off. Sorry it took a few rounds to land.