Spec URL: http://washington.kelkoo.net/fedora/SPECS/pnp.spec SRPM URL: http://washington.kelkoo.net/fedora/SRPMS/pnp-0.4.7-5.fc8.src.rpm Description: PNP is an addon to nagios which analyzes performance data provided by plugins and stores them automatically into RRD-databases.
IANAR, but a few thoughts as I just spent yesterday writing my own spec for this as I'm an idiot who searched for "pnp4nagios" instead of "pnp": - The %name "pnp4nagios" is the official name of the Sourceforge project and may be clearer (obviously has nothing to do with plug-and-play). Additionally, it matches OpenSUSE's package name, which is probably helpful where that abides by Fedora's naming conventions. - /usr/libexec/pnp is a very logical place for the process-perfdata.pl script in FHS terms, but in keeping with existing convention and filesystem layout it may make more sense to drop it in %{_libdir}/nagios/plugins. - The package is creating a separate %{_sysconfdir}/%{name} directory for configs to keep it separate from %{_sysconfdir}/nagios, but is dropping web files inside %{_datadir}/nagios/html, which seems inconsistent/incorrect to me; it might be a better idea to give it a separate data directory and distribute an httpd conf.d file. Beyond that, I think it looks way, way better than mine. :)
> - The %name "pnp4nagios" is the official name of the Sourceforge project and may > be clearer (obviously has nothing to do with plug-and-play). Additionally, it > matches OpenSUSE's package name, which is probably helpful where that abides by > Fedora's naming conventions. Not sure why I used pnp rather than pnp4nagios. Good point about Suse, I'll look at what other distros do. > - /usr/libexec/pnp is a very logical place for the process-perfdata.pl script in > FHS terms, but in keeping with existing convention and filesystem layout it may > make more sense to drop it in %{_libdir}/nagios/plugins. This is not a nagios plugin. It doesn't provide any test and as you noted, it follows better FHS to use /usr/libexec/pnp. > - The package is creating a separate %{_sysconfdir}/%{name} directory for > configs to keep it separate from %{_sysconfdir}/nagios, but is dropping web > files inside %{_datadir}/nagios/html, which seems inconsistent/incorrect to me; > it might be a better idea to give it a separate data directory and distribute an > httpd conf.d file. > I initially packaged the web files in a separate directory, but it forces to authenticate 2 times, once for nagios and once for pnp. Beside that the pnp site recommend to install in a nagios' subdir. However, a separate sysconfdir is cleaner.
Update to 0.4.9 and package rename : http://washington.kelkoo.net/fedora/SPECS/pnp4nagios.spec http://washington.kelkoo.net/fedora/SRPMS/pnp4nagios-0.4.9-1.fc8.src.rpm
New version, it generates a proper -debuginfo package : http://washington.kelkoo.net/fedora/SPECS/pnp4nagios.spec http://washington.kelkoo.net/fedora/SRPMS/pnp4nagios-0.4.9-2.fc8.src.rpm rpmlint output is now clean : pnp4nagios.i386: E: non-standard-uid /var/spool/pnp4nagios nagios pnp4nagios.i386: E: non-standard-gid /var/spool/pnp4nagios nagios pnp4nagios.i386: E: non-standard-uid /var/log/pnp4nagios nagios pnp4nagios.i386: E: non-standard-gid /var/log/pnp4nagios nagios pnp4nagios.i386: E: non-standard-uid /var/lib/pnp4nagios nagios pnp4nagios.i386: E: non-standard-gid /var/lib/pnp4nagios nagios pnp4nagios.i386: W: incoherent-subsys /etc/rc.d/init.d/npcd $prog pnp4nagios.i386: W: incoherent-init-script-name npcd
Your init script still references /etc/pnp instead of /etc/pnp4nagios.
Good catch, thx. I had to miss one of them... http://washington.kelkoo.net/fedora/SPECS/pnp4nagios.spec http://washington.kelkoo.net/fedora/SRPMS/pnp4nagios-0.4.9-3.fc8.src.rpm
Tested with Nagios 3.03. Works for me.
[romal@localhost SPECS]$ rpmlint pnp4nagios.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. [romal@localhost SPECS]$ Builds without problems and works like a charm. All must-requirements are matched. Should: the upstream is 0.4.10, packaged is 0.4.9
Approving the package.
I'm afraid the review is not formal enough. Please refer to the following wiki page for guidance or look at some existing reviews to have an example : http://fedoraproject.org/wiki/Packaging/ReviewGuidelines You should set the review flag back to '?'. I can't do it myself, it is considered bad style when the requestor play with it. Updated SRPM and spec for 0.4.10 : http://washington.kelkoo.net/fedora/SPECS/pnp4nagios.spec http://washington.kelkoo.net/fedora/SRPMS/pnp4nagios-0.4.10-1.fc8.src.rpm
OK - MUST: rpmlint must be run on every package. OK - MUST: The package must be named according to the Package Naming Guidelines . OK - MUST: The spec file name must match the base package %{name}, OK - MUST: The package must meet the Packaging Guidelines . GPLv2 - MUST: The package must be licensed with a Fedora approved license OK - MUST: The License field in the package spec file must match OK - MUST: If (and only if) the source package includes the text of the OK - MUST: The spec file must be written in American English. OK - MUST: The spec file for the package MUST be legible. OK - MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Download; 5e57d50e2d895878b626497fd7b217b7 pnp-0.4.10.tar.gz SRPM: 5e57d50e2d895878b626497fd7b217b7 pnp-0.4.10.tar.gz OK - MUST: The package must successfully compile and build into binary rpms OK - MUST: If the package does not successfully compile, build or work on an architecture OK - MUST: All build dependencies must be listed in BuildRequires, Not relevant, no locales - MUST: The spec file MUST handle locales properly. no libs included - MUST: Every binary RPM package which stores shared library files Not relevant - MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, OK - MUST: A package must own all directories that it creates. OK - MUST: A package must not contain any duplicate files in the %files listing. OK - MUST: Permissions on files must be set properly. OK - MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} OK - MUST: Each package must consistently use macros, Code- MUST: The package must contain code, or permissable content. OK- MUST: Large documentation files should go in a -doc subpackage. OK - MUST: If a package includes something as %doc, it must not affect the runtime of the application. No header files included - MUST: Header files must be in a -devel package. No libs included - MUST: Static libraries must be in a -static package. No pkcconfig - MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). No libs included- MUST: If a package contains library files with a suffix No devel package- MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} OK - MUST: Packages must NOT contain any .la libtool archives, these should be removed in the spec. No GUI - MUST: Packages containing GUI applications must include a OK - MUST: Packages must not own files or directories already owned by other packages. OK - MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} OK - MUST: All filenames in rpm packages must be valid UTF-8. Included - SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. No translations- SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. Ok on 386 and X86_64 - SHOULD: The package should compile and build into binary rpms on all supported architectures. OK - SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. No scriplets included - SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. No Subpackages- SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. No pkcconfig - SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, No file dependencies - SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself.
Thanks for the review Romal. New Package CVS Request ======================= Package Name: pnp4nagios Short Description: Nagios performance data analysis tool Owners: xavierb Branches: F-9 EL-4 EL-5 InitialCC: Cvsextras Commits: yes
cvs done.
imported and built for for Rawhide, F-9, EL-4 and EL-5.
Can I ask an EL-6 package please? Thank you.
(In reply to comment #15) > Can I ask an EL-6 package please? Thank you. If you're willing to adopt the package, yes. I'm not using pnp4nagios anymore and I'm not giving it the love it would deserve. The Fedora branches have been lagging behind for quite some time, and I'm not going to add one more branch, especially for long term support. Please request commit rights in the pkgdb, I'll be thankful to grant them to you.
Package Change Request ====================== Package Name: pnp4nagios New Branches: epel7 Owners: ondrejj
Git done (by process-git-requests).