I can do a basic review for form, but I have no way to test this since I have no
NTFS in sight and there's no mkfs.ntfs included in this package.

OK, this builds and installs fine in mock on x86_64 rawhide.  rpmlint just says:
  W: ntfs-3g-devel no-documentation
which is OK as there's no developer documentation in the tarball.

One wonders why the date in the version is one year off.

I know you wrote the naming guidelines so perhaps I'm misreading, but I'd
interpret this as a prerelease package and give it a version of 0 and a release
of 0.1.%{buildrev}%{?dist}.

Currently the main executable installs into /usr/bin and a symlink is placed
into /sbin.  I wonder if that should go the other way around.  (Although I guess
it would indeed be insane to try to put /usr on NTFS.)  A quick check shows no
symlinks in /sbin that point outside of /sbin on the systems I have handy.

Review:
* source files match upstream:
   6382355a472c96e0ed9f4f62d4d9496f  ntfs-3g-20070920-BETA.tgz
? 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.
* rpmlint has only acceptable complaints.
* final provides and requires are sane:
  ntfs-3g-0.1.20070920-1.fc6.x86_64.rpm
   libntfs-3g.so.0()(64bit)
   ntfs-3g = 0.1.20070920-1.fc6
  =
   /sbin/ldconfig
   libfuse.so.2()(64bit)
   libfuse.so.2(FUSE_2.2)(64bit)
   libfuse.so.2(FUSE_2.5)(64bit)
   libntfs-3g.so.0()(64bit)

  ntfs-3g-devel-0.1.20070920-1.fc6.x86_64.rpm
   ntfs-3g-devel = 0.1.20070920-1.fc6
  =
   libntfs-3g.so.0()(64bit)
   ntfs-3g = 0.1.20070920-1.fc6

! %check is not present; no test suite upstream.  I am not able to test this
package as I have no access to NTFS.
* shared libraries are present; ldconfig is called properly.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* scriptlets are OK (standard ldconfig call)
* 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 subpackage.
* unversioned .so file is in the -devel subpackage.
* no pkgconfig files.
* no libtool .la droppings.

Guestion: What is the legale state of inclusssion of ntfs into Fedora Extras.

As far as I known, the kernel of fedora is compiled without NTFs support becouse
of legal issues.

But if that not be a issue now, it will be nice if fedora may ship the kernel
with compiled NTFS support.

My statement is that because the kernel ships with NTFS source code (whether or
not it is compiled is immaterial), and the kernel is protected on patents from
OIN, then the ntfs userspace implementation which does all of the same things as
the kernel code is also protected. I'm challenging the Fedora Board to step up here.

Either OIN protects us and we're ok, or it doesn't.

And in any case, it's far easier to get a userspace filesystem package into
extras than it is to get an updated, fully AQ'd kernel out to core.

So, spot, any comment on the two issues I found?  And is anyone willing to test
this out?  Alternately, I guess I could get a friend to NTFS-format a USB stick
for me.

You're right. I didn't follow my own naming guidelines. Shame on me. :)

Seems like it is better to be safe with the /sbin/ /usr/bin scenario and make it
a copy rather than a symlink, so thats what I did. Also fixed the
versioning/release.

New SRPM:
http://www.auroralinux.org/people/spot/review/ntfs-3g-0-0.2.20070920.fc6.src.rpm
New SPEC: http://www.auroralinux.org/people/spot/review/ntfs-3g.spec

OK, I'm testing (the previous release, as I already had it built).

I installed it and fuse-libs came in to satisfy the dependency, and went to
mount an NTFS-formatted USB stick I got from a friend.  (Bit of a pain to make
it, too.)  

> s mount -t ntfs-3g /dev/sda1 /mnt
fuse: failed to exec fusermount: No such file or directory
Failed to mount NTFSUnmounting /dev/sda1 (Test)

So it looks like there needs to be a dependency on fuse in there.  After
installing fuse, things seem to work great; I can read existing data, rename
files, create new files and delete stuff.

The default permissions here are a bit wide-open, which may be troubling, but
otherwise things are fine:

> grep sda /proc/mounts
/dev/sda1 /mnt fuse rw,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other 0 0

Other than that missing dependency on fuse, I'd say everything is fine.  I'll go
ahead and approve this and you can add it if you do decide to check this in.

NTFS should be removed from the forbidden item in packaging
guidelines before this can be accepted?

Updated ForbiddenItems to remove NTFS, since OIN has us covered on that one.

Packages are built and in repo, closing.

Just for your information, it does not work with SElinux enabled (bug 211767).