[MIR] libgwibber

[Ken VanDine]

libgwibber is a generic library for accessing the Gwibber service, enabling access from applications written in languages other than python.

It is a new dependency for indicator-me and doesn't violate requirements for main inclusion.

[Alexander Sack (asac)]

Doesnt build on armel yet, but i think its a problem in base libs rather than libgwibber because previous version worked.

There are a bunch of warnings in the build log that should be looked into:

1. no return in non-void func:
entry.c:792: warning: no return statement in function returning non-void

2. "... may be used uninitialized in this function" warnings; most if not all are in generated code, so might be OK or a bug in generator:

service.c:1582: warning: '_edomain' may be used uninitialized in this function
service.c:1583: warning: '_ecode' may be used uninitialized in this function
service.c:1477: warning: '_edomain' may be used uninitialized in this function
service.c:1478: warning: '_ecode' may be used uninitialized in this function
service.c:1372: warning: '_edomain' may be used uninitialized in this function
service.c:1373: warning: '_ecode' may be used uninitialized in this function
service.c:2019: warning: '_edomain' may be used uninitialized in this function
service.c:2020: warning: '_ecode' may be used uninitialized in this function
service.c:1908: warning: '_edomain' may be used uninitialized in this function
service.c:1909: warning: '_ecode' may be used uninitialized in this function
service.c:1797: warning: '_edomain' may be used uninitialized in this function
service.c:1798: warning: '_ecode' may be used uninitialized in this function
service.c:1690: warning: '_edomain' may be used uninitialized in this function
service.c:1691: warning: '_ecode' may be used uninitialized in this function
service.c:835: warning: 'reply' may be used uninitialized in this function
service.c:700: warning: 'reply' may be used uninitialized in this function
service.c:568: warning: 'reply' may be used uninitialized in this function
service.c:438: warning: 'reply' may be used uninitialized in this function
service.c:308: warning: 'reply' may be used uninitialized in this function
accounts.c:1148: warning: '_edomain' may be used uninitialized in this function
accounts.c:1149: warning: '_ecode' may be used uninitialized in this function
accounts.c:1036: warning: '_edomain' may be used uninitialized in this function
accounts.c:1037: warning: '_ecode' may be used uninitialized in this function
accounts.c:922: warning: '_edomain' may be used uninitialized in this function
accounts.c:923: warning: '_ecode' may be used uninitialized in this function
accounts.c:275: warning: 'reply' may be used uninitialized in this function
urlshorten.c:503: warning: '_edomain' may be used uninitialized in this function
urlshorten.c:504: warning: '_ecode' may be used uninitialized in this function
connection.c:555: warning: '_edomain' may be used uninitialized in this function
connection.c:556: warning: '_ecode' may be used uninitialized in this function
streams.c:519: warning: '_edomain' may be used uninitialized in this function
streams.c:520: warning: '_ecode' may be used uninitialized in this function

please fix 1. and review 2. for sanity. At least a few look really not right.

[Ken VanDine (ken-vandine)]

I reviewed these, not sure what the right solution is for #1. I don't have any non-void functions that aren't returning something. The C code generated does create two functions for one lambda, one of which should return a gboolean but doesn't. The vala method is a void. I tried changing the vala code to return a bool and it produced the same C code. Also, I am not seeing these warnings on amd64, so perhaps the compiler flags are more forgiving. Think I should file a bug against valac?

For #2, also not seeing these warnings on amd64. Looking at the generated C code, the variables are initialized inside of an if block where they are also used. So this is safe, they aren't actually used outside.

[Alexander Sack (asac)]

I am looking at i386.

For 1. its:

static gboolean _lambda0_ (GdkEventExpose* source, GwibberInputTextView* self) {
        gboolean result = FALSE;
        gwibber_input_text_view_expose_view (self, source);
}

[Alexander Sack (asac)]

for 2. one example is:

   gint _ecode;
   if (strstr (_dbus_error.name, "org.freedesktop.DBus.Error") == _dbus_error.name) {
...
   }
   g_set_error (error, _edomain, _ecode, "%s", _dbus_error.message);

[Ken VanDine (ken-vandine)]

1) My vala code for expose_view is a void. I tried just changing that to return a bool and it made no difference. Notice the function right below that in the generated C, it returns a bool and just wraps this function. Not sure why it creates both functions, but it is only consumed by the function that wraps it which doesn't seem to actually expect a return, but returns a bool itself.

[Alexander Sack (asac)]

events need a return to ensure that the event either continues to bubble (FALSE) or not (TRUE). patch fixes entry.vala

[Alexander Sack (asac)]

the others "use of unassigned values" are vala bugs. please file them in ubuntu and upstream and drop bug ids here ...

oh also, you probably didnt see these in your local build because you should always build using -Wall ... set that as a default CFLAGS in your configure.ac. to test locally you can do: make clean; make CFLAGS=-Wall

[Alexander Sack (asac)]

looking at your configure.ac you should use --enable-maintainer-flags to develop locally. This would give you -Wall -Werror and all those goodies.

[Alexander Sack (asac)]

after applying fix and double checking that a -Wall build does now properly return FALSE and filing bugs upstream and launchpad about the dbus vala "uninitialized usage" issues, i am fine with this MIR.

[Ken VanDine (ken-vandine)]

Fix is applied to trunk and i fixed some other warnings as well.

Bugs filed:
https://bugs.edge.launchpad.net/ubuntu/+source/vala/+bug/621952
https://bugzilla.gnome.org/show_bug.cgi?id=627592

[Alexander Sack (asac)]

is there an upload scheduled this cycle from trunk?

[Ken VanDine (ken-vandine)]

Yeah, I'll upload a new release with the cleanups early this week. I would like to see if we uncover any bugs when people get the indicator-me version that uses it.

[Alexander Sack (asac)]

good. when that fix from comment 6 is uploaded this MIR is approved. feel free to set to fix committed on your own then - or ping me on irc ;)

[Launchpad Janitor (janitor)]

This bug was fixed in the package libgwibber - 0.0.6-0ubuntu1

---------------
libgwibber (0.0.6-0ubuntu1) maverick; urgency=low

  * New upstream release.
    - Cleaned up some compiler warnings (LP: #618757)
    - Use GLib.HashTable.full for creating hash tables that contain
      hash tables to properly destroy them.
 -- Ken VanDine <email address hidden> Mon, 23 Aug 2010 08:37:37 -0400

[Sebastien Bacher (seb128)]

libgwibber has been promoted now