This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 370751 - Review Request: ggz-client-libs - Client libraries for GGZ gaming zone
Review Request: ggz-client-libs - Client libraries for GGZ gaming zone
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
:
Depends On: 370741
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-07 22:01 EST by Rex Dieter
Modified: 2007-11-30 17:12 EST (History)
5 users (show)

See Also:
Fixed In Version: 0.0.14-4.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-20 12:47:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
tibbs: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2007-11-07 22:01:20 EST
Spec URL: http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/ggz/ggz-client-libs.spec
SRPM URL: http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/ggz/ggz-client-libs-0.0.14-1.src.rpm
Description:
GGZ (which is a recursive acronym for GGZ Gaming Zone) develops libraries,
games and game-related applications for client-server online gaming. Player
rankings, game spectators, AI players and a chat bot are part of this effort.

$rpmlint ggz-client-libs-0.0.14-1.src.rpm
is clean

Can't do scratch build, it depends on libggz (also under view, bug #370741)
Comment 1 Rex Dieter 2007-11-07 22:02:07 EST
Needed to build kdegames > 3.90
Comment 2 Jason Tibbitts 2007-11-08 00:35:53 EST
FYI, I had rpath problems (rawhide, x86_64) but they were easily worked around
with the usual:

BuildRequires: libtool

make LIBTOOL=/usr/bin/libtool %{?_smp_mflags}

rm -f %{buildroot}%{_libdir}/lib*.a

Comment 3 Rex Dieter 2007-11-08 12:02:52 EST
Eww, I'd much rather try to (re)libtoolize or even use chrpath before that.  
Lemme see if I can come up with a better solution.
Comment 4 Rex Dieter 2007-11-08 13:45:42 EST
This seems to do the trick:

Spec URL: http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/ggz/ggz-client-libs.spec
SRPM URL:
http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/ggz/ggz-client-libs-0.0.14-2.src.rpm

%changelog
* Thu Nov 11 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 0.0.14-2
- libtoolize to avoid rpaths
- -devel +%%defattr
Comment 5 Jason Tibbitts 2007-11-09 01:18:12 EST
I don't think that works the way you're hoping it does.  Either that or
something else is wrong, because I still see the same three rpath complaints:

ggz-client-libs.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/ggz/ggzwrap
['/usr/lib64']
ggz-client-libs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/ggz-wrapper
['/usr/lib64']
ggz-client-libs.x86_64: E: binary-or-shlib-defines-rpath
/usr/lib64/libggzmod.so.4.1.0 ['/usr/lib64']

I'm not sure why you find the usual way of dealing with rpath issues
distasteful, but it does work and is minimally disruptive.  Is using the system
libtool instead of the broken one in the package really that bad?
Comment 6 Rex Dieter 2007-11-09 07:38:59 EST
libtoolize kinda sorta does the same thing (supposedly!), but without
side-effects (like system libtool generating static libs, even when using
--disable-static).

My own mock builds did *not* contain rpaths with this fix in place. ??

Well, now that libggz is in rawhide, I'll see if I can make a scratch build
(maybe something is wrong/different with my own local mock setup).
Comment 7 Rex Dieter 2007-11-09 08:14:39 EST
ta da, scratch build succeeded:
http://koji.fedoraproject.org/koji/taskinfo?taskID=231538
Comment 8 Jason Tibbitts 2007-11-09 11:03:07 EST
I grabbed the scratch build from that location and it does indeed have rpath issues:

XYX:temp2:~/work/rpm> rpmlint ggz-client-libs-0.0.14-2.fc9.x86_64.rpm
ggz-client-libs.x86_64: W: non-conffile-in-etc /etc/xdg/menus/ggz.menu
ggz-client-libs.x86_64: W: non-conffile-in-etc
/etc/xdg/menus/applications-merged/ggz.merge.menu
ggz-client-libs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/ggz-wrapper
['/usr/lib64']
ggz-client-libs.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/ggz/ggzwrap
['/usr/lib64']
ggz-client-libs.x86_64: E: binary-or-shlib-defines-rpath
/usr/lib64/libggzmod.so.4.1.0 ['/usr/lib64']


I don't know why you're not seeing it.  Most rpath problems will only show up on
x86_64, so if you're only looking at i386 builds then you won't see it. But you
should be able to grab
http://koji.fedoraproject.org/scratch/rdieter/task_231538/ggz-client-libs-0.0.14-2.fc9.x86_64.rpm
and run rpmlint on it, even on an i386 machine.
Comment 9 Rex Dieter 2007-11-09 11:06:52 EST
doh, crap, coulda sworn I checked the x86_64 build, but I'll go take another
closer look at fixing this.
Comment 10 Rex Dieter 2007-11-09 12:45:07 EST
%changelog
* Fri Nov 09 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 0.0.14-3
- try (no)rpath trick #2: modify configure

Spec URL: http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/ggz/ggz-client-libs.spec
SRPM URL:
http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/ggz/ggz-client-libs-0.0.14-3.src.rpm

scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=231872
Comment 11 Jason Tibbitts 2007-11-14 01:12:58 EST
Well, that worked fine.  Do you still need automake and libtool given that
you're just patching the existing configure file?

Picky, I know, but the ggz-config executable seems to be GPLv2+, not LGPLv2+. 
Probably an oversight by upstream byt annoying nonetheless.  Also, the manpage
for ggz-config should probably be with the ggz-config executable in the devel
subpackage.

There are also several other source files in the tarball that are GPL and not
LGPL (ggzmod-ggz.c, io-ggz.c, ggzwrap.c, game.c, ggz-wrapper.c, loop.c,
server.c).  I'm not really sure that the end result can be LGPL, even though
that's what's in the COPYING file.

I'm a little confused about the ggzwrap executable and it being located in
/usr/lib(64)/ggz.  This package already packages binaries in /usr/bin, so why
have /usr/bin/ggz-wrapper but /usr/lib64/ggz/ggzwrap?  And there is the larger
question of why there are executables at all in the -libs package.  Won't this
cause issues with multilib?

rpmlint says:
  ggz-client-libs.x86_64: W: non-conffile-in-etc /etc/xdg/menus/ggz.menu
  ggz-client-libs.x86_64: W: non-conffile-in-etc 
   /etc/xdg/menus/applications-merged/ggz.merge.menu
both of which are OK as far as I know.


* source files match upstream:
   a2ad93d5158bbe687275cc3ded1379bd2ae6f0463e4fe785cda0fdcf01af8a04  
   ggz-client-libs-0.0.14.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
? license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
? BuildRequires (automake and libtool needed?)
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly
* debuginfo package looks complete.
* rpmlint has acceptable complaints
* final provides and requires are sane:
  ggz-client-libs-0.0.14-3.fc9.x86_64.rpm
   libggzcore.so.9()(64bit)
   libggzmod.so.4()(64bit)
   ggz-client-libs = 0.0.14-3.fc9
  =
   /bin/bash
   /sbin/ldconfig
   libexpat.so.1()(64bit)
   libggz.so.2()(64bit)
   libggzcore.so.9()(64bit)
   libggzmod.so.4()(64bit)

  ggz-client-libs-devel-0.0.14-3.fc9.x86_64.rpm
   ggz-client-libs-devel = 0.0.14-3.fc9
  =
   ggz-client-libs = 0.0.14-3.fc9
   libggz.so.2()(64bit)
   libggzcore.so.9()(64bit)
   libggzmod.so.4()(64bit)

* shared libraries installed; ldconfig called properly.
* unversioned .so files are in the -devel subpackage.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* scriptlets are OK (ldconfig)
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are in the -devel subpackage.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.
Comment 12 Kevin Kofler 2007-11-16 10:52:00 EST
> Picky, I know, but the ggz-config executable seems to be GPLv2+, not LGPLv2+.
> Probably an oversight by upstream byt annoying nonetheless.

It's an executable, not a library, so obviously nothing links against it, so 
what's wrong with GPL?
Comment 13 Jason Tibbitts 2007-11-16 11:01:58 EST
It's annoying because the COPYING file is the LGPL one, and the source code says
"this is under GPL; refer to the copying file".  The authors are simply not
being sufficiently careful about licensing.

Nothing is wrong with GPL in this case, except for the fact that now Rex needs
to take an in-depth look and document just what parts of the package are under
what licenses.
Comment 14 Rex Dieter 2007-11-17 12:03:31 EST
* Sat Nov 17 2007 Rex Dieter <rdieter[AT]fedoraproject.org> 0.0.14-4
- --disable-ggzwrap (for now, until multilib, licensing is sorted out)
- move ggz-config to main pkg (runtime management of ggz modules)
- clarify GPL vs. LGPL bits
- drop BR: automake libtool

Spec URL: http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/ggz/ggz-client-libs.spec
SRPM URL:
http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/ggz/ggz-client-libs-0.0.14-4.src.rpm
Comment 15 Jason Tibbitts 2007-11-17 18:36:17 EST
OK, BRs are better, License: tag reflects reality and the wrapper is gone from
its odd location.

I neglected to note that %find_lang is called properly to deal with the locale
files.  I need to add that to my checklist.

At this point, I have only two comments which I don't believe are blockers:

If possible, please try to note in the spec which bits are under which license.  

The ggc-wrapper manpage is still shipped even though the executable isn't.

But these are pretty minor.  So, APPROVED
Comment 16 Rex Dieter 2007-11-19 08:51:25 EST
New Package CVS Request
=======================
Package Name: ggz-client-libs
Short Description: Client libraries for GGZ gaming zone
Owners: rdieter
Branches: F-8 F-7 EL-5
Cvsextras Commits: yes
Comment 17 Kevin Fenzi 2007-11-19 11:28:32 EST
cvs done.
Comment 18 Fedora Update System 2007-11-20 12:47:57 EST
ggz-client-libs-0.0.14-4.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 19 Fedora Update System 2007-11-20 13:10:00 EST
ggz-client-libs-0.0.14-4.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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