openkal-musl 0.10.0

[Sunrisepeak]

openkal-musl 0.10.0
— the exec search, and the family of answers that were not true (openkal-linux#13,
fifth round).

What a consumer of this version gets

⚠️ execvp could not get past the first PATH entry that missed. execve did
not return when the program could not be started — it ended the calling
program with 127, because the replacement fails inside a duplicate whose failure
the backend reports to nobody. One libc path, nine of a consumer's nineteen test
failures, and four more sections skipped because bwrap — installed at
/usr/bin/bwrap — was reported as not installed. posix_spawnp did not search
PATH at all, and reported success for a program it had not started.

⚠️⚠️ And the heavier one, which was not in the report. fcntl(F_SETLK)
granted every lock and took none: two programs took one exclusive lock and both
were told they had it. F_GETLK reported a lock that was not there, for ever, so
a loop waiting for one never left it. All three now report ENOSYS — and that
refusal is temporary, unlike the permission one: every environment beneath
openkal can lock a byte range, and the word for it is asked for as
mcpplibs/openkal#22.

Also: getppid no longer returns -38 as an identifier; a copy made by fork
names itself; setsid reports the EPERM POSIX writes down rather than ENOSYS
that nothing handles; sigaltstack refuses instead of pretending;
sysconf(_SC_OPEN_MAX) answers the bound rather than 0; a directory's
modification time can be set where the implementation can open a directory.

Resources

Both mirrors carry the same bytes — the sha256 is the GitHub tarball's, and
the gitcode asset was downloaded and compared against it before this entry was
written:

GLOBAL  c5e151aa63e63ce0f13c6fc28bfd26004a9a305b4f1973ee2888ec871c68ee8f
CN      c5e151aa63e63ce0f13c6fc28bfd26004a9a305b4f1973ee2888ec871c68ee8f

mcpp xpkg parse accepts the descriptor; the three platform tables each carry
the new version.