Bug 1057454 - Review Request: python-nagiosplugin - Python class library for writing Nagios (Icinga) plugins
Review Request: python-nagiosplugin - Python class library for writing Nagios...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2014-01-24 02:23 EST by Jordan Metzmeier
Modified: 2015-07-21 08:47 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-06 15:44:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jordan Metzmeier 2014-01-24 02:23:50 EST
Spec URL: http://www.thesimplebrief.com/linux/python-nagiosplugin.spec
SRPM URL: http://www.thesimplebrief.com/linux/python-nagiosplugin-1.2-1.fc20.src.rpm
Description: 
nagiosplugin is a Python class library which helps writing Nagios
(or Icinga) compatible plugins easily in Python. It cares for much of
the boilerplate code and default logic commonly found in Nagios
checks, including:

- Nagios 3 Plugin API compliant parameters and output formatting
- Full Nagios range syntax support
- Automatic threshold checking
- Multiple independent measures
- Custom status line to communicate the main point quickly
- Long output and performance data
- Timeout handling
- Persistent "cookies" to retain state information between check runs
- Resume log file processing at the point where the last run left
- No dependencies beyond the Python standard library (except for Python 2.6).

Fedora Account System Username: jmetzmeier

This is my first package I have requested a sponsor for. I had created packages for internal use in the past, but never with the intention of getting it uploaded to the official archives. I followed the guidelines closely while creating the package.
Comment 1 Alexandre Beche 2014-02-27 10:30:45 EST
Hi,

I am currently doing an informal review of your package.
Do you plan to put your package under EPEL5/6 reposiroty?

Cheers,
Alexandre
Comment 2 Alexandre Beche 2014-02-28 05:38:30 EST
Hello, 

Please find below my informal review (note that is my second :) so I may have been too strict or permissive on some points). I skipped EPEL5/6 as mock failed for it.

If you have doubt on any point, let me know.

Cheers,
Alex

__ = To be corrected
OK = Accepted
NA = Not Applicable

####
#
# MUST
#
####

[OK] - rpmlint must be run on the source rpm and all binary rpms the build produces.
 * rpmlint python-nagiosplugin-1.2-1.fc20.src.rpm
   1 packages and 0 specfiles checked; 0 errors, 0 warnings.

 * rpmlint /var/lib/mock/fedora-rawhide-x86_64/result/python-nagiosplugin-1.2-1.fc21.noarch.rpm
   1 packages and 0 specfiles checked; 0 errors, 0 warnings.

[OK] - The package must be named according to the Package Naming Guidelines .
[OK] - The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption.
[__] - The package must meet the Packaging Guidelines.
  * The unversioned macros, %{__python}, %{python_sitelib}, and %{python_sitearch} are deprecated. You should use %{__python2}, %{python2_sitelib}, and %{python2_sitearch} to explicitly reference the python2 interpreter instead. This is future proofing for the time when things will be switched over to python3 by default instead of python2.
  
[OK] - The License field in the package spec file must match the actual license. 
[OK] - If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.
[OK] - The spec file must be written in American English.

[__] - The spec file for the package MUST be legible. 
 * Could you please add the following comment at the end of your if statement: "# if with_python3"
 * Could you put 1 BuildRequires line per dependency.

[OK] - The sources used to build the package must match the upstream source, as provided in the spec URL
 * 0fe531336190353cceae9c5e629e3ac300f9d2f0b6633dbce44d67efdead4e95  nagiosplugin-1.2.tar.gz
 * 0fe531336190353cceae9c5e629e3ac300f9d2f0b6633dbce44d67efdead4e95  nagiosplugin-1.2.tar.gz.1

[OK] - The package MUST successfully compile and build into binary rpms on at least one primary architecture.
 * rawhide : http://koji.fedoraproject.org/koji/taskinfo?taskID=6577221
 * fc21    : http://koji.fedoraproject.org/koji/taskinfo?taskID=6577223
 * fc20    : http://koji.fedoraproject.org/koji/taskinfo?taskID=6577226

[NA] - If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch.

[OK] - All build dependencies must be listed in BuildRequires.
[NA] - The spec file MUST handle locales properly. 
[NA] - Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun.
[OK] - Packages must NOT bundle copies of system libraries.
[NA] - If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package.
[OK] - A package must own all directories that it creates.
[OK] - A Fedora package must not list a file more than once in the spec file's %files listings. (Notable exception: license texts in specific situations)
[OK] - Permissions on files must be set properly.
[OK] - Each package must consistently use macros.
[OK] - The package must contain code, or permissable content. 
[OK] - Large documentation files must go in a -doc subpackage.
[OK] - If a package includes something as %doc, it must not affect the runtime of the application.
[NA] - Static libraries must be in a -static package.
[NA] - Development files must be in a -devel package.
[NA] - In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release}
[OK] - Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.
[NA] - Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section.
[OK] - Packages must not own files or directories already owned by other packages.
[OK] - All filenames in rpm packages must be valid UTF-8.

# PYTHON SPECIFIC

[OK] - Python eggs must be built from source
[OK] - Python eggs must not download any dependencies during the build process. 
[NA] - When building a compat package, it must install using easy_install -m so it won't conflict with the main package. 
[NA] - When building multiple versions (for a compat package) one of the packages must contain a default version that is usable via "import MODULE" with no prior setup.  

####
#
# SHOULD
#
####

[OK] - If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
[__] - The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
[OK] - The reviewer should test that the package builds in mock.
[OK] - The package should compile and build into binary rpms on all supported architectures.
[__] - The reviewer should test that the package functions as described.
[OK] - If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity.
[NA] - Usually, subpackages other than devel should require the base package using a fully versioned dependency.
[NA] - The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.
[NA] - 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.
[NA] - your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense.

# PYTHON SPECIFIC

[OK] - A package which is used by another package via an egg interface should provide egg info.
Comment 3 Piotr Popieluch 2015-03-21 07:39:48 EDT
This is a quite old request. I'm willing to do the review if you are still interested, please let me know. I can't sponsor you though, you will have to find a sponsor yourself. Best way to find a sponsor is by doing informal review requests and send an email to the fedora devel mailing list.
Comment 4 Piotr Popieluch 2015-06-06 18:08:52 EDT
I haven't seen any progress in this request. Jordan do you still have the intention to become package maintainer? What steps have you taken to get sponsored? I will have to mark this a dead request and close the bug if I get no response in two weeks.
Comment 5 Piotr Popieluch 2015-07-06 15:44:47 EDT
closing due to no response

Note You need to log in before you can comment on or make changes to this bug.