Red Hat Bugzilla – Bug 200348
Review Request: libgadu - Gadu-Gadu protocol support library
Last modified: 2007-11-30 17:11:38 EST
Spec URL: http://pmail.pl/~raven/libgadu.spec SRPM URL: http://pmail.pl/~raven/libgadu-20060726-1.src.rpm Description: Hi, it's my first package and I'm looking for review and sponsor. :) libgadu is intended to make it easy to add Gadu-Gadu communication support to your software. It's needed by gaim-gadugadu package, which provides support for Gadu-Gadu protocol in Gaim IM client.
Hi :) Thanks for packaging it, I wanted to do it, too :) I'm not a sponsor, but I can give you some advices: * as far as I know, license of libgadu is only LGPL * you should include COPYING file to %%doc, and also, include more docs in the main package, not in -devel * I don't think using of libgadu-current.tar.gz is good. This file changes every day and md5sum of upstream source won't match md5 of source included in SRPM * you should change doc files charset to utf8 (by iconv) * change version in changelog entry. According to changelog inital release is 20060717-1, but in fact it is 20060726-1
Thanks for the advicies: >* as far as I know, license of libgadu is only LGPL See it's official site. :) >* you should include COPYING file to %%doc, and also, include more docs in the main package, not in -devel COPYING file is not included in upstream tarball, and more docs are not useful (it's related only to ekg program) >* I don't think using of libgadu-current.tar.gz is good. This file changes every day and md5sum of upstream source won't match md5 of source included in SRPM Have you any idea? >* you should change doc files charset to utf8 (by iconv) OK, I'll do it, but please help me, I'm new to RPM. >* change version in changelog entry. According to changelog inital release is 20060717-1, but in fact it is 20060726-1 Ops, my ommision, I will correct it in next release.
Thanks for the advices. I've updated spec. Spec URL: http://pmail.pl/~raven/libgadu.spec SRPM URL: http://pmail.pl/~raven/libgadu-20060726-1.src.rpm
Sorry, I didn't remember to add changelog entry and bump release. Spec URL: http://pmail.pl/~raven/libgadu.spec SRPM URL: http://pmail.pl/~raven/libgadu-20060726-2.src.rpm
(In reply to comment #2) > >* I don't think using of libgadu-current.tar.gz is good. This file changes > every day and md5sum of upstream source won't match md5 of source included > in SRPM > > Have you any idea? I tried looking for versioned downloads -- if I spoke any Polish I suspect I might have had better luck. But MichaÅ is right; this poses a "challenge" for the review. > >* you should change doc files charset to utf8 (by iconv) > > OK, I'll do it, but please help me, I'm new to RPM. You can use a tool called iconv. See, e.g., "file-not-utf8" at http://www.fedoraproject.org/wiki/PackagingTips/Perl
(In reply to comment #5) > I tried looking for versioned downloads -- if I spoke any Polish I suspect I > might have had better luck. But MichaÅ is right; this poses a "challenge" for > the review. I speak Polish very well (much better than English ;)) but it looks bad. Official site doesn't include versioned downloads. Maybe, he should copy tarball to his own server? > You can use a tool called iconv. See, e.g., "file-not-utf8" at > http://www.fedoraproject.org/wiki/PackagingTips/Perl It has already done in new spec.
(In reply to comment #6) > (In reply to comment #5) > > I tried looking for versioned downloads -- if I spoke any Polish I suspect I > > might have had better luck. But MichaÅ is right; this poses a "challenge" for > > the review. > > I speak Polish very well (much better than English ;)) but it looks bad. > Official site doesn't include versioned downloads. Maybe, he should copy > tarball to his own server? Hrm. Well, one thing to try would be to email upstream and ask if they could start keeping versioned packages somewhere. The viability of that depends on how often the "current" tarball changes, I suspect. But it is critical to be able to point somewhere and say "this package is version foo" authoritatively. If they don't respond, well, then we figure out Plan B :)
Created attachment 133570 [details] Make aclocal shut up
Created attachment 133571 [details] Fixes for the spec file
I'm not a sponsor so this review is informal: * You should pass option --disable-bind or --enable-bind to configure script. Without it rebuild of a package in different build environment can lead to different dependencies/features of final RPM. * Debian package adds option --enable-pthread. IMHO it's worth to enable it, too. * Add CFLAGS_LIBGADU="$CFLAGS" to configure script. Right now package is being built without gcc optimizations/security features. * Mark proper files as %lang(pl). Please see http://www.redhat.com/archives/fedora-extras-list/2006-August/msg00090.html for more information * Replace %files with %%files. Hint: you should run rpmlint on srpms, too: [rpm-build@X RPMS]$ rpmlint ../SRPMS/libgadu-20060726-2.src.rpm W: libgadu macro-in-%changelog files [rpm-build@X RPMS]$ I have changed $RPM_BUILD_ROOT to %{buildroot} because it's shorter. You can revert this change if you don't like it.
Thanks! Spec URL: http://pmail.pl/~raven/libgadu.spec SRPM URL: http://pmail.pl/~raven/libgadu-20060802-1.src.rpm Upstream didn't agree to release standalone libgadu tarballs. :/ Maybe I could use CVS? Otherwise I have to package main ekg program (which has problems with UTF-8), with libgadu as subpackage. :(
(In reply to comment #11) > Upstream didn't agree to release standalone libgadu tarballs. :/ Maybe I could > use CVS? Otherwise I have to package main ekg program (which has problems with > UTF-8), with libgadu as subpackage. :( I don't think so. If your reviewer agrees, you'll can copy upstream source to your own server. I think this is the best solution.
(In reply to comment #12) > (In reply to comment #11) > > Upstream didn't agree to release standalone libgadu tarballs. :/ Maybe I could > > use CVS? Otherwise I have to package main ekg program (which has problems with > > UTF-8), with libgadu as subpackage. :( > > I don't think so. If your reviewer agrees, you'll can copy upstream source > to your own server. I think this is the best solution. I don't know if there's precedent, but given the situation I don't believe hosting a dated copy of the tarball on a different host is unreasonable. I'd make sure that the tarball itself is dated tho -- e.g. libgadu-20060801.tar.gz or somesuch.
Rpmlint output to the newest srpm: W: libgadu macro-in-%changelog configure W: libgadu macro-in-%changelog lang You have to simply change %configure to %%configure and %lang(pl) to %%lang(pl).
And one another thing: shouldn't libgadu.so.3.5 be stripped? Make install strips it, but you unstrips it in %%files section. You can fix it in two ways, either change defattr macro to %defattr(-,root,root,-) or add %attr(0755,root,root) before libgadu.so.3.5 file.
What's the problem with packaging ekg instead? I have a working package if anyone is interested.
(In reply to comment #16) > What's the problem with packaging ekg instead? I have a working package if > anyone is interested. I don't think there'd be a problem packaging ekg -- I'm sure ekg and libgadu are not mutually exclusive. Go ahead and submit it if you like. :)
Unfortunately, there is, because ekg includes it. libgadu was written by ekg developers. And ekg does have numbered releases, hence my suggestion to package ekg instead. I have an ekg src.rpm that produces both ekg and libgadu.
Until such a time that libgadu is released separately from ekg and ekg is fixed to build agains external libgadu, Piotr and I have decided to derive libgadu from ekg. I've submitted ekg in bug 205127. When libgadu is released separately, we can revisit this.