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 188176 - Review Request: gauche-gtk - Gauche extension module to use GTK
Summary: Review Request: gauche-gtk - Gauche extension module to use GTK
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On: 188168
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2006-04-06 17:55 UTC by Gérard Milmeister
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-05-15 23:39:42 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Log from failing build in mock (development, i386) (deleted)
2006-05-03 17:49 UTC, Jason Tibbitts
no flags Details
local build log (deleted)
2006-05-05 08:53 UTC, Gérard Milmeister
no flags Details
mock build log (deleted)
2006-05-05 08:54 UTC, Gérard Milmeister
no flags Details

Description Gérard Milmeister 2006-04-06 17:55:05 UTC
Spec Url: http://math.ifi.unizh.ch/fedora/spec/gauche-gtk.spec
SRPM Url: http://math.ifi.unizh.ch/fedora/5/i386/SRPMS.gemi/gauche-gtk-0.4.1-5.fc5.src.rpm
Description:
Gauche extension module to use GTK.

Comment 2 Jason Tibbitts 2006-05-03 17:48:04 UTC
I'm getting a build failure in mock:

checking for X... no
configure: creating Gauche-gtk.gpd
*** ERROR: Compile Error: can't find dlopen-able module "srfi-1-lib"
"/usr/bin/gauche-package":37:(use srfi-1)

Stack Trace:
_______________________________________

This repeats with the same error a few times; I'll attach a build log.


Comment 3 Jason Tibbitts 2006-05-03 17:49:20 UTC
Created attachment 128549 [details]
Log from failing build in mock (development, i386)

Comment 4 Jason Tibbitts 2006-05-03 18:44:28 UTC
Note, the failure is identical when building for FC5-i386, but is somewhat
different when building for FC5-x86_64.  There it seems to get fully through the
configure phase and most of the way through compilation and then dies:

