Re: Gtk 2.10 availability
Loïc Minier wrote:
On Sat, Sep 23, 2006, Attilio Fiandrotti wrote:
I never filed a bug into GNOME's bugzilla because no one ever was able
to reproduce this bug, but if someone can manage to achieve this (Loic?
:) we could file a proper bugreport to have ot fixed in next GTK release.
I would be happy to be a test puppet, but one of the reason I requested
testing of Gtk 2.10 + DirectFB was that I don't know how to test it. I
know it sounds a bit irresponsible, so I did my best to verify that I
didn't break anything incrementally (but I still missed some stuff).
I don't want you to lose too much time explaining me with details how
your test environment is built, but if you could give some high level
hints on the process you follow to test, what you test, and how you
debug, that would be really nice. If such a documentation already
exist, that would be nice!
The most effective way for me would be to be able to test binaries from
my laptop, perhaps from a different VT. I understand I might need to
boot some d-i builds via the network or a CD in some cases. I also
have a Xen setup, it it can help in any tests, and even a VMWare
Workstation license (didn't update the kernel modules to 2.6.17
Thanks in advance for your help! Please don't feel obliged to document
this in great length, I don't want to waste *your* time.
First, the bad news: GTK 2.10.4 has a broken DFB backend, as an old
bugfix  by Mike Emmel icluded in CVS was not relesed, so to get a
working GTKDFB library you'll have to use sources form CVS HEAD.
In addition to this, the bug i posted about in July still affects GTK
CVS HEAD, so i think this is enough to try re-backporting from scratch
the HEAD GDKDFB to 2.8.20 (current DFB backend in debian unstable is
dated around May 2006).
Your help in testing and debugging GTKDFB would be really useful and
appreciated: what i usually do to is compiling GTKDFB with debugging
symbols, and then running a GTK application like gtk-demo or the GIMP
I have no special methods to test the d-i but runing it into a chroot
cage and attaching gdb at it.
I know davide viti used to attach gdb to the debconf process running in
qemu, but i've never done this by myself.