Bug#987587: libpango1.0-udeb: hangs the installer in various situations

Cyril Brulebois kibi at debian.org
Mon May 17 22:54:01 BST 2021

Hi Simon!

Simon McVittie <smcv at debian.org> (2021-05-17):
> My instinct is that it's far, far too late to be moving to GTK 3 this
> cycle, and I'd prefer to get a suitable hack into GTK 2 if we can
> find one. We can make it #ifdef DEBIAN_INSTALLER to avoid disrupting
> the installed system.

If you're happy with further assisting us with getting away with GTK 2
one more time, that's very fine with me! Huge thanks for all your work
and help so far!

> I think d-i will need to move to GTK 3 early in the Debian 12 cycle,
> but hard freeze is not the time to be fast-forwarding through 10 years
> of GUI library development.

From my little “feasibility survey” over the last few days, there seem
to be a number of obvious issues to solve indeed!

> Getting
> https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/4
> into cdebconf would make this easier, although we can revert it for
> the sake of a smaller diff once we think we have a solution if the
> release team are grumpy about it.

I'm very happy to see this patch merged, and possibly released into
bullseye. The most obvious side effect I can anticipate is possibly
bigger /var/log/installer/syslog files in the installed systems, but
users are expected to compress them anyway before attaching them in
installation reports (BTS and/or lists size limits).

Would you like that to be released into unstable right away? I'm happy
to deal with it if that helps testing stuff.

> It looks as though the problem is that the size GTK chooses for a
> GtkTextView (a debconf "note" or similar) is flapping between two
> values. GTK asks Pango "if you wrap lines at width x, how much space
> will you need?", then uses the result to re-run the layout algorithm,
> which changes the width available, which causes the layout algorithm to
> be re-run and so on. Under normal circumstances, this runs for a few
> iterations and then stabilizes at one size, terminating the loop, but
> when I select Sinhala from the language menu, the width flaps between
> 71 and 72 pixels, with each re-layout resulting in the other width.

Without looking into the code, one might try and keep track of results
that have been seen, and if N/N+1 is detected, maybe just assume this
should be N+1 and move on with other computations? But anyway, further
down your mail you seemed to have ideas already.

> I think this might be related to the fact that when the layout is
> calculated at the narrower width, Pango decides that there isn't space
> to put the "." at the end of a paragraph on the same line as the last
> word, and so wraps it to the next line, which is fine; except that
> you'd expect the space required for the last word to get a bit smaller
> when the "." is not included, but actually Pango tells GTK that it will
> need 1 pixel *more* for "අසම්පූර්ණයි" than for "අසම්පූර්ණයි.", resulting in it
> flapping between the narrower and wider width. I don't know why that
> happens - perhaps the Indic shaper is drawing a character at the end of
> a line more elaborately, or something?

Maybe the Indic shaper makes the problem more obvious but I definitely
saw a similar hang (even if I hadn't patched the installer to generate
log lines to make extra sure) with plain English when starting in rescue

> However, either 71 or 72 pixels seems a ridiculous width to be trying to
> squish multiple sentences into, so arguably it's a bug in GTK 2's layout
> algorithm that it is even considering that as a size. The GTK 2 layout
> algorithm does not necessarily make much sense, and the fact that it
> can feed back into itself is probably a GTK 2 design flaw. During the
> GTK 3 cycle it was redone to be in terms of "height for width" (if I
> give you this width, how much height will you need? the mode cdebconf
> will end up using) and "width for height" (the opposite, rarely used) -
> so hopefully GTK 3 avoids this failure mode. However, it also seems wrong
> that telling Pango that less width is available can result in it saying
> it needs *more* minimum width, and maybe preventing this from happening
> would get GTK 2 to do the right thing.
> My next thing to get a try when I get a chance will be to make GTK refuse
> to obey Pango when GTK asks Pango to stick to a width limit and Pango goes
> outside that limit, with a g_warning(). This might result in the text
> being clipped at the right margin (or left margin in Hebrew/Arabic), or
> even having its "ink rectangle" overlap with the next widget to the right
> (or left); but for d-i, which always uses the full screen width and in
> practice has a generous amount of space for its text, we might get away
> with it? In a very brief test that seemed to resolve the Sinhala thing,
> but I haven't tried the other paths that lead to infinite loops. Please
> could someone who has tried the other scenarios provide a walkthrough?

What I can think of that's not (entirely) full-width:
 - buttons at the bottom;
 - checkboxes to toggle password/passphrase visibility (but they might
   be on their own line actually);
 - anything that can be accompanied by a scrollbar.

All in all, we should have plenty of space most of (if not all) the
time. And to be honest, if we end up having rendering glitches but a
non-hanging/crashing installer for Buster, I can live with it.

Walkthrough for the English vs. rescue mode, using QEMU:

 - Get an sda.img image to “rescue” (see below).

 - Build a netboot/gtk/mini.iso from git master (the TRANSSTATUS is
   important for languages that aren't English, as that file makes it
   possible to distinguish which translations are usable):
     make -C build/ rebuild_netboot-gtk USE_UDEBS_FROM=bullseye TRANSSTATUS=translation-status

 - Run build/dest/netboot/gtk/mini.iso against it with:
     kvm -m 1G -cdrom build/dest/netboot/gtk/mini.iso -hda sda.img -boot d

 - Accept all default values.

 - Once the disk has been detected and scanned, a number of options
   are proposed, pick the first one (executing a shell in the context of
   the installed system) → hang.

To speed things up, you can fetch an image to rescue along with my last
mini.iso build here:a

Note: The hang doesn't happen if one picks French or German at the

> If you want to replicate my super-verbose printf debugging: […]

Thanks for the details, I'll give it a shot!

Cyril Brulebois (kibi at debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20210517/3c9e7df9/attachment-0002.sig>

More information about the pkg-gnome-maintainers mailing list