/usr/bin/ld: gauche-gtk.o: relocation R_X86_64_32 against `a local symbol' can
not be used when making a shared o
bject; recompile with -fPIC
gauche-gtk.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [gauche-gtk.so] Error 1

None of these change when I turn of parallel make, BTW.

Comment 5 Gérard Milmeister 2006-05-03 22:28:57 UTC
The failure on i386 is due to inconsistent naming of the arch
directory in gauche, there are both i386-redhat-linux-gnu and
i686-redhat-linux-gnu, so that the so files could not be found.
I patched gauche, so that the both are the same.
This problem doesn't occur on x86_64. The problem
you reported is probably not from gauche but from gauche-gtk itself.
I will look at it, probably missing -fPIC when compiling the sources,
just as the error message says.

Gauche is being rebuild. Please check it out as soon as it gets to the
repositories and try the following:
- start gosh
- enter "(use srfi-1)"
this should now return #<undef> and no error any more.

Comment 6 Jason Tibbitts 2006-05-05 04:00:03 UTC
Building on i386 with the fixed gauche gets further, but then fails:

gcc -DHAVE_CONFIG_H -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4
-m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables
-I'/usr/lib/gauche/0.8.7/include'  -fomit-frame-pointer -ma
rch=i686 -DUSE_I686_PREFETCH `pkg-config --cflags gtkglext-1.0`   -c -o
glgdGraph.o glgdGraph.c

In file included from /usr/include/pango-1.0/pango/pangofc-font.h:25,
                 from /usr/include/pango-1.0/pango/pangoft2.h:29,
                 from glgd.h:21,
                 from gauche-glgd.h:26,
                 from glgdGraph.c:12:
/usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No such file
or directory

and then there are cascading errors off of that; I'll attach the build log if
you're interested.  I thought the problem might be a missing BR: freetype-devel,
but no luck.  usr/include/freetype2/freetype/config/ftheader.h does exist.  It
almost seems as if a call to pkgconfig --cflags freetype2 needs to be made.

I'm not really sure what's up.  I know you wouldn't have submitted these
packages if they didn't build for you, but I'm just having no luck at all
building them.  Are you able to do mock builds?  I'm pretty sure my build setup
is working OK, so you should be able to see the same failures I'm seeing.

Comment 7 Gérard Milmeister 2006-05-05 08:50:26 UTC
You are right: mock build fails. However outside of mock the build succeeds.
I don't know what happens here, I compared both build logs and they differed
(except for the build paths) only the moment the build fails!
I included buildrequires for some X libraries (configure checks for them),
but nothing changes (package at the same place). The only thing that I noticed
is, that some packages retrieved by mock are older than the corresponding
packages I have installed locally (both mock and local are FC5), for example
cairo = 1.0.4 locally but 1.0.2 in mock, and gtk = 2.8.15 in mock vs 2.8.17
locally.

Comment 8 Gérard Milmeister 2006-05-05 08:53:35 UTC
Created attachment 128648 [details]
local build log

Comment 9 Gérard Milmeister 2006-05-05 08:54:11 UTC
Created attachment 128649 [details]
mock build log

Comment 10 Gérard Milmeister 2006-05-05 08:55:56 UTC
You can use meld to compare the two logs and see that they hardly differ
up to the break down.

Comment 11 Paul Howarth 2006-05-05 10:17:44 UTC
(In reply to comment #10)
> You can use meld to compare the two logs and see that they hardly differ
> up to the break down.

I don't think it's a mock issue; I can reproduce this failure with a local FC5
build. Still investigating.

What I don't understand is how the build can possibly succeed without
-I/usr/include/freetype2 on the failing command. What is the output of:

pkg-config --cflags gtkglext-1.0

on your local systems?

Here, I get:
-I/usr/include/gtkglext-1.0 -I/usr/lib/gtkglext-1.0/include
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0
-I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/atk-1.0

which does not include the necessary directory.

Comment 12 Gérard Milmeister 2006-05-05 12:51:41 UTC
Mea culpa!
On my system I had linked /usr/include/freetype2 to /usr/include/freetype.
When I removed the link, the build doesn't work anymore.
So I defined CFLAGS to use the freetype pkg-config flags in the spec
file. Now it builds in mock too.

However, this means, that there is a bug in the pkg-config for
pango: it returns only -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include, but since the pango header file
pangofc-font.h includes ft2build.h, the include path for freetype
must be added too.

Updated package:
http://math.ifi.unizh.ch/fedora/5/i386/SRPMS.gemi/gauche-gtk-0.4.1-7.fc5.src.rpm

Comment 13 Paul Howarth 2006-05-05 13:01:36 UTC
(In reply to comment #12)
> However, this means, that there is a bug in the pkg-config for
> pango: it returns only -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include, but since the pango header file
> pangofc-font.h includes ft2build.h, the include path for freetype
> must be added too.

I thought it would be something along those lines but was a bit confused by the
fact that pango-devel includes five .pc files, and the pangoft2.pc and
pangoxft.pc files do have the necessary include path.

So perhaps it's gtkglext-1.0.pc or gdkglext-x11-1.0.pc that should require
pangoft2 or pangoxft?


Comment 14 Gérard Milmeister 2006-05-05 13:09:28 UTC
Ah, I see. IMHO this splitting in five .pc files is very bad.
gtkglext probably dates from a time when pango had just one
.pc file.
BTW I also added -fPIC to CFLAGS, otherwise the shared object
file gets a TEXTREL and loading it with selinux enabled will
not work.

Comment 15 Ralf Corsepius 2006-05-05 13:39:05 UTC
(In reply to comment #13)
> So perhaps it's gtkglext-1.0.pc or gdkglext-x11-1.0.pc that should require
> pangoft2 or pangoxft?
Hmm, does anybody see any direct dependency between gtkglext and pangoft2 or
pangoxft?

At least, I don't see any, so I am inclined to think there might be a missing
dep anywhere underneath. Or am I missing something?




Comment 16 Gérard Milmeister 2006-05-05 13:53:15 UTC
(In reply to comment #15)

> At least, I don't see any, so I am inclined to think there might be a missing
> dep anywhere underneath. Or am I missing something?

No, it is glgd.h that includes <pango/pangoft2.h>.



Comment 17 Paul Howarth 2006-05-05 14:01:24 UTC
(In reply to comment #15)
> (In reply to comment #13)
> > So perhaps it's gtkglext-1.0.pc or gdkglext-x11-1.0.pc that should require
> > pangoft2 or pangoxft?
> Hmm, does anybody see any direct dependency between gtkglext and pangoft2 or
> pangoxft?
> 
> At least, I don't see any, so I am inclined to think there might be a missing
> dep anywhere underneath. Or am I missing something?

As it happens, I think Gérard has done exactly the right thing.

This package is explicitly calling for ft2 support by including pango/pangoft2.h
from glgd.h. This only happens if the --enable-glgd-pango option is passed to
the configure script, and HAVE_GLGD_PANGO gets set. So it's this client, and not
a problem stemming from a missing dep somewhere down the tree.

If there's a bug, I suggest that it's that --enable-glgd-pango in this package
should also pull in the pangoft2 pkgconfig file for include directory settings.


Comment 18 Jason Tibbitts 2006-05-06 19:11:07 UTC
OK, now we're getting somewhere.  Rawhide still looks broken to me, but builds
in FC5, i386 and x86_64 succeed and I ran through the examples on x86_64 with no
problems.  rpmlint has a couple of complaints:

W: gauche-gtk hidden-file-or-dir /usr/share/gauche/0.8.7/lib/.packages
W: gauche-gtk hidden-file-or-dir /usr/share/gauche/0.8.7/lib/.packages
W: gauche-gtk doc-file-dependency
/usr/share/doc/gauche-gtk-0.4.1/examples/glgd/run /bin/sh

The problem with the first warning is that it will set off various rootkit
detection programs and is generally a bad idea, but I'm not sure if it would be
feasible to change where gauche looks for its packages.  I'm inclined to say
this isn't a blocker, but if it's not difficult to make gauche look in
"packages" instead of ".packages" then I think it would be best if you could do so.

The second is simply that the doc file is executable, which is generally
considered a bad idea although in this case the dependency doesn't cause
problems.  I would suggest that you just chmod -x examples/glgd/run.

Review:
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* license field matches the actual license.
* license is open source-compatible; text is included in the package.
* source files match upstream:
   18356efab446b9524be8371a3b852a6a  Gauche-gtk-0.4.1.tgz
   18356efab446b9524be8371a3b852a6a  Gauche-gtk-0.4.1.tgz-srpm
* latest version is being packaged.
* BuildRequires are proper.
* package builds in mock (FC5, i386 and x86_64).
O rpmlint has excusable errors.
* final provides and requires are sane.
O shared libraries are present, but they are internal to Gauche and so ldconfig
doesn't need to be called.
* package is not relocatable.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
O file permissions are appropriate, exceot for an executable docfile.
* %clean is present.
O %check is not present; no test suite upstream.
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no libtool .la droppings.

APPROVED, but please consider the two issues above before checking in.

Comment 19 Gérard Milmeister 2006-05-06 19:48:20 UTC
(In reply to comment #18)
> OK, now we're getting somewhere.  Rawhide still looks broken to me, but builds
> in FC5, i386 and x86_64 succeed and I ran through the examples on x86_64 with no
> problems.
That sounds good!
> W: gauche-gtk hidden-file-or-dir /usr/share/gauche/0.8.7/lib/.packages
> W: gauche-gtk hidden-file-or-dir /usr/share/gauche/0.8.7/lib/.packages
I understand the point. In fact the directory ".packages" is coded
in the file package.scm of gauche. The problem is that ".packages"
is hardcoded in the makefiles of the gtk and gl packages. This means
that changing the directory will propagate down to the packages. I
would rather leave it as it is for now.

> W: gauche-gtk doc-file-dependency
> /usr/share/doc/gauche-gtk-0.4.1/examples/glgd/run /bin/sh
This file should be deleted anyway.
BTW, the examples using OpenGL only run when gauche-gl is installed.
Probably gauche-gtk should depend on gauche-gl then. Should we wait
for the gauche-gl to be ready?


Comment 20 Jason Tibbitts 2006-05-06 20:34:06 UTC
> I understand the point. In fact the directory ".packages" is coded
> in the file package.scm of gauche. The problem is that ".packages"
> is hardcoded in the makefiles of the gtk and gl packages.

Isn't it just one line in each makefile, though?  I don't think it's a blocker,
but it's probably easier to change it now than to wait until later when you'd
have to coordinate releases of all three packages.

> BTW, the examples using OpenGL only run when gauche-gl is installed.
> Probably gauche-gtk should depend on gauche-gl then.

Surely not for an example.  If you want to be complete, you can add a note in
that directory indicating that the -gl package needs to be installed in order
for them to work.

I'll be working on gauche-gl soon in any case.

Comment 21 Gérard Milmeister 2006-05-10 20:12:31 UTC
(In reply to comment #20)
> Surely not for an example.  If you want to be complete, you can add a note in
> that directory indicating that the -gl package needs to be installed in order
> for them to work.

The module gl from gauche-gl is in fact imported from the module glgd
which is part of gauche-gtk, so I would say that gauche-gl is required
for gauche-gtk to provide the full functionality.

Comment 22 Jason Tibbitts 2006-05-15 18:14:35 UTC
Were you going to check this in?  I see no reason not to add a dependency on
gauche-gl if it makes sense to do so.

Comment 23 Gérard Milmeister 2006-05-15 19:14:28 UTC
Ok, I thought there would be an further comment about this issue.

Comment 24 Gérard Milmeister 2006-05-15 23:39:42 UTC
Built on FC-4, FC-5 and FC-6.
Added to owners.list.

Thanks for the review!


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