diff options
| author | Ionen Wolkens <ionen@gentoo.org> | 2024-09-24 21:28:23 -0400 |
|---|---|---|
| committer | Ionen Wolkens <ionen@gentoo.org> | 2024-09-24 21:49:50 -0400 |
| commit | bbe03f19766167b539b90af2034340e61ed90e81 (patch) | |
| tree | 0cbbaa0e7dc76e20d0340c5a2014ac898e65bd58 /dev-python/google-api-python-client/google-api-python-client-2.147.0.ebuild | |
| parent | 2f379ffb38f8a40827ac2f0c0e18c3349b2c05f1 (diff) | |
| download | gentoo-bbe03f19766167b539b90af2034340e61ed90e81.tar.gz gentoo-bbe03f19766167b539b90af2034340e61ed90e81.tar.bz2 gentoo-bbe03f19766167b539b90af2034340e61ed90e81.zip | |
dev-qt/qtwebengine: fix build with USE=-vaapi in 6.8+
Per the comment, already couldn't use system's libvpv when USE=vaapi
is enabled (this is intentionally enforced by the build system rather
than "broken"), and now USE=-vaapi fails to build in 6.8 with system's.
Seems like an easy fix but (even if fixed) feel it would be simpler
keep the same setup regardless of USE=vaapi until vaapi allows using
system's. I hardly test USE=-vaapi and missed that it broke, and I
assume this holds for upstream too.
qtwebengine does keep bundled libvpx either up to date or backports
security fixes, albeit bumps are less frequent and fixes could lag a
bit (not that we had a choice with USE=vaapi either way, unless drop
vaapi support).
As a small perk, it'll spare users from rebuilding qtwebengine on
libvpx subslot bumps which happen now and then.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Diffstat (limited to 'dev-python/google-api-python-client/google-api-python-client-2.147.0.ebuild')
0 files changed, 0 insertions, 0 deletions