Bug 239939 - Review Request: libggi - General Graphics Interface toolkit
Summary: Review Request: libggi - General Graphics Interface toolkit
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Matthias Saou
QA Contact: Fedora Package Reviews List
Depends On: 239303
Blocks: 239940
TreeView+ depends on / blocked
Reported: 2007-05-12 22:47 UTC by Nicolas Chauvet (kwizart)
Modified: 2009-07-17 19:20 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-09-15 11:01:01 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Nicolas Chauvet (kwizart) 2007-05-12 22:47:51 UTC
Spec URL:
Description: GGI (General Graphics Interface) toolkit

rpmlint silent

VirtualGL is a project that based upon turbojpeg that requires a special icc compiler. Then there is no need to include it yet...

Comment 1 Parag AN(पराग) 2007-05-22 04:13:46 UTC
*** Bug 239303 has been marked as a duplicate of this bug. ***

Comment 2 Parag AN(पराग) 2007-05-22 04:17:37 UTC
oh just found its confusion of your packages ending gii and ggi.
You submitted same links in 2 review requests.
looks here you need to submit actual libgii package links not libggi.

Comment 3 Nicolas Chauvet (kwizart) 2007-05-22 08:19:41 UTC
Spec URL:
Description: GGI (General Graphics Interface) toolkit

Oups! Indeed... Same directory...

Comment 4 Matthias Saou 2007-05-30 10:39:32 UTC
I'm starting the review for this one :-)

Comment 5 Matthias Saou 2007-05-30 10:51:56 UTC
Preliminary comments :
- Why run autogen.sh when no Makefile.* or configure.* have been patched? Does
it fix something? If it does, please consider adding a comment in the spec file.
- Passing "--libdir=%{_libdir}" to %configure is redundant.
- Why build require Glide3-devel but pass --disable-glide to %configure? Again,
a spec file comment would be nice if anything is known to be broken.
- Why explicitly call "gmake"? RH/Fedora always has GNU make as "make".
- Maybe ChangeLog.1999 could be omitted. Might be the reason why upstream split
the ChangeLog in two in the first place (360kB saved upon installation).
- INSTALL suggests that --enable-threads might be useful.
- Also from INSTALL, might be worth looking at :
 "Use --disable-internal-xf86dga if you are having problems compile/running
  the DGA target.  This will cause the target to use the system's DGA
  protocol implementation instead of rolling its own."

Comment 6 Matthias Saou 2007-05-30 10:54:36 UTC
Oh, blockers now : The package does not own %{_libdir}/ggi/ and the devel
package does not own %{_includedir}/ggi/. Please replace the lines :


With :


Or (but it's longer) :
%dir %{_libdir}/ggi/
%dir %{_includedir}/ggi/

You'll also need to add :
%dir %{_sysconfdir}/ggi/

Comment 7 Nicolas Chauvet (kwizart) 2007-05-30 12:22:23 UTC
ok thx for the review!
I will update to release 3 soon (missed to update to release 2)

fixed some directfb adn glide3 includes...
It seems that if directfb and directfb-internal are added to extra include, it
will break the build.
Some ld skipping incompatible are still present on the log
I think this is minor... ?!

Spec URL:
Description: General Graphics Interface toolkit

Comment 8 Nicolas Chauvet (kwizart) 2007-06-05 16:59:24 UTC
Ok i had some problem with my isp and forgot to upload the spec file...
Now everythnig is right... (well, for reviewing i mean...)

Comment 9 Matthias Saou 2007-06-07 07:33:03 UTC
Further comments :
- I think exporting CFLAGS and CXXFLAGS is redundant (%configure does that)
- Setting "--libdir=%{_libdir}" is redundant (%configure does that)
- The 's|LDFLAGS =  -L/usr/lib|LDFLAGS =  -L%{_libdir}|' substitution seems a
little dangerous, as if the next version has "LDFLAGS =  -L/usr/lib64" somehow,
you're going to be replacing it with /usr/lib6464 on 64bit archs. A more solid
fix could only be better.
- You forgot one last %dir in -devel : %dir %{_includedir}/ggi/
- I don't think the %dirs under %{_sysconfdir} should be in the -devel too.

Other than that it's already looking better ;-)

Comment 10 Matthias Saou 2007-06-15 13:33:32 UTC
Ping? :-)

Comment 11 Nicolas Chauvet (kwizart) 2007-06-18 15:02:04 UTC
Description: General Graphics Interface toolkit

I've disabled directfb because i think liggi is too old to support directfb
0.9.25  from FC-6 (and F-7 version 1.0 )
I've received the advices to uses X from upstream. (from irc)
glide3 plugin is also unable to build whereas it can find headers if
includedir/glide3 is added (might be very rare now...)

- Since i've added %{lib} and %{_libdir} to LDFLAGS i won't try to remove
/usr/lib anymore, 

