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 193106 - Review Request: gtkmozembedmm
Summary: Review Request: gtkmozembedmm
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2006-05-25 10:51 UTC by Haïkel Guémar
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-11-22 07:43:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
mock root.log (deleted)
2006-09-17 08:47 UTC, Haïkel Guémar
no flags Details
mock build.log (deleted)
2006-09-17 08:48 UTC, Haïkel Guémar
no flags Details

Description Haïkel Guémar 2006-05-25 10:51:58 UTC
Spec URL: http://darkenphoenix.free.fr/RPMS/RPMS/Extras/SPECS/gtkmozembedmm.spec
SRPM URL: http://darkenphoenix.free.fr/RPMS/RPMS/Extras/SRPMS/gtkmozembedmm-1.4.2-1.src.rpm
Description: C++ bindings to libgtkembedmoz

This is one of my first packages, I need a sponsor

Comment 1 Kevin Fenzi 2006-09-02 06:35:50 UTC
OK - Package name
OK - Spec file matches base package name.
OK - Meets Packaging Guidelines.
OK - License (LGPL)
OK - License field in spec matches
OK - License file included in package
OK - Spec in American English
OK - Spec is legible.
See below - Sources match upstream md5sum:
See below - Package compiles and builds on at least one arch.
See below - BuildRequires correct
See below - Spec has needed ldconfig in post and postun
OK - Package owns all the directories it creates.
OK - Package has no duplicate files in %files.
OK - Package has %defattr and permissions on files is good.
OK - Package has a correct %clean section.
OK - Spec has consistant macro usage.
OK - Package is code or permissible content.
OK - Packages %doc files don't affect runtime.
OK - Headers/static libs in -devel subpackage.
OK - .pc files in -devel subpackage.
OK - .so files in -devel subpackage.
OK - -devel package Requires: %{name} = %{version}-%{release}
OK - .la files are removed.
See below - Package doesn't own any directories other packages own.
See below - No rpmlint output.

SHOULD Items:
OK - Should include License or ask upstream to include it.
See below - Should build in mock.

Issues:

1. Source's don't match from upstream:
2e15fa5ac91ee0d8434d79fb0bb2badd  gtkmozembedmm-1.4.2.tar.gz
d4233234e0af148764cb59d578f101fd  gtkmozembedmm-1.4.2.tar.gz.1

2. Is this package targeted for fc5 only? devel/rawhide/fc6 doesn't have
mozilla-devel.

3. The URL doesn't seem to mention this library at all:
URL:            http://gtkmm.sourceforge.net/
Is there a more approprate one?

4. Since ldconfg is the only command you are running in the
post and postun, you might change them to '%post -p /sbin/ldconfig'
and '%postun -p /sbin/ldconfig'

5. Might not include the useless INSTALL and perhaps you should
include the TODO file.

6. It doesn't seem to want to build here in mock for fc5:
+ ./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --
target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr 
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --
includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --
localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/
usr/share/info --disable-static --enable-docs
configure: error: cannot find install-sh or install.sh in scripts ./scripts
error: Bad exit status from /var/tmp/rpm-tmp.22962 (%build)
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.22962 (%build)


Comment 2 Haïkel Guémar 2006-09-11 08:44:08 UTC
* updated spec:
http://darkenphoenix.free.fr/RPMS/RPMS/Extras/SPECS/gtkmozembedmm.spec
* updated SRPM:
http://darkenphoenix.free.fr/RPMS/RPMS/Extras/SRPMS/gtkmozembedmm-1.4.2.cvs20060817-3.fc5.src.rpm

0. License has been added (LGPL)

1. this is a mistake, the previous package didn't follow naming guidelines.
Since the last tarball available is 2 years old and no more working, I'm using a
cvs snapshot (17/08/2006 currently). 
I tested the sources, and I can compile and launch a minimal web browser using
the bindings.
2. the autotools scripts requires mozilla-gtkmozembed.pc, so I added a
conditional build requires on firefox-devel for FC6+ (plus a sed script to
require firefox-gtkmozembed.pc) and mozilla-devel for older release.
I didn't test the fc6 package but it builds fine under mock.
3. gtkmozembedmm has no web place except gnome cvs, but gtkmm mailing-lists
provide some support.
The binding is listed here: http://gtkmm.sourceforge.net/extra.shtml
4. done
5. done
6. the install-sh script is a symlink to /usr/share/automake-1.9/install-sh , I
added automake-1.9 as BR, now the package builds in mock for fc5/f6 i386.

Comment 3 Kevin Fenzi 2006-09-12 02:16:30 UTC
0. ok.
 
1. Can you provide a quick script to get the cvs version you are using?

