Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 206875

Summary: Review Request: libgadu - Gadu-Gadu protocol support library
Product: [Fedora] Fedora Reporter: Dominik 'Rathann' Mierzejewski <dominik>
Component: Package ReviewAssignee: Michał Bentkowski <mr.ecik>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: gajownik
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-09-17 20:24:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 163779    

Description Dominik 'Rathann' Mierzejewski 2006-09-17 16:22:25 UTC
Spec URL: http://rpm.greysector.net/extras/libgadu.spec
SRPM URL: http://rpm.greysector.net/extras/libgadu-1.7.0-1.src.rpm
Description:
libgadu is intended to make it easy to add Gadu-Gadu communication
support to your software.

Comment 1 Dominik 'Rathann' Mierzejewski 2006-09-17 17:20:09 UTC
My ekg package is already tested and ready to build against this. I only need to
cvs commit && make tag build. gg2 (currently under review in bug 205136) doesn't
require any changes.

Comment 2 Michał Bentkowski 2006-09-17 19:09:57 UTC
I'll take it.

Comment 3 Michał Bentkowski 2006-09-17 19:35:25 UTC
MUST items:

 * rpmlint:
W: libgadu-devel no-documentation
(should be ignored)
 * package meets Packaging (Naming) Guidelines
 * package is licensed by LGPL open-source compatible license
 * spec file is legible
 * md5sums are matching (152180afbbad584017592a3021aac97a)
 * package successfully compiles on x86_64
 * BRs are good (mock builds fine)
 * no locales
 * proper %post and %postun
 * not relocatable
 * package doesn't create any directories
 * every %files includes %defattr
 * proper %clean section
 * header, .pc and .so files are in -devel
 * devel requires the base package using a fully versioned dependency
 * .la archives removed
 * no gui

Everything looks good.
Don't forget to remove libgadu from ekg.spec.

APPROVED

Comment 4 Dawid Gajownik 2006-09-17 20:11:54 UTC
>  * BRs are good (mock builds fine)

No, they are not. autoconf and automake are superflous.

Comment 5 Dawid Gajownik 2006-09-17 20:19:49 UTC
Oops, I forgot to mention, that it would be better to pass
`--disable-dependency-tracking' to %configure macro. This speeds up a bit
building and makes output more legible.

Comment 6 Michał Bentkowski 2006-09-17 20:22:31 UTC
(In reply to comment #4)
> No, they are not. autoconf and automake are superflous.

Okay, my fault... I only tested if mock builds fine, didn't check for
their superflousment...

Comment 7 Dominik 'Rathann' Mierzejewski 2006-09-17 20:24:54 UTC
Imported and built for devel. FC-5 branch requested. ekg updated and built for
devel. FC-5 rebuild pending. I'll check the BRs later.

Comment 8 Dominik 'Rathann' Mierzejewski 2006-09-18 17:22:32 UTC
According to http://fedoraproject.org/wiki/Extras/FullExceptionList automake and
autoconf are NOT in the minimal buildroot, so they are NOT redundant. Dawid,
feel free to prove me wrong.

Comment 9 Dawid Gajownik 2006-09-18 18:21:34 UTC
Well, you don't regenerate configure script nor Makefile.in files. I don't see a
reason to BR automake or autoconf ;-) Package builds fine without them.

BTW I noticed some differences in libgadu.pc file when someone recompiles
libgadu with or without pkgconfig. What is more, there is to much bloat (I mean
including whole CFLAGS variable from build system). libgadu.pc from ekg's
libgadu-devel subpackage looks more sane to me :)

Comment 10 Dominik 'Rathann' Mierzejewski 2006-10-01 15:42:56 UTC
You are correct. I'll fix this later. Thanks!