Summary: | www-client/chromium-58.0.3026.3 fails with system libvpx (VPXD_GET_LAST_QUANTIZER) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Paweł Hajdan, Jr. (RETIRED) <phajdan.jr> |
Component: | Current packages | Assignee: | Chromium Project <chromium> |
Status: | RESOLVED OBSOLETE | ||
Severity: | enhancement | CC: | arthur, dschridde+gentoobugs, herrtimson, jouni.kosonen, nordaux |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugs.chromium.org/p/chromium/issues/detail?id=697843 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log for amd64 keyword stabilized re-test
Updated libvpx 1.7.0 ebuild needed to fix this bug. |
Description
Paweł Hajdan, Jr. (RETIRED)
2017-03-02 10:08:20 UTC
Created attachment 499590 [details]
build.log for amd64 keyword stabilized re-test
package.use.mask profile entry led me to this bug
suspected keywording on libvpx-1.6.1
performed followup test using stable
Updated testing result:
amd64 keyword-stablized media-libs/libvpx-1.5.0
amd64 keyword-stablized www-client/chromium-62.0.3202.62
chromium with USE +system-libpx still fails to build
vpx_codec_control() error persists, same as above.
(attached build.log.xz)
Will this ever work? If I understand it correctly, libvpx is developed inside the chromium project. Even the latest release (1.6.1) is far behind the bundled code. So wouldn't it be better to drop the system-libvpx option? To me it seems not worth the grief, especially since the library is not that big. I just made an ebuild libvpx-9999 by modifying the existing one to have at the top... ``` DESCRIPTION="WebM VP8 and VP9 Codec SDK" HOMEPAGE="http://www.webmproject.org" if [[ ${PV} == *9999* ]]; then inherit git-r3 EGIT_REPO_URI="https://chromium.googlesource.com/webm/${PN}.git" elif [[ ${PV} == *pre* ]]; then SRC_URI="mirror://gentoo/${P}.tar.bz2" KEYWORDS="~alpha ~amd64 ~arm ~ia64 ~ppc ~ppc64 ~x86 ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux" else SRC_URI="http://webm.googlecode.com/files/${PN}-v${PV}.tar.bz2" KEYWORDS="~alpha ~amd64 ~arm ~ia64 ~ppc ~ppc64 ~x86 ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux" S="${WORKDIR}/${PN}-v${PV}" fi SRC_URI="${SRC_URI} test? ( mirror://gentoo/${PN}-testdata-${LIBVPX_TESTDATA_VER}.tar.bz2 )" ``` And unmasked the use flag profile/package.use.mask/04-lmc:>=www-client/chromium-63.0.3239.132 -system-libvpx Maybe the libvpx guys can add a 9999 ebuild and you could modify the gentoo ebuild to rquire libvpx-9999 to solve this problem. Works for me. Firefox/ffmpeg and others can use libvpx-9999 without any problems too. It doesn't look like google is going to release a libvpx anytime soon. This bug has been open a year so seems like the best solution for those who want to have less duplicated libraries. Luke Created attachment 517706 [details]
Updated libvpx 1.7.0 ebuild needed to fix this bug.
There is already released the libvpx 1.7.0 version on upstream that is fully compatible with latest chromium ebuild from the portage tree. I've attached the updated ebuild on previous comment. should not the use mask be removed now? # Pawel Hajdan jr <phajdan.jr@gentoo.org> (2017-03-02) # Known build issue with system libvpx: # https://bugs.gentoo.org/show_bug.cgi?id=611394 >=www-client/chromium-58.0.3026.3 system-libvpx USE=system-libvpx was removed. |