The '-- \n2.54.0\n\n' trailer added in 989b884 was wrong. The
underlying problem was the malformed @@ hunk counts (off by 1 in
both old and new), fixed in a840f76. With correct @@ counts, patch(1)
processes the hunk fully and then sees the orphan trailer at EOF —
which it tries to parse as the start of a new patch header
('malformed patch at line N: 2.54.0').
The original (no-trailer) shape works correctly in the concatenated
cumulative as long as the @@ counts are right. Removing the trailer
brings the file back to the original 1562-byte size and the
cumulative b2sum to 334c37b5d37067982bd9... (size unchanged 157 458 ->
157 446 since the 12 byte trailer is gone).
Lesson for ka-promote: when concatenating patches as a stream for
patch(1), the LAST patch must not carry a trailing '-- \n<version>\n'
sentinel — the previous patches' sentinels are fine because they are
followed by 'From <sha>' headers that patch(1) recognises as the next
patch boundary. Documented in series-dir README as a gotcha.
The hunk header @@ -9,6 +9,10 @@ understated both old (actual 7) and
new (actual 12) line counts by 1. patch(1) standalone tolerates this
via fuzz, but in the concatenated cumulative the wrong counts cause
patch to mis-judge the hunk boundary and read the trailing context
line ('lib-...uaccess_flushcache.o') as the start of a new patch
header — 'malformed patch at line 4526'.
Cumulative b2sum: bd42cd39106298879eeb... -> ad9e2cb533957f218058...
(size unchanged at 157 458; only the @@ counts in the SCS patch
differ)
The SCS-build-fix patch was missing the standard '-- \n2.54.0\n'
trailer that git format-patch emits between patches. Without it,
BSD-flavour patch(1) in makepkg's prepare() reads the trailing context
line of the @@ hunk as the start of a new patch header and dies with
'malformed patch at line N'. Affects builds where ka-promote
concatenates this series with any others. Reproduced 2026-05-18 on
the first attempted ohm pkgrel=4 build.
Cumulative b2sum changes accordingly:
a807297b25be... -> bd42cd39106298879eeb...
(size 157446 -> 157458; 12 bytes for the trailer)
Audit during ohm pkgrel=4 migration found the per-series -danctnix
mirrors merged in #17 do NOT apply against the linux-pinetab2 baseline:
all 17 of them use DKMS-style root paths (bes2600/foo.c) rather than
in-tree staging paths (drivers/staging/bes2600/foo.c), and at least one
has a corrupted mixed-prefix header
(a/drivers/staging/bes2600/... b/bes2600/...).
ka-promote ohm with those includes produced a 172 644-byte cumulative
touching 27 file paths, of which 11 are bogus. The hand-curated
0001-bes2600-besser-cumulative-series.patch from the working
danctnix-besser-pkgbuild flow on boltzmann (148 149 bytes, 48 in-tree
staging files) is what pkgrel=3 actually builds with.
Until the per-series mirrors are reconstructed (followup issue to be
opened separately), the bes2600 driver scope is satisfied here by
staging that hand-curated cumulative as a single-file series-dir
patches/driver/bes2600/cumulative-c5x-danctnix/. ohm.yaml drops the
broken per-series includes in favour of:
- driver/bes2600/cumulative-c5x-danctnix/
- driver/bes2600/scan-filter-5ghz-danctnix/ (closes besser#1)
- arch/arm64/xor-neon-ffixed-x18-scs-build-fix-danctnix/
ka-promote ohm now produces a self-consistent 157 446-byte cumulative
(148 149 + 7 735 + 1 562 = exact byte arithmetic) with b2sum
a807297b25be... which is what the new
marfrit-packages/arch/linux-pinetab2-danctnix-besser PKGBUILD pkgrel=4
pins.
Also fixes fleet/ohm.yaml YAML parse error: bar5_burn_in had a scalar
value followed by a sub-list, which ka-promote (PyYAML) refused to
parse. The whole manifest had never parsed cleanly since #18 landed.
Refs: #5 (migrate PKGBUILD), #2 (mirror besser series — needs per-series
rewrite followup), besser#1 (Patch I).
claude-noether