[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: More cdebconf patches

Regis Boudin <regis@boudin.name> (2016-01-10):
> On 10/01/16 21:40, Cyril Brulebois wrote:
> Hmm, I didn't test that far. I did follow the GTK doc about migrating
> away from gdk_draw_layout(), and use pango_cairo_show_layout() instead,
> so it should be fine.

I meant to check this part, but see below for more important matters.

> > Some things which come to mind for a gtk3 switch in d-i:
> >  - [ what am I forgetting? ]

We need to check runtime. :D

With the little package rebuild documented in the libepoxy bug report
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788711#12) and a
cdebconf rebuild after this single change in debian/rules:
-UDEB_FRONTENDS=passthrough text newt gtk
+UDEB_FRONTENDS=passthrough text newt gtk3

All I'm getting at start-up (through virt-manager if that matters in any
way) is a black screen and no apparent errors in syslog, but see below.

The sad part is that my old branch no longer builds due to other changes
in gtk3 (a bunch of functions were deprecated/removed since then), so I
can't really judge whether cdebconf or the gtk3 stack isn't behaving as

But. I'm getting the same results without building the udeb against
gtk3. Bisecting from 0.201 led to this commit being the first bad one:
| commit ae9f8d0f40eecceb7c42a77300a89b9ee86dfb05
| Author: Regis Boudin <regis@boudin.name>
| Date:   Sat Jan 9 18:11:39 2016 +0000
|     First shot at being able to build for either GTK+2 or GTK+3

Looking at it, it seems the following part of the diff is strange
|      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

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).

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

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).

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

> At the very least we make it possible to build for gtk3 and look at
> dependencies, run tests, look at themes, etc

Sure, thanks for that!

> These were indeed added by me. In theory I'd have liked to keep them for
> GTK2 but not for GTK3.

OK. Not a big deal anyway.


Attachment: signature.asc
Description: Digital signature

Reply to: