Hi- While there was no official release of libvpx-0.9.8 (or 0.9.9), any version of libvpx based on sources after 11/04/2011 (when commit 142720521539d326ff7a31f17962c1d8c81196d4 (http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=commit;h=142720521539d326ff7a31f17962c1d8c81196d4) was merged) no longer has the VPX_CODEC_USE_INPUT_PARTITION #define in vpx/vpx_decoder.h, which ironically the Mozilla Firefox 10.0 ./configure script (generated by ${S}/configure.in) uses to detect that libvpx is at least at version 0.9.7. So, the Mozilla sourcecode needs to be modified (namely, configure.in needs to be changed), so that it no longer looks for that #define. I have checked ${S}/content/media/webm, and none of the nsWebM* files rely on VPX_CODEC_INPUT_PARTITON, so I believe it's safe to remove the check without patching mozilla-release or libvpx. I will submit a patch within the next couple of days if nobody else comes up with a fix. Thank you for your time and attention in this matter. -Robin K.
Actually, there's libvpx 1.0.0 (version bump request in bug 401871).
(In reply to comment #1) > Actually, there's libvpx 1.0.0 (version bump request in bug 401871). Yes, but it's susceptible to the same problem as the live ebuild when you try to compile Mozilla with WebM support. Namely, the API has been changed such that the check fails but the actual code that uses libvpx should compile. I'm going to test that by either forcing the configure.in to enable libvpx support w/o checking or to fix the check so it checks something unique to libvpx 0.9.7 AND still present in >=libvpx-1.0.0. -Robin K.
Hi- Builds with the patch added by Jory Pratt. Will wait for upstream to tag a release with commit e73a68477cfd, or if they don't fold it into the next revision bump (or, for some inexplicable reason, 11.0) I will submit an ebuild. The diff anarchy linked to effectively doesn't apply due the fact that the location of the configure macro file to be fixed is further in but otherwise is perfect and should be applied completely. I will attach an updated diff. -Robin K.
Created attachment 300873 [details, diff] Patch to require (correctly) libvpx-1.0.0 during the Firefox 10.0 build process Hi- This is the patch to add libvpx 1.0.0 support to Firefox 10.0, adapted from the diff derived from commit e73a68477cfd to the mozilla-central hg repository. While Firefox no longer builds against libvpx 0.9.7, it correctly builds against libvpx 1.0.0 and any version based on sources after November 4, 2011. -Robin K.
We will make a change to the ebuild once libvpx is in tree, I will need to push the maintainer of libvpx as we will need 1.0.0 in order to continue forward with fx-11
(In reply to comment #5) > We will make a change to the ebuild once libvpx is in tree, I will need to > push the maintainer of libvpx as we will need 1.0.0 in order to continue > forward with fx-11 you can proceed now, ff10 is actually broken with the bump
*** Bug 406305 has been marked as a duplicate of this bug. ***
*** Bug 406311 has been marked as a duplicate of this bug. ***
Upstream bug report has a patch, it changes the libvpx check to 1.0.0 citing various crash bugs as the reason. Looks like we should apply the patch from upstream & change our libvpx dep to >=1.0.0 https://bugzilla.mozilla.org/show_bug.cgi?id=722127
*** Bug 406327 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > Upstream bug report has a patch, it changes the libvpx check to 1.0.0 citing > various crash bugs as the reason. Looks like we should apply the patch from > upstream & change our libvpx dep to >=1.0.0 > > https://bugzilla.mozilla.org/show_bug.cgi?id=722127 It was for a month and still missing from version 10.0.1...
We need to get this applied, firefox & thunderbird are both broken on stable amd64
Same issue here with AMD64 and Gcc 4.5.3 When I emerged libvpx-1.0.0 firefox and earlybird stopped working, and now they don't build anymore.
attached patch works both for firefox and thunderbird and matches the upstream-version (just the line location is fixed)
same issue here (amd64 gcc 4.5.3)
*** Bug 406343 has been marked as a duplicate of this bug. ***
Why can't we just mask >=media-libs/libvpx-0.9.8 until the bug is fixed?
*** Bug 406313 has been marked as a duplicate of this bug. ***
(In reply to comment #17) > Why can't we just mask >=media-libs/libvpx-0.9.8 until the bug is fixed? Because of a security issue with older libvpx. You can build Firefox/Seamonky/Thunderbird with USE="-webm" for now, which is better than nothing.
I will handle this in a few hours. I am sorry that you have found breakage that could have been prevented in the first place.
I can confirm this with www-client/icecat-10.0-r1. Please fix it also. Thanks!
(In reply to comment #21) > I will handle this in a few hours. I am sorry that you have found breakage > that could have been prevented in the first place. Jory, to keep more people from hitting this I temporarily changed the dependency in the firefox-10 ebuilds ... 01 Mar 2012; Andreas K. Huettel <dilfridge@gentoo.org> firefox-10.0.1.ebuild, firefox-10.0.1-r1.ebuild: Temporarily require ~libvpx-0.9.7, as quick workaround for bug 401985
Am I the only one who thinks we should just make >=libvpx-1.0.0 a dependency to build firefox and merge the patch from upstream? If I went along and downgraded I would then need to recompile not only firefox but chromium as well.
(In reply to comment #24) > Am I the only one who thinks we should just make >=libvpx-1.0.0 a dependency > to build firefox and merge the patch from upstream? > > If I went along and downgraded I would then need to recompile not only > firefox but chromium as well. I have rolled the new patchset already, I am ready to commit it, the problem is ppc was drop'd from libvpx which I am not sure I want to drop in fx.
(In reply to comment #23) > (In reply to comment #21) > > I will handle this in a few hours. I am sorry that you have found breakage > > that could have been prevented in the first place. > > Jory, to keep more people from hitting this I temporarily changed the > dependency in the firefox-10 ebuilds ... > > > 01 Mar 2012; Andreas K. Huettel <dilfridge@gentoo.org> > firefox-10.0.1.ebuild, > firefox-10.0.1-r1.ebuild: > Temporarily require ~libvpx-0.9.7, as quick workaround for bug 401985 same problem occurs with the r1 ebuild, however, saving the above patch to /etc/portage/patches/www-client/firefox/ allows the build to complete
Created attachment 303787 [details, diff] thunderbird/firefox libvpx-1.0.0 support For those who can not wait, I am attaching the working patch here, soon as I get this ppc/ppc64 issue resolved with libvpx we will get this committed to tree.
y u people no patch the crashed build in /var/tmp/portage by hand find . -name configure -exec sed -e 's/VPX_CODEC_USE_INPUT_PARTITION/VPX_CODEC_USE_INPUT_FRAGMENTS/' {} \; and then run ebuild firefox-10.0.1.ebuild qmerge ? (until official patch is in portage)
(In reply to comment #28) > y u people no patch the crashed build in /var/tmp/portage by hand > > find . -name configure -exec sed -e > 's/VPX_CODEC_USE_INPUT_PARTITION/VPX_CODEC_USE_INPUT_FRAGMENTS/' {} \; > > and then run ebuild firefox-10.0.1.ebuild qmerge > > ? (until official patch is in portage) Firefox/Thunderbird-10.0.1-r1 are in the tree, amd64 will get stable keywords asap, sorry for the problems.
All mozilla products are fixed. amd64 as I stated earlier will get proper keywords to prevent breakage any further problems.
fixed on amd64
(In reply to comment #31) > fixed on amd64 I can confirmed it works on amd64 stable.
*** Bug 406981 has been marked as a duplicate of this bug. ***