Bug 430360 - Review Request: ggz-gtk-client - Gtk+ client libraries for GGZ gaming zone
Review Request: ggz-gtk-client - Gtk+ client libraries for GGZ gaming zone
Status: CLOSED NEXTRELEASE
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:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-26 16:27 EST by Brian Pepple
Modified: 2008-02-05 09:31 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-04 15:18:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tibbs: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Brian Pepple 2008-01-26 16:27:05 EST
Spec URL: http://bpepple.fedorapeople.org/rpms/ggz-gtk-client.spec
SRPM URL: http://bpepple.fedorapeople.org/rpms/ggz-gtk-client-0.0.14-1.fc8.src.rpm
Description: The GGZ Gaming Zone GTK+ Client provides a GTK+ 2.x user interface
for logging into a GGZ server, chatting with other players, and locating and launching game tables.

Here's a link to a F9 scratch build to save time for any reviewer:
http://koji.fedoraproject.org/koji/taskinfo?taskID=374930
Comment 1 Jason Tibbitts 2008-01-26 18:03:56 EST
Seems like this has the same problem as the last ggz package I looked at:
  ggz-gtk-client.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/ggz-gtk 
   ['/usr/lib64']
In addition, there are these:
  ggz-gtk-client.x86_64: W: unused-direct-shlib-dependency 
   /usr/lib64/libggz-gtk.so.1.0.0 /usr/lib64/libatk-1.0.so.0
  ggz-gtk-client.x86_64: W: unused-direct-shlib-dependency 
   /usr/lib64/libggz-gtk.so.1.0.0 /usr/lib64/libpangocairo-1.0.so.0
  ggz-gtk-client.x86_64: W: unused-direct-shlib-dependency 
   /usr/lib64/libggz-gtk.so.1.0.0 /usr/lib64/libcairo.so.2
  ggz-gtk-client.x86_64: W: unused-direct-shlib-dependency 
   /usr/lib64/libggz-gtk.so.1.0.0 /lib64/libgmodule-2.0.so.0
  ggz-gtk-client.x86_64: W: unused-direct-shlib-dependency 
   /usr/lib64/libggz-gtk.so.1.0.0 /lib64/libdl.so.2
These probably come from either an overzealous configure script or .pc files; I
don't think they particularly hurt anything.

The rpath thing, though, will need a tweak.  I guess we're recommending using
chrpath these days, but also check the ggz-client-libs specfile to see what Rex did.
Comment 2 Brian Pepple 2008-01-28 11:35:58 EST
Spec URL: http://bpepple.fedorapeople.org/rpms/ggz-gtk-client.spec
SRPM URL: http://bpepple.fedorapeople.org/rpms/ggz-gtk-client-0.0.14-2.fc8.src.rpm

* Mon Jan 28 2008 Brian Pepple <bpepple@fedoraproject.org> - 0.0.14-2
- Fix rpath.

Here's a link to a F9 scratch build to save time for any reviewer:
http://koji.fedoraproject.org/koji/taskinfo?taskID=378254
Comment 3 Jason Tibbitts 2008-02-03 14:24:04 EST
I recently became aware of a fix for the unused-direct-shlib-dependency
complaints; you can put this after the %configure call:

# hack to omit unused-direct-shlib-dependencies
sed -i -e 's! -shared ! -Wl,--as-needed\0!g' libtool

and the problematic dependencies go away.  It's not a huge issue but it's easy
to fix, so do what you think is best.

With that fix, the only other rpmlint complaint is:
  ggz-gtk-client-devel.x86_64: W: no-documentation
which is not a problem.

* source files match upstream:
   790f7db17e252e02c07f68cbdda3de071945e284582edd1c5b21891e568c6cff  
   ggz-gtk-client-0.0.14.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summaries are OK.
* descriptions are 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 are proper.
* 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-gtk-client-0.0.14-2.fc9.x86_64.rpm
   libggz-gtk.so.1()(64bit)
   ggz-gtk-client = 0.0.14-2.fc9
  =
   /sbin/ldconfig
   libgdk-x11-2.0.so.0()(64bit)
   libgdk_pixbuf-2.0.so.0()(64bit)
   libggz-gtk.so.1()(64bit)
   libggz.so.2()(64bit)
   libggzcore.so.9()(64bit)
   libglib-2.0.so.0()(64bit)
   libgobject-2.0.so.0()(64bit)
   libgtk-x11-2.0.so.0()(64bit)
   libpango-1.0.so.0()(64bit)

  ggz-gtk-client-devel-0.0.14-2.fc9.x86_64.rpm
   ggz-gtk-client-devel = 0.0.14-2.fc9
  =
   ggz-client-libs-devel
   ggz-gtk-client = 0.0.14-2.fc9
   gtk2-devel
   libggz-devel
   libggz-gtk.so.1()(64bit)

* %check is not; no test suite upstream.
* shared libraries installed; ldconfig is called properly.
* unversioned .so files are in the -devel package.
* 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 -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are in the -devel package.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.

APPROVED
Comment 4 Brian Pepple 2008-02-04 09:36:36 EST
New Package CVS Request
=======================
Package Name: ggz-gtk-client
Short Description: Gtk+ client libraries for GGZ gaming zone
Owners: bpepple
Branches: 
Cvsextras Commits: Yes
Comment 5 Kevin Fenzi 2008-02-04 14:21:39 EST
cvs done.
Comment 6 Brian Pepple 2008-02-04 15:18:14 EST
built.  thanks for the review, Tibbs.
Comment 7 Rex Dieter 2008-02-05 09:31:29 EST
Brian, feel free to add yourself as comaintainer in any capacity you wish for 
dep's libggz-devel, ggz-client-libs (and I'll add myself here as mostly an 
observer, if you don't mind).

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