Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 499951 (netdiscover) - Review Request: netdiscover - A network address discovering/monitoring tool
Summary: Review Request: netdiscover - A network address discovering/monitoring tool
Alias: netdiscover
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-05-09 12:56 UTC by Patrick Nussbaumer
Modified: 2010-11-13 17:38 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-11-13 17:38:23 UTC

Attachments (Terms of Use)

Description Patrick Nussbaumer 2009-05-09 12:56:54 UTC
Spec URL:


I would like to submit this package. It's build from the cvs source, because the latest version 0.3-beta6 contains some annoying memory leaks. Netdiscover doesn't seem to be under active development but I think it's a small and useful tool.
This is my first package, so I will need a sponsor.

Netdiscover is an active/passive address reconnaissance tool, mainly developed for those wireless networks without dhcp server, when you are wardriving. It can be also used on hub/switched networks.

Built on top of libnet and libpcap, it can passively detect online hosts, or search for them, by actively sending arp requests, it can also be used to inspect your network arp traffic, or find network addresses using auto scan mode, which will scan for common local networks.

Comment 1 arthurguru 2009-05-12 00:35:40 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
- 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
- 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.,
then library files that end in .so (without suffix) must go in a -devel
- 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} =
- 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
- 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.
- OK

License file included in source but not specified in %doc
Concern over %{dist} tag location when using snapshot release

Kind regards,
Arthur Gouros.

Comment 2 Lubomir Rintel 2009-05-12 17:27:12 UTC 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.

Comment 3 Patrick Nussbaumer 2009-05-12 17:59:44 UTC
Thanks for the comments.

I've added the license file to %doc and made a new SRPM.

New spec file :
New srpm :

Comment 4 Jochen Schmitt 2009-05-13 19:12:42 UTC
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.

Comment 5 arthurguru 2009-05-15 06:41:52 UTC
Hi Patrick,

Did another informal review of netdiscover

Koji build on PPC arch worked fine

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.

Comment 6 Patrick Nussbaumer 2009-05-15 21:23:19 UTC
Thanks for your second review.

> Found an rpmlint warning:
Sorry my mistake, I used the %doc macro in my changelog comment.

Updated SPEC:
Updated SRPM:

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

Comment 7 Patrick Nussbaumer 2009-06-08 20:55:51 UTC
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?

Comment 8 manuel wolfshant 2010-07-21 22:26:09 UTC
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.

Comment 9 Michael Schwendt 2010-10-05 08:23:16 UTC
> > 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:


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:


> %{_mandir}/man8/%{name}.8.gz

Prefer the wildcard extension over .gz


so the compression technique (applied by rpmbuild) could be changed any time without breaking the package build.

Comment 10 Jason Tibbitts 2010-11-03 14:01:13 UTC
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.

Comment 11 Jason Tibbitts 2010-11-13 17:38:23 UTC
No response; closing.

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