I'm unable to compile chromium 44 with the widevine use flag. I can compile chromium 32 and 33 with widevine. I can compile any of the versions without the widevine use flag. Reproducible: Always Steps to Reproduce: 1. Enable the widevine use flag for www-client/chromium 2. Unmask www-client/chromium-44 3. emerge chromium Actual Results: Failed Patch: chromium-widevine-1.4.8.813.patch ! ( /var/tmp/portage/www-client/chromium-44.0.2376.0/temp/chromium-widevine-1.4.8.813.patch ) Include in your bugreport the contents of: /var/tmp/portage/www-client/chromium-44.0.2376.0/temp/chromium-widevine-1.4.8.813.patch.out ERROR: www-client/chromium-44.0.2376.0::gentoo failed (prepare phase): Failed Patch: chromium-widevine-1.4.8.813.patch! Call stack: ebuild.sh, line 93: Called src_prepare environment, line 5242: Called epatch '/var/tmp/portage/www-client/chromium-44.0.2376.0/temp/chromium-widevine-1.4.8.813.patch' environment, line 1838: Called die The specific snippet of code: die "Failed Patch: ${patchname}!"; Expected Results: chromium successfully compiles and installs
Created attachment 401940 [details] build-log
Created attachment 401942 [details] environment
Created attachment 401944 [details] emerge --info '=www-client/chromium-44.0.2376.0::gentoo'
Created attachment 401946 [details] emerge -pqv '=www-client/chromium-44.0.2376.0::gentoo'
Created attachment 401948 [details] /var/tmp/portage/www-client/chromium-44.0.2376.0/temp/chromium-widevine-1.4.8.813.patch.out
Created attachment 402664 [details] build.log after mending patch Just naïvely editing the patch to match the three search/replacements for 'branding == "Chrome"' to 'branding == "Chromium"' and then building it, doesn't work either, you end up with !!! doexe: out/Release/libwidevinecdmadapter.so does not exist Adding my build.log
I removed widevine support from latest 44.x ebuild. Please do not add code to ebuild which applies patches conditionally.
(In reply to Paweł Hajdan, Jr. from comment #7) > I removed widevine support from latest 44.x ebuild. Please do not add code > to ebuild which applies patches conditionally. Sorry for letting that one slip through. I'm not personally interested in maintaining that patch anyway.
Is there still interest in getting Widevine working in some other way?
I really hope so, widevine is a very important feature. Lots of HTPC and couch surfing devices would suffer if there was no Netflix support :P
(In reply to Mike Lothian from comment #9) > Is there still interest in getting Widevine working in some other way? Ideally, we need a patch that can be applied upstream. Nobody wants to maintain this patch at the distro level.
At the very least it should be possible to unconditionally apply the patch.
If the current patch was always applied would it affect the build if the widevine binary was unavailable? I.E. are we making the patch conditional when it doesn't need to be?
(In reply to Mike Lothian from comment #13) > If the current patch was always applied would it affect the build if the > widevine binary was unavailable? I.E. are we making the patch conditional > when it doesn't need to be? Probably... however, do I correctly presume the logic behind this is, you'd like src_prepare to be as deterministic as possible -- kind of a principle of least surprise type of thing? If so, be advised that this particular patch was not applied but patched (we patched the patch, and then applied the patched patch... kinda ugly I'd say... Meanwhile, as of 44.0.2403.42 or thereabouts, the widevine stuff was upstreamed. So, honestly, it's super-annoying that Netflix is broken right now, but probably not worth the effort to fix in gx86, as it will (almost, see below) fix itself if we just wait a few days. Of course, upstream, the feature is for no good reason I can see tied to "branding". Perhaps this was put there because Larry Paige owed one to (RIAA boss) Cary Sherman and (Netflix CEO) Reed Hastings after breaking their long-standing circle jerk tradition and refusing to eat the biscuit (Larry may have tried to claim he'd "had asparagus last night" but those guys are no fools). So once those versions trickle down to gx86, gx86 should just discreetly and without fanfare fix that little upstream branding bug, and pray the bad guys never figure out that this trivial fragment of open-source glue enables people who compiled their own browsers to uh... you know.... do that "N..." thing they probably don't realize we're able to do :)
(In reply to Mike Lothian from comment #13) > If the current patch was always applied would it affect the build if the > widevine binary was unavailable? I.E. are we making the patch conditional > when it doesn't need to be? OK, looking at how this looks now upstream, the problem is more-or-less unchanged. We no longer need to borrow the widevine-cdm stuff from elsewhere, which is nice, but the need for the patch is the same as before. Also, we can't/mustn't apply that patch, at least, not as currently structured, unless www-plugins/chrome-binary-plugins[widevine] is installed. The reason is, we need to pull the version of widevine to know how to patch third_party/widevine/cdm/widevine_cdm_version.h; otherwise, the patch would simply turn valid code into invalid code that cannot compile... OK, idea. Currently we o determine the widevine version (let's call it W_VERSION) o patch ${FILESDIR}/${PN}-widevine.patch with the version of the widevine plugin present at build-time o store the patched patch into ${T}/${PN}-widevine-${W_VERSION}.patch o apply ${T}/${PN}-widevine-${W_VERSION}.patch We follow these contortions because the patch does two things: (a) Update the version dependency in third_party/widevine/cdm/widevine_cdm_version.h (b) Correctly remove the laughable upstream WONTFIX that prevents chromium from running widevine-cdm for no technical reason whatsoever. (a) is only meaningful if the useflag is set -- otherwise, there is no reason to assume that any version of widevine will be installed. (b) is meaningful always, that's just an upstream bug due to the aforementioned circle-jerk problem. If we change the patch do do only (b), by dropping the first hunk, then we can adjust the code to achieve the exact same result as follows: o apply ${FILESDIR}/${PN}-widevine.patch unconditionally o use widevine && determine widevine version as before o use widevine && patch third_party/widevine/cdm/widevine_cdm_version.h via sed script Seems more reasonable, no?
(In reply to Gregory Turner from comment #15) > (In reply to Mike Lothian from comment #13) > > If the current patch was always applied would it affect the build if the > > widevine binary was unavailable? I.E. are we making the patch conditional > > when it doesn't need to be? > > OK, looking at how this looks now upstream, the problem is more-or-less > unchanged. We no longer need to borrow the widevine-cdm stuff from > elsewhere, which is nice, but the need for the patch is the same as before. > > Also, we can't/mustn't apply that patch, at least, not as currently > structured, unless > > www-plugins/chrome-binary-plugins[widevine] > > is installed. The reason is, we need to pull the version of widevine to > know how to patch third_party/widevine/cdm/widevine_cdm_version.h; > otherwise, the patch would simply turn valid code into invalid code that > cannot compile... > > OK, idea. > > Currently we > > o determine the widevine version (let's call it W_VERSION) > o patch ${FILESDIR}/${PN}-widevine.patch with the version of > the widevine plugin present at build-time > o store the patched patch into ${T}/${PN}-widevine-${W_VERSION}.patch > o apply ${T}/${PN}-widevine-${W_VERSION}.patch > > We follow these contortions because the patch does two things: > > (a) Update the version dependency in > third_party/widevine/cdm/widevine_cdm_version.h > (b) Correctly remove the laughable upstream WONTFIX that prevents chromium > from running widevine-cdm for no technical reason whatsoever. > > (a) is only meaningful if the useflag is set -- otherwise, there is no > reason to assume that any version of widevine will be installed. (b) is > meaningful always, that's just an upstream bug due to the aforementioned > circle-jerk problem. > > If we change the patch do do only (b), by dropping the first hunk, then we > can adjust the code to achieve the exact same result as follows: > > o apply ${FILESDIR}/${PN}-widevine.patch unconditionally > o use widevine && determine widevine version as before > o use widevine && patch third_party/widevine/cdm/widevine_cdm_version.h > via sed script > > Seems more reasonable, no? This leaves only the problem that prompted the original bug report -- the existing patch no longer applies. Let me see what I can do about that, I think it's pretty easy to fix up. All of the above contortions are just to eliminate the tacked-on (but, IMO, reasonable) objections that seem to have stymied this bug.
Come to think of it, the remainder of the patch could also be reduced to this sed-script, which, if I'm not mistaken, could be run unconditionally at src_prepare-time. # build widevine_cdm as appropriate even though it's "unsupported" sed -e 's/"Chrome"/"Chromium"/g' \ -i third_party/widevine/cdm/widevine_cdm.gyp
Created attachment 405394 [details, diff] chromium-widevine-ebuild.patch Patches to www-client/chromium-44.0.2403.30.ebuild; it could be quick-and-dirty-tested like: 1) cd ${PORTDIR}/www-client/chromium 2) cp chromium-44.0.2403.30.ebuild chromium-44.0.2403.52.ebuild 3) patch -p0 < /tmp/chromium-widevine-ebuild.patch 4) ebuild chromium-44.0.2403.52 digest This re-enables the widevine useflag and widevine-cdm building. It works mostly as before, but all the code-patching is done via sed scripts, rather than "epatch" invocations, in the interest of maintainability/elegance.
Created attachment 405396 [details, diff] chromium-widevine-ebuild.patch This is a noop update to my original patch which had copy-pasted some old-EAPI-ish code from gentoo-x86 like: doexe ... || die The || die is no longer neccesary so I just dropped that. It's otherwise identical.
(In reply to Gregory Turner from comment #18) > Created attachment 405394 [details, diff] [details, diff] > chromium-widevine-ebuild.patch > > Patches to www-client/chromium-44.0.2403.30.ebuild; it could be > quick-and-dirty-tested like: > > 1) cd ${PORTDIR}/www-client/chromium > 2) cp chromium-44.0.2403.30.ebuild chromium-44.0.2403.52.ebuild Just a note -- this revbump is an essential part of the recipe. If you try to omit it and patch .30 it won't work.
(In reply to Gregory Turner from comment #18) > Created attachment 405394 [details, diff] [details, diff] > chromium-widevine-ebuild.patch > > Patches to www-client/chromium-44.0.2403.30.ebuild; it could be > quick-and-dirty-tested like: > > 1) cd ${PORTDIR}/www-client/chromium > 2) cp chromium-44.0.2403.30.ebuild chromium-44.0.2403.52.ebuild > 3) patch -p0 < /tmp/chromium-widevine-ebuild.patch > 4) ebuild chromium-44.0.2403.52 digest > > This re-enables the widevine useflag and widevine-cdm building. It works > mostly as before, but all the code-patching is done via sed scripts, rather > than "epatch" invocations, in the interest of maintainability/elegance. Fails to compile for me. Looks like an unrelated problem: https://code.google.com/p/chromium/issues/detail?id=502260. I'll see what I can figure out about it.
Created attachment 405446 [details, diff] chromium-backport-blink-r195908.patch Dependency of my patched ebuild. For some reason, the 44.0.2403.52 tarball as distributed by Google seems to be a bit mixed up about a few third-party dependency issues; this fixes two such problems.
Created attachment 405448 [details, diff] chromium-backport-webrtc-7272a2ba.patch Dependency of my patched ebuild. For some reason, the 44.0.2403.52 tarball as distributed by Google seems to be a bit mixed up about a few third-party dependency issues; this fixes one such problem.
Created attachment 405450 [details, diff] chromium-ebuild-widevine-hack-v5.patch Updated patch to ebuild containing just the widevine stuff (and epatch invocations for the two required patches). So, to make a quick-and-dirty test, one could save this patch as /tmp/chromium-ebuild-widevine-hack-v5.patch and: 1) cd ${PORTDIR}/www-client/chromium 2) cp chromium-44.0.2403.30.ebuild chromium-44.0.2403.52.ebuild 3) patch -p0 < /tmp/chromium-ebuild-widevine-hack-v5.patch 4) wget 'https://547630.bugs.gentoo.org/attachment.cgi?id=405446' -O files/chromium-backport-blink-r195908.patch 5) wget 'https://547630.bugs.gentoo.org/attachment.cgi?id=405448' -O files/chromium-backport-webrtc-7272a2ba.patch 6) ebuild chromium-44.0.2403.52.ebuild digest
Ugh, the old-EAPI-ish "doexe ... || die" snuck back in. Anyhow, the ebuild is absolutely full of this type of code, it should all be dropped. All helper functions die unless invoked as nonfatal as of EAPI4. Whoever is maintaining this ebuild should read: https://devmanual.gentoo.org/ebuild-writing/eapi/#eapi=4
Keep your comments to the issue at hand; I don't need a lecture on eapi usage.
(In reply to Mike Gilbert from comment #26) > Keep your comments to the issue at hand; I don't need a lecture on eapi > usage. OK, fair 'nuf but it was meant as more of an excuse for my own laziness than a lecture... Sort of analogous to stuffing your litter inside some existing litter you found on the street, on the basis that you won't be contributing anything to the labor required to pick it up.
Just figured out that my clever idea has the slight drawback of not working. With USE=-widevine, everything goes to poop. I feel like I've been totally gyp'ed. :P I should have read comment 6 more carefully. I guess, the only sane way forward is to teach myself how to correctly add a global gyp frob. As presently formulated, my "improvements" only make one of the patches conditional, and that's the one that's broken. :) Whether the patch is achieved via sed scripting or GNU patch is really immaterial -- if both patches were made use-flag-conditional, then all I would have achieved here would have been to dust the problem under the carpet.
Created attachment 405704 [details, diff] chromium-ebuild-widevine-v6.patch This revbump does not solve the problem documented in comment 28, but it hopefully lays down a nice foundation on which to do so. It eliminates the need for those backport/cherry-pick patches, which is nice for the S/N of this bug (upstream fixed it, I guess). It has only two one-line changes to the ebuild, which don't pertain specifically to widevine (requisites of the revbump afaics). It also adds a recyclable HOWTO-try-it blurb at the beginning of the patch, which can hopefully get mostly cut-pasted into future revs, sparing the bug from repeated boilerplate variants going forward. Also, this version, unlike the last, should work when USE=-widevine.
Created attachment 405706 [details, diff] chromium-ebuild-widevine-v7.patch rev7: Drop the ebuild-header hunk from the patch, since that bit will break the work I did trying to make this merge-conflict-resistant.
Created attachment 405714 [details, diff] chromium-widevine-ebuild-v8.patch Rebase against upstream's latest ebuild.
Created attachment 405762 [details, diff] chromium-widevine-2403.patch Goes in ${FILESDIR} as chromium-widevine-2403.patch; it's a prerequisite of the upcoming -r9 ebuild revision.
Created attachment 405764 [details, diff] chromium-widevine-ebuild-r9.patch Fix the comment 28 problem by patching unconditionally and directing the expression of the use-flag through the gyp machinery. Also, prevent the widevine use-flag from being activated on arm and any future non-whitelisted ARCH'es (which, I presume, perhaps incorrectly, would be of no practical utility). Finally, it re implements the versioning sed-script. The new implementation ends up running the exact same code as the old, but is hopefully more legible in the ebuild. This revision doesn't have any glaring problems I'm aware of, so for those of you who may be following this bug, but waiting for me to get my shit together, I'd appreciate your taking a look now.
Created attachment 405766 [details, diff] chromium-widevine-ebuild-r10.patch noop update (just fixes omission in "howto")
Created attachment 405820 [details, diff] chromium-widevine-ebuild-r11.patch Mostly-noop spin fixing some slightly sloppy usage of die that appeared in my previous patches.
(In reply to Gregory Turner from comment #35) > Created attachment 405820 [details, diff] [details, diff] > chromium-widevine-ebuild-r11.patch > > Mostly-noop spin fixing some slightly sloppy usage of die that appeared in > my previous patches. Thank you for the patch, I'm trying it out right now (on Funtoo). One immediate problem, though: #define WINEVINE_CDM_VERSION_STRING in your patch should instead read #define WIDEVINE_CDM_VERSION_STRING
(In reply to Moritz Maxeiner from comment #36) > (In reply to Gregory Turner from comment #35) > > Created attachment 405820 [details, diff] [details, diff] [details, diff] > problem: > #define WINEVINE_CDM_VERSION_STRING > in your patch should instead read > #define WIDEVINE_CDM_VERSION_STRING Heh, no surprise since I had to read the above about twelve times before I could figure out what the difference was! Thought I had fixed that but I guess it crept back in somehow. Will fix but afk for a bit so may take a few days.
(In reply to Greg Turner from comment #37) > (In reply to Moritz Maxeiner from comment #36) > > (In reply to Gregory Turner from comment #35) > > > Created attachment 405820 [details, diff] [details, diff] [details, diff] [details, diff] > > problem: > > #define WINEVINE_CDM_VERSION_STRING > > in your patch should instead read > > #define WIDEVINE_CDM_VERSION_STRING > > Heh, no surprise since I had to read the above about twelve times before I > could figure out what the difference was! Thought I had fixed that but I > guess it crept back in somehow. Will fix but afk for a bit so may take a > few days. After testing it with a video-on-demand provider, it seems to be working perfectly fine. I will post the adapted patch to Funtoo's bugtracker.
chromium-widevine-ebuild-r11.patch applies almost cleanly to chromium-45.0.2454.6.ebuild too (the last hunk does not apply, and that is easily mendable by removing that libffmpegsumo.so line), and chromium-widevine-2403.patch still works. Just remember Moritz Maxeiner's comment about s/winevine/widevine/.
Just wondered if there was an ebuild in any overlays? I'd be happy to add it to mine if there isn't
This may be a stupid question, but is it actually necessary for WIDEVINE_CDM_VERSION_STRING to be correct? This value is only used for setting the description and version strings for widevine in Chromium's internal list of plugins (i.e. the plugins shown by chrome://plugins). I am unsure whether these values are actually used for anything other than display purposes. Alternatively, it may be possible to patch the ComputeBuiltInPlugins function in chrome_content_client.cc to read the widevine.version file. This function is the only place where WIDEVINE_CDM_VERSION_STRING is used.
Even if Chromium doesn't use these values itself, the description is exposed to web pages through the navigator.plugins array, so I suppose it's possible that web pages could be parsing the version out of that.
Created attachment 407634 [details, diff] chromium-widevine-ebuild-r12.patch Update to patch against latest and greatest chromium ebuild code. Drop all the instructions I was maintaining at the beginning, as the current version in portage works just fine on its own without any upgrade requirements likely to create confusion. n.b.: untested, building this now, I'll report back when it works.
(In reply to Ari Entlich from comment #42) > Even if Chromium doesn't use these values itself, the description is exposed > to web pages through the navigator.plugins array, so I suppose it's possible > that web pages could be parsing the version out of that. It certainly seem better to tell the truth than to lie. The "figure it out dynamically" idea seems pretty sexy, but I'm not going to bother figuring out how to do it. It does create a nasty reverse dependency: chromium should be rebuilt every time chromium-binary-plugins is updated, if the widevine flag is enabled. Given that the consequences of ignoring that dependency are unlikely to be severe, however, I think ignoring it until it causes a problem for somebody, as I presume we always did historically, seems like a reasonable starting point.
(In reply to Gregory Turner from comment #44) > (In reply to Ari Entlich from comment #42) > > Even if Chromium doesn't use these values itself, the description is exposed > > to web pages through the navigator.plugins array, so I suppose it's possible > > that web pages could be parsing the version out of that. > > It certainly seem better to tell the truth than to lie. The "figure it out > dynamically" idea seems pretty sexy, but I'm not going to bother figuring > out how to do it. > > It does create a nasty reverse dependency: chromium should be rebuilt every > time chromium-binary-plugins is updated, if the widevine flag is enabled. > > Given that the consequences of ignoring that dependency are unlikely to be > severe, however, I think ignoring it until it causes a problem for somebody, > as I presume we always did historically, seems like a reasonable starting > point. ... on the other hand once we've made that concession, the argument for lying rather than telling the truth seems stronger. Anyone else have an opinion?
(In reply to Gregory Turner from comment #45) > (In reply to Gregory Turner from comment #44) > > It certainly seem better to tell the truth than to lie. The "figure it out > > dynamically" idea seems pretty sexy, but I'm not going to bother figuring > > out how to do it. > > > > It does create a nasty reverse dependency: chromium should be rebuilt every > > time chromium-binary-plugins is updated, if the widevine flag is enabled. > > > > Given that the consequences of ignoring that dependency are unlikely to be > > severe, however, I think ignoring it until it causes a problem for somebody, > > as I presume we always did historically, seems like a reasonable starting > > point. > > ... on the other hand once we've made that concession, the argument for > lying rather than telling the truth seems stronger. Anyone else have an > opinion? I definitely agree that it seems better to have a real version than to not have one. I've already looked into the "figure it out dynamically" approach a little bit, and I think it would be fairly trivial. I'd be willing to produce a patch for review. I think it would be possible to apply this patch in all cases. It wouldn't be possible to upstream it though, since the widevine.version file is entirely a Gentoo invention. However, why would chromium need to be rebuild every time with this approach? Since it would be dynamically retrieving the version from a file installed by the chrome-binary-plugins package, rebuilding chromium should not result in any differences. It seems to me like the old approach was the one that required constantly rebuilding chromium, since the version would be embedded in the chromium binary. This is one reason that I'd prefer to read the widevine.version file - the chromium and chrome-binary-plugins packages could potentially be updated independently without the versions being incorrect.
(In reply to Gregory Turner from comment #43) > Created attachment 407634 [details, diff] [details, diff] > chromium-widevine-ebuild-r12.patch > > Update to patch against latest and greatest chromium ebuild code. Drop all > the instructions I was maintaining at the beginning, as the current version > in portage works just fine on its own without any upgrade requirements > likely to create confusion. > > n.b.: untested, building this now, I'll report back when it works. Compiled but VOD fails. Maybe I need to update to synchronize versions with chrome-binary-plugins after all :(
(In reply to Ari Entlich from comment #46) > (In reply to Gregory Turner from comment #45) > > (In reply to Gregory Turner from comment #44) > > > It certainly seem better to tell the truth than to lie. The "figure it out > > > dynamically" idea seems pretty sexy, but I'm not going to bother figuring > > > out how to do it. > > > > > > It does create a nasty reverse dependency: chromium should be rebuilt every > > > time chromium-binary-plugins is updated, if the widevine flag is enabled. > > > > > > Given that the consequences of ignoring that dependency are unlikely to be > > > severe, however, I think ignoring it until it causes a problem for somebody, > > > as I presume we always did historically, seems like a reasonable starting > > > point. > > > > ... on the other hand once we've made that concession, the argument for > > lying rather than telling the truth seems stronger. Anyone else have an > > opinion? > > I definitely agree that it seems better to have a real version than to not > have one. I've already looked into the "figure it out dynamically" approach > a little bit, and I think it would be fairly trivial. I'd be willing to > produce a patch for review. I think it would be possible to apply this patch > in all cases. It wouldn't be possible to upstream it though, since the > widevine.version file is entirely a Gentoo invention. That's great, please do! > However, why would chromium need to be rebuild every time with this > approach? Since it would be dynamically retrieving the version from a file > installed by the chrome-binary-plugins package, rebuilding chromium should > not result in any differences. It seems to me like the old approach was the > one that required constantly rebuilding chromium, since the version would be > embedded in the chromium binary. This is one reason that I'd prefer to read > the widevine.version file - the chromium and chrome-binary-plugins packages > could potentially be updated independently without the versions being > incorrect. I was referring to the old approach, that hard-codes the values into the library. Dynamic detection as you are proposing solves that problem.
(In reply to Gregory Turner from comment #47) > (In reply to Gregory Turner from comment #43) > > Created attachment 407634 [details, diff] [details, diff] [details, diff] > > chromium-widevine-ebuild-r12.patch > > > > Update to patch against latest and greatest chromium ebuild code. Drop all > > the instructions I was maintaining at the beginning, as the current version > > in portage works just fine on its own without any upgrade requirements > > likely to create confusion. > > > > n.b.: untested, building this now, I'll report back when it works. > > Compiled but VOD fails. Maybe I need to update to synchronize versions with > chrome-binary-plugins after all :( Hmm. Perhaps I spoke too soon. Having changed nothing except to fix the problem referenced in comment #36, the 44.0.2403.89 build based on my most recent -r12 patch fails to load Netflix. I was guessing this was just due to the differing versions of chrome-binary-plugins and chromium in portage, but, when I try http://www.dash-player.com/demo/drm-and-protection/ it shows that widevine-cdm is working. Furthermore, if I load Netflix in chrome-44.0.2403.89, it works. So, I tried forcing the exact agent string that chrome is using in chromium. Still no dice. This suggests that, somehow, although my patch is still working, its principal purpose may have been thwarted by some other means. Possible explanations, including some head-slappers, I have yet to rule out: * some wacky issue specific to my ~/.config/chromium * fixing the comment #36 problem ("WINEVINE" typo) breaks Netflix somehow * something wacky to do with my particular Netflix account Can someone else with a Netflix Instant subscription (perhaps Moritz Maxeiner or someone for whom it was previously working) try this version and let me know what happens for them? I'm attempting a 44.0.2403.107 build now, just to fully disconfirm the hypothesis that it somehow boils down to differing versions of chromium and chrome-binary-plugins.
(In reply to Gregory Turner from comment #49) > (In reply to Gregory Turner from comment #47) > > (In reply to Gregory Turner from comment #43) > > > Created attachment 407634 [details, diff] [details, diff] [details, diff] [details, diff] > > > chromium-widevine-ebuild-r12.patch > > > > > > Update to patch against latest and greatest chromium ebuild code. Drop all > > > the instructions I was maintaining at the beginning, as the current version > > > in portage works just fine on its own without any upgrade requirements > > > likely to create confusion. > > > > > > n.b.: untested, building this now, I'll report back when it works. > > > > Compiled but VOD fails. Maybe I need to update to synchronize versions with > > chrome-binary-plugins after all :( > > Hmm. Perhaps I spoke too soon. Having changed nothing except to fix the > problem referenced in comment #36, the 44.0.2403.89 build based on my most > recent -r12 patch fails to load Netflix. OK, the culprit was Privacy Badger blocking tracker cookies to assets.nflxext.com (no clue why that isn't also happening in binary chrome but, w/e, it's not related to my patches). So all is well, Netflix works.
(In reply to Ari Entlich from comment #46) > I've already looked into the "figure it out dynamically" approach > a little bit, and I think it would be fairly trivial. I'd be willing to > produce a patch for review. I suppose we could also just punt on the whole thing, like so: http://bazaar.launchpad.net/~saiarcot895/chromium-browser/chromium-browser.wily.beta/view/head:/debian/patches/fix_building_widevinecdm_with_chromium.patch Presumably this hasn't been causing any trouble in the wild.
It looks like Google have given up trying to stop us building Chromium with Widevine support - looks like we don't need your patch any more - I'm not sure how much of the rest of the tweaks are still needed
(In reply to Mike Lothian from comment #52) > It looks like Google have given up trying to stop us building Chromium with > Widevine support - looks like we don't need your patch any more - I'm not > sure how much of the rest of the tweaks are still needed For those of us who missed the press release, perhaps you should let us know what makes you think so?
From the widevine_cdm.gym: 'variables': { # Allow widevinecdmadapter to be built in Chromium. 'variables': { 'enable_widevine%': 0 currently my compilation is failing with: ../../chrome/common/chrome_content_client.cc: In function ‘void {anonymous}::ComputeBuiltInPlugins(std::vector<content::PepperPluginInfo>*)’: ../../chrome/common/chrome_content_client.cc:177:34: error: ‘WIDEVINE_CDM_VERSION_STRING’ was not declared in this scope WIDEVINE_CDM_VERSION_STRING + ")"; ^ will take a look at that now
(In reply to Mike Lothian from comment #54) > From the widevine_cdm.gym: > > 'variables': { > # Allow widevinecdmadapter to be built in Chromium. > 'variables': { > 'enable_widevine%': 0 > > currently my compilation is failing with: > > ../../chrome/common/chrome_content_client.cc: In function ‘void > {anonymous}::ComputeBuiltInPlugins(std::vector<content::PepperPluginInfo>*)’: > ../../chrome/common/chrome_content_client.cc:177:34: error: > ‘WIDEVINE_CDM_VERSION_STRING’ was not declared in this scope > WIDEVINE_CDM_VERSION_STRING + ")"; > ^ > > will take a look at that now I'm preparing a patch which will fix this.
Created attachment 407854 [details, diff] chromium-widevine-version.patch Sorry for the delay guys - I had to test with the widevine flag enabled and disabled, and compiling Chromium takes over 2 hours for me. Here is the patch that I came up with for using the widevine.version file as the source of the version. I don't know whether this is small enough for people to be comfortable maintaining here, but it does have the benefit that it can be applied regardless of the state of the widevine flag.
Ari are you saying without Gregory Turner's modified ebuild or his patch that this does the job and videos are playing in netflix? Thank you. And thanks to Gregory Turner too, we've been following his progress (and using it too!) over at Funtoo for a couple of weeks now.
Created attachment 407862 [details, diff] chromium-44.0.2403.89.ebuild.patch And here's the ebuild patch. This is basically just Gregory Turner's ebuild patch minus the stuff for patching the widevine_cdm_version.h file and the stuff for patching the build system. I think Mike Lothian is correct that we no longer need to patch the build system. Since a recent commit[1], enabling widevine with a Chromium build will build a "stub CDM" for the purposes of correctly linking libwidevinecdmadapter.so. There is also a special widevine_cdm_version.h file for this sort of stub build. This means that we no longer need to move libwidevinecdm.so into the source tree in order for the build to succeed, nor do we need to patch/write our own widevine_cdm_version.h file. There is an upstream bug report[2] already for the issue that my patch fixes, i.e. the need to deal with WIDEVINE_CDM_VERSION_STRING somehow. My patch (I think) solves this issue for Gentoo, but it is unfortunately dependent on the installation of a widevine.version file. I have commented on the upstream bug report with what I think would be a good way to solve this in a more general way. [1] https://chromium.googlesource.com/chromium/src/+/534d59853e0803ee61e6c8a6a4ceacac44df6843 [2] https://code.google.com/p/chromium/issues/detail?id=473866
(In reply to Mike Johnson from comment #57) > Ari are you saying without Gregory Turner's modified ebuild or his patch > that this does the job and videos are playing in netflix? Thank you. And > thanks to Gregory Turner too, we've been following his progress (and using > it too!) over at Funtoo for a couple of weeks now. Unfortunately I don't actually have a Netflix account (then why am I doing this, you ask? I wish I knew...) , so I actually can't say for sure that it makes Netflix work. What I can say is that it makes the build succeed and makes Widevine show up in chrome://plugins with the correct version. Someone else will have to test whether it actually works with Netflix. My apologies - maybe I should have been more up front about this. Please let me know what you discover. I hope it works!
Created attachment 407864 [details, diff] chromium-widevine-version-simple.patch Here's an (untested) alternate version of the patch which is much simpler and should work just as well as the larger one. I THINK the only downside to this version is that the Widevine version that is shown in chrome://plugins and in navigator.plugins will not be correct. My little editorial can be replaced, of course, if it is deemed to be too inflammatory or something. :) The approach that Gregory discovered in comment #51 is also worth considering. It might even be better than this patch, since it completely removes the requirement to define WIDEVINE_CDM_VERSION_STRING rather than simply setting it to whatever nonsense the programmer was thinking at that moment ([1] and this patch, for example). If my larger patch is too much for the chromium team to swallow, one of these two approaches would certainly be better than nothing (although I still think that a real version is a valuable thing to have). [1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/chromium&id=6d0746b2f948c604f50505c97d571e0e6e668561#n71
:) Same here Ari, I'm doing it for a friend far away, who incidentally is leaving on holiday so I too am out of the loop for awhile. I will say though, just today I updated their chromium to 45.0.2454.15, the hand-done ebuild here: https://bugs.funtoo.org/browse/FL-2622 And using the version-independent-widevine.patch there as well (which is really Gregory's patch from about 7/11, slightly modified). My friend just checked, working fine. So not sure what all these revisions are about. Anyhow, there's the facts.
(In reply to Ari Entlich from comment #60) > Created attachment 407864 [details, diff] [details, diff] > chromium-widevine-version-simple.patch > > Here's an (untested) alternate version of the patch which is much simpler > and should work just as well as the larger one. I THINK the only downside to > this version is that the Widevine version that is shown in chrome://plugins > and in navigator.plugins will not be correct. My little editorial can be > replaced, of course, if it is deemed to be too inflammatory or something. :) > > The approach that Gregory discovered in comment #51 is also worth > considering. It might even be better than this patch, since it completely > removes the requirement to define WIDEVINE_CDM_VERSION_STRING rather than > simply setting it to whatever nonsense the programmer was thinking at that > moment ([1] and this patch, for example). > > If my larger patch is too much for the chromium team to swallow, one of > these two approaches would certainly be better than nothing (although I > still think that a real version is a valuable thing to have). > > [1] > https://projects.archlinux.org/svntogit/packages.git/tree/trunk/ > PKGBUILD?h=packages/chromium&id=6d0746b2f948c604f50505c97d571e0e6e668561#n71 (In reply to Ari Entlich from comment #59) > (In reply to Mike Johnson from comment #57) > > Ari are you saying without Gregory Turner's modified ebuild or his patch > > that this does the job and videos are playing in netflix? Thank you. And > > thanks to Gregory Turner too, we've been following his progress (and using > > it too!) over at Funtoo for a couple of weeks now. > > Unfortunately I don't actually have a Netflix account (then why am I doing > this, you ask? I wish I knew...) , so I actually can't say for sure that it > makes Netflix work. What I can say is that it makes the build succeed and > makes Widevine show up in chrome://plugins with the correct version. Someone > else will have to test whether it actually works with Netflix. My apologies > - maybe I should have been more up front about this. Please let me know what > you discover. I hope it works! The best non-for-pay way to test seems to be: http://www.dash-player.com/demo/drm-and-protection/ Although I haven't been banging against it very long, in my limited experience, I have yet to see a case where netflix drm and the above thingy don't fail or succeed together.
(In reply to Gregory Turner from comment #62) > The best non-for-pay way to test seems to be: > > http://www.dash-player.com/demo/drm-and-protection/ > > Although I haven't been banging against it very long, in my limited > experience, I have yet to see a case where netflix drm and the above thingy > don't fail or succeed together. Ah that's right, sorry I had forgotten that you had linked to this. Anyways, it works for me!
I tried the patch suggested by Gregory in post #51 at launchpad on my own machine last night, I have no netflix here. The patch went ok, but chrome://plugins does not show widevine and http://www.dash-player.com/demo/drm-and-protection/ does not indicate widevine either. I did add widevine to make.conf useflags. So they must be doing something with the binary. Also in the recent revisions 44.0.2403.89 is the latest they mention. So next I'll try Ari's alternate patch.
(In reply to Mike Johnson from comment #64) > I tried the patch suggested by Gregory in post #51 at launchpad on my own > machine last night, I have no netflix here. The patch went ok, but > chrome://plugins does not show widevine and > http://www.dash-player.com/demo/drm-and-protection/ does not indicate > widevine either. I did add widevine to make.conf useflags. So they must be > doing something with the binary. Also in the recent revisions 44.0.2403.89 > is the latest they mention. > So next I'll try Ari's alternate patch. When you made this experiment, did you merge the rest of the the stuff in chromium-widevine-ebuild-r12.patch (except for the "WIDEVINE_CDM_VERSION_STRING" line in src_prepare) and apply chromium-widevine-version.patch? Although comment 52 is correct that Google made chromium more widevine-compatible during the lifetime of this bug, unless Mike is aware of something I'm not, some if not all of those changes are still going to be required to make it work. To clarify why I think so, basically here's how I think everything works upstream: OS BUILD-TYPE LIBRARY-TYPE SUPPORTED windows chrome full yes windows chromium stub yes mac chrome full yes mac chromium stub yes linux chrome full yes linux chromium n/a* no Note that "full" doesn't mean to compile the actual DRM blob (libwidevinecdm.so), only some kind of shim loader thingy (libwidevinecdmadapater.so). So, upstream, libwidevinecdmadapter, which may or may not be created during the chrom* build process, is either (a) a stub that simply gets replaced by auto-mothership-download-and-execute at run-time, (b) a shim, targeted to a particular build of the closed-source libwidevinecdm blob, or (c) not compiled and, I presume, not usable even if you compile your own The status quo upstream is (c) for all chromium for linux builds. * With the chromium-widevine-2403 patch applied and the widevine-useflag enabled, we instead make the "full" version in our ebuild. To make that work, instead of that binary appearing via auto-mothership-download-and-execute, we presume that the blob and some metadata about it already appear in gentoo as an artifact of the www-plugins/chrome-binary-plugins[widevine] use-conditional build-time dependency.
(In reply to Gregory Turner from comment #65) > When you made this experiment, did you merge the rest of the the stuff in > chromium-widevine-ebuild-r12.patch (except for the > "WIDEVINE_CDM_VERSION_STRING" line in src_prepare) and apply > chromium-widevine-version.patch? I used my own ebuild patch (with most of the large changes from yours removed) and I seem to have widevine working. > Although comment 52 is correct that Google made chromium more > widevine-compatible during the lifetime of this bug, unless Mike is aware of > something I'm not, some if not all of those changes are still going to be > required to make it work. > > To clarify why I think so, basically here's how I think everything works > upstream: > > OS BUILD-TYPE LIBRARY-TYPE SUPPORTED > windows chrome full yes > windows chromium stub yes > mac chrome full yes > mac chromium stub yes > linux chrome full yes > linux chromium n/a* no > > Note that "full" doesn't mean to compile the actual DRM blob > (libwidevinecdm.so), only some kind of shim loader thingy > (libwidevinecdmadapater.so). Hmm, I'm not really sure what you mean here. What does "stub" mean? I described above what the "stub CDM" is. It does not get installed - it is only needed so that libwidevinecdmadapter.so has something to link against. > So, upstream, libwidevinecdmadapter, which may or may not be created during > the chrom* build process, is either > > (a) a stub that simply gets replaced by > auto-mothership-download-and-execute at run-time, > (b) a shim, targeted to a particular build of the > closed-source libwidevinecdm blob, > > or > > (c) not compiled and, I presume, not usable even if you compile your own > > The status quo upstream is (c) for all chromium for linux builds. As far as I can tell, libwidevinecdmadapter.so is a PPAPI plugin which links to libwidevinecdm.so. In other words, it allows widevine to be loaded as a PPAPI plugin. libwidevinecdm.so is not a PPAPI plugin by itself. The adapter is not replaced by libwidevinecdm.so. Since the commit that I linked to, libwidevinecdmadapter.so is definitely compiled if widevine is enabled, without any patches to the build system or copying of libwidevinecdm.so. > * With the chromium-widevine-2403 patch applied and the widevine-useflag > enabled, we instead make the "full" version in our ebuild. I have built libwidevinecdmadapter.so just fine without this patch. > To make that work, instead of that binary appearing via > auto-mothership-download-and-execute, we presume that the blob and some > metadata about it already appear in gentoo as an artifact of the > www-plugins/chrome-binary-plugins[widevine] use-conditional build-time > dependency.
(In reply to Ari Entlich from comment #66) > (In reply to Gregory Turner from comment #65) > > When you made this experiment, did you merge the rest of the the stuff in > > chromium-widevine-ebuild-r12.patch (except for the > > "WIDEVINE_CDM_VERSION_STRING" line in src_prepare) and apply > > chromium-widevine-version.patch? > > I used my own ebuild patch (with most of the large changes from yours > removed) and I seem to have widevine working. > > > Although comment 52 is correct that Google made chromium more > > widevine-compatible during the lifetime of this bug, unless Mike is aware of > > something I'm not, some if not all of those changes are still going to be > > required to make it work. > > > > To clarify why I think so, basically here's how I think everything works > > upstream: > > > > OS BUILD-TYPE LIBRARY-TYPE SUPPORTED > > windows chrome full yes > > windows chromium stub yes > > mac chrome full yes > > mac chromium stub yes > > linux chrome full yes > > linux chromium n/a* no > > > > Note that "full" doesn't mean to compile the actual DRM blob > > (libwidevinecdm.so), only some kind of shim loader thingy > > (libwidevinecdmadapater.so). > > Hmm, I'm not really sure what you mean here. What does "stub" mean? > > I described above what the "stub CDM" is. It does not get installed - it is > only needed so that libwidevinecdmadapter.so has something to link against. That makes sense. > > So, upstream, libwidevinecdmadapter, which may or may not be created during > > the chrom* build process, is either > > > > (a) a stub that simply gets replaced by > > auto-mothership-download-and-execute at run-time, > > (b) a shim, targeted to a particular build of the > > closed-source libwidevinecdm blob, > > > > or > > > > (c) not compiled and, I presume, not usable even if you compile your own > > > > The status quo upstream is (c) for all chromium for linux builds. > > As far as I can tell, libwidevinecdmadapter.so is a PPAPI plugin which links > to libwidevinecdm.so. In other words, it allows widevine to be loaded as a > PPAPI plugin. libwidevinecdm.so is not a PPAPI plugin by itself. The adapter > is not replaced by libwidevinecdm.so. > > Since the commit that I linked to, libwidevinecdmadapter.so is definitely > compiled if widevine is enabled, without any patches to the build system or > copying of libwidevinecdm.so. > > > * With the chromium-widevine-2403 patch applied and the widevine-useflag > > enabled, we instead make the "full" version in our ebuild. > > I have built libwidevinecdmadapter.so just fine without this patch. Wow, so do you provide the gyp define? Or it simply happens by default? Either way, I didn't realize that worked, must admit I'm surprised it does.
(In reply to Gregory Turner from comment #67) > (In reply to Ari Entlich from comment #66) > > (In reply to Gregory Turner from comment #65) > > > When you made this experiment, did you merge the rest of the the stuff in > > > chromium-widevine-ebuild-r12.patch (except for the > > > "WIDEVINE_CDM_VERSION_STRING" line in src_prepare) and apply > > > chromium-widevine-version.patch? > > > > I used my own ebuild patch (with most of the large changes from yours > > removed) and I seem to have widevine working. > > > > > Although comment 52 is correct that Google made chromium more > > > widevine-compatible during the lifetime of this bug, unless Mike is aware of > > > something I'm not, some if not all of those changes are still going to be > > > required to make it work. > > > > > > To clarify why I think so, basically here's how I think everything works > > > upstream: > > > > > > OS BUILD-TYPE LIBRARY-TYPE SUPPORTED > > > windows chrome full yes > > > windows chromium stub yes > > > mac chrome full yes > > > mac chromium stub yes > > > linux chrome full yes > > > linux chromium n/a* no > > > > > > Note that "full" doesn't mean to compile the actual DRM blob > > > (libwidevinecdm.so), only some kind of shim loader thingy > > > (libwidevinecdmadapater.so). > > > > Hmm, I'm not really sure what you mean here. What does "stub" mean? > > > > I described above what the "stub CDM" is. It does not get installed - it is > > only needed so that libwidevinecdmadapter.so has something to link against. > > That makes sense. So what happens in the "chromium" case -- let's say, for windows -- is that a noop libwidevinecdm.so gets generated? If so I've got it all wrong above.
(In reply to Gregory Turner from comment #68) > So what happens in the "chromium" case -- let's say, for windows -- is that > a noop libwidevinecdm.so gets generated? If so I've got it all wrong above. I guess maybe it'd actually be a noop widevinecdm.dll
(In reply to Gregory Turner from comment #69) > (In reply to Gregory Turner from comment #68) > > So what happens in the "chromium" case -- let's say, for windows -- is that > > a noop libwidevinecdm.so gets generated? If so I've got it all wrong above. > > I guess maybe it'd actually be a noop widevinecdm.dll I imagine it's probably used mostly on Linux, so I don't know how well tested it is in Windows, but yes I imagine theoretically it would work like that on any platform. It's all spelled out in the commit that I linked to earlier.[1] [1] https://chromium.googlesource.com/chromium/src/+/534d59853e0803ee61e6c8a6a4ceacac44df6843%5E!/
Correct, I did not do anything except put that patch in /etc/portage/patches... I thought that Ari was doing the same with his patch, but on closer examination I see that he does modify the ebuild, at least somewhat. I was looking for the "magic wand" solution where ebuilds do not have to be modified, since this is the biggest hassle with updates, dropping in an epatch_user file is nothing...
Hey guys, this bug has been going non-stop with the comments for several days now. At this point, it has become nothing more than background noise for me. Could you please work among yourselves and get back to us when you have settled on a stable solution?
Has anyone got this working with Chromium 46?
(In reply to Mike Lothian from comment #40) > Just wondered if there was an ebuild in any overlays? I'd be happy to add it > to mine if there isn't While I do not know if this is what you're looking for (I am using Funtoo) my personal overlay[1] contains the ebuild I am using, which is patched using the method initially proposed by @Gregory Turner. [1] https://github.com/Calrama/funtoo-overlay(In reply to Ari Entlich from comment #66) (In reply to Ari Entlich from comment #58) > Created attachment 407862 [details, diff] [details, diff] > chromium-44.0.2403.89.ebuild.patch > > And here's the ebuild patch. [...] Not sure I understand correctly. Does that mean that fairly soon there will be no need to use download chrome's widevine separately and patch it into chromium and instead you can just build chromium and it will take care of getting the widevine plugin? If not, what would be the benefit of your way compared to @Gregorys?(In reply to Gregory Turner from comment #49) > (In reply to Gregory Turner from comment #47) > [...] > > Can someone else with a Netflix Instant subscription (perhaps Moritz > Maxeiner or someone for whom it was previously working) try this version and > let me know what happens for them? I'm attempting a 44.0.2403.107 build > now, just to fully disconfirm the hypothesis that it somehow boils down to > differing versions of chromium and chrome-binary-plugins. Sorry for the late reaction, I'm now trying to build chromium-44.0.2403.125 with your patch r12 and will - if successful - test is against Netflix streaming.
(In reply to Mike Lothian from comment #40) > Just wondered if there was an ebuild in any overlays? I'd be happy to add it > to mine if there isn't While I do not know if this is what you're looking for (I am using Funtoo) my personal overlay[1] contains the ebuild I am using, which is patched using the method initially proposed by @Gregory Turner. (In reply to Ari Entlich from comment #58) > Created attachment 407862 [details, diff] [details, diff] [details, diff] > chromium-44.0.2403.89.ebuild.patch > > And here's the ebuild patch. [...] Not sure I understand correctly. Does that mean that fairly soon there will be no need to use download chrome's widevine separately and patch it into chromium and instead you can just build chromium and it will take care of getting the widevine plugin? If not, what would be the benefit of your way compared to @Gregorys?(In reply to Gregory Turner from comment #49) > (In reply to Gregory Turner from comment #47) > [...] > > Can someone else with a Netflix Instant subscription (perhaps Moritz > Maxeiner or someone for whom it was previously working) try this version and > let me know what happens for them? I'm attempting a 44.0.2403.107 build > now, just to fully disconfirm the hypothesis that it somehow boils down to > differing versions of chromium and chrome-binary-plugins. Sorry for the late reaction, I'm now trying to build chromium-44.0.2403.125 with your patch r12 and will - if successful - test is against Netflix streaming. [1] https://github.com/Calrama/funtoo-overlay
Created attachment 408270 [details, diff] chromium-44.0.2403.89.ebuild-nopatch.patch Here's yet another solution to the WIDEVINE_CDM_VERSION_STRING issue, which does not require any additional patches. This method is preferred by at least one member of the Chromium herd, based on our conversation in #gentoo-chromium. It seems that flags added in this way do not affect things built with the "host" toolset, but I don't think this is an issue because the only thing built this way is v8 for the purpose of doing the snapshot stuff. I don't think this copy of v8 is actually installed (it is only used during the build), and this flag should not do anything to v8 anyway, so this shouldn't be an issue. It seems to be impossible to pass a flag which contains spaces using this method, thanks to the awesomeness that is bash scripting. However, bash's quoting semantics have never been my strong suit, so it's possible that I just didn't figure out the right combination of single/double quotes and backslashes. An alternative to passing this flag with CPPFLAGS would be to patch it into one of the build files. I believe the relevant file would be chrome/chrome_common.gypi, since this is the one which references chrome_content_client.cc. This would mean that the flag would be added to a much smaller number of compile commands, and might also allow the flag to include spaces. This method produces pretty much the same end result as my patch in comment #60. Personally, I would prefer one of the patches in comment #51 or comment #56 over either this patch or the one in comment #60. The patch in comment #56 deals with the version in what I think is a robust way, while comment #51, to quote Gregory Turner, "punt[s] on the whole thing". This patch and comment #60 use a sort of weird middle-ground that doesn't sit quite right with me. I don't really see the difference between a small patch to the build system and a small patch to the C++ code, so I don't really see why the comment #51 patch would be less acceptable than a small build system patch. (In reply to Moritz Maxeiner from comment #75) > Not sure I understand correctly. Does that mean that fairly soon there will > be no need to use download chrome's widevine separately and patch it into > chromium and instead you can just build chromium and it will take care of > getting the widevine plugin? No. The only source of libwidevinecdm.so is the official Google Chrome packages. See www-plugins/chrome-binary-plugins for details. However, it does not really need to be "patched into" Chromium. It can be used if Chromium is built with widevine support enabled. The only thing that needs to be dealt with is WIDEVINE_CDM_VERSION_STRING, which determines the version that Chromium shows on the chrome://plugins page. This really shouldn't be required, but Google's process for producing the official Chrome packages apparently sucks, so there it is. > If not, what would be the benefit of your way compared to @Gregorys? We've determined that Gregory's patching of the build system is unnecessary. Furthermore, his ebuild patch is quite complex and produces a tight coupling between specific builds of chromium and specific versions of chrome-binary-plugins. My ebuild patches are based on his, but remove most of the complex parts. My most sophisticated WIDEVINE_CDM_VERSION_STRING fix is in comment #56, and does roughly what Chrome/Chromium should be doing already. I've also posted a number of other solutions.
(In reply to Ari Entlich from comment #76) > Created attachment 408270 [details, diff] [details, diff] > chromium-44.0.2403.89.ebuild-nopatch.patch > > Here's yet another solution to the WIDEVINE_CDM_VERSION_STRING issue, which > does not require any additional patches. [...] > > (In reply to Moritz Maxeiner from comment #75) > > Not sure I understand correctly. Does that mean that fairly soon there will > > be no need to use download chrome's widevine separately and patch it into > > chromium and instead you can just build chromium and it will take care of > > getting the widevine plugin? > > No. The only source of libwidevinecdm.so is the official Google Chrome > packages. See www-plugins/chrome-binary-plugins for details. However, it > does not really need to be "patched into" Chromium. It can be used if > Chromium is built with widevine support enabled. The only thing that needs > to be dealt with is WIDEVINE_CDM_VERSION_STRING, which determines the > version that Chromium shows on the chrome://plugins page. This really > shouldn't be required, but Google's process for producing the official > Chrome packages apparently sucks, so there it is. > > > If not, what would be the benefit of your way compared to @Gregorys? > > We've determined that Gregory's patching of the build system is unnecessary. > Furthermore, his ebuild patch is quite complex and produces a tight coupling > between specific builds of chromium and specific versions of > chrome-binary-plugins. My ebuild patches are based on his, but remove most > of the complex parts. My most sophisticated WIDEVINE_CDM_VERSION_STRING fix > is in comment #56, and does roughly what Chrome/Chromium should be doing > already. I've also posted a number of other solutions. Thank you for both the clarification and your work on the dynamic version patch, I've looked through your comments and the patches once more and would like to confirm what I think to have understood: 1) The widevine plugin is (in Gentoo) always distributed via the chrome-binary-plugins package; it contains the actual binary blob. 2) When building chromium with Gregorys patch from comment 43, the chrome-binary-plugins package must be installed at compile time, because the ebuild looks at the installed (Gentoo specific) widevine.version file belonging to that package to determine the version of the widevine plugin and bakes that version string into chromium. 3) This leads to the problem, that should the chrome-binary-plugins package be updated and the contained widevine plugin have received a version bump in that update, the version information about the widevine plugin will not be correct anymore, i.e. chromium will report a wrong version. 4) This might be an actual problem or it might not be, but in order to minimize the potential problems with web sites using the widevine plugin in chromium and eliminate a wrongly reported version from potential future bug hunts, it seems sensible to report the correct version. 5) Your joint patches from comment 56 and comment 58 patch chromium so that instead it looks at runtime from the widevine.version file and reports the contained version string; and since this file is Gentoo-specific it cannot be upstreamed. 6) The patches from 5) are the only ones so far that dynamically report the correct version. If 1-3,5-6 are correct, I think the patches from comment 56 and comment 58 have the most merit since they guarantee to always report the correct version. I am currently building chromium-44.0.2403.125 with these two patches and will report back. (In reply to Gregory Turner from comment #43) > Created attachment 407634 [details, diff] [details, diff] > chromium-widevine-ebuild-r12.patch > > Update to patch against latest and greatest chromium ebuild code. Drop all > the instructions I was maintaining at the beginning, as the current version > in portage works just fine on its own without any upgrade requirements > likely to create confusion. > > n.b.: untested, building this now, I'll report back when it works. Just finished building chromium-44.0.2403.125 with this and it works perfectly so far, thanks.
(In reply to Moritz Maxeiner from comment #77) > Thank you for both the clarification and your work on the dynamic version > patch, I've looked through your comments and the patches once more and would > like to confirm what I think to have understood: This is a fantastic summary of such a confusing bug. I'll confirm the points I can. > 1) The widevine plugin is (in Gentoo) always distributed via the > chrome-binary-plugins package; it contains the actual binary blob. yes, that's my understanding. > 2) When building chromium with Gregorys patch from comment 43, the > chrome-binary-plugins package must be installed at compile time, because the > ebuild looks at the installed (Gentoo specific) widevine.version file > belonging to that package to determine the version of the widevine plugin > and bakes that version string into chromium. Correct. > 3) This leads to the problem, that should the chrome-binary-plugins package > be updated and the contained widevine plugin have received a version bump in > that update, the version information about the widevine plugin will not be > correct anymore, i.e. chromium will report a wrong version. Also correct. > 4) This might be an actual problem or it might not be, but in order to > minimize the potential problems with web sites using the widevine plugin in > chromium and eliminate a wrongly reported version from potential future bug > hunts, it seems sensible to report the correct version. Precisely right. > 5) Your joint patches from comment 56 and comment 58 patch chromium so that > instead it looks at runtime from the widevine.version file and reports the > contained version string; and since this file is Gentoo-specific it cannot > be upstreamed. > 6) The patches from 5) are the only ones so far that dynamically report the > correct version. Points #5 and #6 seem to capture what other folks are saying as I understand it. I'd trust, but verify, these points, and I haven't yet verified, and so can't speak definitively, but, they are probably right, too, unless someone (perhaps, me) got mixed up.
(In reply to Moritz Maxeiner from comment #77) > [...] > > I am currently building chromium-44.0.2403.125 with these two > patches and will report back. Build just finished and it seems to be working with Netflix as expected. No news is good news. Also, after the first test I have done a downgrade from =www-plugins/chrome-binary-plugins-45.0.2454.15_beta1 to =www-plugins/chrome-binary-plugins-44.0.2403.125_p1 , which changed chrome://plugins/ output from Widevine Content Decryption Module - Version: 1.4.8.824 Enables Widevine licenses for playback of HTML audio/video content. (version: 1.4.8.824) to Widevine Content Decryption Module - Version: 1.4.8.823 Enables Widevine licenses for playback of HTML audio/video content. (version: 1.4.8.823) while still playing Netflix perfectly fine. I restarted chromium out of caution, but I did not (need to) recompile it. So, I can give these dynamic patches a WORKSFORME/SOFAR(TM). I have, additionally, added the ebuild to my personal overlay (see comment 75 for a link) as =www-client/chromium-44.0.2403.125-r2 (r1 is the one with the static patch from comment 43), should that be of interest. (In reply to Gregory Turner from comment #78) > (In reply to Moritz Maxeiner from comment #77) > > This is a fantastic summary of such a confusing bug. I'll confirm the > points I can. > > [...] Thank you for confirming points 1-4 for me, would have been awkward had I still not understood it. > > [...] > > Points #5 and #6 seem to capture what other folks are saying as I understand > it. I'd trust, but verify, these points, and I haven't yet verified, and so > can't speak definitively, but, they are probably right, too, unless someone > (perhaps, me) got mixed up. Fair enough, I shall wait for later judgement on those points.
Are we any closer to getting one of the solutions merged into portage?
(In reply to Mike Lothian from comment #80) > Are we any closer to getting one of the solutions merged into portage? Yes, I think we have some solution in the wall of text above. I just need to find the time/motivation to commit something. Or someone else on the chromium team can do it.
(In reply to Moritz Maxeiner from comment #77) > 5) Your joint patches from comment 56 and comment 58 patch chromium so that > instead it looks at runtime from the widevine.version file and reports the > contained version string; and since this file is Gentoo-specific it cannot > be upstreamed. > 6) The patches from 5) are the only ones so far that dynamically report the > correct version. I can confirm, now, that the comment 56 + comment 58 patches (taken together) do the trick. One other note; perhaps Google wouldn't like it, due to NIH or some technical reason[1] but I see no reason Ari's patch in comment 56 couldn't go upstream. [1] Or, more likely, some inexplicable "not supported" reason that amounts to deliberately giving us the shaft as a favor to the xxAA IP protection gangs and their supporters.
https://github.com/gentoo/gentoo/pull/37 encapsulates the wall of text and captures a couple of other odds-and-ends. Of the three patches in that PR, the middle one is the most questionable, so some real developer should take a look at that before it goes in. The first patch in that PR fixes some confusing/out-of-date-ish advice about chromium[widevine] in chrome-binary-plugins. Pretend "PR37" tags that patch, the head of my pull request. Then, PR37^ attempts to implement the FIXME about flag-masking. This one needs review. And PR37^^ represents just a merge of comment 56 and comment 58 into github's gentoo/gentoo master (only in the :beta slot for now, as usual).
(In reply to Gregory Turner from comment #83) > https://github.com/gentoo/gentoo/pull/37 encapsulates the wall of text and > captures a couple of other odds-and-ends. Of the three patches in that PR, > the middle one is the most questionable, so some real developer should take > a look at that before it goes in. > > The first patch in that PR fixes some confusing/out-of-date-ish advice about > chromium[widevine] in chrome-binary-plugins. > > Pretend "PR37" tags that patch, the head of my pull request. Then, > > PR37^ attempts to implement the FIXME about flag-masking. This one needs > review. > > And PR37^^ represents just a merge of comment 56 and comment 58 into > github's gentoo/gentoo master (only in the :beta slot for now, as usual). No more: I updated my PR to just bake a (conspicuously) fake version number in instead. Aesthetically, I prefer Ari's patches but upstream has expressed a willingness to address the problem, so we should minimize the maintenance burden seems best 'till then. I'd also argue our original off-the-cuff assessments of the potential value of preserving these version numbers were far too generous -- if anyone had a meaningful need for them, they would have spoken up about it, by now. If you want a deontological argument for punting: the "official" chromium binary packages from upstream is, strictly speaking, beer-free, since upstream does not provide its downstreams with the recipe to build an equivalent binary. No big deal, and not ostensibly due to shenanigans, but we can't follow a recipe we don't have. Truly and fully open-source chromium forks with operational widevine-cdm capabilities seem to break down mostly into these camps: o Gentoo's historical approach (ugly vestigial organs) o Ari's approach (unjustifiable maintenance burden) o "punt" approaches (meh, but bene/cost >= 1) Of these, "punting" is the only option without a value-proposition conflict, so we should pick that camp until something better is available. QED! :) :P :)
I would like phajdan.jr to review this please. commit bc7b92e875db316b8b81055c21334dcd0dcbd16c Author: Mike Gilbert <floppym@gentoo.org> Date: Fri Sep 11 12:22:48 2015 -0400 www-client/chromium: Restore widevine support in the dev channel (47) This includes a minimal patch to get chromium to compile. The widevine version is reported as "unknown" in chrome://plugins. A more robust solution should really be implemented upstream. Tested by viewing a video on Netflix. Based on work by Greg Turner and Ari Entlich. Closes #37. Bug: https://bugs.gentoo.org/547630 Bug: https://crbug.com/473866 Package-Manager: portage-2.2.20 www-client/chromium/chromium-47.0.2503.0.ebuild | 10 +++++++--- www-client/chromium/files/chromium-widevine-r1.patch | 14 ++++++++++++++ www-client/chromium/metadata.xml | 1 + 3 files changed, 22 insertions(+), 3 deletions(-)
The flag-mask wasn't merged. If that's not acceptable I would assume REQUIRED_USE="|| ( x86 amd64 !widevine )" is better than nothing.
(In reply to Gregory Turner from comment #84) > (In reply to Gregory Turner from comment #83) > > https://github.com/gentoo/gentoo/pull/37 encapsulates the wall of text and > > captures a couple of other odds-and-ends. Of the three patches in that PR, > > the middle one is the most questionable, so some real developer should take > > a look at that before it goes in. > > > > The first patch in that PR fixes some confusing/out-of-date-ish advice about > > chromium[widevine] in chrome-binary-plugins. > > > > Pretend "PR37" tags that patch, the head of my pull request. Then, > > > > PR37^ attempts to implement the FIXME about flag-masking. This one needs > > review. > > > > And PR37^^ represents just a merge of comment 56 and comment 58 into > > github's gentoo/gentoo master (only in the :beta slot for now, as usual). > > No more: I updated my PR to just bake a (conspicuously) fake version number > in instead. Aesthetically, I prefer Ari's patches but upstream has > expressed a willingness to address the problem, so we should minimize the > maintenance burden seems best 'till then. > Could you provide a public source on that statement from upstream for reference's sake? Because personally, I get an unpleasant feeling whenever someone says something like "we will fix it eventually". > I'd also argue our original off-the-cuff assessments of the potential value > of preserving these version numbers were far too generous -- if anyone had a > meaningful need for them, they would have spoken up about it, by now. I agree in part: If a versed enough dev who also happens to be interested in chromium+gentoo additionally happened to find a site that required correct versions, then yes, he would have said so; anyone else - I don't think so. In any case, without an ETA (emphasis on "estimated") about a fix in upstream, I would always prefer the technically correct solution over the easier, technically incorrect one (if both work, that is). > > If you want a deontological argument for punting: the "official" chromium > binary packages from upstream is, strictly speaking, beer-free, since > upstream does not provide its downstreams with the recipe to build an > equivalent binary. No big deal, and not ostensibly due to shenanigans, but > we can't follow a recipe we don't have. Again, partially true, but right now this isn't about following a recipe, but about semantic equivalence; regardless of what the recipe is. This is also about a workaround solution for an upstream problem for the interim in which we wait for an upstream solution. You can - of course - choose to do punting, but it is the technically inferior solution in terms of semantic equivalence of the solution with chrome, i.e. we do not know that it actually behaves the same as chrome (like it should), you did some tests and it does seem to work for some sites (which is great, don't get me wrong). But with patches 56+58 we know that it behaves like chrome would and should any problems arise we would not risk overlooking the fact that it might be because of punting. Punting introduces an incalculable risk-factor: What about watching for a prolonged period of time? Maybe Netflix (or some other site) only checks this string seldom, but crashes when it doesn't see what it expects (I know that this is far fetched, most likely Netflix doesn't care at all, but it is the difference between knowing something will work and hoping it will because of test coverage; testing is not a replacement for a correctness proof). > > Truly and fully open-source chromium forks with operational widevine-cdm > capabilities seem to break down mostly into these camps: > > o Gentoo's historical approach (ugly vestigial organs) > o Ari's approach (unjustifiable maintenance burden) Here you simply claim that the maintenance burden would be "unjustifiable". I'm sorry, but how did you quantify that? And then weigh it against the unknown risk of bevahorioural divergence from chrome. Because I have been maintaining a local overlay and the maintenance overhead from the patches 56+58 so far have been negligible for me. So much so, in fact, that I will most likely continue maintaining the 56+58 solution for myself in my personal overlay, should punting be chosen here. > o "punt" approaches (meh, but bene/cost >= 1) Technically, since it is impossible to predict what problems might arise from punting for future sites I would state that a proper benefits vs cost analysis cannot be done. > > Of these, "punting" is the only option without a value-proposition conflict, > so we should pick that camp until something better is available. I strongly disagree with that reasoning. I think the technically correct solution - patches 56+58 - should be picked, since they are the only ones that do not introduce possible issues by diverging from semantics sites expect from chrom+widevine. > > QED! > > :) :P :) "quod erat demonstrandum" is something that is historically reserved for proofs, or - imho - at the very least for something where no one can sensibly argue against. In my opinion, your post is neither and - quite frankly - presents your opinion as fact. Other than this - admittedly - slightly harsh criticism: Thank you for your continued work on this issue and your PR.
(In reply to Moritz Maxeiner from comment #87) > (In reply to Gregory Turner from comment #84) > > (In reply to Gregory Turner from comment #83) > > > https://github.com/gentoo/gentoo/pull/37 encapsulates the wall of text and > > > captures a couple of other odds-and-ends. Of the three patches in that PR, > > > the middle one is the most questionable, so some real developer should take > > > a look at that before it goes in. > > > > > > The first patch in that PR fixes some confusing/out-of-date-ish advice about > > > chromium[widevine] in chrome-binary-plugins. > > > > > > Pretend "PR37" tags that patch, the head of my pull request. Then, > > > > > > PR37^ attempts to implement the FIXME about flag-masking. This one needs > > > review. > > > > > > And PR37^^ represents just a merge of comment 56 and comment 58 into > > > github's gentoo/gentoo master (only in the :beta slot for now, as usual). > > > > No more: I updated my PR to just bake a (conspicuously) fake version number > > in instead. Aesthetically, I prefer Ari's patches but upstream has > > expressed a willingness to address the problem, so we should minimize the > > maintenance burden seems best 'till then. > > > > Could you provide a public source on that statement from upstream for > reference's sake? Because personally, I get an unpleasant feeling whenever > someone says something like "we will fix it eventually" I'm just going by what I see in crbug.com/473866. I get that same unpleasant feeling too, truth be told. But even so I see no reason we should drive ourselves crazy over it. > > I'd also argue our original off-the-cuff assessments of the potential value > > of preserving these version numbers were far too generous -- if anyone had a > > meaningful need for them, they would have spoken up about it, by now. > > I agree in part: If a versed enough dev who also happens to be interested in > chromium+gentoo additionally happened to find a site that required correct > versions, then yes, he would have said so; anyone else - I don't think so. > In any case, without an ETA (emphasis on "estimated") about a fix in > upstream, I would always prefer the technically correct solution over the > easier, technically incorrect one (if both work, that is). Well check out chrome://plugins which shows the other "components-as-plugins" or whatever this category of beastie is. On my ::beta everything there is "punting" except flash which doesn't even report a single version but two versions, at least one of which must be wrong :) > > If you want a deontological argument for punting: the "official" chromium > > binary packages from upstream is, strictly speaking, beer-free, since > > upstream does not provide its downstreams with the recipe to build an > > equivalent binary. No big deal, and not ostensibly due to shenanigans, but > > we can't follow a recipe we don't have. > > Again, partially true, but right now this isn't about following a recipe, > but about semantic equivalence; regardless of what the recipe is. This is > also about a workaround solution for an upstream problem for the interim in > which we wait for an upstream solution. Agreed -- my point is, there really is no open-source upstream for us to be equivalent to. Some downstream-of-upstream (sibling-streams?) like the Ubuntu PPA and Arch do provide an open-source solution but they are all "punting". > You can - of course - choose to do punting, but it is the technically > inferior solution in terms of semantic equivalence of the solution with > chrome, i.e. we do not know that it actually behaves the same as chrome > (like it should), you did some tests and it does seem to work for some sites > (which is great, don't get me wrong). But with patches 56+58 we know that it > behaves like chrome would and should any problems arise we would not risk > overlooking the fact that it might be because of punting. Punting introduces > an incalculable risk-factor: What about watching for a prolonged period of > time? Maybe Netflix (or some other site) only checks this string seldom, but > crashes when it doesn't see what it expects (I know that this is far > fetched, most likely Netflix doesn't care at all, but it is the difference > between knowing something will work and hoping it will because of test > coverage; testing is not a replacement for a correctness proof). Can't argue with that. Ari's solution gives the most-perfect near-term result of the available options, no doubt. But OTOH, how long 'till it breaks, and we're back in bugzilla yappin' about it instead of watching Netflix? :) > > Truly and fully open-source chromium forks with operational widevine-cdm > > capabilities seem to break down mostly into these camps: > > > > o Gentoo's historical approach (ugly vestigial organs) > > o Ari's approach (unjustifiable maintenance burden) > > Here you simply claim that the maintenance burden would be "unjustifiable". It's unjustifiable because we want to maximize cost/benefit, right? But as the benefit approaches zero, what happens to this statistic? > I'm sorry, but how did you quantify that? And then weigh it against the > unknown risk of bevahorioural divergence from chrome. Because I have been > maintaining a local overlay and the maintenance overhead from the patches > 56+58 so far have been negligible for me. I dunno, does it even work in ::dev? That'd be a good leading indicator :) > So much so, in fact, that I will > most likely continue maintaining the 56+58 solution for myself in my > personal overlay, should punting be chosen here. It's hard to say, as upstream is pretty opaque. The code has definitely been in flux over the life of this bug and they have a bug open for this... who knows what their process is or how long it'll take. I agree there's a decent chance they'll just do nothing. > > o "punt" approaches (meh, but bene/cost >= 1) > > Technically, since it is impossible to predict what problems might arise > from punting for future sites I would state that a proper benefits vs cost > analysis cannot be done. Right. Since the benefit is unknown and the cost is unknown, it's damn hard to be scientific about this. "QED" was meant as a joke to make fun of precisely that. I basically agree with most of your points -- I just feel that a minimal patch is more likely to go into gx86 and to survive the vagaries of time there until Google decides to fix this or empower someone else to.
(In reply to Gregory Turner from comment #86) > The flag-mask wasn't merged. I will take care of that once phajdan.jr gives his feedback on the current ebuild. The dev channel is hard-masked anyway, so we are fine for now.
(In reply to Gregory Turner from comment #88) > (In reply to Moritz Maxeiner from comment #87) > > (In reply to Gregory Turner from comment #84) > > > > Could you provide a public source on that statement from upstream for > > reference's sake? Because personally, I get an unpleasant feeling whenever > > someone says something like "we will fix it eventually" > > I'm just going by what I see in crbug.com/473866. I get that same > unpleasant feeling too, truth be told. But even so I see no reason we > should drive ourselves crazy over it. Ah right, Ari had linked to that. My bad, I forgot to recheck that. > > > > I agree in part: If a versed enough dev who also happens to be interested in > > chromium+gentoo additionally happened to find a site that required correct > > versions, then yes, he would have said so; anyone else - I don't think so. > > In any case, without an ETA (emphasis on "estimated") about a fix in > > upstream, I would always prefer the technically correct solution over the > > easier, technically incorrect one (if both work, that is). > > Well check out chrome://plugins which shows the other > "components-as-plugins" or whatever this category of beastie is. On my > ::beta everything there is "punting" except flash which doesn't even report > a single version but two versions, at least one of which must be wrong :) Same for my 44 chromium. I do not know the semantics behind the two different slots for versions, but I do agree it seems likely at least one is wrong for flash. > > > > Again, partially true, but right now this isn't about following a recipe, > > but about semantic equivalence; regardless of what the recipe is. This is > > also about a workaround solution for an upstream problem for the interim in > > which we wait for an upstream solution. > > Agreed -- my point is, there really is no open-source upstream for us to be > equivalent to. Some downstream-of-upstream (sibling-streams?) like the > Ubuntu PPA and Arch do provide an open-source solution but they are all > "punting". You are right, there is no open-source upstream to be equivalent to. I personally would prefer, though, that if we import a binary-only feature from chrome, we should try to behave like chrome for sites that require that feature. > > > > You can - of course - choose to do punting, but it is the technically > > inferior solution in terms of semantic equivalence of the solution with > > chrome, i.e. we do not know that it actually behaves the same as chrome > > (like it should), you did some tests and it does seem to work for some sites > > (which is great, don't get me wrong). But with patches 56+58 we know that it > > behaves like chrome would and should any problems arise we would not risk > > overlooking the fact that it might be because of punting. Punting introduces > > an incalculable risk-factor: What about watching for a prolonged period of > > time? Maybe Netflix (or some other site) only checks this string seldom, but > > crashes when it doesn't see what it expects (I know that this is far > > fetched, most likely Netflix doesn't care at all, but it is the difference > > between knowing something will work and hoping it will because of test > > coverage; testing is not a replacement for a correctness proof). > > Can't argue with that. Ari's solution gives the most-perfect near-term > result of the available options, no doubt. But OTOH, how long 'till it > breaks, and we're back in bugzilla yappin' about it instead of watching > Netflix? :) Yes, that is a problem, though that could happen with either solution. Though I will concede that in the short-term, I find it more likely for the 56+58 patches variant to lead there. :) If that happens to me in my personal overlay, you can be certain I will sigh in a most annoyed way and try to fix it while hating myself (and possibly banging my head against my table if I can't get it to work). > > > > Here you simply claim that the maintenance burden would be "unjustifiable". > > It's unjustifiable because we want to maximize cost/benefit, right? But as > the benefit approaches zero, what happens to this statistic? If you want to maximize short term benefit / cost, then yes. The problem comes with middle to long term (since I do not think this is a priority issue for upstream). > > > I'm sorry, but how did you quantify that? And then weigh it against the > > unknown risk of bevahorioural divergence from chrome. Because I have been > > maintaining a local overlay and the maintenance overhead from the patches > > 56+58 so far have been negligible for me. > > I dunno, does it even work in ::dev? That'd be a good leading indicator :) I will look into that as soon as I can get my laptop working again properly. <OT>I went from x11 development overlay back to release to see if the intel broadwell gpu support finally works properly there and had to rebuild my entire system to deal with the dependency nightmare (read as: was too inept to get it done another way). Still some kinks to work out, since somehow I lost consolekit/policykit permissions in the process.</OT> > > > So much so, in fact, that I will > > most likely continue maintaining the 56+58 solution for myself in my > > personal overlay, should punting be chosen here. > > It's hard to say, as upstream is pretty opaque. The code has definitely > been in flux over the life of this bug and they have a bug open for this... > who knows what their process is or how long it'll take. I agree there's a > decent chance they'll just do nothing. OK, thanks for the information: If upstream is really in such a flux, then I can get behind the punting in portage for now. For my own use, I will just take the official ebuild and wrap the punting in an appropriate useflag with patches 56+58 if that useflag is disabled. > > > > o "punt" approaches (meh, but bene/cost >= 1) > > > > Technically, since it is impossible to predict what problems might arise > > from punting for future sites I would state that a proper benefits vs cost > > analysis cannot be done. > > Right. Since the benefit is unknown and the cost is unknown, it's damn hard > to be scientific about this. "QED" was meant as a joke to make fun of > precisely that. I basically agree with most of your points -- I just feel > that a minimal patch is more likely to go into gx86 and to survive the > vagaries of time there until Google decides to fix this or empower someone > else to. Then I do apologize, I misinterpreted your emoticons as something very different. I can get behind the idea of punting as a minimal stop-gap measure with zero short-term maintenance, but I feel that should the issue not be addressed properly upstream in a reasonable time frame (say 3-5 months) this issue should be revisited here.
I've been backporting the ::dev changes to ::beta for some time now, everything seems to be holding together, more or less. Any reason left not to unleash this upon the masses?
(In reply to Moritz Maxeiner from comment #90) > (In reply to Gregory Turner from comment #88) > > (In reply to Moritz Maxeiner from comment #87) > > > > It's hard to say, as upstream is pretty opaque. The code has definitely > > been in flux over the life of this bug and they have a bug open for this... > > who knows what their process is or how long it'll take. I agree there's a > > decent chance they'll just do nothing. > > OK, thanks for the information: If upstream is really in such a flux, then I > can get behind the punting in portage for now. For my own use, I will just > take the official ebuild and wrap the punting in an appropriate useflag with > patches 56+58 if that useflag is disabled. > Update (for reference): Over the last month I have tested a bunch of chromium versions with regards to this (usually somewhat behind gentoo master) and have found the patch to be working without any issue up to the currenly latest version 48.0.2541.0. Of course, this does not necessarily mean it will continue to work in future release, but as long as it does, usable ebuilds can be found in my overlay.
Thank you Moritz Maxeiner for providing these ebuilds. I am using them.
