Bug 192958 - Review Request: ejabberd - A distributed, fault-tolerant Jabber/XMPP server
Review Request: ejabberd - A distributed, fault-tolerant Jabber/XMPP server
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Package Reviews List
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-05-24 10:50 EDT by Jeffrey C. Ollie
Modified: 2013-10-23 14:17 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-23 09:04:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jeffrey C. Ollie 2006-05-24 10:50:27 EDT
Spec URL: http://www.ocjtech.us/ejabberd-1.1.1-1.spec
SRPM URL: http://www.ocjtech.us/ejabberd-1.1.1-1.src.rpm
Description:
ejabberd is a Free and Open Source distributed fault-tolerant
Jabber/XMPP server. It is mostly written in Erlang, and runs on many
platforms (tested on Linux, FreeBSD, NetBSD, Solaris, Mac OS X and
Windows NT/2000/XP).
Comment 1 Jeffrey C. Ollie 2006-05-24 22:57:43 EDT
Updated package:

Spec URL: http://www.ocjtech.us/ejabberd-1.1.1-2.spec
SRPM URL: http://www.ocjtech.us/ejabberd-1.1.1-2.src.rpm

%changelog
* Wed May 24 2006 Jeffrey C. Ollie <jeff@ocjtech.us> - 1.1.1-2
- Munge Makefile.in a bit more...
- Change ownership/permissions - not *everything* needs to be owned by ejabberd
Comment 2 Jason Tibbitts 2006-06-02 15:41:48 EDT
Just took a quick look at this and I'm having trouble figuring out these rpmlint
complaints:

W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/expat_erl.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/iconv_erl.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/stringprep_drv.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/ejabberd_zlib_drv.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/tls_drv.so

"rpmlint -i" is no help, but inspecting the rpmlint source shows that it's
calling objdump --headers --private-headers and grepping for "SONAME".  Indeed,
those libraries don't show one.

