Portage 2.1.8.3 (default/linux/x86/10.0, gcc-4.5.0-asneeded, glibc-2.11.2-r0, 2.6.34 i686) ================================================================= System uname: Linux-2.6.34-i686-Quad-Core_AMD_Opteron-tm-_Processor_2350-with-gentoo-2.0.1 Timestamp of tree: Sat, 19 Jun 2010 00:30:22 +0000 distcc 3.1 i686-pc-linux-gnu [disabled] ccache version 2.4 [disabled] app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r2, 3.1.2-r3 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.4_p6-r1, 1.5-r1, 1.6.3-r1, 1.7.9-r2, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.5.0 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 virtual/os-headers: 2.6.34 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/openjms/config /usr/share/X11/xkb /usr/share/bufrtables /usr/share/config /usr/share/qpsmtpd/plugins /var/bind /var/lib/hsqldb /var/phxd /var/spool/torque /var/vpopmail/etc /var/yp/Makefile" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/games/angband/edit/ /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe" DISTDIR="/var/cache/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms split-log strict test test-fail-continue unmerge-orphans userfetch userpriv usersandbox" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://gentoo.wheel.sk/" LANG="en_US.utf8" LDFLAGS="-Wl,-O1" MAKEOPTS="-j14" PKGDIR="/var/spool/portage/packages" PORTAGE_COMPRESS="" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cache/portage/tree-tinderbox" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl berkdb bzip2 cli cracklib crypt cups cxx dri fortran gdbm gpm iconv ipv6 java5 java6 modules mudflap ncurses nls nostatic nptl nptlonly openmp pam pcre perl pppd python qt3support readline reflection ruby session spl ssl sysfs tcpd unicode vhosts x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias auth_digest" ELIBC="glibc" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18 jruby ruby19 ree18" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lslines 1-44
Created attachment 235983 [details] Build log
This is solved by running snmpcheck outside of sandbox. @netmon: you're the net-snmp maintainers, care to find an alternative? :)
While bug 324777 and bug 324779 technically aren't duplicates, they show the same problem.
A few posts on the forum claim that this somehow depends on snmpd running - http://forums.gentoo.org/viewtopic-t-832879.html Yes, post's about libsoup, but it's the same error.
*** Bug 328053 has been marked as a duplicate of this bug. ***
*** Bug 328459 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > This is solved by running snmpcheck outside of sandbox. Not for me it isn't.
This was "fixed" in php5_2-sapi.eclass by adding an addpredict for the offending file. I can't say why this happens, but I've re-added the fix to the overlay ebuild (layman -a php, if you want to test) and will migrate it shortly, if there's no proper fix.
(In reply to comment #7) > (In reply to comment #2) > > This is solved by running snmpcheck outside of sandbox. > > Not for me it isn't. > In the name of accuracy: Turns out, this was as I did not yet have my KDE environ configured on the system where I was running into this problem. With KDE up, I can actually run snmpcheck and then re-emerge php with no sandbox error.
(In reply to comment #4) > A few posts on the forum claim that this somehow depends > on snmpd running - http://forums.gentoo.org/viewtopic-t-832879.html > Yes, post's about libsoup, but it's the same error. > I can confirm this bug on my system, Intel C2D running ~AMD64. I can post the build into and emerge --info if requested. I did try Willard's suggestion of running snmpcheck before, but the only thing that fixed was some broken Perl modules that I had to recompile. What I found to work, was copying the snmp.conf.example, to snmp.conf, and starting snmpd. Then sure enough, I restarted the emerge of PHP, and it finished without any Sandbox errors. I'm really not sure why it needs to run, but at least it fixed it for compile. And of course I stopped the service after I finished the emerge.
*** Bug 329469 has been marked as a duplicate of this bug. ***
Stupid question I'm sure, but has anyone tried merging w/ USE=-phar?
Yep, stupid question. traced it down to snmp's add_mibdir, which is proving problematic to trace back to candidates in php... This is reproducible by just wiping the .index; it's a cache basically. The reason running snmp once fixes it is that it generates the cache on first read of the mibs dir...
I must be special. I confirmed that snmpd wasn't running on my system -- "ps -ef | grep snmp". As per comment #10, I copied snmpd.conf.example to snmpd.conf. I then did /etc/init.d/snmpd start emerge php No joy. I stopped the snmpd service. As per a reply in the thread referenced in comment #4, I tried: emerge -C net-snmp && emerge libsoup && emerge net-snmp && emerge php Alas, still no joy. Going back to comment #10, I again tried: /etc/init.d/snmpd start emerge php Happy! Happy! Joy! Joy! I suggest that perhaps the default for phar support should be USE="-phar". I can't see that anyone who doesn't have snmpd running is going to want 'phar' support. When USE='phar' then there appears to be some additional configuration which needs to be checked. Point of reference: Needing to unmerge net-snmp and reemerging libsoup and then net-snmpd suggests to me that packages dependent on libsoup should be re-emerged after libsoup is updated. i.e. through library specific revdep-rebuild. I am not a dev and I am not programmer and I don't really know anything. Just thought I'd mention it. Currently, this is the completion message I get from libsoup: >>> Installing (1 of 1) net-libs/libsoup-2.30.2-r1 * Updating desktop mime database ... * Updating shared mime info database ... * No GNOME 2 GConf schemas found * Updating desktop mime database ... * Updating shared mime info database ... >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date.
mabi: I wrote the original addpredict for that directory, way back in the sands of time with the first PHP5 on Gentoo. The problem isn't limited to PHP, but to ANY ebuild that runs a binary linked against some of net-snmp. This is due to the initialization handler for the net-snmp lib being sloppy. Use the addpredict for now, there's not really much other choice.
Thanks for the analysis to ferring & robin. I've fixed the eblit and added a comment with a reference to this bug. If the error persists, please comment and/or reopen.
Doesn't work for me, as the eblit fix is for src_install only, whereas I encounter the sandbox violation in src_compile already. The log from comment #1 looks pretty much like mine. It too reports sandbox violations after src_compile but before src_install. As a further indication, I get the sandbox error if I only execute "ebuild php-5.3.3.ebuild compile". Adn the environment doesn't mention the predict, as that eblit hasn't been sourced. Please someone REOPEN this report, I lack permission to do so.
Created attachment 240675 [details] Build Log I too am still getting the same error message with 5.3.3. Attached is my build log. Also I am unable to reopen it.
Created attachment 240677 [details] See Comment (--info & -pv) Attached for reference if my --info, and emerge php -pv, to show use flags.
Crap, I didn't want to make a third comment, but I can't edit the others.. so... Starting /etc/init.d/snmpd does indeed let the compile finish correctly, again.
(In reply to comment #20) > Crap, I didn't want to make a third comment, but I can't edit the others.. > so... Starting /etc/init.d/snmpd does indeed let the compile finish correctly, > again. > I noticed there are still problems with some systems regarding this,I personally have just emerged php-5.3.3 with this weeks updates and had no problems. Recently my x86_64 updated perl ,I ran perl-cleaner afterwards and it was responsible for updating some 64 files. If you have recently updated perl I would suggest that you do the same,if not already. Just in case this has some bearing on the problem,I do have the snmp.conf file in /etc ,so this may not be related, just a suggestion.
Okay, now that's weird. The old addpredict was in src_install, so I figured adding it back in there would fix the problems. Have you guys synced recently and verified the addpredict is indeed in the src_install eblit?
*** Bug 330555 has been marked as a duplicate of this bug. ***
I --sync'd last night: -- Taranis php # cat php-5.3.3.ebuild | grep -c addpredict 0 -- So it doesn't look like it made it then... I also just resync'd, and it still shows 0. I hope I'm looking in the right place. However after this last sync, it compiles perfectly fine....
(In reply to comment #24) > So it doesn't look like it made it then... > I also just resync'd, and it still shows 0. I hope I'm looking in the right > place. > You are not :) The phase functions are located in individual files in files/eblits % grep -c addpredict files/eblits/src_install-1.eblit 1
Ah.. in that case, it is there now, which would explain why it worked when I tried to recompile. Sadly I can't go back in time to see if it was there for last night's sync... but I got a feeling I got it right before it was changed.
hwoarang@Mystical ~/development/gentoo-cvs/gentoo-x86/dev-lang/php $ grep -c addpredict files/eblits/src_install-v1.eblit 1 Still php fails here with sandbox violations Synced 5' ago ps: Note the file is src_install-v1.eblit and not src_install-1.eblit
(In reply to comment #22) > Have you guys synced recently and verified the addpredict is indeed in the > src_install eblit? Encountered error, synced, checked for CVS rev 1.6 of the eblit (1.5 added the supposed fix), ran "ebuild php-5.3.3.ebuild clean merge" again, encountered error again, ran "ebuild php-5.3.3.ebuild clean compile", still encountered error. So the problem surely is in compile now, no matter where it used to be in the past.
Ok, I ran into this again tonight... this time I looked a bit more at the mibs/.index file. The main reason I did this, is when I tried to compile, and it filed, I noticed snmpd was already running. So, the mibs/.index file had a datestamp of Jul 30. When I stopped, started, and stopped snmpd, the datestamp changed to Aug 2nd. And at that point, php was able to compile perfectly fine. I'm not sure if this is noise, or helping, but I figured if it can help in the least, it's worth putting up :)
5.3.3-r1 compiled without me having to make any changes. This is a week after I had issues. Previously, it was compiled fine, then three days later it wouldn't. Anything change regarding this bug in r1?
(In reply to comment #30) > 5.3.3-r1 compiled without me having to make any changes. This is a week after I > had issues. Previously, it was compiled fine, then three days later it > wouldn't. Anything change regarding this bug in r1? > Same story here with 5.3.3 building but 5.3.3-r1 not due to this recurring sandbox violation. I vote "most annoying bug" for the month.
(In reply to comment #29) > Ok, I ran into this again tonight... this time I looked a bit more at the > mibs/.index file. The main reason I did this, is when I tried to compile, and > it filed, I noticed snmpd was already running. > So, the mibs/.index file had a datestamp of Jul 30. When I stopped, started, > and stopped snmpd, the datestamp changed to Aug 2nd. > And at that point, php was able to compile perfectly fine. > > I'm not sure if this is noise, or helping, but I figured if it can help in the > least, it's worth putting up :) > This sequence of starting and stopping snmpd did not work for me with dev-lang/php-5.3.3-r1. At this point, I cannot emerge this package.
I've added the same addpredict we do for src_install to src_compile. The fix should be on the mirrors soon. Please resync and retry. Sorry for those cycles, this is a really ugly problem :/
I haven't touched the machine since the last recompile, and I was able to sync and compile without any issues.
In the hopes of having fixed all issues, I'm closing this now. If the error creeps back up, please comment and/or reopen.
