Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 217366 - Review Request: libnl - netlink sockets support/manipulation library
Summary: Review Request: libnl - netlink sockets support/manipulation library
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Parag AN(पराग)
QA Contact: Fedora Package Reviews List
Depends On:
TreeView+ depends on / blocked
Reported: 2006-11-27 15:32 UTC by Neil Horman
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-11-30 16:03:44 UTC
Type: ---

Attachments (Terms of Use)
Fixed but not complete SPEC file (deleted)
2006-11-27 16:41 UTC, Parag AN(पराग)
no flags Details

Description Neil Horman 2006-11-27 15:32:10 UTC
Spec URL:

Description: libnl is a infrastructure library which makes the use of netlink protocol sockets much more convienient

Comment 1 Parag AN(पराग) 2006-11-27 16:15:34 UTC
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 16:32:50 UTC
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 16:41:06 UTC
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 16:47:16 UTC
You don't need to add my name in Changelog. Add your name there.

Comment 5 Neil Horman 2006-11-27 20:24:20 UTC
New sepc and srpm available, with changes incorporated:

SPEC File:

Built in mock with no errors

Comment 6 Parag AN(पराग) 2006-11-28 17:15:12 UTC
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/

=>> 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 20:08:19 UTC
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, is currently being built with debug
information in place (just do a readlelf -w /usr/lib/ 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 21:21:37 UTC
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:

Comment 9 Parag AN(पराग) 2006-11-29 04:31:11 UTC
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 13:13:14 UTC
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 13:59:45 UTC
New pacakage available here


Comment 12 Neil Horman 2006-11-29 14:03:14 UTC
sorry that SRPM url should be:

Comment 13 Parag AN(पराग) 2006-11-29 14:58:20 UTC
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 15:41:41 UTC
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 06:41:26 UTC
+ 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 14:15:30 UTC
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 14:50:13 UTC
So tell me which is your last step that failing from ?
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 14:56:39 UTC
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 -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 15:25:42 UTC
found the problem.  Appears we have a bug in the import script.  

Comment 21 Parag AN(पराग) 2006-11-30 15:56:45 UTC
So you had a good hacking experience on
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 16:03:44 UTC
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 16:18:13 UTC
I just realized - libnl is already in core - it's a dependency of
NetworkManager, among other things...

Comment 24 Parag AN(पराग) 2006-11-30 16:41:19 UTC
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 17:02:21 UTC
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.