Description of problem: I just tried to compile package gnome-applets-2.4.1-1, from Redhat Fedora Core 1. The compiler found seven different problems. 1. mixer.c:636: warning: too many arguments for format The source code is data->error_dialog = gtk_message_dialog_new (NULL, GTK_DIALOG_DESTROY_WITH_PARENT, GTK_MESSAGE_ERROR, GTK_BUTTONS_OK, _("Couldn't open mixer device %s\n"), data->device, NULL); Only one %s specifier, but two parameters afterwards. I'm not sure what the fix is for this. 2. cdplayer.c:410: warning: too many arguments for format The source code is dialog = gtk_message_dialog_new (NULL, GTK_DIALOG_DESTROY_WITH_PARENT, GTK_MESSAGE_ERROR, GTK_BUTTONS_OK, _("%s does not seem to be a CD player"), cd->devpath, NULL); Duplicate. 3. cdplayer.c:949: warning: too many arguments for format The source code is dialog = gtk_message_dialog_new (NULL, GTK_DIALOG_DESTROY_WITH_PARENT, GTK_MESSAGE_ERROR, GTK_BUTTONS_OK, _("Audio device is busy, or being used by another application"), NULL); Duplicate. Suggest compile with flag -Wformat or -Wall to avoid these problems occuring in the future. 4. mixer.c(692): remark #592: variable "type" is used before its value is set The source code is Bonobo_UIComponent_EventType type; if (data->mute) mixer_ui_component_event (NULL, "Mute", type, "0", data); I agree with the compiler. Suggest re-work. 5. mixer.c(1141): warning #1011: missing return statement at end of non-void function "cb_row_selected" The source code is panel_applet_gconf_set_int (applet, "channel", data->mixerchannel, NULL); } I'm not sure what the fix is for this. 6. cdplayer.c(644): remark #592: variable "state" is used before its value is set The source code is gboolean state; g_print("(ui-component-event) path is %s and state is %s.\n", path, state); Again, I'm not sure what the fix is for this. 7. applet.c(1187): warning #1011: missing return statement at end of non-void function "accessx_status_applet_fill" g_timeout_add (1000, accessx_status_applet_reset, sapplet); } More broken code. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Sorry this bug was never attended to. Much of this code will have changed in the mean time, so I'd suggest (if you have time) re-doing this against latest gnome-applets and logging the bug against gnome-applets in bugzilla.gnome.org where the upstream maintainers will resolve the problems quickly. Thanks :)
>Sorry this bug was never attended to. No problem. Six months for a response from Redhat is quite fast. >re-doing this against latest gnome-applets If you want to verify that these bugs are fixed in latest release, then that's fine by me. This seems to be yet another case where Redhat think just ignoring a bug for a while, then marking it as gone away, is a quality response to a customer report. There is room for considerably better customer support.
Fedora isn't a supported product. See: http://fedora.redhat.com/about So, rather than filing a customer support request, you are actually contributing to a community project. A healthy community (which Fedora will be in time) would see your contribution put to use quickly. I do understand your frustration - bugs should not be left unattended for an extended about of time and if we do so we are wasting contributors (your) time. But its just the reality of the situation that developers generally only have enough time to get to the critical bugs quickly. My suggestion about logging bugs such as this (i.e. non-critical bugs) upstream, is that you bypass this unfortunate bottleneck and the fix will appear in Fedora as soon as we pull in the latest version. It may not be the case for all packages, but this package does have a relatively healthy upstream which would see the bug resolved quickly. Thanks, and apologies again.