firefox-fourier: fix patches layout + ship missing arch upstream patches #10
Reference in New Issue
Block a user
Delete Branch "claude-noether/marfrit-packages:noether/firefox-fourier-fix-patches-layout"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Follow-up to #9. Discovered when boltzmann tried to actually build firefox-fourier 150.0.1-2 from a clean checkout: the PKGBUILD is structurally broken and has been since at least the 150.0.1 import.
What broke
Two pre-existing issues, neither introduced by #9:
Patches at wrong path. The
source=()array references the fourier patches by bare name ('0001-gfxinfo-...patch') but the files live inpatches/0001-...patch. The chromium-fourier sibling package uses thepatches/-prefix convention (and works); firefox-fourier never did.Arch upstream patches missing entirely. The PKGBUILD references three
arch-0002/3/4toolchain patches (Rust 1.95 simd, glibc 2.43 glslopt, clang 22 wasm32-wasip1) that don't exist anywhere in the repo. The 150.0.1-1 build that's currently published was clearly hand-staged on someone's workstation — the PKGBUILD itself doesn't reproduce.Drive-by find:
0005-rdd-sandbox-v4l2-media-ctl.patchexists inpatches/but wasn't insource=()orprepare()either. README §1 names it as load-bearing for the V4L2 path (broadens RDD sandbox so /dev/media*/dev/video* ioctls reach the decoder child). Wired up too.Why this went unnoticed for so long: firefox-fourier has no Gitea Actions job (build too heavy for the runner pool — Firefox link phase peaks at ~12-16 GB RAM).
What this PR does
patches/prefix (matching chromium-fourier).prepare(): same correction, plus the missing 0005 invocation.patches/arch-0002-...patch,patches/arch-0003-...patch,patches/arch-0004-...patch: fetched verbatim from https://gitlab.archlinux.org/archlinux/packaging/packages/firefox/-/raw/main/ (Arch's0002,0003,0004files, renamed witharch-prefix). These match Arch'spkgver=150.0.3PKGBUILD; offsets vs our 150.0.1 are within 3 lines (verified by dry-run apply, no conflicts).pkgrel 2 → 3.Verification done
patch -Np1 --dry-runagainst firefox-150.0.1 source: all 8 patches (3 arch + 5 fourier) apply cleanly. Offsets ≤3 lines, no rejected hunks.sha256sumslength (11 entries each, all SKIP).What's NOT done yet
mach build. That's hours of compile and was waiting on this PR. Will start once this merges.firefox-fourier-aarch64job tobuild.yml— out of scope; sibling chromium-fourier doesn't have one either. Build-time / RAM requirements make this a separate decision.Bot: claude-noether
The PKGBUILD has been structurally broken since at least the 150.0.1 import: source array referenced patches at top level ('0001-...patch') but the actual files live in patches/ — makepkg searched for them in the package root and failed before doing any work. The arch-0002/3/4 upstream toolchain patches (clang 22, glibc 2.43, Rust 1.95) weren't shipped in the repo at all. Caught when boltzmann tried to build 150.0.1-2 (PR #9 follow-up); fails at the source-staging phase with: ==> ERROR: arch-0002-Bug-2033279-Make-enable-rust-simd-work-with-Rust-1.9.patch was not found in the build directory and is not a URL. Why nobody noticed: firefox-fourier has no Gitea Actions job (too heavy for the runner pool). The shipped 150.0.1-1 .pkg.tar.zst was produced by hand-staging files; the PKGBUILD itself never reproduced from a clean checkout. This commit: - Moves all source-array patch references under patches/ to match the on-disk layout (same convention as chromium-fourier). - Updates prepare() paths accordingly. - Adds arch-0002/3/4 patches fetched verbatim from https://gitlab.archlinux.org/archlinux/packaging/packages/firefox (raw/main/{0002,0003,0004}-...patch). Renamed with arch- prefix in the repo to avoid namespace collision with the local 0001..0005. - Adds the previously-omitted 0005-rdd-sandbox-v4l2-media-ctl.patch to the source array + prepare(); this is the patch that broadens the RDD sandbox so /dev/media* and /dev/video* ioctls reach the decoder child (README §1 enumerates it as load-bearing for the HW path). It was present in patches/ but not wired up. Dry-run verified all 8 patches apply cleanly against firefox-150.0.1 source (some hunks offset by ≤3 lines, no conflicts). pkgrel 2 -> 3.