Random first comments:

* Delete the python_sitearch definition, as it's not used.
* Since this is an original submission, please use a template created by
fedora-newrpmspec and follow that template's style
* Use "BuildArch: noarch" (since this has no arch-dependent file)

New source RPM up at
http://www.enlartenment.com/extras/svnmailer-1.0.6-2.src.rpm (Old spec replaced
with newer shinier model, same place as before)

- BuildArch: noarch added
- Superflous sitearch definition removed
- The inital spec /was/ based off an older FE python template :-P - I've tried
to undo whatever damage my local revisions have done (I've packaged it locally
before..)

* I would still prefer a more strict following of the spec template. Use the new
template and fill it with the older information: it would really make it more
readable.
* Change the license to "Apache Software License" so rpmlint likes it.
* Does it really need subversion as a Buildreq?

Suggestions (non-binding!):
* You may consider separating the documentation into a subpackage. It's large
and it probably won't be useful to most of the users.
* You may also consider running the test suite provided upstream automatically.

(In reply to comment #3)

New SRPM: http://www.enlartenment.com/extras/svnmailer-1.0.6-2.src.rpm
New SPEC: http://www.enlartenment.com/extras/svnmailer.spec

> * I would still prefer a more strict following of the spec template. Use the new
> template and fill it with the older information: it would really make it more
> readable.

Done, hope it's more sensible and legible.

> * Change the license to "Apache Software License" so rpmlint likes it.

Done. How on earth did I miss that before :-P

> * Does it really need subversion as a Buildreq?

Interestingly, yes - as it likes the subversion python bindings there during
builds (and FC4 has them in the base package...).

I've built it before without it and the results are quite erm, *interesting* :-). 

> Suggestions (non-binding!):
> * You may consider separating the documentation into a subpackage. It's large
> and it probably won't be useful to most of the users.

Done (svnmailer-doc - suggestions on a better subpackage convention welcomed)

> * You may also consider running the test suite provided upstream automatically.
> 

Not a bad idea for folks who want to extend or otherwise hack on it, but I'd
like to nail the basic package first. TODO.

Spec Name or Url: http://www.enlartenment.com/extras/svnmailer.spec
SRPM Name or Url: http://www.enlartenment.com/extras/svnmailer-1.0.7-1.src.rpm

Upgrade to new upstream version (may as well keep it current eh? :-))

Ping - anyone interested in this still?

I've rebuilt my copy for FC5, seems to work OK.

The documentation may actually be of some use, as it's needed to generate a
config file. But it does make sense to split it off. You may want to remove an
annoying extra doc folder by doing in the %files doc section something like

%doc docs/*

But that's optional. Also a good idea would be a version bump to 1.0.8.

For now:
- rpmlint checks return clean
- package meets naming guidelines
- package meets packaging guidelines
- license (Apache Software License) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on FC5 (x86_64)
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- nothing in %doc affects runtime
- no need for .desktop file

APPROVED

Imported and a build request on the devel branch queued