Tidied up version commited, not built.

$ rpmlint i386/ElectricFence-2.2.2-21.i386.rpm
W: ElectricFence devel-file-in-non-devel-package /usr/lib/libefence.a
W: ElectricFence devel-file-in-non-devel-package /usr/lib/libefence.so

These are ok, ElectricFence is actually a development package.
Other than that, rpmlint is silent, for both source and binary rpm.

Good:

- rpmlint checks return: 

ElectricFence.spec: W: invalid-url Source0: ElectricFence-2.2.2.tar.gz
The value should be a valid, public HTTP, HTTPS, or FTP URL.

I read the spec comments, where does this live now?

ElectricFence.src: W: spelling-error %description -l en_US malloc -> mallow
The value of this tag appears to be misspelled. Please double-check.

Ignore.

ElectricFence.x86_64: W: shared-lib-calls-exit /usr/lib64/libefence.so.0.0 _exit.5
This library package calls exit() or _exit(), probably in a non-fork()
context. Doing so from a library is strongly discouraged - when a library
function calls exit(), it prevents the calling program from handling the
error, reporting it to the user, closing files properly, and cleaning up any
state that the program has. It is preferred for the library to return an
actual error code and let the calling program decide how to handle the
situation.

Should be fixed if possible.

ElectricFence.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libefence.a
A development file (usually source code) is located in a non-devel package. If
you want to include source code in your package, be sure to create a
development package.

ElectricFence.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libefence.so
A development file (usually source code) is located in a non-devel package. If
you want to include source code in your package, be sure to create a
development package.

These should normally go in -static and -devel, but I think in this case they don't need to.

ElectricFence.x86_64: E: incorrect-fsf-address /usr/share/doc/ElectricFence-2.2.2/COPYING
The Free Software Foundation address in this file seems to be outdated or
misspelled.  Ask upstream to update the address, or if this is a license file,
possibly the entire file with a new copy available from the FSF.

File bug upstream if you like.

ElectricFence.x86_64: W: no-manual-page-for-binary ef
Each executable in standard binary directories should have a man page.

Fix if possible.

- package meets naming guidelines
- package meets packaging guidelines
- license ( GPLv2 ) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream

Impossible to determine.

- package compiles on devel (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
- no need for -docs
- nothing in %doc affects runtime
- no need for .desktop file 

So it's mostly just upstream location and shared lib calls exit.

Ping?

Thanks for the review, I'll take a look at your points tomorrow.

Cool, thanks!

(In reply to comment #2)
> ElectricFence.spec: W: invalid-url Source0: ElectricFence-2.2.2.tar.gz
> The value should be a valid, public HTTP, HTTPS, or FTP URL.
> 
> I read the spec comments, where does this live now?

I don't know.  I don't think anywhere in particular.  I looked through the web but didn't find anything.  Debian has a link to a site that hosts an obsolete version.  I don't think there's any proper upstream for this.

> ElectricFence.x86_64: W: shared-lib-calls-exit /usr/lib64/libefence.so.0.0
> _exit.5
> This library package calls exit() or _exit(), probably in a non-fork()
> context. Doing so from a library is strongly discouraged - when a library
> function calls exit(), it prevents the calling program from handling the
> error, reporting it to the user, closing files properly, and cleaning up any
> state that the program has. It is preferred for the library to return an
> actual error code and let the calling program decide how to handle the
> situation.
> 
> Should be fixed if possible.

Electric fence is a debugger, not a library.  The fact that it comes in the form factor of a library is just because that's how you override malloc and free calls from libc.  Calling _exit is the ultimate outcome of detecting a class of memory errors (double free, free of wild pointer, etc.)  Overflows or underflows are detected by the operating system and lead to process termination as well.

> ElectricFence.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libefence.a
> ElectricFence.x86_64: W: devel-file-in-non-devel-package
> /usr/lib64/libefence.so
> 
> These should normally go in -static and -devel, but I think in this case they
> don't need to.

Yeah, Electric fence is itself a development package.

> ElectricFence.x86_64: W: no-manual-page-for-binary ef
> Each executable in standard binary directories should have a man page.
> 
> Fix if possible.

I'll write a man page later today.

Ok, those sound reasonable, so just some comments in the spec to that effect would be great.  I'll await that and the man page, but then I think we're in great shape, thanks!

I did that, and added the man page.  This is the updated build:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=4029050

Beautiful, thanks very much!