Unfortuantely I've no idea how problematic this is or how you'd go about fixing it.
Comment 3 Jeffrey C. Ollie 2006-06-03 10:46:44 EDT
(In reply to comment #2)
> Just took a quick look at this and I'm having trouble figuring out these rpmlint
> complaints:
> 
> W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/expat_erl.so
> W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/iconv_erl.so
> W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/stringprep_drv.so
> W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/ejabberd_zlib_drv.so
> W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/tls_drv.so
> 
> [...]
> 
> Unfortuantely I've no idea how problematic this is or how you'd go about
fixing it.

I don't think that its a problem... the libraries aren't general purpose shared
libraries but are dynamically loaded modules pulled in by the Erlang runtime. 
They are similar to Python or Perl modules coded in C rather than Python/Perl.
They are versioned by the %{_libdir}/ejabberd-1.1.1 directory so different
versions of ejabberd shouldn't load the wrong modules.  It seemes to work - I
have personally set up three servers using these ejabberd RPMs.
Comment 4 Jason Tibbitts 2006-06-03 14:01:07 EDT
I'm sure the program works; the question is whether the package meets the Extras
guidelines and one of those is that rpmlint must have no valid complaints. 
Unfortunately I'm not familiar with this particular complaint since I've not
seen it before.  I understand that these are modules pilled in by Erlang, but
neither Perl nor Python will generate libraries without SONAME as far as I know.
 I've reviewed other Erlang packages (c.f. wings) which did not have this problem.

I received little guidance on IRC; just a comment that this looks like an
upstream bug.  I'll try on extras-list.

Comment 5 Gérard Milmeister 2006-06-08 16:52:55 EDT
(In reply to comment #4)
> I'm sure the program works; the question is whether the package meets the Extras
> guidelines and one of those is that rpmlint must have no valid complaints. 
There are packages that include .so files without SONAME, e.g.,
R
elfutils
gcj compiled jar packages
...
This is not a problem as long as they are not public libraries in /usr/lib.
However it is probably easy to fix in the Makefile by adding
-Wl,-soname,expat_erl.so for example to the link command.
Comment 6 Jason Tibbitts 2006-06-14 10:17:37 EDT
Adding back some lost comments:

------- Additional Comments From jeff@ollie.clive.ia.us  2006-06-08 22:06 EST
-------
(In reply to comment #5)

> This is not a problem as long as they are not public libraries in /usr/lib.
> However it is probably easy to fix in the Makefile by adding
> -Wl,-soname,expat_erl.so for example to the link command.

I tried adding the "-Wl,-soname,expat_erl.so" to the link command, now all I get
are errors like this from rpmlint:

E: ejabberd invalid-soname /usr/lib64/ejabberd-1.1.1/priv/lib/expat_erl.so
expat_erl.so

where before I was merely getting warnings.  Unless someone can show a
functional problem I'd prefer to ignore those warnings and move on.

Comment 7 Jason Tibbitts 2006-06-14 10:18:18 EDT
------- Additional Comments From gemi@bluewin.ch  2006-06-09 03:09 EST -------
(In reply to comment #6)
> (In reply to comment #5)
> are errors like this from rpmlint:
> 
> E: ejabberd invalid-soname /usr/lib64/ejabberd-1.1.1/priv/lib/expat_erl.so
> expat_erl.so
> 
> where before I was merely getting warnings.  Unless someone can show a
> functional problem I'd prefer to ignore those warnings and move on.

Indeed rpmlint wants the soname to be of the form lib<libname>.so.<major>.
I also think that this isn't worth the trouble and should be ignored.
Comment 8 Jason Tibbitts 2006-06-21 15:06:51 EDT
I took another look at this and after looking over other packages I agree with
Gerard that the no-soname warning is acceptable for libraries that don't live
immediately in %{_libdir}.

Full review forthcoming.
Comment 9 Jason Tibbitts 2006-06-22 16:06:25 EDT
I ended up having to redo my mock setup last night, but everything's working
fine today.  The package builds fine on x86_64, development.  Here's what
rpmlint has to say:

W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/expat_erl.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/iconv_erl.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/stringprep_drv.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/ejabberd_zlib_drv.so
W: ejabberd no-soname /usr/lib64/ejabberd-1.1.1/priv/lib/tls_drv.so
I'll accept these as meaningless for private internal libraries.

E: ejabberd non-standard-uid /var/log/ejabberd ejabberd
E: ejabberd non-standard-uid /etc/ejabberd/ejabberd.cfg ejabberd
E: ejabberd non-standard-uid /etc/ejabberd ejabberd
E: ejabberd non-standard-uid /var/lib/ejabberd/spool ejabberd
E: ejabberd non-standard-uid /etc/ejabberd/inetrc ejabberd
E: ejabberd non-standard-uid /var/lib/ejabberd ejabberd
E: ejabberd non-standard-gid /var/log/ejabberd ejabberd
E: ejabberd non-standard-gid /etc/ejabberd/ejabberd.cfg ejabberd
E: ejabberd non-standard-gid /etc/ejabberd ejabberd
E: ejabberd non-standard-gid /var/lib/ejabberd/spool ejabberd
E: ejabberd non-standard-gid /etc/ejabberd/inetrc ejabberd
E: ejabberd non-standard-gid /var/lib/ejabberd ejabberd
Expected given that the daemon runs with its own uid/gid.

E: ejabberd non-standard-dir-perm /var/log/ejabberd 0750
E: ejabberd non-standard-dir-perm /etc/ejabberd 0750
E: ejabberd non-standard-dir-perm /var/lib/ejabberd/spool 0750
E: ejabberd non-standard-dir-perm /var/lib/ejabberd 0750
E: ejabberd non-readable /etc/ejabberd/ejabberd.cfg 0640
E: ejabberd non-readable /etc/ejabberd/inetrc 0640
Permissions limited for security reasons.

W: ejabberd non-conffile-in-etc /etc/logrotate.d/ejabberd
You should mark this as %config in your %files list.  This is the only rpmlint
issue that I see.

Nothing seems to own /usr/lib64/ejabberd-1.1.1.  This package should own it.

The documentation is about half of the total size of the package.  Would you
consider splitting the html, pdf and image files off into a separate -doc
subpackage?

Review:
* 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.
* source files match upstream:
   ef6fae4a3f9c7f807f21e9cd3dae195b  ejabberd-1.1.1.tar.gz
* latest version is being packaged.
* BuildRequires are proper.
* package builds in mock (development, x86_64).
X rpmlint has many ignorable complaints and one blocker.
* final provides and requires are sane:
   config(ejabberd) = 1.1.1-2.fc6
   ejabberd_zlib_drv.so()(64bit)
   expat_erl.so()(64bit)
   iconv_erl.so()(64bit)
   stringprep_drv.so()(64bit)
   tls_drv.so()(64bit)
   ejabberd = 1.1.1-2.fc6
  =
   /bin/bash
   /bin/sh
   /sbin/chkconfig
   /sbin/service
   config(ejabberd) = 1.1.1-2.fc6
   erlang
   fedora-usermgmt
   libcrypto.so.6()(64bit)
   libexpat.so.0()(64bit)
   libssl.so.6()(64bit)
   libz.so.1()(64bit)
* shared libraries are present, but internal to ejabberd.
* package is not relocatable.
X owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
* %check is not present; no test suite upstream.
* scriptlets present and OK (user creation, service installation and shutdown)
* code, not content.
X documentation not is small.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.
Comment 11 Jeffrey C. Ollie 2006-06-22 17:10:19 EDT
Oops... forgot to remove a patch that i was testing with:

http://repo.ocjtech.us/misc/fedora/5/SRPMS/ejabberd-1.1.1-7.fc5.spec
http://repo.ocjtech.us/misc/fedora/5/SRPMS/ejabberd-1.1.1-7.fc5.src.rpm
Comment 12 Jason Tibbitts 2006-06-22 23:54:30 EDT
Looks like the three issues I had are fixed:

logrotate.d file marked %config.
owns %{_libdir}/ejabberd-1.1.1
-doc package split off.

APPROVED
Comment 13 Jeffrey C. Ollie 2006-06-23 09:04:00 EDT
Thanks for the review!  Package imported and built!  FC-4 and FC-5 branches
requested.
Comment 14 Jeffrey C. Ollie 2007-09-21 10:38:31 EDT
Package Change Request
======================
Package Name: ejabberd
New Branches: EL-5
Updated EPEL Owners: jcollie,silfreed
Comment 15 Jeffrey C. Ollie 2007-09-21 10:39:57 EDT
Package Change Request
======================
Package Name: ejabberd
New Branches: EL-5
Updated EPEL Owners: jcollie,silfreed


Argh, forgot to change the flag...
Comment 16 Kevin Fenzi 2007-09-21 12:42:40 EDT
cvs done.
Comment 17 Peter Lemenkov 2013-10-23 13:59:35 EDT
Package Change Request
======================
Package Name: ejabberd
InitialCC: erlang-sig
Comment 18 Jon Ciesla 2013-10-23 14:16:38 EDT
Done.

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