Only fixing ~arch 4.3.2 given haven't tested muchand haven't tried
the other slots at all (could be missing more).
Ideally all slots need fixes so leaving bug #951199 open, will let
maintainers decide how to handle that.
Bug: https://bugs.gentoo.org/951199
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Seems to have gained a subslot, but that was a while ago
so little reason to revbump (a new release is coming soon
either way).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
All packages (currently) on the ffmpeg-7 tracker should be
either fixed, or using ffmpeg-compat.
Odds are there are more that either A) issue hasn't been found
by tinderboxes yet B) bug exist but isn't blocking the tracker
(found a few but likely missing more) or C) it is runtime
problems and will need user reports.
Bug: https://bugs.gentoo.org/928905
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Mask was missing for ffmpeg-compat but hadn't noticed given
the keyword did exist now, and it came up in stablereqs.
Would rather not push for more sparc stable, so let's just
move the mask.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
It is possible fixes already exist for ffmpeg-7 on this package,
but not planning to look into that myself.
Bug: https://bugs.gentoo.org/948392
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
It is possible fixes already exist for ffmpeg-7 on this package,
but not planning to look into that myself.
Bug: https://bugs.gentoo.org/948466
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
It is possible fixes already exist for ffmpeg-7 for this, but
not planning to look into that myself.
Arguably instead using bundled on ppsspp would not be a bad idea
given playing PSP's videos properly is flaky and ppsspp bundles
ffmpeg3 intentionally even though it could use newer. Then again
that's assuming the bundled copy even builds fine.
That aside, given no code changes here, plans are to sync
keywords back with stable when ready.
Bug: https://bugs.gentoo.org/948816
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Does seem broken with ffmpeg-7 at a glance (was not sure if the
pinning was only to match the bundled version or because it was
actually broken) so let's use ffmpeg-compat instead to let users
upgrade.
kodi-9999 seems to pin to ffmpeg-7 instead, but not going to look
at making that work in the older version esp. since I do not use
this.
Keeping old revision which can be stabled without pulling
ffmpeg-compat:6 for stable users, not that it'd be a big deal.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Meant to do ffmpeg-compat rather than bump, but the bump is very
trivial only containing our patches + ffmpeg 6/7 compat for changes.
Closes: https://bugs.gentoo.org/909159
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
It is possible fixes already exist for ffmpeg-7 on this package,
but not planning to look into that myself.
Given no code changes, plans are to sync keywords back with stable
when ready.
Bug: https://bugs.gentoo.org/948852
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
It is possible fixes already exist for ffmpeg-7 on this package,
but not planning to look into that myself.
Given no code changes, plans are to sync keywords back with stable
when ready.
Bug: https://bugs.gentoo.org/949272
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Apparently there are upstream fixes (not in a release), but not
planning to do a snapshot or backport + test this myself.
Given no code changes, plans are to sync keywords back with stable
when ready.
Bug: https://bugs.gentoo.org/948390
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Maybe a newer snapshot would fix this by now but not planning to
try myself.
Given no code changes, plans are to sync keywords back with stable
when ready.
Bug: https://bugs.gentoo.org/948254
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Apparently already fixed in a newer version, but leaving bumping
to the actual maintainer.
Given no code changes, plans are to sync keywords back with stable
when ready.
Bug: https://bugs.gentoo.org/948162
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Apparently already fixed in the next version, but not planning
to handle the bump myself.
Given no code changes, plans are to sync keywords back with stable
when ready.
Bug: https://bugs.gentoo.org/948077
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
It is possible fixes already exist for ffmpeg-7 on this package,
but not planning to look into that myself.
Given no code changes, plans are to sync keywords back with stable
when ready.
Bug: https://bugs.gentoo.org/948076
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Seems patches are going around, but not planning to test this myself,
also feel that this package should just be last-rited instead.
Given no code changes, plans are to sync keywords back with stable
when ready.
Bug: https://bugs.gentoo.org/942966
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Seems already fixed upstream, but not planning to handle a potential
snapshot or backports + testing myself.
Given no code changes, plans are to sync keywords back with stable
when ready.
Bug: https://bugs.gentoo.org/942964
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
It is possible fixes already exist for ffmpeg-7 on this package, but
this is something that should be handled by the actual maintainers.
Given no code changes, plans are to sync keywords back with stable
when ready.
Bug: https://bugs.gentoo.org/926787
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Most packages are fine, but then there's cmake.
Also some others doing -L/usr/lib64 *before* pkg-config flags.
Not great, but adding to CPPFLAGS/LDFLAGS directly tend to
workaround most issues and helper will spare repeating this.
Also emphasize on importance to verify libraries, e.g. it can
build against ffmpeg-compat:6 but the -L/usr/lib64 will make
it use ffmpeg-7 and this sometimes succeed even if package was
broken with ffmpeg-7 assuming no missing symbols. -rpath could
also have been lost and libraries be not found.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>