2. Sounds reasonable. I think there is movement to get a seperate package that 
provides this in fc7+, but for now this is the best solution. 

3, 4, 5, 6: ok. 

Now that I can get it to build in mock, rpmlint says: 

W: gtkmozembedmm unstripped-binary-or-object /usr/lib/libgtkmozembedmm-
1.4.so.0.0.0
E: gtkmozembedmm-debuginfo empty-debuginfo-package

These two are likely the permissions on the library being 644 instead of 755, 
so they don't properly get stripped and debuginfo collected. Change that file 
to 755 and it should clear up those issues. 

E: gtkmozembedmm-devel only-non-binary-in-usr-lib

Some of the path's look wrong: 

drwxr-xr-x    2 root    root                0 Sep 11 20:08 /usr/lib/
gtkmozembedmm-1.4
drwxr-xr-x    2 root    root                0 Sep 11 20:08 /usr/lib/
gtkmozembedmm-1.4/include
-rw-r--r--    1 root    root              289 Sep 11 20:08 /usr/lib/
gtkmozembedmm-1.4/include/gtkmozembedmmconfig.h
drwxr-xr-x    2 root    root                0 Sep 11 20:08 /usr/lib/
gtkmozembedmm-1.4/proc
drwxr-xr-x    2 root    root                0 Sep 11 20:08 /usr/lib/
gtkmozembedmm-1.4/proc/m4
-rw-r--r--    1 root    root              177 Sep 11 20:08 /usr/lib/
gtkmozembedmm-1.4/proc/m4/convert.m4
-rw-r--r--    1 root    root             1154 Sep 11 20:08 /usr/lib/
gtkmozembedmm-1.4/proc/m4/convert_gtkmozembedmm.m4

Shouldn't that be /usr/include/gtkmozembedmm/ ? 
not sure where the m4 files should go, but /usr/lib/ seems wrong...

W: gtkmozembedmm-devel no-documentation

This can be ignored. 

Comment 4 Haïkel Guémar 2006-09-14 14:50:39 UTC
* updated spec:
http://darkenphoenix.free.fr/RPMS/RPMS/Extras/SPECS/gtkmozembedmm.spec
* script to build the tarball from cvs: 
http://darkenphoenix.free.fr/RPMS/RPMS/Extras/SPECS/gtkmozembedmm-cvs.sh
* updated SRPM:
http://darkenphoenix.free.fr/RPMS/RPMS/Extras/SRPMS/gtkmozembedmm-1.4.2.cvs20060817-4.fc5.src.rpm

1. Well, I made a little script that download a cvs snapshot and compress it in
a tarball. I'm not sure why, but md5sum between 2 snapshots are always different
though diff -Naur between 2 directories shows no difference.
2. done
3. looks like m4 macros are mostly located in /usr/include, so I put them there. 
4. Since i automated the generation of the tarball, I made minor changes like
enabling maintainer mode in %configure, this is necessary to enable specific
parts of makefiles without them the build will fail. (So I had to add libtool as
a BR)
5. builds in mock for fc5 i386 & fc6 i386 configuration, new package seems
working, rpmlint output:
W: gtkmozembedmm-devel no-documentation

Comment 5 Kevin Fenzi 2006-09-16 00:15:14 UTC
In reply to comment #4: 

1. Yeah, the md5 is going to be diffrent because you change some files and copy 
them, which changes timestamps. Also, the autogen.sh run each time will have 
diffrent timestamps, so it's not going to match. 
Everything looks good with diff however, so I don't think thats a blocker. 

2-4: ok. 

5. I am getting failures in mock... 
fc6/i386 gives me: 

./configure: line 19134: syntax error near unexpected token `5.6.0'
./configure: line 19134: `GLIBMM_CHECK_PERL(5.6.0)'
error: Bad exit status from /var/tmp/rpm-tmp.78710 (%build)


Comment 6 Haïkel Guémar 2006-09-17 08:47:41 UTC
Created attachment 136472 [details]
mock root.log

Comment 7 Haïkel Guémar 2006-09-17 08:48:20 UTC
Created attachment 136473 [details]
mock build.log

Comment 8 Haïkel Guémar 2006-09-17 08:51:48 UTC
Weird, I tried twice to build the package under Mock for this configuration and
it never failedwith the same src.rpm.
$ mock -r fedora-6-i386-core.cfg gtkmozembedmm-1.4.2.cvs20060817-4.fc5.src.rpm
init
clean
prep
This may take a while
setup
build
ending
done
Results and/or logs in: /var/lib/mock/fedora-development-i386-core/result


