Bug 176205 - Review Request: GZLauncher
Review Request: GZLauncher
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Mahowald
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-20 02:30 EST by Nick
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-08 21:31:01 EST
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 Nick 2005-12-20 02:30:16 EST
Spec Name or Url: http://www.filelodge.com/files/hdd4/84253/gzlauncher.spec
SRPM Name or Url: http://www.filelodge.com/files/hdd4/84253/gzlauncher-1.06.4-1.src.rpm

Description: This program allows linux users to connect to and play on ZDaemon servers.
Comment 1 John Mahowald 2005-12-21 12:28:26 EST
Missing BuildRequires: gtk2-devel

This is what shows up in the build log:

checking for gtk+-2.0 >= 2.0.0... Package gtk+-2.0 was not found in the
pkg-config search path. Perhaps you should add the directory containing
`gtk+-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'gtk+-2.0'
found
configure: error: Library requirements (gtk+-2.0 >= 2.0.0) not met; consider
adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a
nonstandard prefix so pkg-config can find them.

In fact, you can skip BuildRequires: gtk2 and change it to gtk2-devel. rpm is
good at finding what libraries things require, but not at the -devel packages
required.

Also change curl to curl-devel.

Drop the auto tools if you're not going to run them before configure.

So in the end we have BuildRequires: gtk2-devel curl-devel desktop-file-utils

Don't own %{_datadir}/applications, filesystem owns that. You can use
%{_datadir}/applications/*
Comment 3 Nick 2005-12-21 17:50:16 EST
Sorry, forgot to drop those auto tools.
New spec file and rpm:
http://www.filelodge.com/files/hdd4/84253/gzlauncher.spec
http://www.filelodge.com/files/hdd4/84253/gzlauncher-1.06.4-2.src.rpm
Comment 4 Nick 2005-12-21 18:25:57 EST
Sorry, forgot to add a changelog entry.
New srpm (spec file included in comment #3):
http://www.filelodge.com/files/hdd4/84253/gzlauncher-1.06.4-3.src.rpm
Comment 5 John Mahowald 2005-12-22 10:07:40 EST
We need to find you a sponsor.

It builds and installs OK, but when I skip the account part and use Launcher >
Preferences in the menus it segfaults.

Doesn't own all directories it creates, particularly %{_datadir}/gzlauncher/.
Instead of including the pixmaps seperately just put ${_datadir}/gzlauncher/ in
%files and own the whole thing.

You don't need to wipe the changelog clean after every new release, it's common
to put new entries on top of the changlog and keep the old ones. But that's not
critical.

Comment 6 Nick 2005-12-22 23:23:10 EST
(In reply to comment #5)
The reason for the program seg faulting is not becasue of the RPM package, it's
because of the program itself.

New spec file and rpm:
http://www.filelodge.com/files/hdd4/84253/gzlauncher.spec
http://www.filelodge.com/files/hdd4/84253/gzlauncher-1.06.4-4.src.rpm
Comment 7 John Mahowald 2005-12-26 21:10:31 EST
Still a couple minor things to fix.

Change Source1 to merely gzlauncher.desktop, by default rpm looks in the sources
dir.

%{_datadir}/gzlauncher/*  does not own the directory %{_datadir}/gzlauncher/
itself.  %{_datadir}/gzlauncher/ will own the directory itself.

Segfault bug submitted.
http://sourceforge.net/tracker/?func=detail&atid=667062&aid=1390964&group_id=114060

- package meets naming guidelines
- package meets packaging guidelines
- license (GPL) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on FC4
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime 
Comment 8 Nick 2006-01-01 03:05:08 EST
I beleive you made a mistake in your comment (comment #7). A few questions:
Is "no locales" bad? An error or something I have to include?
When you say "code, not content", what do you mean? And is this statement good
or bad?

Apart from slight unclarity, I'm glad you like my spec file :)
Comment 9 Nick 2006-01-01 03:18:41 EST
Uploaded new rpm and spec file. Same links.
Comment 10 John Mahowald 2006-01-25 20:31:18 EST
No locales is not necessarily bad. It just means there is no translated messages
you would need the %find_lang macro for. See the packaging guidelines. I'm going
through a checklist of things before approval.
Comment 11 Michael Wood 2006-02-08 14:21:32 EST
Thank you for submitting a bug report for my gzlauncher project. I also
appreciate the testing that is taking place in your attempt to approve the
software. I need to note a few things about the current state of gzlauncher.

1) Due to DoS attacks on the gzlauncher master server the gzlauncher developers
decided that with the latest release of zdaemon they would close the launcher
protocol. The developers would allow me access to the launcher protocol if it
weren't for the open nature of my launcher. As I will not close-source my
software this means that gzlauncher is currently unable to contact the zdaemon
master servers. In the event that someone decides to do a branch off the most
recent open-source version of Zdaemon and use an open launcher protocol I will
support that project with gzlauncher. In the event that Zdaemon decides to open
the launcher protocol at some point I will support that project again as well.

2) GZLauncher was developed rather quickly due to a sudden demand for a decent
Linux launcher. I exclusively use Linux and when I decided I wanted a launcher
other users expressed their desire for one. So, I decided to build GZLauncher
and I cranked it out as quickly as possible. Their are very likely some bugs
including the one that has been reported to me. There is probably memory
allocated but never freed, etc, etc. When the opportunity arises to continue
GZLauncher developent (when the protocol is again open) I plan on doing a full
re-write of the application. This will include changing to the use of libglade
as opposed to using glade produced code for the interface. I will also develop
it more cleanly which will hopefully mean less bugs. I also have many ideas for
features including adding buddly list and an irc client to connect to the
zdaemon player chat as the windows launcher does.

Basically, in my opinion, this software is not in a state to be included in any
packages particularly since it is useless as long as the Zdaemon launcher
protocol remains closed.
Comment 12 John Mahowald 2006-02-08 21:31:01 EST
Closed as per request of Michael in comment 11.

(What a silly condition, only allowing protocol access to closed software. What
are they trying to achieve, security through obscurity?)

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