commit 2f864407a1c6ab709bffbd3917c4ae7d91f93b3d
Author: lucascouts <lucascs@protonmail.com>
Date: Mon Sep 7 10:36:32 2026 -0300

fix(sys-firmware/edk2): the firmware was building single-threaded, mod(13 ebuilds): tag the INHERIT divergences, mod(scripts/gentoo-parity.sh): re-measure A20

Fifteen INHERIT rows. Fourteen are eclasses this overlay correctly does not
inherit; one was a real loss. INHERIT reaches zero ALIGN with this and PATCHES
is the only axis left.

THE FIX. sys-firmware/edk2's my_build is character-for-character ::gentoo's
except for one missing line:

edo build \
-n "$(get_makeopts_jobs)" \ <- absent here
-t "$" \

Without -n, edk2's build driver falls back to the thread count in target.txt,
which is 1. The whole firmware compiled serially, on every machine, silently -
nothing fails, it is just slow, which is exactly the kind of regression no test
catches. get_makeopts_jobs comes from multiprocessing.eclass, so the missing
inherit and the missing flag are one defect with two symptoms, and the parity
axis is what surfaced it.

TEN OF THE FOURTEEN ARE ONE FINDING: virtualx across the gstreamer family,
gst-plugins-{bad,base,good}, gstreamer and gst-plugins-libav, two versions each.
Checked rather than assumed. gstreamer-meson.eclass does "inherit virtualx"
itself, in the branch a top-level module takes, and the two eclasses are
identical at that point. virtualx appears in _eclasses_ of BOTH md5-cache
entries, so the same eclass is loaded either way - ::gentoo simply restates in
the ebuild what its own eclass already did. Nothing to align.

The other four:

imagemagick has no verify-sig, same root as its SRC_URI and BDEPEND tags -
there is no .asc to check.

nodejs has no shell-completion, twice. ::gentoo uses it to write npm's
completion into the shared /usr/share/bash-completion/completions; this
overlay slots nodejs by major, where a shared path would have every slot
fighting over one file, so src_install writes it inside the slot prefix. The
ebuild already said this in prose, but named bash-completion-r1 - the
predecessor eclass, not the one ::gentoo actually inherits.

mesa has no toolchain-funcs. Nothing there calls a tc-* function: get_libdir
is multilib's and get_llvm_prefix is llvm-r2's. ::gentoo inherits it for
tc-check-openmp, which this ebuild does not use.

Verified. Every md5-cache delta is _md5_ and eclass reordering only, except
edk2's INHERIT gaining multiprocessing, which is the intended change. pkgcheck
against a worktree at 496137166 is identical on all eight packages committed
here. The sweep goes 225 rows to 224, ALIGN 38 to 23. --self-test 24/24 with A20
re-measured.

media-libs/mesa IS DELIBERATELY NOT IN THIS COMMIT. Its tag is written and its
row is measured above, but another session is mid-edit on that ebuild in the
working tree - 32 insertions, 20 deletions, a new VENUS_PROTOCOL_COMMIT and a
changed Manifest. Committing the file would carry unfinished work that is not
mine. The tag stays in the tree for that session to commit with its own change;
until then mesa's INHERIT row remains ALIGN and the real count is 24, not 23.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

commit 0922e3b48f2a627434a525b4a264160e439334af
Author: lucascouts <lucascs@protonmail.com>
Date: Sat Sep 5 14:07:28 2026 -0300

mod(sys-firmware/edk2, net-libs/libqmi, app-editors/{vim,zed}, app-office/libreoffice, +10): apply the approved parity remediation

Second pass over the 2026-09-04 audit, after the items that block or verify.
Each one was re-measured against the tree as it stands today rather than taken
from the report, and three of them came out differently for it.

SECURITY, and the one judgement call in the set:

sys-firmware/edk2 -> openssl 3.5.8 (revbump to -r2). We are deliberately NOT
faithful to edk2-stable202608's submodule pin (8cf17aae = 3.5.7) here, which is
the unusual direction for this overlay, so the ebuild carries the reasoning: the
library is linked statically into firmware with no host update path, and 3.5.8
fixes ten CVEs including CVE-2026-63072, an 8-byte OOB heap write in CMS
AES-WRAP-PAD. Diverging from a submodule SHA is reversible at any bump; an
unfixed CVE in flashed firmware is not. ::gentoo made the same call.

SILENT CORRECTNESS:

net-libs/libqmi declared SLOT="0/5.11" while installing libqmi-glib.so.5.12.0
(measured in VDB CONTENTS). A subslot that does not match its library disables
the rebuild it exists to trigger. Revbumped to -r1, because correcting the value
alone only changes what FUTURE consumers record.

app-editors/zed gained sys-apps/xdg-desktop-portal, which it never had: ashpd is
used from both gpui backends (x11/client.rs and wayland/client.rs), so file
dialogs and screen capture failed at runtime, not at build. ::gentoo has it.

dev-util/glslang gained the multilib_src_test skip for bug #977176. We keyword
~arm without the skip that makes ~arm testable.

app-office/libreoffice: --disable-gtk3 sat 44 lines above $(use_enable gtk3),
contradicting IUSE="+gtk3". It works today only because autoconf honours the
last flag, so a reordering breaks it silently -- removed.
--enable-skia-vulkan-validation was passed unconditionally inside
--enable-release-build; that is SK_ENABLE_VK_LAYERS=1, debug instrumentation, so
it is now gated on USE=debug. Plus the two missing := subslots.

app-editors/vim: restore five of the six patches in ::gentoo's vim-patches
snapshot, which this overlay had been dropping on every bump. Measured, not
assumed -- each verified with portage's own patch flags against the 9.2.1036
tarball. 002_all_vim-7.3-apache is deliberately excluded and tagged: it fails
with 2 hunks because upstream rewrote the block, and it costs syntax
highlighting for two Gentoo-specific config paths. ::gentoo has not hit this yet
(its newest vim is 9.1.1652, where it still applies).

ARCH COVERAGE, against the overlay's own "restricting to ~amd64 needs a
justification" rule. All widened to ~arch only -- our versions are newer than
::gentoo's, so nothing enters stable: dev-lang/lua (1 arch -> 16),
media-plugins/frei0r-plugins (2 -> 9), app-emulation/qemu (2 -> 8),
net-analyzer/netdata (1 -> 5), dev-util/mesa_clc (+~riscv).

dev-util/spirv-headers is the one with a measured failure behind it, and the
audit had it backwards. It is not behind ::gentoo -- it is byte-identical to
their 9999. The defect is INTERNAL: our spirv-tools carries 13 arches and our
spirv-headers 8, so the consumer cannot resolve its header on ~mips (48
profiles) and ~alpha (82). Widened to match the consumer; pkgcheck
NonsolvableDeps for the pair goes to zero.

STALE FLOORS: media-libs/mesa RUST_MIN_VER 1.82.0 -> 1.85.0 (::gentoo raised it
at 26.2.1); net-misc/modemmanager was LOWERING the tree-wide
gobject-introspection floor to 1.38.

WHERE THE REPORT WAS WRONG:

media-gfx/imagemagick "lost verify-sig" is not remediable and the ebuild now
says why, with evidence. The old comment claimed upstream signs only the latest
release; it does not sign that either -- 7.1.2-31 IS the newest and both the
tarball and its .asc are 404 on all three mirror://imagemagick hosts, as are
-30, -29, -28 and -25. ::gentoo's copy works because Gentoo mirrors distfiles on
its own infrastructure. Adopting their SRC_URI would trade a working fetch for a
signature we cannot obtain, so the divergence is documented with the two
conditions that would reverse it.

The vim finding was five patches, not four. The spirv-headers finding pointed at
the wrong tree.

Also drops app-editors/vim-core/files/{vimrc-r7,xxd-completion}, orphaned -- no
ebuild in the overlay references either.

Verification: pkgcheck one target at a time with --cache=-git over all 16
packages. What remains is pre-existing or inherited and was checked as such:
app-editors/zed DeprecatedEclass llvm-r1 (::gentoo's zed uses it too),
app-office/libreoffice NonsolvableDeps on media-libs/libeot (no ~arm in
::gentoo). egencache with an explicit filter; it also pruned 101 orphan cache
entries, and no live ebuild lost its entry. No build was merged -- this host has
no sudo.

app-office/libreoffice-l10n is NOT in this commit. The new digest axis found all
180 of its 26.2.6.1 distfiles missing from the Manifest; regenerating it is a
separate change and a large download.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

commit 3d0e56184e14c24c90539156565a9e7f8c244b00
Author: lucascouts <lucascs@protonmail.com>
Date: Sat Sep 5 09:12:50 2026 -0300

mod(eclass/gstreamer-meson.eclass): rebase onto ::gentoo, mod(89 ebuilds): apply the parity audit

Executes the tracks in .epic/reports/agent-parity-audit/03-execution-plan.md.
The audit's single systemic cause: a version bump renames our own ebuild forward
and never re-reads ::gentoo, so every fix the distribution made to that revision
is discarded in silence. These are the discarded fixes.

PROVEN BROKEN, now fixed:

dev-python/gst-python: our pygobject patch is upstream 0496a778, already in the
tarball. Reproduced "3 out of 3 hunks FAILED" against real 1.28.6 sources, and
confirmed the line it adds already sits at gstpythonplugin.c:239. Dropped.

media-plugins/gst-plugins-webrtc: PATCHES pointed at the 1.24.10 patch, which
dies with "sctp Hunk #1 FAILED". ::gentoo's rebased 1.26.11 copy applies clean
to both 1.28.6 and 1.29.2 -- adopted. libnice floor 0.1.21 -> 0.1.23: upstream
needs 0.1.23 and BOTH trees were below it, so matching ::gentoo (0.1.22) would
have left the configure-time death standing.

net-libs/webkit-gtk-{r410,r600}: added 2.52.6-no-video.patch (FTBFS with
USE=-gstreamer) and 2.52.6-no-sse2.patch plus the SSE IUSE and the 17-line x86
block (bug 730044) -- we keyword ~x86 without the fix that makes ~x86 build.
Same pattern for ~ppc64: added it to the SKCMS_HAS_MUSTTAIL=0 guard (bug
970556). Both patches come from ::gentoo's copies of these same revisions.

dev-util/nvidia-cuda-toolkit: PYTHON_COMPAT ( 11..13 ) against a 3.14 profile
default made REQUIRED_USE unsatisfiable on EVERY profile on EVERY arch, not the
94 first reported -- PYTHON_TARGETS is set once in base/make.defaults. pkgcheck
RequiredUseDefaults goes from 762 profiles to 0. dev-python/gst-python and
media-libs/gstreamer-editing-services had the same defect; both moved to
( 12..14 ).

net-libs/nodejs-26.8.1: nghttp3 floor 1.15.0 -> 1.18.0 (upstream needs 1.18.0;
--shared-nghttp3 FTBFS below it) and ngtcp2 1.22.0 -> 1.22.1 (CVE-2026-40170).

THE ECLASS, which unblocks four of the above:

Rebased onto ::gentoo's, keeping exactly two additions, both tagged in the
header. (1) meson.options support: GStreamer 1.28.0 renamed meson_options.txt,
and ::gentoo's eclass reads the old name unconditionally -- measured, 1.28.6
ships only meson.options, so their copy would die in gstreamer_get_plugins on
all 153 gst-plugins-* here. (2) -Dtests=disabled on split plugins. Recovered
from ::gentoo in return: GST_PLUGINS_MULTILIB, the meson-1.4 BDEPEND, the
src_test guard, and correct "$" quoting.

SILENT CORRECTNESS:

media-libs/gst-plugins-bad had lost the entire vulkan USE flag. Worse than
"removed": the options still exist upstream at value: 'auto' and our eclass sed
extracts none of them (measured: 0 of 3, because they sit under a section
header neither pattern matches), so no -Dvulkan=disabled was emitted -- an
automagic dependency on vulkan-loader, not a disabled one. Restored ::gentoo's
GST_PLUGINS_NOAUTO + explicit meson_feature. Also fixed `rm -f ... || die`,
where -f makes the || die unreachable.

media-libs/gst-plugins-base hardcoded -Dtools=enabled on every ABI, so 32-bit
tools overwrite 64-bit ones in /usr/bin. Now $(meson_native_enabled tools) --
which needs `inherit meson-multilib`, as ::gentoo does; pkgcheck caught the
omission. Restored the libpng:0= subslot in the same file.

Subslot := restored on gst-plugins-{chromaprint,neon,soundtouch,webp} (8
ebuilds): without it portage never rebuilds the consumer on an ABI change.

KEYWORDS on 52 ebuilds: 1.28.6 carried 1.24.13's line verbatim, re-asserting
arm/arm64/ppc as STABLE on a version whose arch teams never signed off. Only
the monotonic rule was applied -- demote stable->testing where ::gentoo did not
stabilise, never promote. Note the 1.29.2 ebuilds are already all-~; blanket
"align with ::gentoo" there would have STABILISED a masked development series.
The comparison must also be against ::gentoo's newest (1.26.11): against the
union of all their versions it yields zero hits, because 1.24.13 is where the
carry-forward came from.

SUPPLY CHAIN:

verify-sig restored on the 8 packages ::gentoo verifies (16 ebuilds). All 8 .asc
URLs return 200; Manifests regenerated one explicit target at a time. Not 9 as
first reported -- gst-plugins-libav has no verify-sig in ::gentoo either.

sys-firmware/edk2: added edk2-202608-fix-gic-hvf.patch. We keyword ~arm64 and
build ArmVirtQemu.dsc without the ArmVirtPkg GIC series ::gentoo applies to the
same 202608 release. The OpenSSL 3.5.7-vs-3.5.8 question is deliberately NOT
touched here: it is a judgement call, not a bug.

TEXTS THAT STATED THE OPPOSITE OF REALITY -- all seven, each re-verified live:

x11-base/xwayland claimed test/{sync,damage,bigreq}/ do not exist in 24.1.x. The
GitLab API returns 200 for all three at tag xwayland-24.1.13 and 404 only for
test/pyxtest/. The dependency is still right, for the half of the reason that
survived.

dev-games/godot x2 claimed master still carries the unguarded calls with no PR.
Upstream 2e26ab8a3afb (2026-08-28) touches exactly the two files these patches
guard. Marked DROP-at-next-bump, explicitly not rebase.

dev-util/spirv-tools described an -r1 and an EGIT_COMMIT that no longer exist;
kept the mechanism, which still applies. dev-util/vulkan-tools omitted that the
same edit deleted test? ( dev-cpp/gtest ). www-client/chromium said slot 22 was
"enabled" -- 2ff7214ee narrowed ( 21 22 ) to ( 22 ), a substitution that leaves
an LLVM-21-only system unable to build chromium at all; flagged as an open
decision rather than silently reworded.

VERIFICATION

Every claim above is executed evidence except one: the webkit-gtk patches have
not had a patch --dry-run, because the tarball is not in DISTDIR. They are
byte-identical to ::gentoo's for the same revisions, which is strong, but it is
not a run.

egencache with --repositories-configuration and an explicit 96-package filter;
collateral checked and benign. pkgcheck one target at a time with --cache=-git;
what remains is pre-existing or inherited (::gentoo reports the same 16
RequiredUseDefaults on webkit-gtk). No build was merged -- this host has no
sudo, so nothing here claims a merge-tested pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

commit 9a1458a6d6cb75104168fe48c782c91073ebf15a
Author: lucascouts <lucascs@protonmail.com>
Date: Tue Sep 1 21:58:50 2026 -0300

up(sys-firmware/edk2-202608 -> -r1), add(scripts/check-edk2-dbx-freshness.sh), mod(.autoupdate/packages.toml, CLAUDE.md)

edk2 pins TWO independent release trains and only one of them was being
watched. PV follows tianocore's edk2-stableYYYYMM tag, which the registry
probes and which is current at 202608. SBO_VER follows
microsoft/secureboot_objects, which supplies the signed DBXUpdate.bin blobs --
the Secure Boot revocation list that secureboot_auto_sign enrolls -- and it had
been sitting at 1.6.4 since the August bump while v1.6.5 was published
2026-07-07.

That is a worse class of stale than an ordinary pin. It breaks no build and
trips no pkgcheck; it just ships a machine that still trusts binaries Microsoft
has already revoked. The amd64 blob grew 24053 -> 24629 bytes across the two
versions, so those are real new revocations rather than a re-signing. The arm64
blob is byte-identical between 1.6.4 and 1.6.5 -- only the DIST name changes
there.

Bumping SBO_VER changes the fetched distfiles, hence the revbump rather than an
in-place edit.

PYTHON_COMPAT gains python3_15, which clears the last pkgcheck finding. Stated
plainly: this is NOT execution-verified. dev-lang/python-3.15.0_rc2 carries
empty KEYWORDS in ::gentoo, so it is installable on no arch and is absent from
this host. The exposure is small because the ebuild uses python-any-r1 --
Python is build-time only and generates no IUSE -- and `emerge -pv` with full
dependency resolution still selects the installed 3.14 rather than pulling
3.15.

The new script is the part meant to outlive this commit. .autoupdate cannot
watch SBO_VER: aux_pattern is documented as applying to the SAME response body
as the version probe, the DBX lives in another repository, and there is no
aux_url -- verified against the INSTALLED binary's field list, not the source
checkout, which is four days behind it. So the registry will keep reporting
"up to date" over a rotting revocation list forever. check-edk2-dbx-freshness.sh
closes that hole, and all three of its paths were exercised, not just the green
one: a stale pin exits 1 naming both versions, a missing SBO_VER exits 1 saying
the check has gone blind, and an unreachable API exits 2 -- deliberately not 1,
because "could not determine" is not a gap. It stays out of pre-commit since it
needs the network, and a guard that turns red offline is a guard people learn
to skip.

sys-firmware/edk2-bin is NOT added here. A copy was prepared and dropped: it was
byte-identical to ::gentoo's 202605, `overlay prune` filed it under "Identical
to ::gentoo -- our copy holds nothing of ours", and 202608 could not be built on
top of it because only the aarch64 xpak had landed on dev.gentoo.org/~chewi
(the other three still 404, upload order across past releases is not stable).
Its registry record stays, disabled, per the overlay's own rule that a removed
package becomes enabled = false rather than a deleted entry: the endpoint,
select = "max" and type = "bin" are all probe-verified, so re-adding the package
when the four xpaks land costs nothing. disabled_by = "auto" so reconciliation
re-enables it by itself.

Verified: the six submodule SHAs in the Manifest all match what the
edk2-stable202608 tag actually points at (openssl included, via dereferencing
the annotated openssl-3.5.7 tag to 8cf17aae); both patches apply sequentially
at fuzz zero against the real tarball, tools_def.template included; Manifest
regenerated by real download; md5-cache _md5_ matches the ebuild after the
git mv; pkgcheck is clean; shellcheck on the new script is clean and its
--self-test passes.

Not built: this host has no sudo, so validation stopped at `emerge -pv`, which
resolves the ebuild as a 25 KiB upgrade -- exactly the new amd64 DBX blob.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

commit 49495cc234309f997be1d1f4767f8fa993a56301
Author: lucascouts <lucascs@protonmail.com>
Date: Sat Aug 22 23:57:21 2026 -0300

mod(net-wireless/mt7927-dkms/metadata.xml), rm(sys-firmware/edk2/files/{edk2-202408-binutils-2.41-textrels, edk2-202411-gcc15, edk2-202411-loong, edk2-202411-werror, edk2-202502-nasm-3, edk2-202511-werror}.patch), up(net-wireless/mt7927-dkms-2.14 -> 2.14-r1)

mt7927-dkms-2.14-r1 fixes a defect introduced in 2.14: the MT6639 Bluetooth
firmware was gated behind USE=btmtk, which is off by default.

Nothing else on the system carries that blob -- linux-firmware only accepts
vendor blobs from the copyright holder, so MR !946 was closed, and qfile
confirms this package is its only owner here. But the firmware is not needed
only by the modules this package rebuilds: the kernel's OWN btmtk, the in-tree
one that runs precisely when the flag is off, asks for the same
mediatek/mt7927/BT_RAM_CODE_MT6639_2_<n>_hdr.bin. So the default configuration
shipped a machine whose native Bluetooth stack had no firmware to load.

The blob is now fetched and installed unconditionally, and the flag gates only
the out-of-tree btusb/btmtk rebuild. LICENSE and RESTRICT=mirror go back to
being unconditional, since the proprietary file is always part of the package.

Verified by staging both configurations: USE=-btmtk now yields 7 modules, 7
depmod overrides and the firmware; USE=btmtk yields 9, 9 and the same firmware.
The bug was only visible once the package was actually installed -- inspecting
the -btmtk image alone showed a missing file, not a broken Bluetooth stack.

Also drops six patches under sys-firmware/edk2/files/ that no ebuild in the
overlay references any more, left behind by earlier bumps because the applier
renames the ebuild but never the patches. The two the 202608 ebuild does use
are untouched; git history keeps the rest.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

commit ba5ee02456f40d842a879e85fe73324ea72db044
Author: lucascouts <lucascs@protonmail.com>
Date: Sat Aug 22 21:56:52 2026 -0300

add(app-portage/bentoolkit/bentoolkit-0.27.0.ebuild, net-wireless/mt7927-dkms/mt7927-dkms-2.14.ebuild, metadata/md5-cache/{app-portage/bentoolkit-0.27.0, net-wireless/mt7927-dkms-2.14}), rm(sys-firmware/edk2/{edk2-202605.ebuild, files/edk2-202605-werror.patch}), mod(net-wireless/mt7927-dkms/metadata.xml, .autoupdate/packages.toml), up(app-portage/bentoolkit-0.26.0 -> 0.27.0, net-wireless/mt7927-dkms-2.13 -> 2.14)

app-portage/bentoolkit 0.27.0: no dependency or USE change -- the release adds
the --depth=install rung and an unwired terminal design system. Two inherited QA
findings fixed in passing: IUSE now precedes RESTRICT, and the ldflags line no
longer runs past 120 columns.

net-wireless/mt7927-dkms 2.14 is a rebase, not a version bump. Upstream moved
MT76_KVER from 7.1.3 to 7.2, where Sean Wang's MT7927 series landed in mainline,
which is why the numbered WiFi patch set collapsed from 32 to the 4 AP-mode
additions still out of tree. Three consequences:

- The mini source tarball for the new base did not exist. Repacked from the
official linux-7.2.tar.xz (sha256 verified against sha256sums.asc) with the
same deterministic recipe as 7.1.3, and published to R2. Verified end to
end: portage fetched it from distfiles.obentoo.org and the Manifest
checksum matched, byte for byte identical to what was uploaded. The recipe
now lives in the .autoupdate record, because a base move makes every fetch
404 until someone repacks.

- The WiFi firmware is no longer installed, following upstream 2.14-4. The
collision is real and was measured here with qfile: sys-kernel/linux-firmware
owns .../mt7927/WIFI_RAM_CODE_MT6639_2_1.bin.zst (MR !1055) while this
package owned the uncompressed name, which the kernel loader tries first --
so a June 2025 blob out of a Windows driver ZIP shadowed the April 2026
vendor build. pkg_postinst now warns when neither form is present, since
dropping ours on a host with an older linux-firmware would take out the
connection needed to fix it.

- The Bluetooth side is now USE=btmtk, default off, mirroring the gate
upstream added in 2.14-6: from kernel 7.1 the MT6639 is native, so the
rebuild adds only the HP EliteMini ID 0489:e156 while replacing the in-tree
Bluetooth stack for every device on the machine. The flag is deliberately
NOT named "bluetooth" -- that is a global Gentoo USE flag enabled by most
desktop profiles, and emerge -pv confirmed it would have turned this opt-in
into an opt-out. It also gates the firmware SRC_URI, the proprietary half of
LICENSE and RESTRICT=mirror, so USE=-btmtk fetches nothing proprietary.

Validated by running the real phases (no sudo on this host: PORTAGE_TMPDIR of
our own, USE=-modules-sign, PORTAGE_INST_UID/GID overridden). bentoolkit built
and installed, and the binary reports 0.27.0. mt7927-dkms went through a full
clean install on both paths against the running 7.1.9 kernel, which exercises
the pre-7.2 EML compat shim: with btmtk, 9 modules plus BT_RAM_CODE and 9 depmod
overrides; without, 7 modules, 7 overrides and no firmware at all. The 0489:e156
ID is present in both binaries -- modinfo does not show it because the patch
puts it in quirks_table, which generates no MODULE_DEVICE_TABLE entry.

sys-firmware/edk2 202605 removed: 202608 landed in e0d40c2fc and the registry
already pinned it, leaving the old ebuild, its werror patch, its cache entry and
two now-orphaned DIST lines (11 -> 9) behind.

Not verified: edk2-202608 itself still has not been compiled or merged anywhere,
and no MT7927 module was loaded on real hardware -- both builds were staged into
an image and inspected, never installed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

commit e0d40c2fc7155bdb407600119c842927b057990b
Author: lucascouts <lucascs@protonmail.com>
Date: Sat Aug 22 19:40:06 2026 -0300

add(sys-firmware/edk2/{edk2-202608.ebuild, files/edk2-202608-werror.patch}, metadata/md5-cache/sys-firmware/edk2-202608), mod(.autoupdate/packages.toml), up(sys-firmware/edk2-202605 -> 202608)

Upstream tag edk2-stable202608 (released 2026-08-21).

Submodule pins re-read from the tag itself rather than copied forward: only
libspdm moved, 1be116c7 -> f55cf6d4. brotli, libfdt, mbedtls and mipi-sys-t
are unchanged, and the openssl gitlink (8cf17aae) still resolves to exactly
the openssl-3.5.7 release commit, so BUNDLED_OPENSSL_SUBMODULE_P stays put.

The werror patch needed a rebase, not a rename: upstream restructured the GCC
flag hierarchy in BaseTools/Conf/tools_def.template, routing -Werror through a
new GCC_ALL_CC_FLAGS indirection shared by every arch. Stripping it from
GCC_ALL_CC_COMMON and GCC_LOONGARCH64_CC_FLAGS now covers RISCV too, so the
old RISCV-specific hunk is gone. 202605 keeps its own copy of the patch, since
the two contents have diverged and that ebuild is still in the tree.

Not verified: nothing was compiled or merged -- this host has no sudo, so the
BaseTools/EDK II build and the secureboot signing path went unexercised.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

commit f6d7d7545746467495c47b6c90372a2da5c676ec
Author: lucascouts <lucascs@protonmail.com>
Date: Fri Aug 21 14:20:56 2026 -0300

fix(sys-firmware/edk2-202605): restore missing Manifest and md5-cache

The package was deleted whole in 594a1ec46 and re-added in 91fbbda7d without
its Manifest or its md5-cache entry. With thin-manifests a missing Manifest
means no DIST entries at all, so every fetch died before src_prepare:

!!! Fetched file: edk2-202605.tar.gz VERIFY FAILED!
!!! Reason: Insufficient data for checksum verification

That, not the 202608 bump, is what made the autoupdate validation gate report
edk2 as FAILED at none.

Regenerated with an explicit target (pkgdev manifest sys-firmware/edk2) and
egencache --repositories-configuration filtered to this package. Verified:
ebuild fetch exits 0 with all 7 amd64-profile distfiles checksummed, and
_md5_ matches the ebuild.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

commit 91fbbda7d45e50bbf100bedf7d983cda49a97d0a
Author: lucascouts <lucascs@protonmail.com>
Date: Fri Aug 21 13:20:58 2026 -0300

add(sys-firmware/edk2-202605), mod(.autoupdate/packages.toml)

commit 594a1ec464d9cca63ce6463ecc162d2fbe92ecc0
Author: lucascouts <lucascs@protonmail.com>
Date: Mon Jun 29 23:06:53 2026 -0300

add(app-editors/zed-1.10.0_pre20260629-r1), add(metadata/md5-cache/app-editors/zed-1.10.0_pre20260629-r1), del(dev-db/redis-8.8.0, kde-plasma/breeze{,-gtk}-6.7.1, media-sound/audacity-3.7.8, net-misc/rclone-1.74.3, sys-apps/{bleachbit-6.0.0, fwupd-2.1.5}, sys-firmware/edk2-202605), mod(.autoupdate/packages.toml), up(kde-plasma/{kameleon-qmk-helper, kdeplasma-addons}-6.7.1 -> 6.7.1-r1)

commit ceacc94df931b11f4d5331631b8d46d2bb446d03
Author: lucascouts <lucascs@protonmail.com>
Date: Mon May 25 21:18:51 2026 -0300

mod(sys-firmware/edk2-202605), mod(metadata/md5-cache/sys-firmware/edk2-202605)

commit 30e0cbad0399709f2bbc17609b26efcf796de2df
Author: lucascouts <lucascs@protonmail.com>
Date: Mon May 25 20:53:34 2026 -0300

del(sys-firmware/edk2-202602), mod(sys-firmware/edk2-202605), mod(metadata/md5-cache/sys-firmware/edk2-202605)

commit e9b83b55a57858502eeb46aa70c623cb210a7bce
Author: lucascouts <lucascs@protonmail.com>
Date: Mon May 25 20:19:49 2026 -0300

mod(app-editors/antigravity-bin-2.0.3.6242596486512640, sys-firmware/edk2-202605), mod(metadata/{md5-cache/app-editors/antigravity-bin-2.0.3.6242596486512640, md5-cache/sys-firmware/edk2-202605})

commit c14efd5041ff444e9c827d0a7700d56daa0d7fee
Author: lucascouts <lucascs@protonmail.com>
Date: Mon May 25 00:58:42 2026 -0300

add(dev-games/godot-4.7_beta3, sys-firmware/edk2-202605), add(metadata/{md5-cache/dev-games/godot-4.7_beta3, md5-cache/sys-firmware/edk2-202605})

commit 07d8b7d03121fc74acc90bc24fe02de6d81602d8
Author: lucascouts <lucascs@protonmail.com>
Date: Mon Mar 23 13:56:51 2026 -0300

add(app-emulation/qemu-11.0.0_rc0, media-video/vlc-4.0.0_pre20260323, sys-firmware/edk2-202602)