From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 21A0D139694 for ; Tue, 18 Apr 2017 07:13:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 23D94E0DDB; Tue, 18 Apr 2017 07:13:02 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CEE4EE0D8F for ; Tue, 18 Apr 2017 07:13:01 +0000 (UTC) Received: from [192.168.2.10] (85.253.85.240.cable.starman.ee [85.253.85.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: leio) by smtp.gentoo.org (Postfix) with ESMTPSA id 40F6733BEAE for ; Tue, 18 Apr 2017 07:13:00 +0000 (UTC) Message-ID: <1492499576.6457.1.camel@gentoo.org> Subject: Re: [gentoo-dev] chromium-59.0.3053.3 will require >=sys-apps/sandbox-2.11 (currently hard masked) From: Mart Raudsepp To: gentoo-dev@lists.gentoo.org Date: Tue, 18 Apr 2017 10:12:56 +0300 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: dbae5609-6e05-476d-b478-bade7e606570 X-Archives-Hash: 280f91982808124b6aab82ad6a1c8a2e Ü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. > 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 > > > 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? ( ! > 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