this sais it it all (vim won't build after rsyncing): --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-vim-6.1-r8-17415.log" chmod: /dev/pty/s0 chmod: /dev/pty/s0 -------------------------------------------------------------------------------- !!! emerge aborting on /usr/portage/app-editors/vim/vim-6.1-r8.ebuild .
Uh it should work now.. my mistake
I rsync and remerged vim now, and this is funny (one pty more): --------------------------- ACCESS VIOLATION SUMMARY ---------------------------LOG FILE = "/tmp/sandbox-vim-6.1-r8-4145.log" chmod: /dev/pty/s1 chmod: /dev/pty/s1 --------------------------------------------------------------------------------!!! emerge aborting on /usr/portage/app-editors/vim/vim-6.1-r8.ebuild .
Ok this is past funny now, once it fails on s0, then s1, than thats fixed and then s2 now back to s0 again: --------------------------- ACCESS VIOLATION SUMMARY ---------------------------LOG FILE = "/tmp/sandbox-vim-6.1-r8-3478.log" chmod: /dev/pty/s0 chmod: /dev/pty/s0 --------------------------------------------------------------------------------
Ok at which point in the ebuild does this happin install or make stage? Also are you sshed into the box and trying to emerge vim? maybe try this: ebuild vim-6.1-r8.ebuild compile ebuild vim-6.1-r8.ebuild install ebuild vim-6.1-r8.ebuild merge see where it breaks at.. I need more info.. the addpredict line should be working..but it's in the src_compile() stage only.. Naz
I have the same sandbox violation as Milosz. I found out that it only happens when emerging from within an X terminal (gnome-terminal) and that the /dev/pty/s? is obviously the terminal from which you emerge (thus the different numbers). Emerging from console (/dev/vc/1) is ok. hth, Markus
Markus I still cant' reproduce the bug locally.. can you maybe try to add this line into the ebuild right under the addwrite /dev/pty/* line addpredict /dev/pty/* or maybe under the src_install() { addpredict /dev/pty/* try both and see what happens, tell me if it works or not. Naz hmm well maybe I will just add the ebuild in few with these updates.. along with a digest and have your test with those.. :o)
Tried 'addpredict' in src_compile and src_install with no luck -> still same access violation. I did another test and did # USE="-*" emerge vim and I got the same violation but instead of 2 times "chmod: /dev/pty/s1" I only got it once. I'm currently short on time but I will have a deeper look into this bug maybe weekend. Until then, here are some more information to reproduce this error: profile: default-1.0-gcc3 kernel: 2.4.19-gentoo-r7 CFLAGS="-march=athlon-tbird -O3 -fomit-frame-pointer -pipe" glibc-2.2.5-r5 gcc-3.1-r7 emerge is done in a gnome-terminal-2.0.0-r1 when the violation occurs. Markus
its like bug #5766
If you look into the configure script of vim you find a section that tests if the /dev/pty's are world writeable (line 5683ff). For that purpose there's a small program that looks like that: main() { struct stat sb; char *x,*ttyname(); int om, m; FILE *fp; if (!(x = ttyname(0))) exit(1); if (stat(x, &sb)) exit(1); om = sb.st_mode; if (om & 002) exit(0); m = system("mesg y"); if (m == -1 || m == 127) exit(1); if (stat(x, &sb)) exit(1); m = sb.st_mode; if (chmod(x, om)) exit(1); <---- causes sandbox violation if (m & 002) exit(0); if (sb.st_gid == getgid()) exit(1); if (!(fp=fopen("conftest_grp", "w"))) exit(1); fprintf(fp, "%d\n", sb.st_gid); fclose(fp); exit(0); } The marked line causes the sandbox violation. (Oddly enough the "mesg y" doesn't cause sb violation!) 2 questions: 1) Why does vim check for world writeable perms on these files? 2) Shouldn't "addwrite /dev/pty/*" allow the chmod? -Markus-
addwrite /dev/pty/* is in the newest vim r9? is this still a issue for you guys? I would love to hear.. Naz
addwrite has already been in r8 and it didn't work. However, it works for me now with r10 (r8 now works, too!!).
Ok I finally think this one is dead, I'm going to say this one is fixed. I hope you agree Naz
