Bug 225722 - Merge Review: ElectricFence
Merge Review: ElectricFence
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jon Ciesla
Fedora Package Reviews List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-31 13:32 EST by Nobody's working on this, feel free to take it
Modified: 2012-04-27 11:51 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-27 11:51:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
limburgher: fedora‑review+


Attachments (Terms of Use)

  None (edit)
Description Nobody's working on this, feel free to take it 2007-01-31 13:32:27 EST
Fedora Merge Review: ElectricFence

http://cvs.fedora.redhat.com/viewcvs/devel/ElectricFence/
Initial Owner: pmachata@redhat.com
Comment 1 Petr Machata 2007-02-07 12:35:37 EST
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.
Comment 2 Jon Ciesla 2012-04-06 10:17:03 EDT
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@GLIBC_2.2.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.
Comment 3 Jon Ciesla 2012-04-26 08:53:43 EDT
Ping?
Comment 4 Petr Machata 2012-04-26 12:42:26 EDT
Thanks for the review, I'll take a look at your points tomorrow.
Comment 5 Jon Ciesla 2012-04-26 12:49:47 EDT
Cool, thanks!
Comment 6 Petr Machata 2012-04-27 08:56:24 EDT
(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@GLIBC_2.2.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.
Comment 7 Jon Ciesla 2012-04-27 10:31:32 EDT
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!
Comment 8 Petr Machata 2012-04-27 11:46:11 EDT
I did that, and added the man page.  This is the updated build:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=4029050
Comment 9 Jon Ciesla 2012-04-27 11:51:33 EDT
Beautiful, thanks very much!

Note You need to log in before you can comment on or make changes to this bug.