I had a look at the spec it at first sight I can't see anything strange.

The mock build was fine and no rpmlint is silent on all output packages

The only couple of questions I have are:

is there a reason why you don't use %{_sbindir} everywhere in:
# Clear up symlink confusion by making a copy
rm -rf $RPM_BUILD_ROOT/sbin/mkfs.ntfs
cp -a $RPM_BUILD_ROOT%{_sbindir}/mkntfs $RPM_BUILD_ROOT/sbin/mkfs.ntfs

and, what about the kernel module needed for NTFS support?
is it going to be activated (so can we assume legal issues are gone, maybe with
the same reasoning that pulled in Mono) ?

$ rpm --eval %_sbindir
/usr/sbin

The only kernel module needed for NTFS support is the FUSE module, which is
already there.  Everything else is in userspace.  The existing kernel-mode NTFS
is essentially read-only, and while it might not hurt to enable it, it shouldn't
be what we expect users to use when they want to work with NTFS.

One thing I immediately notice about this package: the dreaded rpath problem:
  E: ntfsprogs binary-or-shlib-defines-rpath /usr/bin/ntfsinfo ['/usr/lib64']
and 14 other similar errors.

Unortunately I'm once again without an existing NTFS to test, but I'll try to
get something together and do some testing.

OK, I was able to create an NTFS filesystem on a USB stick, view it using the
tools, mount it via ntfs-3g, and access the files on a windows machine.

I was able to get rid of the rpath via the usual method: BR: libtool, add
"LIBTOOL=/usr/bin/libtool" to the make line, and delete any .a files that pop
up.  After that, rpmlint is happy.

Any reason why you have the BuildRequires: down in the -gnomevfs subpackage
declaration?

There is a test suite, it looks like, but trying to run it produces
   The libntfs test code has been configured out of this release.
   ./configure --enable-test and rebuild.
I did that and the tests do pass.  I'm not sure what this changes; an additional
executable (/usr/bin/runlist) gets installed but I'm not sure if that's all.

Is it reasonable to enable encryption?

* source files match upstream:
   23160eb8d34abe3d2a88cd6d054faa47  ntfsprogs-1.13.1.tar.gz
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
* build root is correct.
* 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 (development, x86_64).
* package installs properly
* debuginfo package looks complete.
X rpmlint has valid complaints (rpath)
* final provides and requires are sane:
  ntfsprogs-1.13.1-1.fc6.x86_64.rpm
   libntfs.so.9()(64bit)
   ntfsprogs = 1.13.1-1.fc6
  =
   /sbin/ldconfig
  libntfs.so.9()(64bit)

  ntfsprogs-devel-1.13.1-1.fc6.x86_64.rpm
   libntfs-gnomevfs.so.1()(64bit)
   ntfsprogs-devel = 1.13.1-1.fc6
  =
   libntfs-gnomevfs.so.1()(64bit)
   libntfs.so.9()(64bit)
   ntfsprogs = 1.13.1-1.fc6

  ntfsprogs-gnomevfs-1.13.1-1.fc6.x86_64.rpm
   config(ntfsprogs-gnomevfs) = 1.13.1-1.fc6
   libntfs-gnomevfs.so.1()(64bit)
   ntfsprogs-gnomevfs = 1.13.1-1.fc6
  =
   config(ntfsprogs-gnomevfs) = 1.13.1-1.fc6
   libntfs-gnomevfs.so.1()(64bit)
   libntfs.so.9()(64bit)
   ntfsprogs = 1.13.1-1.fc6

? %check is not present; there is a test suite but I'm not sure if it's feasible
to run it.  The tests pass when run manually (all files files are identical).

* shared libraries are present; ldconfig is called as necessary.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* scriptlets are OK.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers and unversioned .so files are in the -devel package.
* no pkgconfig files.
* no libtool .la droppings.

Enabled crypto (new BR: libgcrypt-devel, gnutls-devel)
Enabled testsuite (can't hurt)
Fixed rpath by prefixing system libtool (new BR: libtool)

New SRPM:
http://www.auroralinux.org/people/spot/review/ntfsprogs-1.13.1-2.fc6.src.rpm
New SPEC: http://www.auroralinux.org/people/spot/review/ntfsprogs.spec

Hmm, still has the rpath problem; the make line should read
   make LIBTOOL=/usr/bin/libtool %{?_smp_mflags}
instead of
   LIBTOOL=/usr/bin/libtool make %{?_smp_mflags}
and of course you'll still have to delete the .a files that crop up.

Enabling the test suite has installed another binary, /usr/bin/runlist, which
I'm not sure should actially be installed.

I note thhat you pass --enable-crypto, but ntfsdecrypt isn't built.  I added
another make line:
   make LIBTOOL=/usr/bin/libtool %{?_smp_mflags} extra
which does build the additional executables, they still aren't installed.  It
looks like that would need to be done manually.  I'm not sure what you'd prefer
to do here.  The package is fine without those utilities.

Fixed make line
Added make extra line
Manually installed "extra" programs
Nuked runlist.

New SRPM:
http://www.auroralinux.org/people/spot/review/ntfsprogs-1.13.1-3.fc6.src.rpm
New SPEC: http://www.auroralinux.org/people/spot/review/ntfsprogs.spec

OK, everything looks good now.  rpmlint is quiet and all of the executables,
including the extra ones, are installed.

APPROVED

Built and in the repos. Thanks for the review.