ffmpeg_8: 8.1.1 -> 8.1.2

[bartoostveen]

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.
• Follows the automation/AI policy.

[bartoostveen]

Will build and test on x86_64-linux in a sec

[bartoostveen]

Oh, historically this was done on master, will rebase upon staging then. I probably do not have the cycles to run this on staging though

[bartoostveen]

cc @dotlambda (as a committer that seemed to be involved in the past)

[bartoostveen]

(CVE-2026-8461, CVE-2026-30999)

[dotlambda]

Oh, historically this was done on master, will rebase upon staging then.

Please rebase on git merge-base master staging instead. That makes it easier to test the builds locally.

[bartoostveen]

I did this already, the bot is still catching up

[dotlambda]

I actually suggest splitting this into multiple PRs. Some of them can go straight to master.

[bartoostveen]

Which ones do you want on master?

[bartoostveen]

All except 8 I suppose?

Review dismissed automatically

[dotlambda]

Yeah, it looks like every other version causes less than 500 rebuilds.

[bartoostveen]

#534377, #534378, #534379

[dotlambda]

I did this already, the bot is still catching up

No, there are plenty of commits in your branch that are not in master. But I also noted that 8.1.1 is only in staging, so it would have been impossible to base on git merge-base master staging anyway.
Doesn't matter now, it's advice for the future.

Also, please link to the changelog in the commit message and PR description going forward.

[nixpkgs-ci]

Successfully created backport PR for staging-26.05:

• [Backport staging-26.05] ffmpeg_8: 8.1.1 -> 8.1.2 #534409

[jopejoe1]

@NixOS/nixpkgs-ci any idea why the ffmpeg maintainers where not pinged on this pr?

[MattSturgeon]

I'd need to re-familiarize myself with eval's comparison and maintainer filtering.

The comparison artifact found 15041 changed packages and no relevant maintainers, but the comparison logs also show:

This PR touches 1 files
File pkgs/development/libraries/ffmpeg/default.nix is unowned

IIRC, files outside of by-name need to be owned by ci/OWNERS, because we cannot assume a file->package relationship outside of by-name. But I could be misremembering something or missing some detail.

[purcell]

Just wanted to flag here that there are other ffmpeg versions packaged in nixpkgs: jellyfin uses ffmpeg 7.1.4, and radarr and sonarr depend on ffmpeg 5.1.4.

[dotlambda]

radarr and sonarr depend on ffmpeg 5.1.4

#535419

[purcell]

Thanks @dotlambda. And the jellyfin folks seem to have patched jellyfin-ffmpeg too, and we have the patched version in nixpkgs. ✅

[MattSturgeon]

IIRC, files outside of by-name need to be owned by ci/OWNERS, because we cannot assume a file->package relationship outside of by-name. But I could be misremembering something or missing some detail.

That can't be it, as #535552 pinged the maintainers correctly. Sorry for responding in haste earlier!

This PR did affect 15000 packages, so maybe it just ran into the "too many maintainers" case:

nixpkgs/ci/github-script/reviewers.js

Lines 33 to 43 in 0bfa3a1

	// Early sanity check, before we start making any API requests. The list of maintainers
	// does not have duplicates so the only user to filter out from this list would be the
	// PR author. Therefore, we check for a limit of 15+1, where 15 is the limit we check
	// further down again.
	// This is to protect against huge treewides consuming all our API requests for no
	// reason.
	if (user_maintainers.length + team_maintainers.length > 16) {
	core.warning('Too many potential reviewers, skipping review requests.')
	// Return a boolean on whether the "needs: reviewers" label should be set.
	return users_reached.size === 0 && teams_reached.size === 0
	}

I'm still confused why the comparison artifact shows maintainers.json as {}, despite changed-paths.json listing the affected packages. That's implemented here:

nixpkgs/ci/eval/compare/maintainers.nix

Lines 146 to 153 in 007fdaf

	byUser = lib.pipe (byType.user or [ ]) [
	(lib.groupBy (ping: toString ping.userId))
	(lib.mapAttrs (_user: lib.map (pkg: pkg.context)))
	];
	byTeam = lib.pipe (byType.team or [ ]) [
	(lib.groupBy (ping: toString ping.teamId))
	(lib.mapAttrs (_team: lib.map (pkg: pkg.context)))
	];

[dominikpaulus]

Was this intentionally backported to staging instead of staging-next? (Given that this is a security-relevant release)

[wegank]

This PR introduces an unresolved regression on loongarch64-linux: upstream issue + Debian Bug report