Skip to content

Publish release media as versioned, checksummed bundles - #4

Merged
jordanhubbard merged 2 commits into
mainfrom
release/uniform-assets
Sep 22, 2026
Merged

jordanhubbard merged 2 commits into
mainfrom
release/uniform-assets

Conversation

@jordanhubbard

Copy link
Copy Markdown
Owner

Why

RubyOS and RemoteOS-SDL both publish <name>-<version>-<platform>.tar.gz with a .sha256 beside it. PythonOS attached bare pythonos.iso and pythonos-arm64.elf — no version in the filename, nothing to verify a download against, and no README or licence travelling with the image.

before after
naming pythonos.iso pythonos-0.4.3-x86_64.tar.gz
integrity none .sha256 per bundle
contents raw image image + README + LICENSE + RELEASE-NOTES + BUILD-INFO

What it does

package_release_image wraps each CI image the way scripts/package-release.sh already wraps a local one, and the release attaches each bundle with its checksum.

On the asset count

It still differs from the siblings, and it should. Their tarballs are host bundles — a runtime, the display service, and guest images for both architectures — so there is one per host platform (linux-arm64, linux-x86_64, macos-arm64). PythonOS ships guest media, so the platform field is the guest architecture and there are two of them.

Making the counts match would mean PythonOS also shipping a host Python runtime, which is a different decision from how the files are named — and not one this PR takes.

Testing

Exercised the real helper against the images v0.4.3 actually published:

pythonos-0.4.3-x86_64.tar.gz: OK
pythonos-0.4.3-arm64.tar.gz: OK
IDENTICAL  pythonos.iso
IDENTICAL  pythonos-arm64.elf

Both bundles unpack to byte-identical media and their checksums verify. tests/ci_gate_test.py passes (41 checks) — the previous attaches both images assertion is replaced by three that check the packaging contract, the checksum pairing, and the bundled docs.

🤖 Generated with Claude Code

jkh and others added 2 commits September 22, 2026 07:39
RubyOS and RemoteOS-SDL both ship <name>-<version>-<platform>.tar.gz
with a .sha256 beside it. PythonOS attached bare pythonos.iso and
pythonos-arm64.elf: no version in the filename, nothing to verify a
download against, and no README or licence travelling with the image.

Wrap each CI image the way scripts/package-release.sh already wraps a
local one, and attach the pair plus its checksum.

The asset count still differs from the siblings, and should. Their
tarballs are host bundles -- a runtime, the display service, and guest
images for both architectures -- so they have one per host platform.
These are guest media, so the platform field is the guest architecture
and there are two. Making the counts match would mean shipping a host
Python runtime, which is a different decision from how the files are
named.

Verified against the images v0.4.3 published: both bundles unpack to
byte-identical media and their checksums verify.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The macOS Intel job failed the desktop smoke with every sampled pixel
black and 3072 of 3072 tiles differing -- the screenshot was taken before
the desktop had painted, not after it painted something wrong.

desktop_smoke_test.py polls for the window's signature pixels against a
hardcoded 60 second deadline. Its own comment notes that startup "under
TCG takes much longer than under KVM"; on a runner that is both TCG and
inside a VM it is marginal, which is why this passed twice before failing
here. PYTHONOS_GUI_FRAME_TIMEOUT makes it settable and the macOS entry
gets 240, alongside the command budget raised for the same reason.

The tolerant environment reader moves to qmp_helper, which every GUI test
already imports, and desktop_smoke_test.py's boot timeout now uses it
too -- it had the same bare float(os.environ.get(...)) that would raise on
the empty string a partially-populated matrix key produces.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@jordanhubbard
jordanhubbard merged commit e15f8a9 into main Sep 22, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant