Re: [gentoo-dev] [PATCH 01/14] cdrom.eclass: Detect case-insensitively and handle special characters

2017-04-18 Thread Michał Górny 
Dnia 18 kwietnia 2017 23:31:31 CEST, James Le Cuirot  
napisał(a):
>On Tue, 18 Apr 2017 08:08:44 +0200
>Michał Górny  wrote:
>
>> On pon, 2017-04-17 at 22:53 +0100, James Le Cuirot wrote:
>> > diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
>> > index 41488d2446c2..de72f15563db 100644
>> > --- a/eclass/cdrom.eclass
>> > +++ b/eclass/cdrom.eclass
>> > @@ -79,12 +79,13 @@ cdrom_get_cds() {
>> >export CDROM_ROOT=${CD_ROOT_1:-${CD_ROOT}}
>> >einfo "Found CD #${CDROM_CURRENT_CD} root at ${CDROM_ROOT}"
>> >export CDROM_SET=-1
>> > -  for f in ${CDROM_CHECK_1//:/ } ; do
>> > +  IFS=:  
>> 
>> 'local', please.
>
>This line disappears later in the series but I've amended it for the
>history anyway.
>
>> > @@ -181,28 +182,24 @@ _cdrom_locate_file_on_cd() {
>> >local showedmsg=0 showjolietmsg=0
>> >  
>> >while [[ -z ${CDROM_ROOT} ]] ; do
>> > -  local i=0
>> > -  local -a cdset=(${*//:/ })
>> > +  local i=0 cdset
>> > +  IFS=: read -a cdset <<< "${*}"  
>> 
>> -r to avoid handling escapes; -d '' to avoid finishing on newline.
>
>Good call.
>
>> > @@ -243,4 +240,27 @@ _cdrom_locate_file_on_cd() {
>> >done
>> >  }
>> >  
>> > +# @FUNCTION: _cdrom_glob_match
>> > +# @USAGE:  
>> > +# @INTERNAL
>> > +# @DESCRIPTION:
>> > +# Locates the given path ($2) within the given root directory ($1)
>> > +# case-insensitively and returns the first actual matching path.
>This
>> > +# eclass previously used "find -iname" but it only checked the
>file
>> > +# case-insensitively and not the directories. There is "find
>-ipath" but
>> > +# this does not intelligently skip non-matching paths, making it
>> > +# slow. Case-insensitive matching can only be applied to patterns
>so
>> > +# extended globbing is used to turn regular strings into patterns.
>All
>> > +# special characters are escaped so don't worry about breaking
>this. The
>> > +# first person to make this work without an eval wins a cookie.
>> > +_cdrom_glob_match() {
>> > +  local p=\?\($(sed -e 's:[^A-Za-z0-9/]:\\\0:g' -e 's:/:)/?(:g' <<<
>"$2" || die)\)  
>> 
>> Explanatory comment needed, i.e. what gets converted into what, and
>why.
>
>I'll add this:
>
># The following line turns this:
>#  foo*foo/bar bar/baz/file.zip
>#
># Into this:
>#  ?(foo\*foo)/?(bar\ bar)/?(baz)/?(file\.zip)
>#
># This turns every path component into an escaped extended glob
># pattern to allow case-insensitive matching. Globs cannot span
># directories so each component becomes an individual pattern.

Why do you escape pattern chars? Wasn't the variable supposed to be a pattern 
in the first place?

-- 
Best regards,
Michał Górny (by phone)
-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] [PATCH 01/14] cdrom.eclass: Detect case-insensitively and handle special characters

2017-04-18 Thread James Le Cuirot 
On Tue, 18 Apr 2017 08:08:44 +0200
Michał Górny  wrote:

> On pon, 2017-04-17 at 22:53 +0100, James Le Cuirot wrote:
> > diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
> > index 41488d2446c2..de72f15563db 100644
> > --- a/eclass/cdrom.eclass
> > +++ b/eclass/cdrom.eclass
> > @@ -79,12 +79,13 @@ cdrom_get_cds() {
> > export CDROM_ROOT=${CD_ROOT_1:-${CD_ROOT}}
> > einfo "Found CD #${CDROM_CURRENT_CD} root at ${CDROM_ROOT}"
> > export CDROM_SET=-1
> > -   for f in ${CDROM_CHECK_1//:/ } ; do
> > +   IFS=:  
> 
> 'local', please.

This line disappears later in the series but I've amended it for the
history anyway.

> > @@ -181,28 +182,24 @@ _cdrom_locate_file_on_cd() {
> > local showedmsg=0 showjolietmsg=0
> >  
> > while [[ -z ${CDROM_ROOT} ]] ; do
> > -   local i=0
> > -   local -a cdset=(${*//:/ })
> > +   local i=0 cdset
> > +   IFS=: read -a cdset <<< "${*}"  
> 
> -r to avoid handling escapes; -d '' to avoid finishing on newline.

Good call.

> > @@ -243,4 +240,27 @@ _cdrom_locate_file_on_cd() {
> > done
> >  }
> >  
> > +# @FUNCTION: _cdrom_glob_match
> > +# @USAGE:  
> > +# @INTERNAL
> > +# @DESCRIPTION:
> > +# Locates the given path ($2) within the given root directory ($1)
> > +# case-insensitively and returns the first actual matching path. This
> > +# eclass previously used "find -iname" but it only checked the file
> > +# case-insensitively and not the directories. There is "find -ipath" but
> > +# this does not intelligently skip non-matching paths, making it
> > +# slow. Case-insensitive matching can only be applied to patterns so
> > +# extended globbing is used to turn regular strings into patterns. All
> > +# special characters are escaped so don't worry about breaking this. The
> > +# first person to make this work without an eval wins a cookie.
> > +_cdrom_glob_match() {
> > +   local p=\?\($(sed -e 's:[^A-Za-z0-9/]:\\\0:g' -e 's:/:)/?(:g' <<< "$2" 
> > || die)\)  
> 
> Explanatory comment needed, i.e. what gets converted into what, and why.

I'll add this:

# The following line turns this:
#  foo*foo/bar bar/baz/file.zip
#
# Into this:
#  ?(foo\*foo)/?(bar\ bar)/?(baz)/?(file\.zip)
#
# This turns every path component into an escaped extended glob
# pattern to allow case-insensitive matching. Globs cannot span
# directories so each component becomes an individual pattern.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpkMgCgMuOu9.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] cdrom.eclass: Near rewrite

2017-04-18 Thread James Le Cuirot 
On Tue, 18 Apr 2017 07:51:58 +0200
Ulrich Mueller  wrote:

> > On Mon, 17 Apr 2017, James Le Cuirot wrote:  
> 
> > If you've been wondering why I've been quiet of late (you have,
> > right?!) then this is partly why. I'm not sure why I spent so long
> > on an eclass that hardly anyone uses but it's utilised by many of my
> > old favourite games.  
> 
> Wouldn't this be a good time to rethink the whole concept? By all our
> standards, ebuilds shouldn't be interactive. AFAICS, cdrom.eclass is
> the last remnant in the tree using PROPERTIES="interactive".

mgorny makes good points, it is indeed not quite that simple.

I didn't actually notice the --accept-properties=-interactive feature
until just now, that's pretty cool.

Although I agree it should be avoided, there may be other uses for it
in future. I'd still like to go ahead with my lgogdownloader plan
(probably via a new src_fetch) and that may need it for entering
credentials on rare occasions though there are other possibilities.

> Maybe the eclass could be replaced by a utility that extracts the ISO
> image and places it into DISTDIR, so that ebuilds could use regular
> non-interactive unpacking? The additional disk space used shouldn't be
> an argument any more with today's large disks.

Don't assume everyone has such huge disks. ;) My main system isn't bad
but that doesn't mean I want to waste the space on something like this.
Many have written optical media off but I still have two big flight
cases full of discs of various kinds nearby.

No one is forced to use this stuff and it is possible to use it in a
non-interactive manner similar to how you suggest. You can copy the
files from the disc(s) and point CD_ROOT to this location in a
per-package env file.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpDGHji1Ztv1.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] stable gcc 5.4.0 ??

2017-04-18 Thread Tomas Mozes 
On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Hi,
>
> according the logs, gcc 4.5.0-r3 is stable for amd64:
> https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1
>
> However, after synching the tree, this version is still unstable for me.
> Looking at the packages overview, it becomes even more weird, because there
> seem to be two 4.5.0-r3 versions, one stable for amd64 and one unstable:
> https://packages.gentoo.org/packages/sys-devel/gcc
>
> Can someone shed some light on this?
>
> Cheers,
> Jörg
>
>
>
You did mean 5.4.0-r3, right?

Re: [gentoo-dev] Re: Re: stable gcc 5.4.0 ??

2017-04-18 Thread Tomas Mozes 
On Tue, Apr 18, 2017 at 3:12 PM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Tomas Mozes wrote:
>
> [snip]
>
> > As mentioned by others, bugs on packages.gentoo.org will not affect your
> > portage tree. I've just installed gcc 5.4.0-r3 on amd64, so try syncing
> > your portage tree. Don't you have it in your package.mask?
>
> As said, I synced the tree twice this morning (4 hours ago) and the
> KEYWORDS
> in the ebuild do not declare amd64 as stable although it was committed to
> GIT already yesterday. And this is no wonder, because the stable branch of
> the GIT mirror is still not up-to-date:
> https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc
>
> gcc-4.5.0-r3 is declared unstable and is not masked.
>
> Cheers,
> Jörg
>
>
>
According to git
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e2be964b72fce0cdb7c16a378b4fa3fa1d37ee38
- the KEYWORDS have amd64 and x86. The github mirror shows the same
https://raw.githubusercontent.com/gentoo-mirror/gentoo/stable/sys-devel/gcc/gcc-5.4.0-r3.ebuild.
Syncing the tree shows the same.

And as such, on a stable system:

# emerge -p gcc
[ebuild  NS] sys-devel/gcc-5.4.0-r3:5.4.0::gentoo [4.9.4:4.9.4::gentoo]
USE="cxx fortran (multilib) nptl openmp sanitize vtv (-altivec) (-awt)
-cilk -debug -doc (-fixed-point) -gcj -go -graphite (-hardened) (-jit)
(-libssp) -mpx -nls -nopie -nossp -objc -objc++ -objc-gc -regression-test
-vanilla" 0 KiB

The git message says it's stable, the bug report also, the mirrors too, so
yes, it is stable now. Maybe check another rsync mirror.

[gentoo-dev] Re: Re: Re: stable gcc 5.4.0 ??

2017-04-18 Thread Jörg Schaible 
James Le Cuirot wrote:

> On Tue, 18 Apr 2017 15:12:13 +0200
> Jörg Schaible  wrote:
> 
>> As said, I synced the tree twice this morning (4 hours ago) and the
>> KEYWORDS in the ebuild do not declare amd64 as stable although it was
>> committed to GIT already yesterday. And this is no wonder, because
>> the stable branch of the GIT mirror is still not up-to-date:
>> https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc
> 
> It's been held up by this outstanding issue:
> https://qa-reports.gentoo.org/output/gentoo-ci/58d678e2a/output.html#dev-db/psqlodbc
> 

Thanks for the info. Always good to know, why something does not behave as 
expected.

Cheers,
Jörg

Re: [gentoo-dev] [PATCH 7/7] chromium.eclass: Remove no-longer necessary gnome2_icon_savelist call

2017-04-18 Thread Mike Gilbert 
On Mon, Apr 17, 2017 at 7:07 AM, Michał Górny  wrote:
> ---
>  eclass/chromium.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/chromium.eclass b/eclass/chromium.eclass
> index 5f8c53cabf35..fcc02dd6e028 100644
> --- a/eclass/chromium.eclass
> +++ b/eclass/chromium.eclass
> @@ -120,7 +120,7 @@ chromium_remove_language_paks() {
>  }
>
>  chromium_pkg_preinst() {
> -   gnome2_icon_savelist
> +   :
>  }
>
>  chromium_pkg_postinst() {
> --
> 2.12.2

I last-rited this eclass back in February, so you can skip this patch.

Re: [gentoo-dev] Re: Re: stable gcc 5.4.0 ??

2017-04-18 Thread Aaron W. Swenson 
On 2017-04-18 14:27, James Le Cuirot wrote:
> On Tue, 18 Apr 2017 15:12:13 +0200
> Jörg Schaible  wrote:
> 
> > As said, I synced the tree twice this morning (4 hours ago) and the
> > KEYWORDS in the ebuild do not declare amd64 as stable although it was
> > committed to GIT already yesterday. And this is no wonder, because
> > the stable branch of the GIT mirror is still not up-to-date:
> > https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc
> 
> It's been held up by this outstanding issue:
> https://qa-reports.gentoo.org/output/gentoo-ci/58d678e2a/output.html#dev-db/psqlodbc

Oh, that’s ridiculous.

I’ve just dropped the particular ebuild that used pgsql-9.1 now.


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: Re: stable gcc 5.4.0 ??

2017-04-18 Thread James Le Cuirot 
On Tue, 18 Apr 2017 15:12:13 +0200
Jörg Schaible  wrote:

> As said, I synced the tree twice this morning (4 hours ago) and the
> KEYWORDS in the ebuild do not declare amd64 as stable although it was
> committed to GIT already yesterday. And this is no wonder, because
> the stable branch of the GIT mirror is still not up-to-date:
> https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc

It's been held up by this outstanding issue:
https://qa-reports.gentoo.org/output/gentoo-ci/58d678e2a/output.html#dev-db/psqlodbc

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[gentoo-dev] Re: Re: stable gcc 5.4.0 ??

2017-04-18 Thread Jörg Schaible 
Tomas Mozes wrote:

[snip]

> As mentioned by others, bugs on packages.gentoo.org will not affect your
> portage tree. I've just installed gcc 5.4.0-r3 on amd64, so try syncing
> your portage tree. Don't you have it in your package.mask?

As said, I synced the tree twice this morning (4 hours ago) and the KEYWORDS 
in the ebuild do not declare amd64 as stable although it was committed to 
GIT already yesterday. And this is no wonder, because the stable branch of 
the GIT mirror is still not up-to-date:
https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc

gcc-4.5.0-r3 is declared unstable and is not masked.

Cheers,
Jörg

Re: [gentoo-dev] Re: stable gcc 5.4.0 ??

2017-04-18 Thread Tomas Mozes 
On Tue, Apr 18, 2017 at 11:16 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Hi Tomas,
>
> Tomas Mozes wrote:
>
> > On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible <
> > joerg.schai...@bpm-inspire.com> wrote:
> >
> >> Hi,
> >>
> >> according the logs, gcc 4.5.0-r3 is stable for amd64:
> >> https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1
> >>
> >> However, after synching the tree, this version is still unstable for me.
> >> Looking at the packages overview, it becomes even more weird, because
> >> there seem to be two 4.5.0-r3 versions, one stable for amd64 and one
> >> unstable: https://packages.gentoo.org/packages/sys-devel/gcc
> >>
> >> Can someone shed some light on this?
> >>
> >> Cheers,
> >> Jörg
> >>
> >>
> >>
> > On which platform do you have it unstable? The packages problem is
> > probably related to:
> > https://bugs.gentoo.org/show_bug.cgi?id=612178
>
> Amd64.
>
> Yes, it might be the same problem. The ebuild for gcc-4.5.0-r3 on my
> machine
> lists amd64 as unstable after synching the tree while the ebuild available
> over packages.gentoo.org has a stable version in KEYWORDS.
>
> Even if some GIT mirrors might be out of sync, it does not explain why
> https://packages.gentoo.org/packages/sys-devel/gcc lists the same version
> more than once.
>
> Cheers,
> Jörg
>
>
>
As mentioned by others, bugs on packages.gentoo.org will not affect your
portage tree. I've just installed gcc 5.4.0-r3 on amd64, so try syncing
your portage tree. Don't you have it in your package.mask?

Re: [gentoo-dev] Re: stable gcc 5.4.0 ??

2017-04-18 Thread M. J. Everitt 
On 18/04/17 10:44, Mart Raudsepp wrote:
> Ühel kenal päeval, T, 18.04.2017 kell 11:16, kirjutas Jörg Schaible:
>> Hi Tomas,
>>
>> Tomas Mozes wrote:
>>
>>> On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible <
>>> joerg.schai...@bpm-inspire.com> wrote:
>>>
 Hi,

 according the logs, gcc 4.5.0-r3 is stable for amd64:
 https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showm
 sg=1

 However, after synching the tree, this version is still unstable
 for me.
 Looking at the packages overview, it becomes even more weird,
 because
 there seem to be two 4.5.0-r3 versions, one stable for amd64 and
 one
 unstable: https://packages.gentoo.org/packages/sys-devel/gcc

 Can someone shed some light on this?

 Cheers,
 Jörg



>>> On which platform do you have it unstable? The packages problem is
>>> probably related to:
>>> https://bugs.gentoo.org/show_bug.cgi?id=612178
>> Amd64.
>>
>> Yes, it might be the same problem. The ebuild for gcc-4.5.0-r3 on my
>> machine 
>> lists amd64 as unstable after synching the tree while the ebuild
>> available 
>> over packages.gentoo.org has a stable version in KEYWORDS.
>>
>> Even if some GIT mirrors might be out of sync, it does not explain
>> why 
>> https://packages.gentoo.org/packages/sys-devel/gcc lists the same
>> version 
>> more than once.
> This is a packages.gentoo.org Ruby on Rails webapp bug, and has
> absolutely nothing to do with some package being stable on an
> architecture or not. Don't let that disturb you.
>
>
> Mart
>
+1

CONFIRMED but fix unknown at present. Gcc is /not/ the only package that
is affected by the Ruby-on-Rails bug.

RESOLVED:DUPLICATE :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: stable gcc 5.4.0 ??

2017-04-18 Thread Mart Raudsepp 
Ühel kenal päeval, T, 18.04.2017 kell 11:16, kirjutas Jörg Schaible:
> Hi Tomas,
> 
> Tomas Mozes wrote:
> 
> > On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible <
> > joerg.schai...@bpm-inspire.com> wrote:
> > 
> > > Hi,
> > > 
> > > according the logs, gcc 4.5.0-r3 is stable for amd64:
> > > https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showm
> > > sg=1
> > > 
> > > However, after synching the tree, this version is still unstable
> > > for me.
> > > Looking at the packages overview, it becomes even more weird,
> > > because
> > > there seem to be two 4.5.0-r3 versions, one stable for amd64 and
> > > one
> > > unstable: https://packages.gentoo.org/packages/sys-devel/gcc
> > > 
> > > Can someone shed some light on this?
> > > 
> > > Cheers,
> > > Jörg
> > > 
> > > 
> > > 
> > 
> > On which platform do you have it unstable? The packages problem is
> > probably related to:
> > https://bugs.gentoo.org/show_bug.cgi?id=612178
> 
> Amd64.
> 
> Yes, it might be the same problem. The ebuild for gcc-4.5.0-r3 on my
> machine 
> lists amd64 as unstable after synching the tree while the ebuild
> available 
> over packages.gentoo.org has a stable version in KEYWORDS.
> 
> Even if some GIT mirrors might be out of sync, it does not explain
> why 
> https://packages.gentoo.org/packages/sys-devel/gcc lists the same
> version 
> more than once.

This is a packages.gentoo.org Ruby on Rails webapp bug, and has
absolutely nothing to do with some package being stable on an
architecture or not. Don't let that disturb you.


Mart

[gentoo-dev] Re: stable gcc 5.4.0 ??

2017-04-18 Thread Jörg Schaible 
Hi Tomas,

Tomas Mozes wrote:

> On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible <
> joerg.schai...@bpm-inspire.com> wrote:
> 
>> Hi,
>>
>> according the logs, gcc 4.5.0-r3 is stable for amd64:
>> https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1
>>
>> However, after synching the tree, this version is still unstable for me.
>> Looking at the packages overview, it becomes even more weird, because
>> there seem to be two 4.5.0-r3 versions, one stable for amd64 and one
>> unstable: https://packages.gentoo.org/packages/sys-devel/gcc
>>
>> Can someone shed some light on this?
>>
>> Cheers,
>> Jörg
>>
>>
>>
> On which platform do you have it unstable? The packages problem is
> probably related to:
> https://bugs.gentoo.org/show_bug.cgi?id=612178

Amd64.

Yes, it might be the same problem. The ebuild for gcc-4.5.0-r3 on my machine 
lists amd64 as unstable after synching the tree while the ebuild available 
over packages.gentoo.org has a stable version in KEYWORDS.

Even if some GIT mirrors might be out of sync, it does not explain why 
https://packages.gentoo.org/packages/sys-devel/gcc lists the same version 
more than once.

Cheers,
Jörg

Re: [gentoo-dev] stable gcc 5.4.0 ??

2017-04-18 Thread Tomas Mozes 
On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Hi,
>
> according the logs, gcc 4.5.0-r3 is stable for amd64:
> https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1
>
> However, after synching the tree, this version is still unstable for me.
> Looking at the packages overview, it becomes even more weird, because there
> seem to be two 4.5.0-r3 versions, one stable for amd64 and one unstable:
> https://packages.gentoo.org/packages/sys-devel/gcc
>
> Can someone shed some light on this?
>
> Cheers,
> Jörg
>
>
>
On which platform do you have it unstable? The packages problem is probably
related to:
https://bugs.gentoo.org/show_bug.cgi?id=612178

[gentoo-dev] stable gcc 5.4.0 ??

2017-04-18 Thread Jörg Schaible 
Hi,

according the logs, gcc 4.5.0-r3 is stable for amd64:
https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1

However, after synching the tree, this version is still unstable for me. 
Looking at the packages overview, it becomes even more weird, because there 
seem to be two 4.5.0-r3 versions, one stable for amd64 and one unstable:
https://packages.gentoo.org/packages/sys-devel/gcc

Can someone shed some light on this?

Cheers,
Jörg

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

2017-04-18 Thread 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.
>  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