Spec Name or Url: http://www.enlartenment.com/extras/svnmailer.spec SRPM Name or Url: http://www.enlartenment.com/extras/svnmailer-1.0.6-1.src.rpm Description: Svnmailer is a tool to post subversion repository commit information by mail, news or XML (to a CIA tracker).
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