Created attachment 174009 [details] cnagios-0.33-2016082300.patch Hi all! I've just released cnagios 0.33 via github, which includes a few important user-contributed fixes. * Fix segfault in time parsing (pull #5 from Peter Hill) * Add support for Nagios 4.x status files (pull #4 from Peter Hill) Attached is a patch that bumps the distinfo and package version. Note that I've removed the dependency on net-mgmt/nagios, as the cnagios port now works with either net-mgmt/nagios *or* net-mgmt/cnagios. However, I can't find a clean way to represent that logic with the *_DEPENDS variables. If someone knows a best practices way to do deal with that, I'm curious. So, as things sit right now I think it's fairly reasonable to yank the nagios dependency, since: 1) All the other nagios-related ports (such as the nagios-plugins, monitoring-plugins, nagios-plugin-*, etc) also choose not to depend on a specific flavor of nagios, probably for this same reason. 2) You have to have nagios up and running before it's possible to install cnagios, due to the nagios status.dat checks that run during configure time, and as such no *_DEPENDS variable will work for automating this port. 3) Specifying a version via the "--with-nagios-data" option doesn't actually do anything to prevent the need to query Nagios' status.dat file. 4) The cnagios utility doesn't link against nagios at all, and in theory could be installed without nagios and used only for parsing of status.dat files. Thoughts? The real fix is to clean up the build process upstream, which I plan to address in a future release. But for now, we probably shouldn't block Nagios 4.x users since cnagios now works equally well with 3.x and 4.x.
Pardon, I meant to say "works with net-mgmt/nagios or net/mgmt/nagios4".
Hi! I think you should take maintainership, Danny :). What do you think about it?
It fails to build if no nagios is installed. Is this to avoid a fixed dependency on nagios or nagios4 ? If not, can you add a BUILD_DEPEND on nagios4 ?
You're right, it does do a check for a live nagios status.dat file if you don't pass in an explicit version variable at config time. So, looks like it's always going to have problems building in this way, as it is looking for a live running nagios install to pull the version from at build time - which will never exist on a package build box or poudriere. Locking it to nagios4 would work, since passing the the version in via "--with-nagios-data" prevents it from looking for a live nagios install. But that would be unfortunately, since it works great with net-mgmt/nagios. Is there a sane way to add a dependency on net-mgmt/nagios *or* net-mgmt/nagios4? Given that I have control of upstream now, I could also fix the build process there to not be so brittle, too.
Yes, if possible, fix it upstreams. A warning at runtime is much better than a fail at buildtime.
There's a way using OPTIONS, but it hard-codes the version into the pkg from the pkg-builders (which it should not, if it is not necessary).
Agreed. I'll fix it upstream so that cnagios doesn't require a live nagios instance at build time. I'll submit a new patch after that.
(In reply to alexander.4mail from comment #2) Alexander, I'd love to take maintainership of this port, as long as that is acceptable to the freebsd-ports folks. I stare at cnagios all day on several production systems, so there will definitely be some eyeballs on it.
Btw, does it also work with icinga2 ?
(In reply to Kurt Jaeger from comment #9) Good question. It *should*, since I believe they have the same status.dat format, but I've never tried it. I'll verify that when testing the upstream build fixes.
A commit references this bug: Author: ohauer Date: Sat Sep 17 17:54:25 UTC 2016 New revision: 422337 URL: https://svnweb.freebsd.org/changeset/ports/422337 Log: - change MAINTAINER PR: 212102 Approved by: alexander.4mail@gmail.com (old maintainer) Changes: head/net-mgmt/cnagios/Makefile
Hi all, sorry about the delay in implementing the upstream fixes required to fix this PR, I've been swamped at $dayjob the past few weeks. I should be able to get this wrapped up in the next week. Thanks everyone!
Hi, any news one this one?
(In reply to Ruslan Makhmatkhanov from comment #13) Hi! I'm planning on picking this back up and getting it finished in the next few weeks, apologies again for the delay.
Ok, just pinging to make sure it still actual :). Thanks for response!
(In reply to Ruslan Makhmatkhanov from comment #15) Understood, and appreciated! :)
All - I just noticed some movement on this bug and realized I've been punting this fix for way too long. The proper fix requires some heavy work on upstream cnagios to make everything work cleanly with just build flags alone to avoid nasty workarounds on the ports Makefile side. I just haven't been able to get to that bigger work, it's messy. The above patch would unblock cnagios 0.33 for the use case mentioned in this bug, but doesn't fix the big picture problems with cnagios, but it definitely doesn't do things the right way for a sensible port Makefile. Not sure what to do here. Ideas?
Closing this bug, as this has gone past its original scope. I need to incorporate all the feedback from this PR along with a few github bugs and rework the project in to an application agnostic one. I will track this on the upstream side, and then submit a new PR and a version bump once the upstream work is done. If anyone objects, I'm happy to reopen. Thanks everyone for all the advice here.