Bugzilla Bug 196720

any machine using glibc-2.7 gets sandbox failures on just about anything
(usually complaining about /etc/passwd and /etc/group when they get opened for
reading *only*)

27502 open("/etc/group", O_RDONLY|0x80000 /* O_??? */) = 5

the new flag 0x80000 causes the failure

# define O_CLOEXEC     02000000 /* Set close_on_exec.  */

(in hex, that is 0x80000)

Is it possible to have the glibc-2.7 ebuild masked as opposed to having a die
command with a note to review this bug?

While this is a very interesting bug, it doesn't offer suggestions as to how to
overcome the upgrade issue.

(1) it is masked seeing as how it doesnt have any KEYWORDS
(2) there is no solution in the message because none currently exists

looks like the "e" fopen() for cloexec pisses it off

fixed in 1.2.18.1-r2

*** Bug 198509 has been marked as a duplicate of this bug. ***

Alright, went back to glibc 2.6.1, and portage emerges fine with sandbox

but still: someone needs to fix it for glibc 2.7...

it's already been fixed, hence the bug being closed as "FIXED"

In case anyone gets trapped in a catch-22 where glibc-2.7 got installed and now
they can't emerge the new sandbox or anything for that matter, execute 

export FEATURES="-sandbox" 

and then you can emerge the new sandbox. 

"got installed" implies the package should have been on your system when
there's absolutely no way it could have been without the user putting glibc
into accept keywords locally

at any rate, that should work, but if it doesnt, i just do:
rm /usr/lib/libsandbox*
emerge sandbox

*** Bug 201409 has been marked as a duplicate of this bug. ***

it looks like this was caused by a bug in portage
the new version of sandbox failed, but then emerge --resume --skipfirst went a
ahead and installed the version of glibc that depended on sandbox without it
being at the right version

--skipfirst is a powerful tool ... portage isnt going to protect you from doing
something stupid with it

there are related feature requests in portage, but you telling emerge to do
something dumb isnt a bug in portage

*** Bug 198509 has been marked as a duplicate of this bug. ***

i still have this bug with 
sys-apps/sandbox-1.3.2
sys-libs/glibc-2.9_p20081201-r1
shouldn't this be reopened?

once you verify that your system has no stale libsandbox binaries in /lib*/,
open a new bug.  i doubt you're having the same problem here.

(In reply to comment #15)
> once you verify that your system has no stale libsandbox binaries in /lib*/,
gosh.. i'm embarassed
sorry

np ... i'll add a sanity check to the sandbox ebuild

(In reply to comment #15)
> once you verify that your system has no stale libsandbox binaries in /lib*/,
> open a new bug.  i doubt you're having the same problem here.
> 

Someone should have told me earlier to delete those files!
I was running portage with -sandbox since about over one year now, but now it
works with the sandbox again.