Today starts the Ubuntu “Reduce the delta with upstream” week where we will spend some time to clean up the packages changes and to send upstream the patches that should go upstream. The desktop team has created a wiki page for that, you might be interest to have a look on it and give a hand to update it (other team might be interested to do the same).
If you want to participate or have any question feel free to join #ubuntu-bugs on freenode (or team specific chans like #ubuntu-desktop). We also welcome upstream wanting to talk about changes we do to their application! (Vincent if you read that, are you sure you still don’t want that gnome-panel “add to panel” patch upstream?
The new version of Ubuntu:”Edgy Eft” is now available. It has GNOME 2.16.1, firefox 2.0, f-spot, a faster and nicer startup and many other things too. You can read the details from the announce mail. The new version of Edubuntu, Xubuntu and Kubuntu are also available. Congrats to all the people who worked on those new versions and contributed to make them rock!
The Mountain View summit will take place soon. If you have nice ideas for the next version of Ubuntu, a Call for Topics has been made for you
Some days ago, after the pygtk 2.10.2 issue which created a flood of deskbar-applets bugs on bugzilla, I had a discussion on #bugs with guenther about the number of bugs opened against evolution without an useful backtrace.
I already noticed on some occasions than there is cases where gdb produces a correct backtrace and bug-buddy doesn’t get an useful one. I was wondering if the issue is due to bug-buddy and I decided to have an another look with that the pygtk 2.10.2,deskbar crasher
From the bug-buddy bug:
Thread 1 (Thread 47961906685648 (LWP 32518)): #0 0x00002b9efffbeeef in waitpid () from /lib/libpthread.so.0 No symbol table info available. #1 0x000000000000000b in ?? () No symbol table info available. #2 0x38000000006fa750 in ?? () No symbol table info available. #3 0x0000000000000000 in ?? () No symbol table info available. #0 0x00002b9efffbeeef in waitpid () from /lib/libpthread.so.0
The apport backtrace is about the same
From gdb when running deskbar-applet with it:
Thread 1 (Thread 47933151876816 (LWP 32616)): #0 0x00002b984e97b297 in IA__g_type_fundamental (type_id=4035225266131284752) at gtype.c:3098 #1 0x00002b984e961b90 in IA__g_boxed_free (boxed_type=4035225266131284752, boxed=0x7fff5cac71d0) at gboxed.c:453 #2 0x00002b984e82ef85 in init_gobject () from /var/lib/python-support/python2.4/gtk-2.0/gobject/_gobject.so #3 0x000000000044537f in PyTuple_Size () ...
It looks like a gdb issue then. Attaching gdb after the crash doesn’t produce a correct backtrace in some cases. I’ve tried with gdb 6.4.1 from dapper and gdb 6.4.90 from edgy, no difference. Opinions on that? Any reason why, in some case, gdb can’t get a proper backtrace?