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
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.
