Three small runtime checks in qtbase 6.11.0:
1. src/opengl/qopengltextureglyphcache.cpp createTextureData() and
load_glyph_image_to_texture() — the `#else` branch (active when
qtbase is built with QT_CONFIG(opengles2), every aarch64 distro)
hard-codes GL_ALPHA without checking the runtime context's ES
version. Replace with `useR8 = ctx->format().majorVersion() >= 3`
so ES 3+ contexts get GL_R8 + GL_RED.
2. src/gui/rhi/qrhigles2.cpp toGlTextureFormat() RED_OR_ALPHA8 case
— gated only on caps.coreProfile. Extend with
`caps.gles && caps.ctxMajor >= 3`.
3. src/opengl/qopengltextureuploader.cpp Format_Alpha8 and
Format_Grayscale8 cases — short-circuit on `context->isOpenGLES()`
before reaching the swizzle fallback. Restrict to ES 2 only so
ES 3+ falls through to the existing TextureSwizzle path.
Discovered while validating chromium-fourier patch 3/3 (NV12
EXTERNAL_OES) on ohm. The chrome stall, VLC vout init failure and
mpv "could not initialize video chain" all share this Qt 6 root
cause: every Qt application running on Mali / panfrost / panthor
under a KWin Wayland session emits glTexImage2D(GL_ALPHA) on every
text-glyph cache upload, mesa returns GL_INVALID_VALUE, the
compositor's frame-callback path stalls, and every wayland video
client deadlocks behind it.
PKGBUILD inherits from extra/qt6-base 6.11.0-2 with arch+=aarch64,
epoch=1 to dominate Arch's pkgrel until upstream lands the fix.
qt6-base-cflags.patch and qt6-base-nostrip.patch carried verbatim
from upstream packaging.
KWIN_PIVOT.md (in chromium-fourier/) carries the full diagnosis
thread.
Source-grep collapsed Phase 1+2 onto a single pass. KWin's own GL paths
use GL_R8 correctly (gltexture.cpp:61, shadowitem.cpp:494). The
glTexImage2D(GL_ALPHA) calls observed in the journal originate from
Qt 6:
- qtbase/src/opengl/qopengltextureglyphcache.cpp:111-117 — text glyph
cache upload path. The #else branch (active when qtbase is built
with QT_CONFIG(opengles2)) unconditionally uses GL_ALPHA, with no
runtime check for ES context major version. Correct on ES 2.x;
broken on ES 3.x where GL_ALPHA is no longer a valid glTexImage2D
internalFormat.
- qtbase/src/gui/rhi/qrhigles2.cpp:1373-1378 — Qt-Quick-RHI sibling.
Same logic, gated only on caps.coreProfile, missing the ES≥3 case.
- qtbase/src/opengl/qopengltextureuploader.cpp:253-257 — QImage→GL
upload path; same shape.
KWin runs an ES 3.2 context on Mali-G52 panfrost (RK3566), Qt picks
GL_ALPHA, mesa returns GL_INVALID_VALUE, every dependent draw errors
at level 0, the compositor's frame-callback path stalls. KWin is the
visible victim because it's the compositor, but the bug is in Qt.
KWIN_PIVOT.md rewritten: the patch series and packaging now target
qt6-base-fourier instead of kwin-fourier. Three small hunks (~3 lines
each), runtime-safe via existing caps.gles + caps.ctxMajor / surface
format majorVersion checks. Upstream landing path: bugreports.qt.io
+ Gerrit change against qtbase dev branch.
Earlier framing was wrong — the wall isn't 'Arch ARM clang 22 vs Arch
x86_64 clang 23'. Arch x86_64 is also on 22.1.3; LLVM 23 isn't anywhere
in extra/staging. The flags chromium 147 emits come from chromium's
clang fork (Google maintains an LLVM fork with chromium-specific
passes), not upstream LLVM 23. PKGBUILD'ing clang 23 is the wrong tree.
Right tree: cross-compile from x86_64 so chromium's bundled clang
prebuilt is reachable. CIPD has full linux-amd64 prebuilts, gclient
sync works cleanly, no qemu-x86_64-static dance needed.
his provisioned CT 220 chromium-builder-x86 on data (Ryzen 7 1700,
14 cores, 32 GiB RAM, 200 GiB ZFS). data is normally asleep — woke
via /opt/herding/bin/wake-data. Reach pattern: hertz -> ssh data ->
pct exec 220.
Source fetch running as chromium-fetch.service transient unit on
CT 220. Once src is in, plan: tools/clang/scripts/update.py for
chromium's bundled clang + arm64 sysroot, gn gen with target_cpu=arm64,
build, transfer aarch64 binary to ohm/fresnel/ampere.
boltzmann chromium-builder LXD container preserved as fallback; can
be torn down if cross-compile pans out.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
First-build summary on chromium-builder@boltzmann. gn gen succeeds
with our V4L2VDA-unlock args. ninja fails immediately on:
1. chromium 147 emits clang flags (-fno-lifetime-dse,
-fsanitize-ignore-for-ubsan-feature=array-bounds) that clang 22
doesn't know. Arch Linux ARM is on clang 22; clang 23 hasn't
landed in extra yet.
2. Bundled x86_64 esbuild is invoked via qemu-x86_64-static but
/lib64/ld-linux-x86-64.so.2 isn't installed — same shape as the
bundled node-linux-x64 issue we already fixed by symlinking to
system node. Smaller wall.
Documents 5 paths forward (grind patches / pin chromium 132 (7Ji's
known-good) / pin 138-141 middle ground / use chromium's bundled
clang / wait for Arch ARM clang 23) with estimated effort and trade-
offs. Recommends pinning to a chromium version that compiles clean
against clang 22 as the fastest path to a working browser, then
bumping as Arch ARM bumps clang.
Build host state preserved — container running, source extracted,
gn-gen'd, no compile artifacts. Easy to resume from any of the five
paths.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Initial chromium-fourier shape on the chromium-builder@boltzmann LXD
container we provisioned today. Approach is the 7Ji-style "tarball +
system tools" pattern (no gclient/CIPD, the linux-arm64 dependency
binaries don't exist anyway) but stripped of the MPP/X11/panfork
specifics — chromium-fourier targets mainline kernel + Wayland +
panfrost/panthor + V4L2 stateless on /dev/video0, not the vendor
stack 7Ji's chromium-mpp targets.
PKGBUILD highlights:
- pkgver=147.0.7727.116 (current Chrome stable as of 2026-04-25)
- gn args: use_v4l2_codec=true, use_v4lplugin=true, use_linux_v4l2_only=true,
use_vaapi=true. The first three are the magic that unlocks V4L2VDA on
Linux non-ChromeOS without source patches; if they're sufficient on
their own, the chromeos-pipeline-bypass patch stays a no-op.
- ffmpeg_branding="Chrome" + proprietary_codecs=true for H.264.
- enable_widevine=false, enable_nacl=false to keep the tree small.
- Currently development-shaped: prepare()/build() operate on a
pre-extracted /build/chromium/src rather than makepkg-fetched
source. Will switch to canonical source=(...tarball.xz) shape once
the patches stabilise.
patches/chromeos-pipeline-bypass.patch is a placeholder; the actual
patch (if any) gets developed once we see what 7Ji's gn args do or
don't unlock for us.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Stage the next side-project: patch upstream Chromium to do HW video
decode through VaapiVideoDecoder + our marfrit/libva-v4l2-request-fourier
backend on a mainline Linux Wayland system, instead of going through
the chromeos pipeline that fails on Brave today.
STUDY.md captures:
- The exact failure stack we're fixing (PickDecoderOutputFormat ->
ImageProcessor init failure in media/gpu/chromeos/video_decoder_pipeline.cc)
- Three candidate patches (chromeos pipeline bypass, V4L2VideoDecoder
factory un-gate, libva backend default)
- Reference forks (JeffyCN, igel-oss, 7Ji-PKGBUILDs/chromium-mpp,
amazingfate/chromium-debian-build) — all use the older V4L2VDA path
with vendor MPP, not VAAPI; useful for PKGBUILD shape and
factory-un-gating patterns but not directly applicable
- Build plan on fermi (depot_tools, ~30 GB fetch, 6-10 h initial build,
distcc-avahi acceleration through CT108 + tesla)
- Phase order — workspace done now, build env next session,
patches after that, package after that, brave-fourier rebase last
No PKGBUILD added yet; one will land when there's something to actually
package. Build artifacts intentionally not in repo (chromium tree is
~100 GB).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
First carrier package for the Fourier umbrella. Tracks Kwiboo's
v4l2-request-n8.1 branch (ffmpeg 8.1 base) pinned at commit b57fbbe —
bump _commit to rebase onto newer tip. CI job chained after
claude-his-any so it serializes on the shared aarch64 repo-db;
continue-on-error: true so long ffmpeg builds don't block the debian
downstream.
Deliberately diverges from the AUR package:
- AUR pins 6.1.1 with epoch=2 → would downgrade stock Arch ffmpeg 2:8.1-3.
We track 8.1 so install is a sideways swap, not a regression.
- AUR pulls X11/AMF/CUDA/FireWire/AviSynth/OpenMPT/Bluray/OpenMAX/JPEG-XL/
Theora/XVid/rsvg/soxr/ssh/vidstab/modplug/SDL2/Vulkan/JACK/GSM/Speex —
dropped here; none are needed on a Wayland ARM video-decode fleet.
- AUR uses #branch=…, sha256sums=(SKIP) → every build is tip-of-branch,
not reproducible. We pin via #commit=<sha>.
Kept: encoders (libx264/libx265/libvpx/libdav1d), VAAPI, libdrm, libv4l2,
neon, OpenGL, PulseAudio, subtitle/font stack, gnutls TLS. SDL2 dropped
means no ffplay binary (mpv covers interactive playback).
provides=(ffmpeg) conflicts=(ffmpeg) so it replaces stock ffmpeg on the
target host deliberately. Primary consumers: ohm (Fourier step 5),
fresnel, ampere.
pkgrel 16 builds ship an upstream distcc 3.4 bug: src/compile.c sizes
the rewritten-compiler-name buffer with strlen(argv[0] + 1) — pointer
arithmetic applied before strlen — under-allocating by 2 bytes. glibc
FORTIFY_SOURCE=2 catches the resulting overflow in strcat and aborts,
so every "distcc gcc ..." invocation dies on a modern Arch.
Patch moves the +1 outside the strlen, as intended.
Closesmarfrit/marfrit-packages#3.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Observed two flakes in 24h — distcc-avahi-aarch64 at 66a7050 and lmcp-any
at 22060e0. Journal for both showed the job starting then failing silently
before any sudo/makepkg line. Theory: transient pacman mirror sync
failures on \"pacman -Syu --needed\" in the bootstrap steps, with the
rsync-to-nc step as secondary exposure (IPv6 prefix rotations from the
Fritz reconnect cron are visible in the runner journal).
Wrap pacman -Syu (5 sites), rsync to nc and hertz (5 sites), and ssh
publish-deb (2 sites) in a tiny 3-try exponential-backoff retry helper
defined per-step. No workflow restructure, no job-graph changes.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
distcc-avahi build failure was breaking the entire chain (lmcp-* and
claude-his-* depend transitively on it). These jobs only share a runner,
not real build outputs — one failing package should not block the
others.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Tag v0.1.3 added the scripts + quickref, v0.1.4 fixed doc paths.
Package both /usr/bin/repo-inventory.sh and /usr/bin/repo-inventory-nosudo.sh.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Claude Code Edit semantics — literal string replace with uniqueness
check. replace_all flag for bulk edits. Fixes missing edit tool on
lmcp-backed boltzmann / tesla / broglie.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- arch/claude-his-agent/PKGBUILD: fetches v0.1.0 tarball from
git.reauktion.de/marfrit/claude-his-agent, installs agent+skill+helper
to /usr/share/claude-agents/, /usr/share/claude-skills/his/, /usr/bin/
- debian/claude-his-agent/: control+changelog+copyright + build-deb.sh
mirroring the lmcp-debian pattern (dpkg-deb, reproducible mtimes)
- .gitea/workflows/build.yml: two new serialized jobs (claude-his-any +
claude-his-debian) after lmcp-debian; same publish flow as lmcp.
makepkg output isn't byte-deterministic across runs; same pkgver-pkgrel
rebuilds produce different .pkg.tar.xz bytes. repo-add no-ops on
same-version entries, leaving the db's CSIZE/SHA256 pointing at the
previous build while the nc copy is the new one — alpm then refuses
download with 'Maximum file size exceeded'. Force-remove first.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
reprepro refuses to re-include a .deb if the bytes differ from one
already in pool/. Fixed mtimes via SOURCE_DATE_EPOCH make subsequent
builds byte-identical, so CI re-runs of the same pkgver/pkgrel are
accepted as no-ops instead of failing.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- debian/lmcp/build-deb.sh fetches the v0.3.0 tarball, lays out the
filetree, and uses dpkg-deb to assemble lmcp_0.3.0-1_all.deb directly
on the Arch aarch64 runner (no debhelper needed for a pure-Lua pkg).
- workflow job 'lmcp-debian' rsyncs the .deb to hertz's marfritrepo
incoming dir, then ssh-triggers 'publish-deb <suite>' for both
bookworm and trixie. publish-deb wraps 'reprepro includedeb' and
rsyncs dists/+pool/ to nc.
- New secret MARFRIT_REPO_HERTZ_KEY uploaded to Gitea repo. Forced
command on hertz routes rsync uploads vs publish-deb triggers.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
lmcp is arch=any (pure Lua). One build on the aarch64 runner serves
all pacman targets — the pure-Lua package drops into both repo dbs.
Depends on lua + lua-socket from the target distro's base repos.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Fixes install conflict with filesystem pkg on merged-usr systems where
/usr/sbin is a symlink to /usr/bin.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- distcc-3.4 tarball hash + local support files hashed (no more SKIP)
- .gitea/workflows/build.yml now builds, signs, repo-adds and rsyncs
to nc via the marfrit-repo-deploy key. Triggers on push to arch/**
or manual workflow_dispatch.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
marfrit
test0r