[Pkg-nagios-devel] Bug#736331: Bug#736331: nagios-plugins: Nagios plugins renamed to monitoring plugins

Jan Wagner waja at cyconet.org
Tue Jan 28 15:36:23 UTC 2014

Hash: SHA1

Hi Robie,

you can join us (upstream) on IRC on freenode/#Monitoring-Plugins, I`m
spy6 there.

Am 28.01.14 15:04, schrieb Robie Basak:
> On Wed, Jan 22, 2014 at 02:30:04PM +0100, Jan Wagner wrote:
>>> At the very least the homepage in the source package should
>>> move from http://nagiosplug.sourceforge.net to 
>>> https://www.monitoring-plugins.org/ ; also, the package name
>>> should probably be renamed to monitoring-plugins.
>> We have a fix in our VCS already.
> I don't see this at: 
> http://anonscm.debian.org/viewvc/pkg-nagios/nagios-plugins/trunk/debian/

switched over to git (more or less) recently:


> Is there a different public branch I should be looking at?
> I work for Canonical and am on the Ubuntu Server Team. I have
> concerns about the fork, since in our next release in April we'd be
> committing to support src:nagios-plugins for 5 years, and our
> security team will commit to security releases for 5 years, and I
> don't want us to lose an upstream.

I would (Ubuntu) recommand to be stick with 1.5 eventually. If you
want, I could upload the actual 1.5-2 (keep in mind that the
debian/changelog is getting generated by git-dch).
The 1.6 release shouldn`t be too far, but this would be a rush.

> This is time critical for us in Ubuntu - we feature freeze in mid
> Feb. It would be easiest for us if we were aligned with Debian
> here, but due to our imminent release we may have to do something
> ahead of Debian.
> I'm wondering what your plans are here, in terms of which
> upstreams you'll be packaging, and how you'll do the transition. Do
> you mind sharing this, please, in private if you feel necessary?
> Then we can better avoid diverging from Debian if possible.

There is a good discussion in the Fedora Bug about this.


I would opt for just following the origin upstream source (in terms of
people), which is the named "Monitoring Plugins" actualy.

I would opt for renaming the source package to "monitoring-plugins"
which builds then all it`s monitoring-plugins* packages (replacing and
breaking the nagios-plugins* packages) and creating nagios-plugins*
transition packages.

I started to work into it at
https://github.com/waja/pkg-nagios-plugins/tree/m-p (push requests are

The big problem are the pathes /etc/nagios-plugins/configs (this
should be possible to migrate with dpkg-maintscript-helper) and
/usr/lib/nagios/plugins/, which are used by many other packages. I
don`t have any smooth solution to migrate this over in mind yet.

For now we plan to be stick with this pathes. This gives us the
freedom not to rush all packages depending on the pathes into the
trash bin. But this maybe just a short- or mid-term solution

Cheers, Jan.
- -- 
Never write mail to <waja at spamfalle.info>, you have been warned!
Version: 3.12
GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V-
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++
- ------END GEEK CODE BLOCK------
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org


More information about the Pkg-nagios-devel mailing list