At this time this package is not supposed to be multilib ( example: config files
set .root: /usr/lib64/ggi). I think it this is mandatory to add it to some
exeptions list for this (with libgii also...)

Comment 12 Matthias Saou 2007-06-19 09:40:44 UTC
Looking good! :-)
Minor :
- Why is ChangeLog.1999 back? It doesn't want to die? ;-)
- Why not just use a single "%{_includedir}/ggi/" line for the headers in devel?
  (you already use a single "%{_libdir}/ggi/" line in the main package)
- Maybe it could be interesting to split out the binaries and man1 pages into a
  libggi-utils sub-package? (not sure what the policy is for this, but it might
  be a good thing regarding multilib for instance)
Major :
- The man3 pages should go into the devel package. Only man1 and man7 in main.

Comment 13 Nicolas Chauvet (kwizart) 2007-06-19 15:25:43 UTC
Ok i will update soon..

I discussed with the main libggi's dev who told me that since libs requires
/etc/libggi (hardcoded) and binaries to be present, then the package is not
multilib capable... (i can send you the full log)
I've requested if this can evolve with next release so i may have to reconsider
this later...
For now i think i will need to add libggi (and libgii also) on some exeption
list for multilibs

Comment 14 Nicolas Chauvet (kwizart) 2007-06-19 15:29:09 UTC
This is a libggi review (not libgii which is already reviewed)

Comment 15 Nicolas Chauvet (kwizart) 2007-06-19 15:48:59 UTC
Description: General Graphics Interface toolkit

%{_sysconfdir}/ggi is owned by libgii package

Comment 16 Matthias Saou 2007-06-19 16:24:42 UTC
One more regression :-(

%{_includedir}/ggi/*   is wrong
%{_includedir}/ggi/    is right

Unless you meant "%{_includedir}/ggi is owned by libgii-devel package" in your
previous comment.

I think the first thing to sort out is which package should require the other
for proper ownership of all directories, and add explicit requirements to it
(and its devel package) to get things straight. Note that peeking at libgii, I
saw a ChangeLog.1999 there as well as all man3 pages :-/
I also see that your new release doesn't list man7 pages... did you actually try
and build it?

Comment 17 Nicolas Chauvet (kwizart) 2007-06-19 21:42:31 UTC
well ok i followed the discution with ggi's dev and there is a way to have
multilibs... This will requires to rebuild libgii and i will submit
libggi-2.2.2-7 soon...
About man3 and man7 i will bundle them with ggi-utils (I think this name will
prevent to be present in lib64 repository whereas libggi-utils will not !?)

The method (for multilib) is to rename libggi.conf to lib64ggi.conf because path
and name for this config file is hardcoded into the libs. Then all the config
files will be bundled with the libraries...

Nexts release (currently in cvs) will provide a way not uses thoses config files
hack anymore...

Comment 18 Nicolas Chauvet (kwizart) 2007-06-19 23:07:52 UTC
Description: General Graphics Interface toolkit

libgii need to be rebuild with this new scheme... I will run quick test (and
request advices). Until then i'me going to run futher testing...

Comment 19 Matthias Saou 2007-06-27 12:49:00 UTC
OK, I think I'm starting to understand :-)
Could you maybe add some comments in the %files sections saying something like
"# The %{_sysconfdir}/ggi/ and targets sub-directory are owned by the libgii
package we require", this way it would be clear why they aren't being owned in
this package. (same for %{_libdir}/ggi/ and %{_includedir}/ggi/)

From there, a hardcoded "Requires: libgii" in the main package might be a good idea.

One more question : Why is the devel package "ggi-devel" and not left as the
default "libggi-devel"?

The rest of the changes, especially for multilib handling, look good.

Comment 20 Nicolas Chauvet (kwizart) 2007-07-06 20:08:07 UTC
Description: General Graphics Interface toolkit

Still in testing phase... Actually some internal tests (demo) seems good, others
seem to need futher (user) configuration...
This is the case for vlc using General Graphics Interface toolkit output for
example... (asking to set some display-x )

About last changes, i was not really aware about how was working multilibs from
the repository. Actually all starts from -devel, so the name do not matter.

Comment 21 Parag AN(पराग) 2007-09-19 01:43:10 UTC
any progress here on review?
Is the packaging complete now for official review?

Comment 22 Nicolas Chauvet (kwizart) 2007-09-19 09:07:31 UTC
well actually, there is no problem at build time, but i'm still searching for a
problem at runtime (at least on x86_64 and maybe with an nVidia card). But I
haven't made any progress last days... I will retry next...

Comment 23 Nicolas Chauvet (kwizart) 2008-09-15 11:01:01 UTC
Not interested in this package anymore.
(no success at runtime)

If any wants to take the last wip version, see:

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