Bug 592487

rpmlint output: 
[louis@travel ffgtk]$ rpmlint ffgtk.spec ~/rpm/SRPMS/ffgtk-0.7.5.1098-1.fc12.src.rpm ~/rpm/SRPMS/ffgtk-*1098*
ffgtk.spec: W: invalid-url Source0: http://www.tabos.org/ffgtk/download/ffgtk-0.7.5.1098.tar.bz2 HTTP Error 404: Not Found
ffgtk.src: W: invalid-url Source0: http://www.tabos.org/ffgtk/download/ffgtk-0.7.5.1098.tar.bz2 HTTP Error 404: Not Found
ffgtk.src: W: invalid-url Source0: http://www.tabos.org/ffgtk/download/ffgtk-0.7.5.1098.tar.bz2 HTTP Error 404: Not Found
2 packages and 1 specfiles checked; 0 errors, 3 warnings.

The warnings are due to the fact that this spec currently uses an SVN version (included in the version. this will be corrected as soon as 0.7.6 is released.

Spec URL: http://fazant.net/ffgtk/0.7.6-1/ffgtk.spec
SRPM URL: http://fazant.net/ffgtk/0.7.6-1/ffgtk-0.7.6-1.fc12.src.rpm

Rpmlint is almost silent, the remaining warning can be ignored I think:

[louis@travel ffgtk]$ rpmlint ffgtk.spec ~/rpm/SRPMS/ffgtk-0.7.6-1.fc12.src.rpm ~/rpm/RPMS/x86_64/ffgtk-0.7.6-1.fc12.x86_64.rpm  ~/rpm/RPMS/x86_64/ffgtk-*0.7.6*
ffgtk-plugin-capifax.x86_64: W: spelling-error Summary(en_US) libcapifax 
ffgtk-plugin-capifax.x86_64: W: spelling-error %description -l en_US libcapifax 
ffgtk-plugin-capifax.x86_64: W: no-documentation
ffgtk-plugin-evolution.x86_64: W: no-documentation
6 packages and 1 specfiles checked; 0 errors, 4 warnings.

The plugins are split out in order to avoid dependency bloat, both plugins are optional.

Thee is a new version of the software available.

I can't determine the GPL version in use.  The source files don't seem to specify a version, but the manpage has the proper notice in comments at the top:

"
.\" This is free documentation; you can redistribute it and/or
.\" modify it under the terms of the GNU General Public License as
.\" published by the Free Software Foundation; either version 2 of
.\" the License, or (at your option) any later version.
"

but of course that only applies to the documentation.

Further down in the manpage:

"
.SH LICENSE
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License.
"

which makes... no sense.  I'll block FE-Legal; you should get upstream to clarify.

Same problem in throttle - bug 617340 . Adding myself to CC list.

I clarified the situation with upstream (my apologies for the delay, I have been on a business trip). The license is GPLv2 only. here is what Jan replied:

Hi,

ffgtk is GPLv2 only, no GPLv3. I'll change the manpage.

Jan
Is this sufficient?

The man page in SVN upstream now has:

 .\" Copyright (c) 2009, Jan-Michael Brummer <jan.brummer>
.\"
.\" This is free documentation; you can redistribute it and/or
.\" modify it under the terms of the GNU General Public License as
.\" published by the Free Software Foundation; version 2 only.
.\"
.\" The GNU General Public License's references to "object code"
.\" and "executables" are to be interpreted as the output of any
.\" document formatting or typesetting system, including
.\" intermediate and printed output.
.\"
.\" This manual is distributed in the hope that it will be useful,
.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
.\" GNU General Public License for more details.
.\"
.\" You should have received a copy of the GNU General Public
.\" License along with this manual; if not, write to the Free
.\" Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
.\" Boston, MA  02111-1301  USA.

at the top for the documentation.
The License section now has:

.SH LICENSE
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; version 2 only.

This program is distributed in the hope that it will be useful, but
\fBWITHOUT ANY WARRANTY\fR; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02111-1301  USA

Yes, please include in the package (as documentation) a file containing the message from the author (with headers) which clarifies the license.  Or, I guess if you want, you can package a subversion checkout.

Unblocking FE-Legal.

Sorry for the delay: I am traveling a lot over the last weeks. I have already made most for the updates and had one additional question outstanding with the author. I plan to get back to packaging ffgtk next week or the week after (depending on whether I will be on business trip next week)

Sure, just clear the whiteboard when you've updated the package.

Updated to the latest stable release:
Spec file: http://fazant.net/ffgtk/0.7.8-1/ffgtk.spec
SRPM: http://fazant.net/ffgtk/0.7.8-1/ffgtk-0.7.8-1.fc14.src.rpm

Rpmlint output:
[louis@travel ffgtk-0.7.8.patched]$ rpmlint ffgtk.spec ~/rpm/RPMS/x86_64/ffgtk* ~/rpm/SRPMS/ffgtk-0.7.8-1.fc14.src.rpm 
ffgtk-plugin-capifax.x86_64: E: world-writable /var/spool/ffgtk 0777L
ffgtk-plugin-capifax.x86_64: E: non-standard-dir-perm /var/spool/ffgtk 0777L
6 packages and 1 specfiles checked; 2 errors, 0 warnings.

The 777 permission on the spool directory is required due to the somewhat limited spooler included. I will work on a proper one later that will not require the spool directory to be wide open...

The current package fails to build; looks like a missing build dependency on desktop-file-utils:

+ desktop-file-validate /builddir/build/BUILDROOT/ffgtk-0.7.8-1.fc15.x86_64//usr/share/applications/ffgtk.desktop
/var/tmp/rpm-tmp.VzkV8L: line 47: desktop-file-validate: command not found

Please do a local mock build or a koji scratch build to ensure that the packages you submit build properly.

Also note that given that spool thing, there's no chance that I would approve it as it would be unconscionable to allow such a package into the distribution.  I'd suggest that if the package really requires that for some or all functionality, you give the directory the usual restricted permissions, document what won't work and leave it up to the local administrator to widen the permissions if they wish.

Re: fails to build: I was sure that I checked this recently. Apparently not: my bad, sorry!

Re: spool directory permissions: I did not like the solution myself either. I had another look at it and found out that I was doing things unnecessarily complicated: the old spooler code is still there. This will use a socket between CUPS and ffgtk. I am working on some patches to make that work properly(done). I just need to test things to make sure it all works as expected. Expect an update pretty soon.

* Fri Dec 24 2010 Louis Lagendijk <louis.lagendijk> 0.7.8-2
- Re-instated old print-spooler
- Added a ppd for the fax printer
- Automatically create/delete the required printer in cups

Spec file: http://fazant.net/ffgtk/0.7.8-2/ffgtk.spec
SRPM: http://fazant.net/ffgtk/0.7.8-2/ffgtk-0.7.8-2.fc14.src.rpm

rpmlint output:
[louis@travel ffgtk-0.7.8.patched]$ rpmlint  /home/home1/louis/rpm/RPMS/x86_64/ffgtk*fc14* /home/home1/louis/rpm/SRPMS/ffgtk-0.7.8-2.fc14.src.rpm ffgtk.spec 
6 packages and 1 specfiles checked; 0 errors, 0 warnings.

Now checked build in mock.

I don't see that clarification from the author included in the package.  As I
wrote before in comment 6, you need to include the email from the author with
headers in the package as documentation, or you can package the updated version
that has the fixed manpage.  Of course, the author of the code should still
follow the directions in the GPL itself and include proper license blocks in
the code.

AUTHORS, COPYING, ChangeLog, README and README.Fedora seem to be duplicated
between each package.  You should not duplicate files in that manner.  All of
the packages require ffgtk, so placing that information in the ffgtk package
should be sufficient.

I'm unsure about the scriptlets.  The dependencies for them seem to be missing,
for one, but even then, I don't understand the point of setting up a printer if
cups happens to be running at the moment the package is installed (or
upgraded).  That seems rather nondeterministic.  Wouldn't it be best to leave
management of the printer to the end user?

This package, like many, bundles one of the md5.c implementations.  I've requested that FPC give this a blanket exemption as a copylib.

* source files match upstream.  sha256sum:
  185605137e1c591c6585cbe6a810689365ff5033652064a5d678def52f7485d3
   ffgtk-0.7.8.tar.bz2
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
X license clarification not include in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint is silent.
X final provides and requires; capifax subpackage is missing scripelet
   dependencies.
  ffgtk-0.7.8-2.fc15.x86_64.rpm
   lib_ab_fritzfon.so.0()(64bit)  
   lib_ab_local.so.0()(64bit)  
   lib_ab_thunderbird.so.0()(64bit)  
   lib_ab_vcard.so.0()(64bit)  
   lib_audio_ao.so.0()(64bit)  
   lib_pwd_gnome.so.0()(64bit)  
   ffgtk = 0.7.8-2.fc15
   ffgtk(x86-64) = 0.7.8-2.fc15
     =
   lib_ab_fritzfon.so.0()(64bit)  
   lib_ab_local.so.0()(64bit)  
   lib_ab_thunderbird.so.0()(64bit)  
   lib_ab_vcard.so.0()(64bit)  
   lib_audio_ao.so.0()(64bit)  
   lib_pwd_gnome.so.0()(64bit)  
   libao.so.4()(64bit)  
   libatk-1.0.so.0()(64bit)  
   libcairo.so.2()(64bit)  
   libcurl.so.4()(64bit)  
   libdbus-1.so.3()(64bit)  
   libdbus-glib-1.so.2()(64bit)  
   libfontconfig.so.1()(64bit)  
   libfreetype.so.6()(64bit)  
   libgdk-x11-2.0.so.0()(64bit)  
   libgdk_pixbuf-2.0.so.0()(64bit)  
   libgio-2.0.so.0()(64bit)  
   libglib-2.0.so.0()(64bit)  
   libgmodule-2.0.so.0()(64bit)  
   libgnome-keyring.so.0()(64bit)  
   libgobject-2.0.so.0()(64bit)  
   libgstapp-0.10.so.0()(64bit)  
   libgstbase-0.10.so.0()(64bit)  
   libgstinterfaces-0.10.so.0()(64bit)  
   libgstreamer-0.10.so.0()(64bit)  
   libgthread-2.0.so.0()(64bit)  
   libgtk-x11-2.0.so.0()(64bit)  
   libpango-1.0.so.0()(64bit)  
   libpangocairo-1.0.so.0()(64bit)  
   libpangoft2-1.0.so.0()(64bit)  
   libpng12.so.0()(64bit)  
   libsndfile.so.1()(64bit)  
   libsndfile.so.1(libsndfile.so.1.0)(64bit)  
   libspeex.so.1()(64bit)  
   libxml2.so.2()(64bit)  
   libxml2.so.2(LIBXML2_2.4.30)(64bit)  
   
  ffgtk-plugin-capifax-0.7.8-2.fc15.x86_64.rpm
   lib_fax_capifax.so.0()(64bit)  
   ffgtk-plugin-capifax = 0.7.8-2.fc15
   ffgtk-plugin-capifax(x86-64) = 0.7.8-2.fc15
  =
   /bin/sh  
   cups  
   ffgtk = 0.7.8-2.fc15
   ghostscript  
   lib_fax_capifax.so.0()(64bit)  
   libcapifax.so.0()(64bit)  
   libgthread-2.0.so.0()(64bit)  

  ffgtk-plugin-evolution-0.7.8-2.fc15.x86_64.rpm
   lib_ab_ebook.so.0()(64bit)  
   ffgtk-plugin-evolution = 0.7.8-2.fc15
   ffgtk-plugin-evolution(x86-64) = 0.7.8-2.fc15
  =
   ffgtk = 0.7.8-2.fc15
   lib_ab_ebook.so.0()(64bit)  
   libcamel-1.2.so.21()(64bit)  
   libebook-1.2.so.10()(64bit)  
   libedataserver-1.2.so.14()(64bit)  
   libgconf-2.so.4()(64bit)  
   libgio-2.0.so.0()(64bit)  
   libglib-2.0.so.0()(64bit)  
   libgmodule-2.0.so.0()(64bit)  
   libgobject-2.0.so.0()(64bit)  
   libgthread-2.0.so.0()(64bit)  
   libnspr4.so()(64bit)  
   libnss3.so()(64bit)  
   libnssutil3.so()(64bit)  
   libplc4.so()(64bit)  
   libplds4.so()(64bit)  
   libsmime3.so()(64bit)  
   libsoup-2.4.so.1()(64bit)  
   libsqlite3.so.0()(64bit)  
   libssl3.so()(64bit)  
   libxml2.so.2()(64bit)  
   
  ffgtk-plugin-gstreamer-0.7.8-2.fc15.x86_64.rpm
   lib_audio_gstreamer.so.0()(64bit)  
   ffgtk-plugin-gstreamer = 0.7.8-2.fc15
   ffgtk-plugin-gstreamer(x86-64) = 0.7.8-2.fc15
  =
   ffgtk = 0.7.8-2.fc15
   lib_audio_gstreamer.so.0()(64bit)  
   libglib-2.0.so.0()(64bit)  
   libgmodule-2.0.so.0()(64bit)  
   libgobject-2.0.so.0()(64bit)  
   libgstapp-0.10.so.0()(64bit)  
   libgstbase-0.10.so.0()(64bit)  
   libgstinterfaces-0.10.so.0()(64bit)  
   libgstreamer-0.10.so.0()(64bit)  
   libgthread-2.0.so.0()(64bit)  
   libxml2.so.2()(64bit)  
   
? md5.c seems bundled libraries.
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
X many duplicates in %files.
* file permissions are appropriate.
* no generically named files.
? unsure about the scriptlets
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no static libraries.
* desktop files valid and installed properly.

Seems there is some disagreement in FPC over whether md5.c should be given a copylib exemption, so this may get held up a bit.  You are of course welcome to fix the other issues.

Thanks for the thorough review!

(In reply to comment #13)
> I don't see that clarification from the author included in the package.  As I
> wrote before in comment 6, you need to include the email from the author with
> headers in the package as documentation, or you can package the updated version
> that has the fixed manpage.  Of course, the author of the code should still
> follow the directions in the GPL itself and include proper license blocks in
> the code.

Added, I don't understand how I missed this. My apologies!

> 
> AUTHORS, COPYING, ChangeLog, README and README.Fedora seem to be duplicated
> between each package.  You should not duplicate files in that manner.  All of
> the packages require ffgtk, so placing that information in the ffgtk package
> should be sufficient.
>

Done, removed. Rpmlint now complains about missing documentation for the plugin packages.That is why I added the files in the first place. Should this be ignored?
 
> I'm unsure about the scriptlets.  The dependencies for them seem to be missing,
> for one, but even then, I don't understand the point of setting up a printer if
> cups happens to be running at the moment the package is installed (or
> upgraded).  That seems rather nondeterministic.  Wouldn't it be best to leave
> management of the printer to the end user?
> 
I copied this more or less verbatim from the cups-pdf package. The check if cups is running is there because lpadmin will throw an error when cups is not running. I have to admit that it escapes me why this check is not done when the package is removed though. It is fine with me to remove the scriptlets if you prefer so.

> This package, like many, bundles one of the md5.c implementations.  I've
> requested that FPC give this a blanket exemption as a copylib.
> 
Ok, I will wait for the outcome. I understand the delay. Is there a lib that provides the functionality? If so I can create patch to use that and submit that upstream. I could not find a suitable lib so far, but will continue looking.

> X final provides and requires; capifax subpackage is missing scripelet
>    dependencies.
There is a Requires cups, which offers lpadmin. Do we need more? The dependencies for cups and ghostscript are also borrowed from cups-pdf.


> X many duplicates in %files.

I m not sure I understand this one. Does this refer to the doc sections, or would you like to remove the .so.0.0 files and keep only the .so.0 libs?
If so, I could something like
find %{buildroot} -name '*.so.0' -exec mv -f {}.0.0 {} ';' (untested)

Thanks again!

You should ignore rpmlint complaints about missing documentation when there is no documentation to be had.  You shouldn't fabricate documentation or duplicate it from the main package just to make the complaint go away.

Perhaps you don't understand the distinction between the regular package dependencies and scriptlet dependencies.  Package dependencies simply need to be satisfied in order for the package to work, so rpm ensures that they are installed by the end of the transaction.  Scriptlets may run at other times (during the transaction, either before or after the package is installed, upgraded or removed) and so any dependencies they may have needs to be specified so that rpm will ensure those dependencies are present when the scriptlets run.  Or, to put it another way, simply having the package depend on something called in the scriptlets is not sufficient.

The "many duplicates in files" issue refers to the duplicated documentation.

(In reply to comment #16)
> You should ignore rpmlint complaints about missing documentation when there is
> no documentation to be had.  You shouldn't fabricate documentation or duplicate
> it from the main package just to make the complaint go away.
> 
Understood. 

> Perhaps you don't understand the distinction between the regular package
> dependencies and scriptlet dependencies.  Package dependencies simply need to
> be satisfied in order for the package to work, so rpm ensures that they are
> installed by the end of the transaction.  Scriptlets may run at other times
> (during the transaction, either before or after the package is installed,
> upgraded or removed) and so any dependencies they may have needs to be
> specified so that rpm will ensure those dependencies are present when the
> scriptlets run.  Or, to put it another way, simply having the package depend on
> something called in the scriptlets is not sufficient.
> 
Thanks for the heads up,I was indeed not aware of the differences. I am reading the information I can find for this.
 
> The "many duplicates in files" issue refers to the duplicated documentation.
Thanks.

Re. the md5 inclusion: would it help if I make a separate libmd5 package? I whipped up a quick autofoo configuration, so I could package this as a separate package. I would not know what license to put in the spec file.... If that would help I can add a simple check for libmd5 in ffgtk's config and be done with it. comments?

Unfortunately FPC did not get to discuss the md5 issue this week due to time pressure.

The problem with md5 on Linux is that unlike BSD there seems to be no standard system library for it (and in particular no support for it in libc).  Unless you count things like nss or openssl, neither of which is really a solution for something that just needs to compute an occasional md5 hash.  The situation is pretty flawed.  I found a couple of other packages using the same md5.c as this package, and some other packages using an entirely different md5.c authored by Colin Plumb, and I only looked for fifteen minutes or so.

It would certainly be reasonable to unbundle the md5 library, although I'm concerned that the issue is more complicated than that.  Will you be the upstream for this new library?  Will it support the same API as both md5.c versions?

Finally FPC was able to discuss this, and this md5 implementation was exempted from the rule about bundled libraries.  Please add:
  Provides: bundled(md5-deutsch)
to the package and I'll approve this.

The provide makes it easy for us to look for packages that bundle this code in case a security issue is found, or in case someone packages up a compatible library and is looking to port packages over to using it.

Updated now all items I hope:

Spec file: http://fazant.net/ffgtk/0.7.8-3/ffgtk.spec
SRPM: http://fazant.net/ffgtk/0.7.8-2/ffgtk-0.7.8-3.fc14.src.rpm

[louis@travel SRPMS]$ rpmlint ffgtk-0.7.8-3.fc14.src.rpm ../RPMS/x86_64/ffgtk-*-3* ~/fritz-fun/ffgtk-0.7.8.patched/ffgtk.spec 
ffgtk.src:23: W: unversioned-explicit-provides bundled(md5-deutsch)
ffgtk-plugin-capifax.x86_64: W: no-documentation
ffgtk-plugin-evolution.x86_64: W: no-documentation
ffgtk-plugin-gstreamer.x86_64: W: no-documentation
/home/home1/louis/fritz-fun/ffgtk-0.7.8.patched/ffgtk.spec:23: W: unversioned-explicit-provides bundled(md5-deutsch)
6 packages and 1 specfiles checked; 0 errors, 5 warnings.

Could you please explicitly check the scriptlet dependencies, I am not 100% sure that what I have now is correct.

I left in the scriptlets as I feel that the probability that cups is not running at install is pretty slim: cups is a pretty standard deamon, installed in most installations that run a desktop I would guess. I did add the check if cups is running for the postun scriptlet as well.

Comments? Thanks for all your help

oops, SRPM is of course: http://fazant.net/ffgtk/0.7.8-3/ffgtk-0.7.8-3.fc14.src.rpm

I've been sick for several days and have just now been able to make it back to this ticket.  Unfortunately now I find that it fails to build in rawhide.  Since -Wall is being passed and there are some new complaints in the absolutely new GCC that's appeared recently, things fail:

e/ffgtk/html/\" -DLIBEXECDIR=\"/usr/libexec/\" -rdynamic -Wall -Werror -D_GNU_SOURCE -DLOCALE_DIR=\"/usr/share/locale/\" -g -DUSE_OLD_SPOOLER  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c -o ffgtk-callmonitor.o `test -f 'callmonitor.c' || echo './'`callmonitor.c
address-dialog.c: In function 'AddressBook':
address-dialog.c:757:13: error: variable 'psInfoBox' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
server.c: In function 'PrintServerInit':
server.c:125:11: error: variable 'psServer' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make[2]: *** [ffgtk-address-dialog.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [ffgtk-server.o] Error 1
monitor.c: In function 'showNotification':
monitor.c:213:13: error: variable 'psAddButton' set but not used [-Werror=unused-but-set-variable]
monitor.c: In function 'InitMonitor':
monitor.c:732:11: error: variable 'psMonitor' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make[2]: *** [ffgtk-monitor.o] Error 1
profiles.c: In function 'setActiveProfile':
profiles.c:162:11: error: variable 'psCallList' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make[2]: *** [ffgtk-profiles.o] Error 1

It does build fine on F14, and at this point I'm just going to go with that because the rawhide breakage is recent and for all I know could be transient.  If not, however, you will have to deal with that at some point soon or this package will not make it into F15.

I'm still a bit wary of the scriptlets.  I checked the cups-pdf package and while you're correct that it does this kind of thing, it isn't exactly a good package to use as a model.  Still, it doesn't violate any guidelines and seems to be safe enough.

The other stuff that needed fixing is fixed, so I'm going to say this is done.

APPROVED

hello Jason
I hope you are feeling better now!
Thanks for the review and help. I will have a look at the breakage before I import the package.
Thanks again!

New Package CVS Request
=======================
Package Name: ffgtk
Short Description: A solution for controlling Fritz!Box or compatible routers
Owners: llagendijk
Branches: f13 f14 el6
InitialCC:

Git done (by process-git-requests).

ffgtk-0.7.8-4.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/ffgtk-0.7.8-4.fc15

ffgtk-0.7.8-4.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/ffgtk-0.7.8-4.fc14

ffgtk-0.7.8-4.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/ffgtk-0.7.8-4.fc13

ffgtk-0.7.8-4.fc15 has been pushed to the Fedora 15 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update ffgtk'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/ffgtk-0.7.8-4.fc15

ffgtk-0.7.8-4.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

ffgtk-0.7.8-4.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

ffgtk-0.7.8-4.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.