Bug 505155

1. www.web-insights.net does not resolve for me.

2. There is no URL on Source0.

3. The COPYING file is GPLv2 but the library sources are LGPLv2.1+. As you're the upstream, please add also the LGPLv2.1 text in the original tarball.

4. There is missing rm -rf $RPM_BUILD_ROOT on the beginning of %install.

5. The symlink libcap-ng.so in the -devel subpackage should be in %{_libdir} not /%{_lib}/

rpmlint is silent:

$ rpmlint -v libcap-ng-0.4-1.x86_64.rpm 
libcap-ng.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-debuginfo-0.4-1.x86_64.rpm 
libcap-ng-debuginfo.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-devel-0.4-1.x86_64.rpm 
libcap-ng-devel.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-0.4-1.src.rpm 
libcap-ng.src: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-utils-0.4-1.x86_64.rpm 
libcap-ng-utils.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

A couple of notes:

- Doesn't
 %configure --disable-static
disable building the static library?

- Normally, you don't need to
 mkdir -p $RPM_BUILD_ROOT/%{_mandir}/{man3,man8}
 mkdir -p $RPM_BUILD_ROOT/%{_lib}
as make install will do this for you. Also, you need to
 rm -rf $RPM_BUILD_ROOT
at the beginning of %install.

- You shouldn't need to define attributes in %files. If the attributes are not correct, the Makefile should be adjusted to give 644 for normal files and 755 for libraries and binaries (or set the attributes using chmod in %install).

- Time stamps are not preserved, use
 make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"

wrt to comment #1 item 1, power supply on that server burned up and hasn't been replaced. Updated the spec file to point to my people page for now. Items 2-4 are also fixed. For item 5, all example rpms that I looked at have the .so file in /lib64 if the library is there also. Is there a guideline that says this is wrong or something bad that will happen if I don't? IOW, what are the problems caused by leaving it in /lib64?

wrt to comment #2 item 1, No. Item 2 is fixed. Item 3, I like explicit attributes so that when I look at the specfile I know exactly how everything is going to land just in case there is a mistake in the make files. (I can point to bz on the prelude stack where explicit perms would have prevented doing security errata.) Item 5, I don't see any spec files doing this. Why would build-time timestamps be important? I can see the reason for multilib timestamp coordination for shared resources, but why would I need to do this?

Thanks for the review comments. I posted a new spec file to the same place as above, but won't update the srpm until later today after I put some man pages in the tarball and do an official release.

(In reply to comment #3)
> wrt to comment #1 item 1, power supply on that server burned up and hasn't been
> replaced. Updated the spec file to point to my people page for now. Items 2-4
> are also fixed. For item 5, all example rpms that I looked at have the .so file
> in /lib64 if the library is there also. Is there a guideline that says this is
> wrong or something bad that will happen if I don't? IOW, what are the problems
> caused by leaving it in /lib64?

That's not a standard location according to FHS. You have been looking only at some core utilities spec files, everything else installs the libraries in %{_libdir}. Using %{_lib} for anything else is forbidden.
 
> wrt to comment #2 item 1, No. Item 2 is fixed. Item 3, I like explicit
> attributes so that when I look at the specfile I know exactly how everything is
> going to land just in case there is a mistake in the make files. (I can point
> to bz on the prelude stack where explicit perms would have prevented doing
> security errata.)

But the normal umasks set by the build environment are fine.

> Item 5, I don't see any spec files doing this. Why would
> build-time timestamps be important? I can see the reason for multilib timestamp
> coordination for shared resources, but why would I need to do this?

http://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps

It's a guideline and thus mandatory. Files that aren't generated in the build (e.g. the header file) need to keep their time stamps. This package will also be multilib, won't it?
 
> Thanks for the review comments. I posted a new spec file to the same place as
> above, but won't update the srpm until later today after I put some man pages
> in the tarball and do an official release.  

You didn't increment the release, which you should do whenever making revisions.

In the new spec there is a typo in Source0 URL and extra space at the end of the %configure line.

Jussi, note that the version is bumped so release doesn't have to be.

And the library itself should stay in  /lib{64,} because the system core utilities will depend on it. The question is only about the devel symlink.

Also the timestamps guideline is not a strict guideline - note the 'consider' word in the guideline and so on.

(In reply to comment #6)
> Jussi, note that the version is bumped so release doesn't have to be.

OK, I hadn't noticed that.

> And the library itself should stay in  /lib{64,} because the system core
> utilities will depend on it. The question is only about the devel symlink.

Okay, in that case, my bad. However, Tomas is right; there are quite a few .so files in %{_lib}.

> Also the timestamps guideline is not a strict guideline - note the 'consider'
> word in the guideline and so on.  

Yes, but it's trivial and doesn't hurt anything to keep them.

Oh, the permission lines
 %defattr(-,root,root)
should AFAIK be
 %defattr(-,root,root,-)
as per http://fedoraproject.org/wiki/Packaging/Guidelines#File_Permissions

ok, new spec file uploaded to same place. Wrt to timestamp issue, the suggested fix doesn't work. The symlink was moved. The typos are fixed.

New srpm has been uploaded to:

http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-0.4.1-1.src.rpm

Please let me know if there are any other issues.

I have only two nitpicks:

1. the script to create the new symlink is overly complicated why not do it this way:
rm -f $RPM_BUILD_ROOT/%{_lib}/%{name}.so
mkdir -p $RPM_BUILD_ROOT/%{_libdir}
VLIBNAME=$(ls $RPM_BUILD_ROOT/%{_lib}/%{name}.so.*.*.*)
LIBNAME=$(basename $VLIBNAME)
ln -s ../../%{_lib}/$LIBNAME $RPM_BUILD_ROOT/%{_libdir}/%{name}.so

2. there is unnecessary / before %{_libdir} on the symlink line in %files devel.

The rpmlint is still silent:

$ rpmlint -v libcap-ng-0.4.1-1.x86_64.rpm 
libcap-ng.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-debuginfo-0.4.1-1.x86_64.rpm 
libcap-ng-debuginfo.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-devel-0.4.1-1.x86_64.rpm 
libcap-ng-devel.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-0.4.1-1.src.rpm 
libcap-ng.src: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -v libcap-ng-utils-0.4.1-1.x86_64.rpm 
libcap-ng-utils.x86_64: I: checking
1 packages and 0 specfiles checked; 0 errors, 0 warnings.  

The nitpicks are no showstoppers so the package is ACCEPTED.

In response to comment #11, I can remove the '/' from %{_libdir} even though it hurts nothing. 

But wrt to item 1, the only complication is that its saving the cwd and using it later. Its impossible to make a relative link without being in the directory so that the kernel sees both ends connected. You cannot make an absolute link since this is in the build root. So, I have updated the spec file with only the libdir fix.

(In reply to comment #12)
> But wrt to item 1, the only complication is that its saving the cwd and using
> it later. Its impossible to make a relative link without being in the directory
> so that the kernel sees both ends connected. You cannot make an absolute link
> since this is in the build root. So, I have updated the spec file with only the
> libdir fix.  

AFAIK there's nothing to prevent it. You will just get a dangling-symlink warning from rpmlint if the file you link to is not in the same rpm package.

I must have had a typo when I tried it. It works. New spec file and srpm uploaded.

OK

New Package CVS Request
=======================
Package Name: libcap-ng
Short Description: An alternative posix capabilities library
Owners: sgrubb
Branches: F-11 F10
InitialCC:

cvs done.

The package has been built in devel. I will build into F-11 and F-10 in the next day or two. Closing. Thanks for the review and feedback.