Re: More cdebconf patches

[Regis Boudin <regis@boudin.name>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> Looking at it, it seems the following part of the diff is strange 
> (src/modules/frontend/gtk/screenshot.c): |      width =
> gdk_window_get_width(gdk_window); |      height =
> gdk_window_get_height(gdk_window); | +#if GTK_CHECK_VERSION(3,0,0) 
> |      pixbuf = gdk_pixbuf_get_from_drawable( |          NULL /*
> allocate a new pixbuf */, gdk_window, |
> gdk_colormap_get_system(), 0 /* src_x */, 0 /* src_y */, | +#else |
> +    pixbuf = gdk_pixbuf_get_from_window(gdk_window, | +#endif |
> 0 /* dest_x */, 0 /* dest_y */, width, height);
> 
> Contrary to other hunks, the if/else seems inverted: the else
> (gtk2) bit is getting the new code while the if (gtk3) gets the old
> one. nm seems to confirm this: 
> /usr/lib/x86_64-linux-gnu/libgtk-3.so       → U
> gdk_pixbuf_get_from_window 
> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so → U
> gdk_pixbuf_get_from_drawable

Indeed it is inverted. And with the screenshot feature not getting
built for deb, I managed to miss it. Combined with the fact I've had
to disable -Werror because of some gcc warning flags.
I'll try to see if I can fix the warnings, unfortunately we use
asprintf quite a lot.

> The black screen seems easily explained by some missing symbols,
> leading to a UI crash (nothing shows up when grepping for gtk in
> /proc/*/maps).

Actually, what happens is that dlopen() fails to load the plugin
because all symbols cannot be resolved (been there with my tests). But
that's more informative.

> Inverting the logic fixes the black screen with gtk2, so I'm about
> to commit it.

Thanks, that was definitely the right thing to do, as it would
otherwise break gtk2 as well.

> Going back to a gtk3 build, I'm again getting a black screen,
> because something is trying to open libGL.so.1; the only hit in the
> temporary build tree is libepoxy (unsurprisingly, since that's an
> OpenGL wrapper).

Oh dear. that sounds... big. But unsurprising, with dlopen failing,
just like in the previous case.

> I'll be poking the libgtk-3-0-udeb bug report to see if we could
> do without pulling libepoxy/libGL…

Well, that's at least one thing this patch will have been useful to
find out and try to track.

Thanks a lot for the prompt testing and bug fixing.
Regis