Upstream bug report here: https://github.com/gwaldron/osgearth/issues/333
The Gentoo Chromium team is now phasing out dev-lang/v8 shared package. I'm working with v8 upstream to get the library in better shape API and ABI-wise, but the ETA is very long ("years"). Please switch the package to use bundled v8.
(In reply to Paweł Hajdan, Jr. from comment #1) > The Gentoo Chromium team is now phasing out dev-lang/v8 shared package. I'm > working with v8 upstream to get the library in better shape API and > ABI-wise, but the ETA is very long ("years"). Please switch the package to > use bundled v8. wat? There is no bundled v8.
(In reply to Julian Ospald (hasufell) from comment #2) > wat? There is no bundled v8. This either needs to be bundled or (I've noticed this is an optional dependency) just drop it. Note: talking is easy. Feel free to produce patches to stay on top of latest stable v8 releases. Every 6 weeks. I actually spend considerable time unbundling what's possible from chromium. I'm sorry some dependencies actually require more effort. I'm working with v8 upstream to improve this, but it'll take a long time before effects become visible (provided it succeeds).
Created attachment 362458 [details, diff] osgearth-v8.patch I'd like to make osgearth ebuild apply the attached patch and pass -DOSGEARTH_USE_V8=OFF to cmake. It currently fails to build otherwise.
(In reply to Paweł Hajdan, Jr. from comment #4) > Created attachment 362458 [details, diff] [details, diff] > osgearth-v8.patch > > I'd like to make osgearth ebuild apply the attached patch and pass > -DOSGEARTH_USE_V8=OFF to cmake. > > It currently fails to build otherwise. and then what? Have a crippled version? this is what I'm going to do: a) treeclean or b) fix the dep to =dev-lang/v8-3.18.5.14
+ 03 Nov 2013; Julian Ospald <hasufell@gentoo.org> osgearth-2.4.ebuild: + fix dev-lang/v8 dep wrt #484786
(In reply to Julian Ospald (hasufell) from comment #5) > and then what? Have a crippled version? You can talk to upstream to bundle v8. I'm really convinced in the current situation this is the only option. > this is what I'm going to do: > a) treeclean Feel free. Isn't it better to at least have non-JS functionality though? I'm not that familiar with osgearth, maybe JS is critical, but from what I've read it's optional. > b) fix the dep to =dev-lang/v8-3.18.5.14 I've seen you went this way - please note however we (Chromium team) are going to remove old vulnerable v8 versions. Maybe even v8-3.18, I'll need to check the security status. Also, this is just inviting dependency conflicts, and is exactly the reason for moving away from shared v8 for now. Note that I do work with upstream to improve this, but ETA is very long and it's not certain whether it's going to happen.
when you remove a library you have to check reverse deps and mask the library you want to remove first everything else will be resolved then, so I don't understand why you reopen this bug =foo/bar-12.3 deps are perfectly valid
(In reply to Julian Ospald (hasufell) from comment #8) > when you remove a library you have to check reverse deps and mask the > library you want to remove first That's correct. dev-lang/v8 actually is very likely to go masked in the coming weeks. I'd either mask osgearth then or file a bug about either masking it or removing the v8 dep. That's totally fine for me. > everything else will be resolved then, so I don't understand why you reopen > this bug > > =foo/bar-12.3 deps are perfectly valid Agreed. Closing then. If you have further comments (I'm always willing to listen and try to find a solution that would work for you) you're always welcome to either send a direct e-mail to me, or to chromium@ if you prefer.
mask reverted, v8 support dropped, bumped to 2.5
