Spec URL: http://kwizart.free.fr/fedora/rpmfusion/libgii.spec SRPM URL: http://kwizart.free.fr/fedora/rpmfusion/libgii-1.0.2-1.kwizart.fc6.src.rpm 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...
*** Bug 239303 has been marked as a duplicate of this bug. ***
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.
Spec URL: http://kwizart.free.fr/fedora/rpmfusion/libggi.spec SRPM URL: http://kwizart.free.fr/fedora/rpmfusion/libggi-2.2.2-1.kwizart.fc6.src.rpm Description: GGI (General Graphics Interface) toolkit Oups! Indeed... Same directory...
I'm starting the review for this one :-)
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."
Oh, blockers now : The package does not own %{_libdir}/ggi/ and the devel package does not own %{_includedir}/ggi/. Please replace the lines : %{_libdir}/ggi/* %{_includedir}/ggi/* With : %{_libdir}/ggi/ %{_includedir}/ggi/ Or (but it's longer) : %dir %{_libdir}/ggi/ %{_libdir}/ggi/* %dir %{_includedir}/ggi/ %{_includedir}/ggi/* You'll also need to add : %dir %{_sysconfdir}/ggi/
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: http://kwizart.free.fr/fedora/rpmfusion/libggi.spec SRPM URL: http://kwizart.free.fr/fedora/rpmfusion/libggi-2.2.2-3.kwizart.fc6.src.rpm Description: General Graphics Interface toolkit
Ok i had some problem with my isp and forgot to upload the spec file... Now everythnig is right... (well, for reviewing i mean...)
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 ;-)
Ping? :-)
SRPMS: http://kwizart.free.fr/fedora/7/testing/libggi/libggi-2.2.2-5.kwizart.fc7.src.rpm SPECS: http://kwizart.free.fr/fedora/7/testing/libggi/libggi.spec 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...)
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.
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
This is a libggi review (not libgii which is already reviewed)
SRPMS: http://kwizart.free.fr/fedora/7/testing/libggi/libggi-2.2.2-6.kwizart.fc6.src.rpm SPECS: http://kwizart.free.fr/fedora/7/testing/libggi/libggi.spec Description: General Graphics Interface toolkit %{_sysconfdir}/ggi is owned by libgii package
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?
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...
SRPMS: http://kwizart.free.fr/fedora/7/testing/libggi/libggi-2.2.2-7.kwizart.fc6.src.rpm SPECS: http://kwizart.free.fr/fedora/7/testing/libggi/libggi.spec 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...
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.
SRPMS: http://kwizart.free.fr/fedora/6/testing/libggi/libggi-2.2.2-8.kwizart.fc6.src.rpm SPECS: http://kwizart.free.fr/fedora/6/testing/libggi/libggi.spec 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.
any progress here on review? Is the packaging complete now for official review?
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...
Not interested in this package anymore. (no success at runtime) If any wants to take the last wip version, see: http://rpms.kwizart.net/fedora/7/SRPMS/libggi-2.2.2-2.kwizart.fc7.src.rpm