firefox-fourier: flatten patches to top-level (makepkg has no subdir support) #11

2026-05-15T08:00:50Z

claude-noether commented

2026-05-15 08:00:50 +00:00

Follow-up to #10. The subdir layout I introduced in #10 also doesn't work.

What happened

I assumed chromium-fourier's patches/foo.patch pattern was proven-working and copied it. After #10 merged, boltzmann tried makepkg:

==> Retrieving sources...
  -> Found firefox-150.0.1.source.tar.xz
  -> Found mozconfig
==> 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.

Same error as before, even though the files exist at patches/arch-0002-...patch.

Root cause (per `man PKGBUILD`)

The filename in the array must NOT include any path components like ./

makepkg's source-staging strips the subdir component when checking for local files. The chromium-fourier pattern looks like it should work but doesn't — and since chromium-fourier has no CI either, that latent breakage was never caught. (Filing the chromium-fourier fix is a separate issue, not this PR's scope.)

The actually-working pattern

mpv-fourier keeps patches at the top level next to the PKGBUILD, and its CI build (run #92 — just merged) is green. That's the proven pattern; this PR adopts it.

What this PR does

git mv arch/firefox-fourier/patches/*.patch arch/firefox-fourier/ (8 files; preserves blame)
Removes the now-empty patches/ subdir
Strips patches/ prefix from source-array entries
Strips /patches from prepare() patch -i paths
No content changes; same 8 patches, same apply order
pkgrel 3 → 4

Verification

patch -Np1 --dry-run of all 8 patches against firefox-150.0.1 source: clean (already done before #10; nothing changed in the patch content)
makepkg --printsrcinfo should pick up the new source layout without complaint
Real makepkg run will start on boltzmann after this lands

Postmortem note (for the receipt)

Mistake pattern: I treated a sibling package's PKGBUILD as a working reference without verifying it had actually built recently. mpv-fourier (proven by CI) was the better reference. Carrying this to memory.

Bot: claude-noether

Follow-up to #10. The subdir layout I introduced in #10 *also* doesn't work. ## What happened I assumed chromium-fourier's `patches/foo.patch` pattern was proven-working and copied it. After #10 merged, boltzmann tried `makepkg`: ``` ==> Retrieving sources... -> Found firefox-150.0.1.source.tar.xz -> Found mozconfig ==> 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. ``` Same error as before, even though the files exist at `patches/arch-0002-...patch`. ## Root cause (per `man PKGBUILD`) > The filename in the array must NOT include any path components like ./ makepkg's source-staging strips the subdir component when checking for local files. The chromium-fourier pattern *looks* like it should work but doesn't — and since chromium-fourier has no CI either, that latent breakage was never caught. (Filing the chromium-fourier fix is a separate issue, not this PR's scope.) ## The actually-working pattern mpv-fourier keeps patches at the top level next to the PKGBUILD, and its CI build (run #92 — just merged) is green. That's the proven pattern; this PR adopts it. ## What this PR does - `git mv arch/firefox-fourier/patches/*.patch arch/firefox-fourier/` (8 files; preserves blame) - Removes the now-empty `patches/` subdir - Strips `patches/` prefix from source-array entries - Strips `/patches` from `prepare()` `patch -i` paths - No content changes; same 8 patches, same apply order - `pkgrel 3 → 4` ## Verification - `patch -Np1 --dry-run` of all 8 patches against firefox-150.0.1 source: clean (already done before #10; nothing changed in the patch content) - makepkg `--printsrcinfo` should pick up the new source layout without complaint - Real makepkg run will start on boltzmann after this lands ## Postmortem note (for the receipt) Mistake pattern: I treated a sibling package's PKGBUILD as a working reference without verifying it had actually built recently. mpv-fourier (proven by CI) was the better reference. Carrying this to memory. Bot: claude-noether

claude-noether added 1 commit 2026-05-15 08:00:51 +00:00

firefox-fourier: flatten patches to top-level (makepkg has no subdir support) 109858eae5

Follow-up to #10. The subdir layout I assumed worked turned out to not
work — per 'man PKGBUILD':

  The filename in the array must NOT include any path components like ./

makepkg's source-staging only honors basenames; the patches/ subdir
references staged the files but the basename-lookup at apply time
failed with the same 'not found in build directory' error that #9 hit.

I copied the chromium-fourier convention thinking it was proven, but
chromium-fourier has no CI either and likely has the same latent
breakage (separate issue, not in this PR's scope).

The actually-working pattern is the mpv-fourier one: patches at the
top level next to the PKGBUILD. mpv-fourier iter2 just built green
on CI (#92) with that layout.

This commit:
- Moves all 8 patches (5 fourier + 3 arch upstream) from patches/
  to arch/firefox-fourier/ via git mv (preserves blame).
- Removes the now-empty patches/ subdir.
- Strips 'patches/' prefix from source array entries.
- Strips '/patches' from prepare() patch -i paths.

No semantic change to the patch content or apply order.

pkgrel 3 -> 4.

marfrit merged commit 860ebf2df5 into main

2026-05-15 08:04:12 +00:00

marfrit referenced this issue from a commit

2026-05-15 08:04:13 +00:00

firefox-fourier: flatten patches to top-level (makepkg has no subdir support) (#11)

claude-noether referenced this pull request

2026-05-17 17:18:42 +00:00

lmcp: 0.5.4 -> 1.0.0-rc1 (full MCP 2025-06-18 surface) #22

claude-noether referenced this pull request

2026-05-17 19:44:39 +00:00

lmcp: 1.0.0~rc1 -> 1.1.0 (concurrent dispatch + cancellation + windows sync) #23

marfrit referenced this issue from a commit