Comment 10 Kevin Fenzi 2006-09-17 15:48:18 UTC
Very odd. 
I have downloaded your src.rpm from comment #9 and unpacked it and fired off 
some mock builds on it. Will see if that works or if I can see the issue 
anywhere else. 

Comment 11 Kevin Fenzi 2006-09-17 16:57:41 UTC
ok, Not sure if I had a corrupt autocache or a stale mirror or what... 
It now builds fine on fc6/i386. 

I am getting a diffrent build error on fc6/x86_64 however: 

Making all in src
make[2]: Entering directory `/builddir/build/BUILD/gtkmozembedmm-
1.4.2.cvs20060817/gtkmozembed/src'
/usr/lib/glibmm-2.4/proc/gmmproc -I ../../tools/m4 --defs . webcontrol . ./../
gtkmozembedmm
make[2]: /usr/lib/glibmm-2.4/proc/gmmproc: Command not found
make[2]: *** No rule to make target `/usr/lib/glibmm-2.4/proc/
generate_wrap_init.pl', needed by `../gtkmozembedmm/wrap_init.cc'.  Stop.
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [.stamps/stamp-webcontrol] Error 127
make[2]: Leaving directory `/builddir/build/BUILD/gtkmozembedmm-
1.4.2.cvs20060817/gtkmozembed/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/builddir/build/BUILD/gtkmozembedmm-
1.4.2.cvs20060817/gtkmozembed'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.44057 (%build)

Looks like it's looking for proc/gmmproc in lib instead of lib64... 


Comment 12 Kevin Fenzi 2006-09-22 22:08:33 UTC
Removing FE-NEEDSPONSOR blocker, as submitter was sponsored in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193109


Comment 13 Kevin Fenzi 2006-09-29 17:49:37 UTC
Any ideas on the failure from comment #11?

I can provide access to a x86_64 test machine if you would like... 

Comment 14 Kevin Fenzi 2006-11-12 01:37:38 UTC
Ping. Have you had a chance to look at the error in comment #11 ?

Comment 15 Haïkel Guémar 2006-11-12 18:17:51 UTC
- new spec
http://darkenphoenix.free.fr/RPMS/RPMS/Extras/SPECS/gtkmozembedmm.spec
- new srpm
http://darkenphoenix.free.fr/RPMS/RPMS/Extras/SRPMS/gtkmozembedmm-1.4.2.cvs20060817-5.src.rpm
I finally someone for testing the build on x86_64, it seems to build now.
It still build under Mock.
- rpmlint output
$ rpmlint -i gtkmozembedmm-1.4.2.cvs20060817-5.fc7.i386.rpm
$ rpmlint -i gtkmozembedmm-devel-1.4.2.cvs20060817-5.fc7.i386.rpm
W: gtkmozembedmm-devel no-documentation
The package contains no documentation (README, doc, etc).
You have to include documentation files.

Comment 16 Michael Schwendt 2006-11-12 18:51:01 UTC
You mix firefox-devel and gecko-devel in a questionable way.
The first provides the latter. Please verify your BuildRequires.

Comment 17 Haïkel Guémar 2006-11-12 20:58:50 UTC
I had uploaded the wrong src.rpm (and the same for the spec), they have been
re-uploaded (same links as above)
For BR, it will depend on mozilla-devel for FC5 and gecko-devel for FC6+, no
more firefox-devel. 

Comment 18 Kevin Fenzi 2006-11-13 02:30:37 UTC
The BR's look ok to me with the re-uploaded version... 

Is the Requires correct though?

Requires: gecko-libs = 1.5.0.8

Why hardcoding the version there? This causes it to break on devel, since devel
has firefox 2.0 in it, which doesn't provide that version of gecko-libs. 

Comment 19 Haïkel Guémar 2006-11-13 08:49:53 UTC
Yes, I asked Remi Collet (from Extras) about it, it avoids breaking packages
depending on Gecko during updates.  
Anyway, the bindings have to be rebuilt each time gecko is updated.
I will increase the versionning for devel when it will be uploaded on cvs.

Comment 20 Kevin Fenzi 2006-11-16 18:21:25 UTC
ok. I guess that makes sense. It will mean that you will have to make sure and
keep on top of rebuilding this package against gecko updates, but as long as you
are willing to do so thats not a blocker. (As a side note you have a comment in
the spec talking about firefox-devel, should update to say gecko-devel).

I don't see any further issues/blockers, so this package is APPROVED. 

Please close this NEXTRELEASE once it's been imported and built. 

Also, consider doing a review on a waiting package to help spread out the
reviewing load. 

Comment 21 Haïkel Guémar 2006-11-22 07:43:56 UTC
I have imported and built the package yesterday.
Closed.


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