The unused-direct-shlib-dependency comes from linking to libuuid but not calling
any functions in it.  The tools call it, and the package just uses the same
options to link the tools and the library.  I don't think it's enough of an
issue to justify patching around in the package's Makefile.

Lovely how upstream forces you to use https but has an expired certificate.

The upstream web pages indicate that this is stable.  Is the eight digit number
looking suspiciously like a date actually the package's version?  If so, then
you could just use that as the version instead of treating the package as a
snapshot with no version.  Which would make your version "20070512" and your
release as "1".  Of course, this breaks (forcing you to use Epoch:) if upstream
does decide to release version 1.0 in the future, so I'll leave this up to you.
 If upstream is still sufficiently active, you could ask them what they plan to do.

The COPYING file seems to me to include the 4-clause BSD license, including the
advertising clause, although they swapped two of the clauses for whatever reason.

- All advertising materials mentioning features or use of this software
  must acknowledge the contribution by people stated in the acknowledgements.

So, first off, your License: tag is wrong; it must be "BSD with advertising".

Then, this program cannot link against anything which conflicts with
BSD+advertising.  zlib is OK, glibc is OK (LGPL), openssl/libcrypto is OK, and
e2fsprogs has four different licenses.  Looking in the source, libuuid (which is
all that's being linked against here) is plain 3-clause BSD without advertising.
 So that should be OK as well.  Running ldd against all binaries and libraries
doesn't show anything else, so that should OK.

When submitting packages with difficult licenses, you need to do this kind of
review up front.  We can't generally trust upstream to do this kind of thing
properly, because it seems to be those that pick the "you must mention me in
your advertising materials" clause who understand the implications of such a
thing the least.  You also need to make sure that the package doesn't grow
additional dependencies in the future which would cause a licensing conflict,
and that the licenses of your dependencies don't change and cause conflicts.

Review:
* source files match upstream:
   5479bc06d0eb9a83c6dc793b87ee05a4c957fc73cb7c509b57ecc7dd5154ca0c  
   libewf-20070512.tar.gz
* package meets naming and versioning guidelines (but consider using date as 
  version as detailed above).
* specfile is properly named, is cleanly written and uses macros consistently.
* summaries are OK.
* descriptions are OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly
* debuginfo package looks complete.
* rpmlint complaints are OK.
* final provides and requires are sane:
  ewftools-0-1.20070512.fc8.x86_64.rpm
   ewftools = 0-1.20070512.fc8
  =
   libcrypto.so.6()(64bit)
   libewf = 0-1.20070512.fc8
   libewf.so.1()(64bit)
   libuuid.so.1()(64bit)
   libz.so.1()(64bit)

  libewf-0-1.20070512.fc8.x86_64.rpm
   libewf.so.1()(64bit)
   libewf = 0-1.20070512.fc8
  =
   /sbin/ldconfig
   libcrypto.so.6()(64bit)
   libewf.so.1()(64bit)
   libuuid.so.1()(64bit)
   libz.so.1()(64bit)

  libewf-devel-0-1.20070512.fc8.x86_64.rpm
   libewf-devel = 0-1.20070512.fc8
  =
   libewf = 0-1.20070512.fc8
   libewf.so.1()(64bit)
   pkgconfig

* %check is not present; no test suite upstream.  I have no existing EWF files 
   to use test this, although I did run the tools and "acquired" a file and 
   things seemed to work well enough.
* shared libraries present; ldconfig called properly.
* unversioned .so files are in the -devel package.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* scriptlets are OK (ldconfig calls)
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are in the -devel package.
* pkgconfig file present in -devel package.
* no static libraries.
* no libtool .la files.

APPROVED

Thx for the review! I will update the License field before built...

This package is used by http://www.sleuthkit.org
which uses http://www.porcupine.org/forensics/tct.html (IBM License)
Maybe there will be a problem then... (I cannot find the wiki about compatibles
licenses...)

New Package CVS Request
=======================
Package Name:      libewf
Short Description: Library for the Expert Witness Compression Format (EWF)
Owners:            kwizart
Branches:          F-8 F-7
InitialCC:         <empty>
Commits by cvsextras: yes

Well, there is http://fedoraproject.org/wiki/Licensing but it only deals with
compatibility between common licenses.  Doing that work for all licenses we know
about would require more lawyers than I care to think about.

If you have doubts about compatibility of a specific set of licenses, just ask
or block FE-Legal on your review ticket.

cvs done.

Package Change Request
======================
Package Name: libewf
New Branches: EL-5
Owners: kwizart

cvs done.