Fedora Merge Review: nmap http://cvs.fedora.redhat.com/viewcvs/devel/nmap/ Initial Owner: harald
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.
please check nmap-4.20-3.fc7
(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.
Doh.. still forgot to fix old no.1 .. Besides please check nmap-4.20-5.fc7
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!