here is the snip >>> Emerging (1 of 3) media-libs/libvpx-0.9.0_p20100612 >>> Downloading 'ftp://mirror.isoc.org.il/gentoo/distfiles/libvpx-0.9.0_p20100612.tar.bz2' --2010-06-16 10:49:31-- ftp://mirror.isoc.org.il/gentoo/distfiles/libvpx-0.9.0_p20100612.tar.bz2 => `/usr/portageTree/portage/distfiles/libvpx-0.9.0_p20100612.tar.bz2' Resolving mirror.isoc.org.il... 192.115.211.70 Connecting to mirror.isoc.org.il|192.115.211.70|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD (1) /gentoo/distfiles ... done. ==> SIZE libvpx-0.9.0_p20100612.tar.bz2 ... 1184266 ==> PASV ... done. ==> RETR libvpx-0.9.0_p20100612.tar.bz2 ... done. Length: 1184266 (1.1M) (unauthoritative) 100%[===================================================>] 1,184,266 1.06M/s in 1.1s 2010-06-16 10:49:33 (1.06 MB/s) - `/usr/portageTree/portage/distfiles/libvpx-0.9.0_p20100612.tar.bz2' saved [1184266] * libvpx-0.9.0_p20100612.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * CPV: media-libs/libvpx-0.9.0_p20100612 * REPO: gentoo * USE: amd64 elibc_glibc kernel_linux mmx multilib sse sse2 sse3 ssse3 threads userland_GNU >>> Unpacking source... >>> Unpacking libvpx-0.9.0_p20100612.tar.bz2 to /var/tmp/portage/media-libs/libvpx-0.9.0_p20100612/work >>> Source unpacked in /var/tmp/portage/media-libs/libvpx-0.9.0_p20100612/work >>> Preparing source in /var/tmp/portage/media-libs/libvpx-0.9.0_p20100612/work/libvpx-0.9.0_p20100612 ... >>> Source prepared. >>> Configuring source in /var/tmp/portage/media-libs/libvpx-0.9.0_p20100612/work/libvpx-0.9.0_p20100612 ... Configuring selected codecs enabling vp8_encoder enabling vp8_decoder Configuring for target 'x86_64-linux-gcc' enabling x86_64 enabling runtime_cpu_detect enabling mmx enabling sse enabling sse2 enabling sse3 enabling ssse3 Creating makefiles for x86_64-linux-gcc libs Creating makefiles for x86_64-linux-gcc examples Creating makefiles for x86_64-linux-gcc docs >>> Source configured. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-6306.log" VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /usr/share/snmp/mibs/.index A: /usr/share/snmp/mibs/.index R: /usr/share/snmp/mibs/.index C: php -v -------------------------------------------------------------------------------- >>> Failed to emerge media-libs/libvpx-0.9.0_p20100612, Log file: >>> '/var/tmp/portage/media-libs/libvpx-0.9.0_p20100612/temp/build.log' Starfleet ffmpeg # cat /var/log/sandbox/sandbox-6306.log VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /usr/share/snmp/mibs/.index A: /usr/share/snmp/mibs/.index R: /usr/share/snmp/mibs/.index C: php -v Reproducible: Always
Created attachment 235575 [details] emege --info
I've went around it by unmergeing net-analyzer/net-snmp, emergeing libvpx and reemerging net-analyzer/net-snmp.
I've solved it by using a workaround but it isn't solved in general. someone said it might be related to the fact that I have php installed with the doc flag.
Looks like php is at fault, anybody could suggest a solution?
Please see http://bugs.gentoo.org/show_bug.cgi?id=324739#c15 for an explanation why this is *not* php's fault. It's basically snmp fscking up. You need to addpredict the file where the hickup happens.
I've also got this happening on amd64 with the latest media-libs/libvpx-0.9.5. Similar setup as previously described, php installed with doc use-flag. Any way of getting around this?
In my case I got around the problem by * Adding the line media-libs/libvpx -doc to /etc/portage/package.use . This removes the dependency on php. * Uninstalling php (otherwise the ebuild will still try to use it). After doing the above, the package emerged fine. It seems that it might be possible to avoid the sandbox violation by prepopulating the snmp cache, but I didn't succeed in my trivial tests. If you actually need the libpvx documentation, you can of course emerge the ebuild with FEATURES=-sandbox (not recomended).
I tried with: sudo USE="-doc" emerge libvpx and it shows that it's emerging with -doc, but it still errors out the same way.
Has there been any progress made on this? There's been several version/revision bumps that keep requiring the removal of snmp and then readding just to get this completely unrelated package installed. This seems like a core problem of net-snmp storing cache data in /usr, but checking other bugs for this, I couldn't find any mention of it getting fixed. Does someone in netmon@g.o have an upstream bug for this, or just somewhere we could check on progress of getting rid of this bug properly rather than addpredicting all the afflicted packages?
*** This bug has been marked as a duplicate of bug 249496 ***
