A job goes to whichever runner carrying its label polls first, and the
`flatpak` label this job shared with imsd's package job is also on the
organisation-wide cx33-org-flatpak runner (registered 2026-10-14), which
has no deploy mounts, no Flatpak volume and defaults to an alpine image.
Crafter.Build's run 550 landed there on 2026-10-16 and failed before
building; runs 549 and 552 of this job reached the right runner only
because it polled first.
The repository's runner now declares `catcrafts-deploy:docker://archlinux:latest`
(a config edit and a service restart; labels are not part of the
registration), and the job asks for that. Nothing else changes.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Crafter.Build 2.2.0 (2026-10-16) releases the Shader `defines` and
`variant` fields Crafter.Graphics master has used since 2026-10-06, so
CRAFTER_REF goes back to //stable and the toolchain moves only with a
Crafter.Build release again, the way imsd's package job has it. The
comments and the README now describe beta as the stopgap for the next
time Crafter.Graphics runs ahead of a release.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Run 533, the first on the Flatpak toolchain, installed the Flatpak, built
the server and passed all 28 suites, then failed building the wasm bundle:
Crafter.Graphics master has used the Shader `defines` and `variant` fields
since 2026-10-06, and the `stable` Flatpak is the 2.1.0 release from three
days before that. Only Crafter.Build master has them, so the toolchain is
its `beta` branch for now, which is also what the rolling `latest` tarball
this job used to download was: a build of master.
The branch is one variable at the top of the job, the way imsd's package
job pins its own (imsd stays on stable; it has no Crafter.Graphics). Flip
it back to //stable once a Crafter.Build release carries the fields. The
wrapper scripts expand the ref at write time, and the install step prints
them along with the Flatpak's branch and commit so a run's log says which
toolchain it used.
Verified locally with beta 2.1.0-10-g4af9280: the wasm bundle builds and
the server suite passes, except ShouldServePostPages, which needs the media
mirror on the deploy mount that only exists in CI.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Crafter.Build's CI publishes only the Flatpak since 2026-10-02, so the
rolling `latest` tarball the Install crafter-build step downloaded is gone
and the 2026-10-12 deploy failed with a 404 before building anything.
Take the route imsd's package job takes. The job runs on `flatpak`, a
privileged runner registered to this repository alone
(forgejo-runner-catcrafts on the box, same arrangement as imsd's), with the
installed Flatpak and its Sdk kept on a docker volume between runs. The
container installs nothing that compiles any more: clang, lld, libc++, the
WASI sysroot, cmake, perl, gpg and OpenSSL all come with the Flatpak and its
Sdk. `crafter-build` is a wrapper around `flatpak run`, `crafter-run` runs a
built binary inside the sandbox, cast is installed under /opt where the
sandbox can see it, and the cache path is the Flatpak's own.
The server binary links the Flatpak's libc++, libc++abi and libunwind, which
are newer than the host's, so the deploy ships them next to the binary the
way it already ships libmsquic; the rpath finds them there. They need at
most GLIBC_2.38, the host has 2.41.
ShouldMatchBankTransfers passed braced lists straight into a std::span
parameter. That compiled only because libc++ 22 had the C++26
span(initializer_list) constructor; the libc++ 23 in the Flatpak does not,
so the lists now go through a vector like the rest of the file.
deploy/README.md documents the runner, the sandbox's private /tmp and how
to run a built binary where the host lacks a matching libc++.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The webhook is deregistered at bunq and the callback endpoint, its parser,
default-deny classifier, dedup ledger and signature check are removed; the
code is in git history if a bank feed ever comes back. /financials keeps
reading the hand-maintained aggregates file, and sales + shop donations
stay live from the order ledger.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The H.264 sibling landed on the media mount after the previous deploy
ran, and fetch-media.sh only discovers siblings at build time.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The AV1-only publish lasted four hours in the wild: the first viewer on
mobile Safari got "bad media error" from the raw file, because a post's
link is fetched raw — Lemmy apps and browsers play that exact URL, with
no <source> negotiation in front of it. The previous commit's note
("--raw ... if that audience matters") had it backwards: the audience
that cannot play AV1 is not a per-post judgement call, it is whoever
happens to open the thread on an iPhone.
So publish-media.sh now emits two encodings and points the post at the
compatible one:
* Every video transcode also produces <hash>.h264.mp4 (x264 crf 23,
same denoise, same frames), uploaded beside the AV1 under the AV1's
hash — the poster's sibling-naming trick, reused, so fetch-media.sh
finds it by name with nothing to look up.
* The printed URL to paste into the post is the H.264 one. pict-rs
can thumbnail it too, so instance thumbnails come back as a bonus.
fetch-media.sh adopting an own-origin .h264.mp4 URL swaps the AV1 back
in as the page's primary when it is on the mount, and records the H.264
as `fallback` in posts.json. The renderer turns a non-empty fallback
into a <source> pair: the AV1 first with an explicit codecs parameter —
both files are video/mp4, so the parameter is the only thing that lets
a non-AV1 browser skip to the file it can play — and the H.264 second.
Browsers with AV1 keep downloading the small file; Safari before 17
gets one that plays instead of an element that will not.
e2e gains the matching conditional gate: a page offering an av01
<source> must offer an .h264.mp4 one, so an AV1 video can never again
ship without its fallback.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The posts-feed note promise became a link: every version of this page and
its diffs are at /legal/privacy/history (redirect to this file's history).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
