Summary: | dev-php/PEAR-DB-1.6.8 and other PEAR packages sandbox violation | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jakub Moc (RETIRED) <jakub> |
Component: | New packages | Assignee: | PHP Bugs <php-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bravecobra, dago158, duke, in-gentoo, jesse, llarian, nils, rockoo, stefano, tm-8rjpk, vapier |
Priority: | Highest | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jakub Moc (RETIRED)
2005-04-11 00:59:52 UTC
Same result for PEAR-Auth_SASL-1.0.1, PEAR-Net_SMTP-1.2.6 and probably many other PEAR packages. :-/ I cannot reproduce with FEATURES="sandbox" emerge PEAR-DB Besides that, the PECL and PEAR ebuilds only act as a wrapper for the PEAR Installer an call "pear install <package>". To the best of my knowledge the PEAR Installer will not touch and file it did not install itself and certainly not files like /var/lib/net-snmp/snmpapp.conf. I tried without userpriv and usersandbox, but it does not help - same result. This is after upgrade to 4.3.11. Upgrading to 4.3.11 unmerges a lot of PEAR packages. This is what I get with 4.3.10 and 4.3.10-r1: # pear list Installed packages: =================== Package Version State Archive_Tar 1.1 stable Console_Getopt 1.2 stable DB 1.6.2 stable HTTP 1.2.2 stable Mail 1.1.3 stable Net_SMTP 1.2.6 stable Net_Socket 1.0.1 stable PEAR 1.3.2 stable XML_Parser 1.0.1 stable XML_RPC 1.1.0 stable Now with 4.3.11: # pear list Installed packages: =================== Package Version State Archive_Tar 1.1 stable Console_Getopt 1.2 stable HTML_Template_IT 1.1 stable Net_UserAgent_Detect 2.0.1 stable PEAR 1.3.5 stable XML_RPC 1.2.2 stable Itself this would not be a problem (some advice on this result of upgrade would be useful though) but the sandbox violation is bad. This probably seems related to php/mod_php emerged USE="snmp". This problem is related to php-4.3.11. I spent a couple of hours digging into it last night, but didn't track down the culprit code. I'm still looking, and hopefully will get to the bottom of it soon. In the meantime, add this: addpredict /var/lib/net-snmp/ to the pear eclass's src_install() as a workaround. PHP won't be able to write to the file (so you'll see some warnings on the screen), but the install will succeed. Best regards, Stu Wow, thanks, Stuart! Now it f*cks up on FEATURES="collision-protect" but this can be easily "fixed" ;-) * checking 63 files for package collisions existing file /usr/lib/php/php/.filemap is not owned by this package existing file /usr/lib/php/php/.lock is not owned by this package * spent 0.0195341110229 seconds checking for file collisions * This package is blocked because it wants to overwrite * files belonging to other packages (see messages above). * If you have no clue what this is all about report it * as a bug for this package on http://bugs.gentoo.org package dev-php/PEAR-DB-1.6.8 NOT merged Now I finally got success, emerged it and cron stopped spitting out an annoying email with error message every five minutes (I am using a PHP script to move spam to DB email quarantine). The issue with FEATURES="collision-protect" should be gone once we have separated PECL and PEAR from PHP itself. Sebastian: Sure, no problem. You can close this bug if you want - or wait until Stuart figures it out ;-) Thanks to everyone. Found a link to fix in Bug 88857. Upstream does not consider this to be a bug so this probably won Found a link to fix in Bug 88857. Upstream does not consider this to be a bug so this probably won´t be fixed there. Besides, mod_php-{4.3.11,4.3.11-r1} should depend on >=net-snmp-5.2.1. http://bugs.php.net/bug.php?id=32613&edit=0 *** Bug 88849 has been marked as a duplicate of this bug. *** *** Bug 88857 has been marked as a duplicate of this bug. *** Ok, sorry for coming up here sounding like a fool, but what's the story here? I've got my system screwed up the same way, or maybe more, but anyway I'm getting the same errors when I try to install PEAR-DB, which is new on my system but now required. I see that you all seem to have maybe fixed them yourselves, but not for the general public? I don't quite understand how to perform the fix (well, ok, more specifically I don't know where "the pear eclass's src_install()" is), but I also can't decide from the bug whether I should just sit back and wait until it gets fixed by the package maintainers. Is it something that's going to be fixed directly, and I should just wait, or do I need to go ahead and work around it, and if the latter, how? Also, do you guys figure this is related to the php weirdness I've been having? I upgraded to 4.3.11 when it came into x86, and about a week later I noticed all my previously-working php was segfaulting. So was 'php -i' and anything else php from the command line (mod_php was working fine). I tried to remerge, and that segfaulted too. Nothing I tried to fix it worked, until I rebooted the box on a whim. Then the remerge worked fine and it didn't segfault. So I went on about my business...that was about a week ago, and nothing bad happened until this morning, when I noticed that everything segfaulted again. Rebooting the box fixed it, and was the first thing I tried. How crazy is that? But anyway, that whole time (well, starting right after the successful php build following the first reboot) I haven't been able to build PEAR-DB for the same reasons cited by this bug. Comment #11: See Comment #4 - just pust that line into /usr/portage/eclass/php-pear.eclass to php_pear_src_install () P.S. If you have PHP randomly segfaulting then it is not this bug but possibly a broken hardware. PHP herd - could someone implement the eclass workaround now? Does not look like a real fix will be available anytime soon and Stuart is probably away now. *** Bug 90524 has been marked as a duplicate of this bug. *** Thanks Jakub, that was just the clarification I was looking for; built fine with that edit. Figured it was a long shot on the PHP weirdness, but thought I'd ask anyhow. Don't know about the hardware failure; there has been absolutely no other strange behavior on the box. But I'm looking into it; too bad it's a colo that I lack physical access to. Anyway, thanks again for the help. So, can the fix be placed in Portage sometime soon? Thanks! ping - a fix plz net-analyzer/net-snmp-5.2.1 stable dev-php/mod_php-4.3.11 stable alot dev-php/pear-pkg stable, but NOT working and a open bug for 4 weeks :( I committed Stuart's patch for the php-pear.eclass. Closing. *** Bug 90315 has been marked as a duplicate of this bug. *** |