Ühel kenal päeval, N, 13.04.2017 kell 16:01, kirjutas Mike Gilbert: > On Thu, Apr 13, 2017 at 3:29 PM, Paweł Hajdan, Jr. > <[email protected]> wrote: > > The latest dev channel release of chromium (59.0.3053.3) will > > require > > > =sys-apps/sandbox-2.11 to build. > > > > I'm sending this announcement because this version of sandbox is > > currently hard masked. So is the chromium version, but with its > > fast > > release cycle we can expect it hitting ~arch in few weeks, and > > stable in > > the next few weeks. I'd like to make sure we'd be able to push > > sandbox > > to stable at the same pace, or find some alternative solution. > > > > For curious folks, new sandbox fixes a hang which occurs with > > tcmalloc. > > See https://crbug.com/586444 . The new chromium adds a code > > generator > > needed for build (inside the network stack). I didn't find an easy > > way > > to disable tcmalloc just for that code generator, and after finding > > above bug new sandbox seemed like the best choice. > > > > See > > <https://gitweb.gentoo.org/repo/gentoo.git/commit/www-client/chromi > > um?id=f2345c0af633116a69051239ab10d858d5aea69a> > > for the commit which introduced this, and feel free to share your > > suggestions. > > The sandbox blocker could be moved behind a use-conditional: > > tcmalloc? ( !<sys-apps/sandbox-2.11 ) > > If vapier or the QA team don't drop the sandbox mask, we can > package.mask the tcmalloc USE flag as an interim workaround.
Yeah, I would say unmasking is not possible until https://bugs.gentoo.org/show_bug.cgi?id=615906 is solved. Due to that bug, unmasking would mean firefox/thunderbird/etc can't be upgraded anymore, while chromium could be with optional tcmalloc support that could be disabled. Interestingly the XUL sandbox failure is triggered by it hitting ptrace paths now due to custom allocator, while you apparently need new sandbox due to a custom allocator choice apparently... Mart
