public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Mart Raudsepp <leio@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] chromium-59.0.3053.3 will require >=sys-apps/sandbox-2.11 (currently hard masked)
Date: Tue, 18 Apr 2017 10:12:56 +0300	[thread overview]
Message-ID: <1492499576.6457.1.camel@gentoo.org> (raw)
In-Reply-To: <CAJ0EP43ZsgSPdZkzXAsJs3fBV_DgYkB8yfCBUBgCcHdF9wz5AA@mail.gmail.com>

Ü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


      reply	other threads:[~2017-04-18  7:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-13 19:29 [gentoo-dev] chromium-59.0.3053.3 will require >=sys-apps/sandbox-2.11 (currently hard masked) Paweł Hajdan, Jr.
2017-04-13 20:01 ` Mike Gilbert
2017-04-18  7:12   ` Mart Raudsepp [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1492499576.6457.1.camel@gentoo.org \
    --to=leio@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox