[gentoo-dev] chromium-59.0.3053.3 will require >=sys-apps/sandbox-2.11 (currently hard masked)

[gentoo-dev] chromium-59.0.3053.3 will require >=sys-apps/sandbox-2.11 (currently hard masked)

[Paweł Hajdan, Jr.]

[-- Attachment #1.1: Type: text/plain, Size: 1009 bytes --]

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/chromium?id=f2345c0af633116a69051239ab10d858d5aea69a>
for the commit which introduced this, and feel free to share your
suggestions.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] chromium-59.0.3053.3 will require >=sys-apps/sandbox-2.11 (currently hard masked)

[Mike Gilbert]

On Thu, Apr 13, 2017 at 3:29 PM, Paweł Hajdan, Jr.
<phajdan.jr@gentoo.org> 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/chromium?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.

Re: [gentoo-dev] chromium-59.0.3053.3 will require >=sys-apps/sandbox-2.11 (currently hard masked)

[Mart Raudsepp]

Ü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.
> <phajdan.jr@gentoo.org> 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