[Bug 218556] Review Request: ecryptfs-utils - Linux eCryptfs utilities

Fri Dec 8 10:19:04 UTC 2006

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: ecryptfs-utils - Linux eCryptfs utilities

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218556

bjohnson at symetrix.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bjohnson at symetrix.com
OtherBugsDependingO|163776                      |163778
              nThis|                            |

------- Additional Comments From bjohnson at symetrix.com  2006-12-08 05:19 EST -------
I will provide you a review.  It is not an official review as you need a sponsor.

rpmlint -i ecryptfs-utils-5-0.src.rpm 
W: ecryptfs-utils summary-not-capitalized eCryptfs mount helper and support
libraries
Summary doesn't begin with a capital letter.
- This can be ignored.

W: ecryptfs-utils no-url-tag
The URL tag is missing.
-add:
URL: http://ecryptfs.sourceforge.net

W: ecryptfs-utils setup-not-quiet
You should use -q to have a quiet extraction of the source tarball, as this
generate useless lines of log ( for buildbot, for example )
- add "-q" flag to %setup

W: ecryptfs-utils rpm-buildroot-usage %build ./configure
--prefix=$RPM_BUILD_ROOT/usr
$RPM_BUILD_ROOT should not be touched during %build or %prep stage, as it
will break short circuiting.
- change to "%{_configure}

E: ecryptfs-utils configure-without-libdir-spec
A configure script is run without specifying the libdir. configure
options must be augmented with something like --libdir=%{_libdir}.

E: ecryptfs-utils hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/ecryptfs
A library path is hardcoded to one of the following paths: /lib,
/usr/lib. It should be replaced by something like /%{_lib} or %{_libdir}.
- change:
  /usr/bin to %{_bindir}
  /usr/lib to %{_libdir}

E: ecryptfs-utils hardcoded-library-path in /usr/lib/libecryptfs.so.0.0.0
A library path is hardcoded to one of the following paths: /lib,
/usr/lib. It should be replaced by something like /%{_lib} or %{_libdir}.
- ditto

E: ecryptfs-utils hardcoded-library-path in /usr/lib/libecryptfs.so.0
A library path is hardcoded to one of the following paths: /lib,
/usr/lib. It should be replaced by something like /%{_lib} or %{_libdir}.
- ditto

E: ecryptfs-utils hardcoded-library-path in /usr/lib/libecryptfs.so
A library path is hardcoded to one of the following paths: /lib,
/usr/lib. It should be replaced by something like /%{_lib} or %{_libdir}.
- ditto

E: ecryptfs-utils hardcoded-library-path in
/usr/lib/ecryptfs/libecryptfs_pki_passphrase.so
A library path is hardcoded to one of the following paths: /lib,
/usr/lib. It should be replaced by something like /%{_lib} or %{_libdir}.
- ditto

E: ecryptfs-utils hardcoded-library-path in
/usr/lib/ecryptfs/libecryptfs_pki_openssl.so
A library path is hardcoded to one of the following paths: /lib,
/usr/lib. It should be replaced by something like /%{_lib} or %{_libdir}.
- ditto

E: ecryptfs-utils no-buildroot-tag
The BuildRoot tag isn't used in your spec. It must be used in order to
allow building the package as non root on some systems.
- add:
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

You might consider installing rpmdevtools and running fedora-newrpmspec to get a
nice template spec file to work from.  Templated spec files make it faster for
reviewers to review.

Additionally:
make does not use smp flags (see template spec file)
make install does not use DESTDIR (see template spec file)
%defattr has missing param (see template spec file)

Question for submitter: Is ecryptfs already in the kernel?  If it's not, this
would be a blocker until it is.

Once these changes are made, here is the probably output from rpmlint on the
binary rpms:
rpmlint -i mock-results/ecryptfs-utils-5-0.i386.rpm 
E: ecryptfs-utils explicit-lib-dependency libgcrypt
You must let rpm find the library dependencies by itself. Do not put unneeded
explicit Requires: tags.
- remove dependency on libgcrypt

W: ecryptfs-utils summary-not-capitalized eCryptfs mount helper and support
libraries
Summary doesn't begin with a capital letter.
- ignore

W: ecryptfs-utils no-version-in-last-changelog
The last changelog entry doesn't contain a version. Please insert the
version that is coherent with the version of the package and rebuild it.
- please add a version to the changelog entry:
* Mon Dec 04 2006 Mike Halcrow <mhalcrow at us.ibm.com> - 5-0

W: ecryptfs-utils unstripped-binary-or-object
/usr/lib/ecryptfs/libecryptfs_pki_passphrase.so
W: ecryptfs-utils unstripped-binary-or-object
/usr/lib/ecryptfs/libecryptfs_pki_openssl.so
- I believe the problem here is that they were not chmod a+x so they are not
stripped... however, see below first.

E: ecryptfs-utils library-without-ldconfig-postin /usr/lib/libecryptfs.so.0.0.0
This package contains a library and provides no %post scriptlet containing
a call to ldconfig.
- add
  %post -p /sbin/ldconfig

E: ecryptfs-utils library-without-ldconfig-postun /usr/lib/libecryptfs.so.0.0.0
This package contains a library and provides no %postun scriptlet containing
a call to ldconfig.
- add
  %postun -p /sbin/ldconfig

W: ecryptfs-utils devel-file-in-non-devel-package /usr/lib/libecryptfs.so
A development file (usually source code) is located in a non-devel
package. If you want to include source code in your package, be sure to
create a development package.
- If these are development libraries, they should be removed entirely, or put in
a -devel package.  If they are loadable modules, I believe this can be ignored,
but I'll have to look it up.

E: ecryptfs-utils zero-length /usr/share/doc/ecryptfs-utils-5/ChangeLog
- if changelog is 0 length, remove it from the installation

Please fix these issues and repost a new srpm and spec file and I'll continue
your review.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.