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 226201 - Merge Review: nmap
Summary: Merge Review: nmap
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-01-31 20:17 UTC by Nobody's working on this, feel free to take it
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-06-20 07:56:52 UTC
jima: fedora-review+


Attachments (Terms of Use)

Description Nobody's working on this, feel free to take it 2007-01-31 20:17:02 UTC
Fedora Merge Review: nmap

http://cvs.fedora.redhat.com/viewcvs/devel/nmap/
Initial Owner: harald@redhat.com

Comment 1 Jima 2007-02-09 20:27:45 UTC
OK - Spec in American English
OK - Spec is legible.
OK - Sources match upstream md5sum:
ea50419f99472200c4184a304e3831ea  nmap-4.20.tar.bz2
ea50419f99472200c4184a304e3831ea  nmap-4.20.tar.bz2.1
OK - BuildRequires correct
See below - Package has %defattr and permissions on files is good.
OK - Package has a correct %clean section.
See below - Package has correct buildroot
OK - Package is code or permissible content.
OK - Packages %doc files don't affect runtime.
OK - Package compiles and builds on at least one arch.
OK - Package has no duplicate files in %files.
OK - Package doesn't own any directories other packages own.
OK - Package owns all the directories it creates.
See below - No rpmlint output.
OK - final provides and requires are sane:

SHOULD Items:

OK - Should build in mock.
OK - Should build on all supported archs
OK - Should function as described.
OK - Should have dist tag
OK - Should package latest version
0 bugs - check for outstanding bugs on package.

1. Not sure if this is a blocker, but the standard format for defattr
now is:

%defattr(-,root,root,-)

People I've talked to have had the opinion that it's a "should."

2. The recommended BuildRoot is:

%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

3. rpmlint says:

rpmlint on nmap-4.20-2.fc7.src.rpm
W: nmap mixed-use-of-spaces-and-tabs (spaces: line 56, tab: line 62)
W: nmap patch-not-applied Patch1: makefile.patch
W: nmap patch-not-applied Patch0: inet_aton.patch

The first one is easy enough to fix if you want to change the multiple
spaces on lines 56-59 to tabs; I don't believe it's a blocker, though.
I don't believe the other two are, either, but if you're done with the
patches... :-)

Also, I had a couple other concerns about the package.  First off, see:

http://fedoraproject.org/wiki/Packaging/Guidelines#head-fcaf3e6fcbd51194a5d0dbcfbdd2fcb7791dd002

I've successfully tested the package with this change:

-%makeinstall nmapdatadir=$RPM_BUILD_ROOT%{_datadir}/nmap
+make install nmapdatadir=%{_datadir}/nmap DESTDIR=$RPM_BUILD_ROOT

Secondly, there's a pretty major mistake in nmap-4.20-nostrip.patch.  As
I said in an email to Florian La Roche (who, as far as I can tell, added
that patch):

--- snip ---
 In your effort to remove -s's from install lines, you also made this
effective change:

-$(SHTOOL) mkln -f -s $(DESTDIR)$(bindir)/nmapfe $(DESTDIR)$(bindir)/xnmap
+$(SHTOOL) mkln -f $(DESTDIR)$(bindir)/nmapfe $(DESTDIR)$(bindir)/xnmap

 Which has this annoying effect on the build:

ln: `nmapfe': hard link not allowed for directory
...
RPM build errors:
    File not found: /var/tmp/nmap-root/usr/bin/xnmap

 I'm pretty sure that's not what you meant to do. :-)
 I fixed the patch in my local copy and threw it against my buildsys and it
worked fine.  Just thought I'd let you know.
--- snip ---

So, please, add the -s back to the `mkln` part of that line.  The build
fails otherwise. :-P

In closing, if you could address the above issues, I think nmap should  
be cleared for merging.

Comment 2 Harald Hoyer 2007-03-23 13:44:41 UTC
please check nmap-4.20-3.fc7

Comment 3 Jima 2007-03-23 14:59:30 UTC
(4.20-4.fc7 is in CVS, actually...)

1. Not fixed, but it's not (AFAIK) a blocker.

2. Fixed, thanks.  (It's a blocker now, too.)

3. Fixed (rpmlint on SRPM is now silent), thanks.

4. `make install`-y line looks better and appears to work fine.

5. nmap-4.20-nostrip.patch fixed.

A couple (minor) problems creeped in, however.

1. Versions in %changelog shouldn't have %{?dist} on the end; see the last point
in this section:

http://fedoraproject.org/wiki/Packaging/DistTag#head-5fff04551074fb311a96352be7e7cc3006c90f25

Totally logical mistake, I fully admit. :-)

2. We now have an rpmlint warning on the binary package:

W: nmap incoherent-version-in-changelog 4.20-4 2:4.20-4.fc7

This is due to Karsten Hopp's changelog entry -- it should have contained the
Epoch used (as you and Florian have been doing).

In a totally random comment, in running `rpmdiff` on the RPMs produced by your
changes (against ones from before), it seems you may have fixed a bug that I
hadn't noticed.  It looks like before your 1.35 CVS change to nmap.spec, nmap
was using its own libpcap.  Your BR change from libpcap to libpcap-devel fixed
that, and added a dependency on libpcap.  This, in my opinion, is a very good
thing -- thanks.

Fix the new 1 and 2, and I think nmap's good to go.

Comment 4 Harald Hoyer 2007-03-23 15:58:27 UTC
Doh.. still forgot to fix old no.1 .. 

Besides please check nmap-4.20-5.fc7

Comment 5 Jima 2007-03-23 19:44:15 UTC
It finally propogated to the public CVS. :-)

Changelog entries are happy now!

Also, on my last glance at the package, I noticed this (in %package frontend):

Requires: nmap = %{epoch}:%{version}

I'm not sure, but maybe that should be %{epoch}:%{version}-%{release} ?  Not a
huge deal, and I doubt it's a blocker, but it seems like it might be good form. :-)

That and the %defattr are the only things that (slightly) annoy me, so I think
we can call nmap APPROVED for merging.  Thanks!


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