Bug 499951 (netdiscover)
Summary: | Review Request: netdiscover - A network address discovering/monitoring tool | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Patrick Nussbaumer <patrick.nussbaumer> |
Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | arthurg.work, bugs.michael, fedora-package-review, jochen, lkundrak, manuel.wolfshant, notting, pahan, tuju |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://nixgeneration.com/~jaime/netdiscover/ | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-11-13 17:38:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 201449 |
Description
Patrick Nussbaumer
2009-05-09 12:56:54 UTC
Hi Patrick, Here is my informal review of package netdiscover MUST: rpmlint must be run on every package. The output should be posted in the review. - netdiscover-0.3-1.20090503cvs.fc10.src.rpm OK - netdiscover-0.3-1.20090503cvs.fc7.i386.rpm OK - netdiscover-debuginfo-0.3-1.20090503cvs.fc7.i386.rpm OK - 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 - DistTag doc says append to the end for the simple example used. - Release: 1.20090503cvs%{?dist} - OK Note for more experienced reviewers Potential for {?dist} being mixed with an {?alphatag} suffix, I’ve seen a format being used similar to this Release: 1%{?dist}.20090503cvs Maybe an extra snapshot example in NamingGuidelines would clear this up. MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines . - OK, GPLv3 MUST: The License field in the package spec file must match the actual license. - OK MUST: 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 - file "COPYING" which contains the license is not listed in %doc - Not 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 - a0c8fe2025547528aa47d10ac8217282 *netdiscover-0.3-20090503cvs.tar.gz (RPM) - a0c8fe2025547528aa47d10ac8217282 *netdiscover.tar.gz (upstream) - OK MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. - OK, i386 MUST: If the package does not successfully compile, build or work on an architecture - OK MUST: All build dependencies must be listed in BuildRequires - OK MUST: The spec file MUST handle locales properly. - OK, no locales available MUST: 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, no shared libraries. MUST: 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. Without this, use of Prefix: /usr is considered a blocker. - OK, no relocatable package MUST: A package must own all directories that it creates. - OK MUST: A Fedora package must not list a file more than once in the spec file's %files listings. - OK MUST: Permissions on files must be set properly. - OK MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). - OK MUST: Each package must consistently use macros. - OK MUST: The package must contain code, or permissable content. - OK MUST: Large documentation files must go in a -doc subpackage. - OK, no large documentation MUST: If a package includes something as %doc, it must not affect the runtime of the application. - OK MUST: Header files must be in a -devel package. - OK, no header files MUST: Static libraries must be in a -static package. - OK, no static libraries MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). - OK, no .pc files MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. - OK, no library files. MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} - OK, not a -devel package. MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built. - OK, no .la files MUST: Packages containing GUI applications must include a %{name}.desktop file - OK, no gui available 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} (or $RPM_BUILD_ROOT). - OK MUST: All filenames in rpm packages must be valid UTF-8. - OK Conclusion: License file included in source but not specified in %doc Concern over %{dist} tag location when using snapshot release Kind regards, Arthur Gouros. http://fedoraproject.org/wiki/Packaging/DistTag(In reply to comment #1) > Potential for {?dist} being mixed with an {?alphatag} suffix, I’ve seen a > format being used similar to this > Release: 1%{?dist}.20090503cvs Have a link? > Concern over %{dist} tag location when using snapshot release It is indeed correctly used. Thanks for the comments. I've added the license file to %doc and made a new SRPM. New spec file : http://www.firetux.ch/download/fedora/netdiscover.spec New srpm : http://www.firetux.ch/download/fedora/netdiscover-0.3-2.20090503cvs.fc10.src.rpm On the project homepage I could read, that the last official release is from 2007/06. This is aproximaly 2 years ago. so it may be nice, if you can ask upstream why they haven't submit an official release in the last two years. The Fedora guidelines says, that a project which should introduced in the Fedora distribution should be under active development. I you can present a new official release here, I'm willing to review the package and sponsor you, if the package is ok. Hi Patrick, Did another informal review of netdiscover Koji build on PPC arch worked fine http://koji.fedoraproject.org/koji/taskinfo?taskID=1355750 Found an rpmlint warning: rpmlint netdiscover.spec netdiscover.spec:55: W: macro-in-%changelog doc 0 packages and 1 specfiles checked; 0 errors, 1 warnings. Not OK ... I know the feeling. Best regards, Arthur Gouros. Thanks for your second review. > Found an rpmlint warning: Sorry my mistake, I used the %doc macro in my changelog comment. Updated SPEC: http://www.firetux.ch/download/fedora/netdiscover.spec Updated SRPM: http://www.firetux.ch/download/fedora/netdiscover-0.3-3.20090503cvs.fc10.src.rpm I asked upstream if they plan to publish a new release in the future and if there's active development but didn't receive an answer yet. I'll post as soon as I get an answer. Kind regards, Patrick Nussbaumer Today, I received an answer from Jaime Peñalba the author of netdiscover. He told me that the last changes in CVS have been made around 4 months ago. But he's still working on netdiscover and there's also a pending patch from a contributor. He plans to release a stable version 0.3 but there's no release date for it. Hope this information will help. Is there a chance to include netdiscover in the official Fedora repository? Hey Patrick If you are still interested in this review, please - update to the latest release ( it seems that several changes were made 9 months ago) - update the Source0 and the comment ( the project seems to be hosted at SF now) - publish the links to the new spec and src.rpm Also, as potential sponsor, I would like to see any other review that you might have made or any other package that you have submitted. Thank you. > > Concern over %{dist} tag location when using snapshot release > > It is indeed correctly used. Well, it's not a big issue, and occasionally packagers run into the pitfall and interchange pre-release and post-release versioning schemes. So, what is it? A pre-release snapshot or a post-release snapshot? What will the next upstream release become? The last official release was 0.3-beta6 (and down to betaN many years ago), assumably a pre-release. | Version: 0.3 | Release: 3.20090503cvs%{?dist} For a pre-release snapshot, correct would be Release: 0.3.20090503cvs%{?dist} with the 0. prefix and the X in 0.X being increased with every modification of the package, so there could be a final Version: 0.3 Release: 1%{?dist} package. Guidelines here: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages https://fedoraproject.org/wiki/Packaging:NamingGuidelines#PreReleasePackages [...] The BuildRoot tag is non-standard, too, and didn't follow the old guidelines. Meanwhile, the tag is not needed anymore, but if present, the old guidelines are still linked for Fedora EPEL: https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#BuildRoot_tag [...] > %{_mandir}/man8/%{name}.8.gz Prefer the wildcard extension over .gz %{_mandir}/man8/%{name}.8.* so the compression technique (applied by rpmbuild) could be changed any time without breaking the package build. It's been several months since the last comment by the submitter. Please address the commentary that's been given, or I'll go ahead and close this ticket out. No response; closing. |