pnp4nagios fails to emerge citing a requirement for php to be emerged with pcre use flag enabled. PHP verison 5.3.3.-r1 does not have a pcre use flag Reproducible: Always Steps to Reproduce: 1. emerge pnp4nagios Actual Results: Fails Expected Results: pnp4nagios to install
Created attachment 251293 [details] emerge --info output
Created attachment 251295 [details] pnp4nagios emerge output
Created attachment 251297 [details] php emerge -pv output showing use flags
ldd /usr/bin/php | grep pcre shows php is using libpcre.so.0 ... a check of php shows the pcre use flag has not been present since version 5.2.14. Removing pcre from the required use flag on line 29 allowed the package to build; however, when run multiple php errors occur related depreciated and bad functions. Unmasking pnp4nagios versions 0.6.4 or 0.6.5 will force a php version downgrade to version 5.2.14 at emerge. I don't know why pnp4nagios version 0.6.5-r1 was pulled in as part of an emerge --update without unmasking it.
I fail to reproduce this with 0.6.7, please test and report back.
Fresh install of pnp4nagios version 0.6.7 installs without complaint; however, attempting to access the pnp web interface results in a 404 looking for "graph" in the root of /usr/share/pnp. This appears to be due to the default config assuming url rewriting is configured for apache. Perhaps a post-install message can be added warning of this? Please note that this test was run on gentoo x86_64 and I will test again on the x86 system this bug was filed on when I get to work on Monday.
(In reply to comment #6) > This appears to be due to the default config assuming url rewriting is > configured for apache. Perhaps a post-install message can be added warning of > this? Sounds like a plan. > Please note that this test was run on gentoo x86_64 and I will test again on > the x86 system this bug was filed on when I get to work on Monday. > Okies :)
Tested on x86 ... installed and working. XML files under /var/nagios/perfdata also had to be removed as per the upgrade guide. Marking this bug as closed.
(In reply to comment #7) > (In reply to comment #6) > > This appears to be due to the default config assuming url rewriting is > > configured for apache. Perhaps a post-install message can be added warning of > > this? > > Sounds like a plan. Fixed in CVS.