This isn't a formal review, as I can't do that yet, and I'm not 100% 
comfortable doing so, and this appears to be your first package in Fedora, and 
I can't sponsor you.  So this is practice for both of us. :-)

!! building on FC4 x86_64, rpmlint yields 
$  rpmlint RPMS/x86_64/wavpack-4.3-1.x86_64.rpm
E: wavpack binary-or-shlib-defines-rpath /usr/bin/wavpack ['/usr/lib64']
E: wavpack binary-or-shlib-defines-rpath /usr/bin/wvunpack ['/usr/lib64']

$  rpmlint RPMS/x86_64/wavpack-devel-4.3-1.x86_64.rpm
E: wavpack-devel only-non-binary-in-usr-lib

this one appears to be because of the inclusion of the .pc file.

* named per PackageNamingGuidelines
* spec file name matches
* PackagingGuidelines appear to be met
* open source license (BSD)
* license in %doc
* spec in english
* spec file legible
* sources match upstream package (md5sum)
* builds in mock for FC4 x86_64
* no exceptional BuildRequires
* no spec file locales issues
* %pre/%post calling ldconfig properly
* not relocatable
* no directory ownership problems
* no duplicate files
* %files have %defaddr
* package has %clean that contains rm -rf buildroot
* consistent use of macros
* no docs subpackage necessary
* header files in -devel, no static libs
* pkgconfig .pc file in -devel
* library file .so in -devel
* -devel Requires fully versioned base package
* .la files removed
* no desktop file needed, command line only
* license in %doc
* no translations provided
* builds in mock for FC4 x86_64 at least

* On the pedantic side:
  It is commonly considered bad taste to mention the software name
  in the Summary line. Keep the summary short and include relevant
  keywords. That's enough. More details fit into the package description.

  Probably also  s/wavpack/WavPack/gi  since that is how they
  spell it online.

* pkgconfig template file wavpack.pc.in contains hardcoded libdir,
  which most likely breaks on multilib platforms if installed like
  that. Needs a patch which does  libdir=@libdir@  instead of 
  libdir=${prefix}/lib  and provided that libdir will be defined and
  substituted by the used autotools framework.

* pkgconfig file Cflags line is questionable. Adding a standard path
  for headers to the search list is dangerous. Also, are WavPack
  API users expected to do #include <wavpack/wavpack.h> or
  #include <wavpack.h>? In case of the latter, the pkgconfig file
  is wrong.

  Same for Libs line. -L${libdir} disturbes library location search list
  because libwavpack.so is installed into a standard location.

>   It is commonly considered bad taste to mention the software name
>   in the Summary line. Keep the summary short and include relevant
>   keywords. That's enough. More details fit into the package description.

Done.

>   Probably also  s/wavpack/WavPack/gi  since that is how they
>   spell it online.

Done. Except the RPM-name.

> * pkgconfig template file wavpack.pc.in contains hardcoded libdir,
>   which most likely breaks on multilib platforms if installed like
>   that. Needs a patch which does  libdir=@libdir@  instead of 
>   libdir=${prefix}/lib  and provided that libdir will be defined and
>   substituted by the used autotools framework.
> * pkgconfig file Cflags line is questionable. Adding a standard path
>   for headers to the search list is dangerous. Also, are WavPack
>   API users expected to do #include <wavpack/wavpack.h> or
>   #include <wavpack.h>? In case of the latter, the pkgconfig file
>   is wrong.
>   Same for Libs line. -L${libdir} disturbes library location search list
>   because libwavpack.so is installed into a standard location.

Done.

I also updated spec-file due to mainstream version change (4.3 -> 4.31).

Spec Name or Url: http://lemenkov.newmail.ru/SPECS/wavpack.spec
SRPM Name or Url: http://lemenkov.newmail.ru/SRPMS/wavpack-4.31-1.src.rpm

* spec file looks good
* patch visited
* upstream locations verified
* binary package contents look good
* test WAV file packed/unpacked (i386)

APPROVED

* Caution: 4.3 => 4.31 : 4.4 would be seen as older than 4.31, since 4 < 31 =>
you would need to choose version=4.40 if next release were 4.4

* Debian package contains contributed manual pages and mentions problems on some
archs where "char" is unsigned by default (may need investigation, since
compiler gives several related warnings),
http://packages.debian.org/unstable/sound/wavpack

Consider giving it some testing in FE development first prior to
publishing it for FC4 and older.

> * Caution: 4.3 => 4.31 : 4.4 would be seen as older than 4.31, since 4 < 31 =>
> you would need to choose version=4.40 if next release were 4.4

Maybe it would be beter to choose version == 4.3.1 for this package?

> Consider giving it some testing in FE development first prior to
> publishing it for FC4 and older.

Ok.

To most users, 4.40 looks newer than 4.4.0 while 4.3.1 looks older
than 4.31. ;-)  And you still want to stay close to upstream versioning
scheme.   (the fun starts when you feel the need to bump %{epoch})

Package Change Request
======================
Package Name: wavpack
New Branches: EL-4 EL-5

cvs done.