Bug 370751

Needed to build kdegames > 3.90

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

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.

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

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?

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).

ta da, scratch build succeeded:
http://koji.fedoraproject.org/koji/taskinfo?taskID=231538

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.

doh, crap, coulda sworn I checked the x86_64 build, but I'll go take another
closer look at fixing this.

%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

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.

> 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?

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.

* 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

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

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

cvs done.

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.

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.