Re: Gtk 2.10 availability
Loïc Minier wrote:
On Sun, Sep 24, 2006, Attilio Fiandrotti wrote:
Meanwhile, if you want to see if you can reproduce the "BOOM" bug in GTK
from CVS, you can proceed as follows (you'll need a ssh terminal).
-Run gtk-demo and open the hypertext app
-Attach gdb to the process and set a breakpoint at
gtk_target_table_free() and continue running
-close the hypertext window with meta-c, you'll enter the
-At some point you should get a crash in the for() loop, can you
Ok, I suppose I could reach the crash and setup an initial environment
for testing, but that's not good enough for debugging for now. Here's
what I did:
- boot with a vesa framebuffer on the kernel command line
- build gtk-demo against directfb from the gtk source:
* fakeroot debian/rules debian/stampdir/configure-stamp-directfb
* cd debian/tmp/build/directfb/demos/gtk-demo
* make (should fail at the final link)
* gcc $(pkg-config --cflags --libs gtk+-directfb-2.0) -o gtk-demo *.o
* launch ./gtk-demo as root
- I also had to setup mode= in /root/.directfbrc and capslock-meta
So, I could launch the hypertext app, and close it with CapsLock+c.
I still had the mouse afterwards, but I did *not* have the
etch-a-sketch bug. Instead, nothing else was happening, I couldn't do
anything with the interface anymore. I couldn't switch VT anymore.
That's *exactly* the bug i used to experience and i reported about in
July, you were able to reproduce it perfectly :)
I'm not 100% sure this is also the BOOM bug, but if you try running a
cdebconf test application with the GTK frontend, when you click the "OK"
or "BACK" button, the bug will make cdebconf hang, so i guess it's
important fixing it anyway.
Now that this bug has been reproduced by someone else than me too, i'll
file a bugreport in GNOME's BTS.
Since I have a single console, it's not easy to debug the graphical
problem; perhaps there's a virtual output for DirectFB (like Xvfb)?
try adding to /etc/directfbrc this line
now you should be able to have DFB rendering into a X window.