Cyril Brulebois <kibi@debian.org> (2021-05-17):
> > The steps to use GTK 3 in d-i would be:
> >
> > - convert cdebconf-gtk-udeb from GTK 2 to GTK 3
> > - convert cdebconf-gtk-entropy from GTK 2 to GTK 3
> > - convert cdebconf-gtk-terminal from GTK 2 to GTK 3 and, simultaneously,
> > from libvte9-udeb to libvte-2.91-0-udeb
> >
> > The big blocker for libvte-2.91-0-udeb used to be that it's written in
> > C++, but I've switched it to be built with -static-libstdc++ so that we
> > don't need a libstdc++6-udeb (its public API/ABI is GLib-flavoured C,
> > only the internals are C++). The result is that libvte-2.91-0-udeb isn't
> > much larger than libvte9-udeb.
>
> Based on the (perceived) unlikeliness that we might find a fix for GTK 2
> (yeah, inertia… but it had been working so neatly for so long that
> moving away from it just hadn't happened…), I've checked what would
> happen with GTK 3 in cdebconf and cdebconf-gtk-terminal (I had forgotten
> about cdebconf-gtk-entropy until writing this reply).
>
> The installer seems to be working somewhat. I'm seeing strange things
> regarding layout, regarding widget expansion (basically we have some
> wasted vertical space). I'm also seeing a different behaviour regarding
> the expose (GTK 2) vs. draw (GTK 3) event handling, meaning the banner
> doesn't get repainted automatically; trying to do that on my own results
> on it being painted over and over again (that happens with a
> pango_cairo_show_layout), meaning “Mode de récupération” (fr) gets
> rendered on top of “Rescue mode” (en) after selecting French. I wouldn't
> call any of those two issues a blocker for 11.0 *if we were to go the
> “Switch to GTK 3” route*.
>
> I'm also seeing a warning when spawning a shell, that comes from
> vte2.91; again, not a blocker. But exiting the shell leads to a crash,
> and the installer gets restarted. The syslog has this:
>
> May 17 15:28:46 debconf: cdebconf_gtk (process:257): GLib - DEBUG: setenv()/putenv() are not thread-safe and should not be used after threads are created
> May 17 15:28:46 debconf: cdebconf_gtk (process:257): VTE - WARNING: (../src/vtepty.cc:670):bool _vte_pty_spawn_sync(VtePty*, const char*, const char* const*, const char* const*, GSpawnFlags, GSpawnChildSetupFunc, gpointer, GDestroyNotify, GPid*, int, GCancellable*, GError**): runtime check failed: ((spawn_flags & forbidden_spawn_flags()) == 0)
> May 17 15:31:14 kernel: [ 218.924148] event_listener[263]: segfault at 0 ip 00007f2ecb006500 sp 00007f2ecaf12a98 error 4 in plugin-terminal.so[7f2ecb006000+2000]
>
> I'm assuming the DEBUG/WARNING parts aren't too scary, and that the
> segfault upon exit might be unrelated. I would call that a blocker for a
> new release candidate of the installer since that would leave /target
> mounted, possibly with other filesystems, and one couldn't re-enter the
> shell.
>
> I'll check what needs to happen with cdebconf-gtk-entropy, and whether
> that might have a link with the segfault…
(No change.)
Additionally, even with all 3 cdebconf-gtk-* packages converted, we
still get libgtk2.0-0-udeb pulled into a netboot-gtk build, because this
package pulls it:
build/pkg-lists/gtk-common:libgail18-udeb
Adding debian-accessibility@ to the loop for awareness, and for input
since it's been a while since I last looked into accessibility details…
Would we need some prospective libgail-3-0-udeb to replace it in a GTK 3
world?
And for those not following #debian-boot, I'm finding myself between a
rock and a hard place, as both options (trying to work around the
rendering-related hangs versus switching to GTK 3 at the last moment)
are very far from ideal… I'm not sure what we'll end up doing, and I'm
happy to get some “votes” pro or against any of those options, and to
hear about other options entirely.
Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature