fix: mozjs140 - remove flagged files

[Andrew Phelps (anphel31)]

Remove a UPX-packed Win32 test fixture (toolkit/components/mediasniffer/test/unit/data/ff-inst.exe) from the mozjs140 source tarball and drop the two references to it.

The package-signing scan flags the packed PE inside the .src.rpm and rejects it, blocking signing. The file is a media-sniffing negative test fixture; this package builds SpiderMonkey from js/src only, so nothing in the build reads it and it is not shipped in any binary RPM.

• An azldev archive overlay (file-remove) drops the fixture and repacks the tarball; the post-overlay hash is pinned via origin = { type = "overlay" }.
• Two file-search-replace overlays drop the now-dangling references in xpcshell.toml and test_mediasniffer_ext.js.

Note: the deterministic repack emits a single-block xz stream, so the tarball grows from 613.3 MiB to 743.6 MiB. Uncompressed content is unchanged.

azldev comp render --check-only reports no drift.

[Copilot]

🟢 Approval recommended

The change follows an existing in-repo pattern for removing scan-flagged fixtures via archive overlays and updates the lock + rendered outputs consistently.

Pull request overview

Removes a package-signing-scan flagged Windows PE test fixture from the mozjs140 upstream Firefox source tarball via azldev archive overlays, and pins the repacked archive hash so the SRPM no longer contains the flagged bytes.

Changes:

• Introduce a dedicated mozjs140 component definition that removes ff-inst.exe from the upstream source archive and cleans up its test references.
• Pin the post-overlay (repacked) firefox-140.6.0esr.source.tar.xz via source-files with replace-upstream = true.
• Refresh rendered spec/sources and the component lock fingerprint to match the updated inputs.

File summaries

File	Description
base/comps/mozjs140/mozjs140.comp.toml	New per-component config with archive overlays removing the flagged fixture and a pinned post-overlay source hash.
base/comps/components.toml	Removes the now-customized mozjs140 from the “unmodified Fedora-imported components” list.
locks/mozjs140.lock	Updates input-fingerprint to reflect the new component inputs.
specs/m/mozjs140/mozjs140.spec	Bumps release/changelog to capture the component change in rendered output.
specs/m/mozjs140/sources	Updates the SHA512 to the repacked, post-overlay source tarball hash.

Review details

• Files reviewed: 4/5 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Andrew Phelps (anphel31)]

Two follow-up changes pushed (amended into the single commit, per the squash convention):

1. Overlay metadata category corrected to azl-pruning. The three overlays were tagged azl-security-compliance, which .agents/skills/azldev-overlay-metadata/SKILL.md defines as "Makes FIPS or crypto-policy changes". Removing a file is azl-pruning — "Removes content for AZL: unshipped deps, unneeded features, sub-packages, or files."

2. The three overlays moved into a single per-file overlay document. They were three inline [[components.mozjs140.overlays]] entries each repeating identical metadata. The skill calls that out directly: "if you find yourself stamping the same metadata on several inline overlays, that is a signal they are one logical change — move them into a single overlay file with one [metadata] block", and recommends the per-file layout for all new work. They are now in base/comps/mozjs140/overlays/0001-remove-packed-windows-test-fixture.overlay.toml with one top-level [metadata] block, auto-loaded via the project-wide overlay-files glob. mozjs140.comp.toml retains only the source-files pin.

This is a pure reorganization: same three overlays, same order, same archive/file/regex values, so the repacked tarball and its pinned SHA-512 are unchanged.

---

On the ~130 MiB tarball growth

Root cause is a missing knob rather than anything about this change. Upstream ships firefox-140.6.0esr.source.tar.xz at xz -9e (64 MiB dictionary, ratio 0.180); azldev's archive-overlay repack emits at the liblzma default preset (8 MiB dictionary, ratio 0.218). Dictionary size accounts for essentially the whole delta — it is a preset difference, not a blocking/threading difference.

Worth noting this component is the first large .tar.xz to go through the overlay-repack path. The only other origin = { type = "overlay" } pin in the tree is minizip-ng, a small .tar.gz, where a ~20% ratio difference is invisible. So this is newly-exposed rather than a regression.

Three options:

1. Accept it. Simplest, but a 21% size increase on an already-large SRPM is a real cost.
2. Add an xz preset option to the archive-overlay repack in azldev (e.g. per-component compression = { preset = "9e" }). This is the clean fix and would benefit every future large-archive overlay. Requires an azldev change.
3. Repack out-of-band, following the merged gnome-autoar precedent. base/comps/gnome-autoar/modify_source.py pipes tar --sort=name --mtime=... --owner=0 --group=0 --numeric-owner into xz -T1 -9e and serves the result via origin = { type = "download", uri = ... } from the staging lookaside. That reproduces upstream's compression exactly and would land at or slightly below the original 613 MiB.

Option 3 works today with existing in-repo precedent, but it moves artifact generation outside the repo (pinned by hash, produced by a script rather than by config), and single-threaded -9e over a 3.4 GiB tree is slow. Option 2 is the better long-term answer if we expect more large archives to need overlays.

Happy to go with whichever the maintainers prefer — flagging it rather than silently shipping the growth.

[Copilot]

🟢 Approval recommended

The overlay approach and post-overlay source pinning follow established repository patterns for removing scanner-flagged fixtures, and the lock/rendered updates are consistent with the new component inputs.

Review details

• Files reviewed: 5/6 changed files
• Comments generated: 0 new
• Review effort level: Lite

[reuben olinsky (reubeno)]

issue(blocking): These regexes look quite brittle, with hard-coded whitespace chars (ditto for the one below). What's the simplest regex that could be used instead to remove the required entries?