Bug 217366 - Review Request: libnl - netlink sockets support/manipulation library
Review Request: libnl - netlink sockets support/manipulation library
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Parag AN(पराग)
Fedora Package Reviews List
Depends On:
  Show dependency treegraph
Reported: 2006-11-27 10:32 EST by Neil Horman
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-30 11:03:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fixed but not complete SPEC file (1.27 KB, application/octet-stream)
2006-11-27 11:41 EST, Parag AN(पराग)
no flags Details

  None (edit)
Description Neil Horman 2006-11-27 10:32:10 EST
Spec URL: http://people.redhat.com/nhorman/rpms/libnl.spec
SRPM URL: http://people.redhat.com/nhorman/rpms/libnl-1.0-pre6.src.rpm

Description: libnl is a infrastructure library which makes the use of netlink protocol sockets much more convienient
Comment 1 Parag AN(पराग) 2006-11-27 11:15:34 EST
Got rpmlint errors on SRPM package as
W: libnl unversioned-explicit-provides %{name}-%{version}-%{release}
The specfile contains an unversioned Provides: token, which will match all
older, equal, and newer versions of the provided thing.  This may cause
update problems and will make versioned dependencies, obsoletions and conflicts
on the provided thing useless -- make the Provides versioned if possible.

E: libnl no-cleaning-of-buildroot %install
You should clean $RPM_BUILD_ROOT in the %clean section and just after the
beginning of %install section. Use "rm -Rf $RPM_BUILD_ROOT".

correct those things and submit updated package. 
1) You need to add under %install 

2) You don't need to specify
Provides: %{name}-%{version}-%{release}
remove that.
Comment 2 Parag AN(पराग) 2006-11-27 11:32:50 EST
Got some more things for you to add in SPEC file
You need to go through
You followed old method that was used for pre fedora releases.
Comment 3 Parag AN(पराग) 2006-11-27 11:41:06 EST
Created attachment 142181 [details]
Fixed but not complete SPEC file

I fixed some issues in your SPEC file. But still this not complete SPEC file.
You need to test this in mock build also.
Comment 4 Parag AN(पराग) 2006-11-27 11:47:16 EST
You don't need to add my name in Changelog. Add your name there.
Comment 5 Neil Horman 2006-11-27 15:24:20 EST
New sepc and srpm available, with changes incorporated:

SPEC File: http://people.redhat.com/nhorman/rpms/libnl.spec
SRPM: http://people.redhat.com/nhorman/rpms/libnl-1.0-0.1.pre6.src.rpm

Built in mock with no errors
Comment 6 Parag AN(पराग) 2006-11-28 12:15:12 EST
Got again rpmlint warnings on i386 binary rpm as
W: libnl incoherent-version-in-changelog 1.0-0.1.pre6..fc7 1.0-0.1.pre6.fc7
The last entry in %changelog contains a version identifier that is not
coherent with the epoch:version-release tuple of the package.
==>Change 1.0-0.1.pre6.%{?dist} to 1.0-0.1.pre6%{?dist}

W: libnl unstripped-binary-or-object /usr/lib/libnl.so.1.0-pre6

=>> Please compile with debug symbols and let rpm automatically extract them out
  into the debuginfo package.

W: libnl no-documentation
The package contains no documentation (README, doc, etc).
You have to include documentation files.
==> You forgot %doc line in SPEC. include it.

Also on -devel as
W: libnl-devel no-dependency-on libnl
try using under %package
Requires: %{name} = %{version}

Update Package
Comment 7 Neil Horman 2006-11-28 15:08:19 EST
The other items are no issue, I'm taking care of them now, but the
unstripped-binary-or-object warning is confusing to me.  I'm looking at it, and
as it currently stands, libnl.so.1.0-pre6 is currently being built with debug
information in place (just do a readlelf -w /usr/lib/libnl.so.1 to see all the
contained dwarf information).  Yet, rpmbuild is failing to strip the binary and
place its dwarf info in the debuginfo package.  Is there any way to force a
library to get included in the debuginfo package?
Comment 8 Neil Horman 2006-11-28 16:21:37 EST
scratch that last comment, figured it out: install stage was converting DSO's to
be non-executable, so they weren't getting packaged in debuginfo.  New package
ready and available for review:

SPEC File: http://people.redhat.com/nhorman/rpms/libnl.spec
SRPM: http://people.redhat.com/nhorman/rpms/libnl-1.0-0.2.pre6.src.rpm
Comment 9 Parag AN(पराग) 2006-11-28 23:31:11 EST
Got mock build error 
you may need to doxygen as BR.
Kindly check your package in mock and then submit new links
Comment 10 Neil Horman 2006-11-29 08:13:14 EST
Thats odd, built fine for me in mock.  I'll add the BR anyway, since it would
seem to make sense and repost
Comment 11 Neil Horman 2006-11-29 08:59:45 EST
New pacakage available here
SPEC FILE: http://people.redhat.com/nhorman/rpms/libnl.spec
SRPM: http://people.redhat.com/nhorman/rpms/libnl-1.0-0.2.pre6.src.rpm

