Skip to content

Five packages: the routes openkal 0.8's atoms made possible - #267

Merged
Sunrisepeak merged 2 commits into
mainfrom
feat/openkal-capability-completeness
Aug 27, 2026
Merged

Five packages: the routes openkal 0.8's atoms made possible#267
Sunrisepeak merged 2 commits into
mainfrom
feat/openkal-capability-completeness

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

Five packages move, and the specification does not. openkal 0.8 already carried
the atoms; what changed is that the layers above and below it now use them.

package what it carries
openkal-musl 0.4.0 → 0.5.0 the socket family upon openkal.net, datagrams upon openkal.datagram, poll/select/O_NONBLOCK upon openkal.timeout, and fork composed above openkal.space. hidden, weak and weak_alias are scoped to the internal overlay, so a program above this library may use the names (openkal-musl#13)
openkal-macos 0.4.0 → 0.5.0 the five interfaces 0.8 added, all of them
openkal-windows 0.2.0 → 0.3.0 four of the five; openkal.space is declined in terms, which clause 3 permits and clause 6.1 makes a link error naming the operation
openkal-llvm-runtime 0.2.0 → 0.3.0 __config_site's claims about the environment beneath asserted by a program that uses them, and the C library repinned
sbase 0.1.1 → 0.1.2 ninety-seven utilities above the new C library. The old pin bounded it below 0.4.0, so it had been testing a C library two minors behind

openkal and openkal-linux are unchanged and are not here: the specification
did not move, and openkal-linux already provided every interface.

What the reported defects were

mcpplibs/openkal-linux#13ENOSYS for fork, socket, poll, select.
The atoms existed and nothing above them used any: musl's network sources
compile and issue system calls the port had no case for.

mcpplibs/openkal-musl#13 — a program could not declare hidden as an ordinary
identifier. Measured: musl/include/ uses the name zero times, so the
neutralisation only ever needed to act when the internal overlay is on the
command line.

Every hash was fetched back before it was written here

publish-pkg.sh tags, uploads through gtc, and then retrieves the CN asset
and compares its bytes
— the index records one sha256 for two URLs, and a
wrong digit there produces a package that resolves, downloads and fails
verification on every machine but the one that published it. The value written
into each descriptor is read out of that verified block rather than copied.

Sunrisepeak and others added 2 commits August 27, 2026 20:16
MCPP_VERSION 2026.8.27.1 -> 2026.8.27.2.

#263 moved this pin seventeen versions forward, to 2026.8.27.1. That is the
version PR #260 is failing on, and the failure is not #260's:

  error: internal: unhandled exception: No mapping for the Unicode character
  exists in the target multi-byte code page.

three times, in `workspace (windows default 0/2)` and `1/2` — one per httplib
example. It is mcpp-community/mcpp#516: on Windows `path::string()` converts
through the process ANSI code page and throws for a name that code page cannot
spell, and `is_excluded_walk_dir` narrowed a directory name on the first line
of the glob walk. cpp-httplib ships `test/www/<CJK>Dir/`, and the
`include_dirs = { "*" }` convention walks the whole extracted tarball.

Fixed in mcpp 2026.8.27.2 (mcpp-community/mcpp#517), released and mirrored on
both hosts, with xim-pkgindex's `latest` pointing at it.

⚠️ RE-RUNNING #260 WITHOUT THIS BUMP PROVES NOTHING. Its CI would fetch
2026.8.27.1 — the version that still carries the defect — and reproduce the
same three errors. That is a re-confirmation of the bug, not a test of the fix.
Attribution first: the failing job's log was read and it is #516's message
verbatim, not some other Windows problem wearing the same red.

Keeping #263's caution in force: a red at this pin can come from the engine
change or from what accumulated across the versions this repository never ran
against, and a one-sided reading cannot tell them apart.
    openkal-musl          0.4.0 -> 0.5.0
    openkal-macos         0.4.0 -> 0.5.0
    openkal-windows       0.2.0 -> 0.3.0
    openkal-llvm-runtime  0.2.0 -> 0.3.0
    sbase                 0.1.1 -> 0.1.2

The specification does not move. openkal 0.8 already carried the atoms;
what changed is that the layers above and below now use them --- the
socket family upon `openkal.net', datagrams upon `openkal.datagram',
`poll' and `select' upon `openkal.timeout', and `fork' composed above
`openkal.space'. Reported as mcpplibs/openkal-linux#13 and
mcpplibs/openkal-musl#13.

`openkal-windows' provides four of the five and declines `openkal.space'
in terms: this system starts a NAMED PROGRAM and has no primitive that
copies an address space, so a program calling `kal_space_start' fails at
the link naming the operation, which is clause 6.1's report.

`sbase' had been pinned below 0.4.0 --- a caret on a 0.x version bounds
it under the next minor --- so ninety-seven utilities were testing a C
library two minors behind the one everything else builds against.

⚠️ EVERY HASH WAS FETCHED BACK BEFORE IT WAS WRITTEN HERE. The publisher
tags, uploads, and then RETRIEVES the CN asset and compares its bytes;
this index records one sha256 for two URLs, and a wrong digit produces a
package that resolves, downloads and fails verification on every machine
but the one that published it. Both mirrors were then read a second time,
independently of the publisher, and all ten fetches matched.
@Sunrisepeak
Sunrisepeak merged commit d5417d3 into main Aug 27, 2026
8 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.

2 participants