Bug#987587: libpango1.0-udeb: hangs the installer in various situations
kibi at debian.org
Mon May 17 22:54:01 BST 2021
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!
> 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...
Size: 833 bytes
Desc: not available
More information about the pkg-gnome-maintainers