Comment 12 Neil Horman 2006-11-29 09:03:14 EST
sorry that SRPM url should be:
Comment 13 Parag AN(पराग) 2006-11-29 09:58:20 EST
I don't think we can have following message in build.log as blocker
doxygen Doxyfile
sh: dot: command not found
Problems running dot. Check your installation!
Comment 14 Parag AN(पराग) 2006-11-29 10:41:41 EST
Also can you check Documentation index.html showed 1.0-pre2
it will confuse user as they know they installed 1.0-pre2 or 1.0-pre6
its coming from Doxygen file. So you may consider to patch it.
Comment 16 Parag AN(पराग) 2006-11-30 01:41:26 EST
+ package builds in mock (development i386).
+ rpmlint is silent for SRPM and RPMS.
+ source files match upstream.
0f57cb7085dc27e054691bff858613c9  libnl-1.0-pre6.tar.gz
+ package meets naming and packaging guidelines.
+ specfile is properly named, is cleanly written
+ Spec file is written in American English.
+ Spec file is legible.
+ dist tag is present.
+ build root is correct.
+ license is open source-compatible.  License text included in package.
+ %doc is small; no -doc subpackage required.
+ %doc does not affect runtime.
+ BuildRequires are proper.
+ %clean is present.
+ package installed properly.
+ Macro use appears rather consistent.
+ Package contains code, not content.
+ no headers or static libraries.
+ libnl-1.pc file present.
+ -devel subpackage exists
+ included
  %post -p /sbin/ldconfig
  %postun -p /sbin/ldconfig
+ no .la files.
+ no translations are available
+ Dose owns the directories it creates.
+ no duplicates in %files.
+ file permissions are appropriate.
Comment 17 Neil Horman 2006-11-30 09:15:30 EST
cool, thanks!  

I'm trying to import the srpm to cvs, accoording to:
Unfortunately libnl doesn't exist as a directory in CVS yet, and the cvs-import
script, while it can add lbnl to the modules file, can't seem to create it in
the CVS tree, as the documentation indicates that it should.  Any thoughts as to
whats going on?
Comment 18 Parag AN(पराग) 2006-11-30 09:50:13 EST
So tell me which is your last step that failing from
http://fedoraproject.org/wiki/Extras/Contributors ?
Also you will get good information at #fedora-extras or in case having some
problem to your account ask at #fedora-admin
Comment 19 Neil Horman 2006-11-30 09:56:39 EST
Its all working great until I run the cvs-import script.  The script
successfully checks out the modules file, adds libnl to the end of it, and
checks it back in.  Then it goes to check out the libnl module, but the module
doesn't exist in the CVS tree:

cvs -d :ext:nhorman@cvs.fedora.redhat.com:/cvs/extras -Q checkout libnl
Enter passphrase for key '/home/nhorman/.ssh/id_dsa': 
cvs [checkout aborted]: there is no repository /cvs/extras/rpms/libnl

Any thoughts would be greatly appreciated.
I'll ask on #fedora-extras.  Thanks!
Comment 20 Neil Horman 2006-11-30 10:25:42 EST
found the problem.  Appears we have a bug in the import script.  
Comment 21 Parag AN(पराग) 2006-11-30 10:56:45 EST
So you had a good hacking experience on cvs-import.sh
then manages to fix cvs co also.
Go ahead and file a bug against script owner.
So it did helped from #fedora-extras :)
Now once its built you can CLOSE this bug as NEXTRELEASE resolution.
Comment 22 Neil Horman 2006-11-30 11:03:44 EST
done.  bug 217875 is open for the cvs-import issue, and libnl is building for
fc7 now.  Thanks for all your help!
Comment 23 Jeffrey C. Ollie 2006-11-30 11:18:13 EST
I just realized - libnl is already in core - it's a dependency of
NetworkManager, among other things...
Comment 24 Parag AN(पराग) 2006-11-30 11:41:19 EST
If you had looked Core contains
whereas extras contain
libnl-1.0-0.4.pre6.i386.rpm which is newer

More explanation can be given here by package owner. And i don't think they can
conflicts each other but extras package can replace Core package in future.
Comment 25 Parag AN(पराग) 2006-11-30 12:02:21 EST
oops they are really conflicting because of Core's libnl is dependency of
Its My Bad. 
Neil and Jeffrey,
Sorry for not checking before about conflicting issue. I will take care from
next time while reviewing packages. But i think i took enough time to review
this package except should not have forgot to check package's existence and its
confliction to other packages.

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