Hi Simon, And thanks a lot for debugging/digging/sharing!
Simon McVittie <s...@debian.org> (2021-05-03):
> On Mon, 03 May 2021 at 17:17:21 +0100, Simon McVittie wrote:
> > I've also been able to attach a debugger to debconf. My preliminary finding
> > is: we enter gtk_container_idle_sizer() in GTK 2 and never exit, because
> > every time we go into gtk_container_check_resize(), we end up in
> > gtk_text_layout_emit_changed() which emits a signal that eventually calls
> > _gtk_container_queue_resize(), so gtk_container_idle_sizer() has more work
> > to do and we loop indefinitely.
> ...
> > My next step is going to be to try to hack Harfbuzz to disable the Indic
> > shaper (which is what seems to be in use here) and see whether that stops
> > the infinite loop. That's unlikely to be an acceptable solution, but it'll
> > at least tell us whether the Indic shaper is what's triggering this.
>
> Yes, this worked! If I disable the Indic shaper with the attached hack,
> that seems to be enough to make installation proceed.
Yes and no: the Indic shaper triggers it for Sinhala indeed (confirmed
locally by deploying a hack harfbuzz udeb with your patch on top of
exactly the components used for D-I Bullseye RC 1), but that doesn't
explain the failure for Persian.
Of course, one can also apply the same kind of hack to other scripts
that share the same dedicated Arabic shaper, via:
- return &_hb_ot_complex_shaper_arabic;
+ return &_hb_ot_complex_shaper_default;
While the problem was obvious for certain languages (first screen after
language selection, #987449), and could exist for any languages using a
script that comes with a dedicated shaper, that still doesn't explain
the regression with English in rescue mode (#987377). I fear this issue
could actually show up with any languages (e.g. all those sharing the
Latin script), depending on $some_conditions.
I think I'll add a GTK-level patch to easily spot whether that last
issue is similar (infinite loop with signals all around the place), and
maybe try to pinpoint when the problem started to happen in the pango1.0
Git repository.
There's also a problem with Swedish during regular install (not rescue),
that I haven't tried to reproduce yet:
https://lists.debian.org/debian-boot/2021/05/msg00018.html
This would seem to confirm one doesn't need a “complex” script to get
the issue, Latin is enough…
> Again, this is probably not an acceptable solution: Harfbuzz has
> shapers for complex scripts for a reason, and I suspect someone who
> can speak the relevant language would find the text either ugly or
> unreadable when using the default shaper. However, I hope this does at
> least point someone who knows more about the mechanics of text
> rendering and/or GTK relayout in the right direction...
Despite all the above, once we have a better grasp of what's happening,
would it seem reasonable to add a hack in whatever would make sense
(pango1.0, harfbuzz, and/or gtk+2.0), but only in the udeb build, so
that we dodge the issue for Bullseye without impacting installed
systems/deb packages? If git bisecting yields a prospective (set of)
patch(es) of course…
ISTR you proposed then implemented changes to alleviate one of the
blockers for GTK3 in d-i (vte vs. libstdc++ if memory serves), but I
haven't managed to look at it during the bullseye cycle; we definitely
should look into gtk3-ifying (perhaps gtk4-ifying, time flies) d-i at
some point, but that's very likely bookworm material at this stage…
> I think the reason this regressed between Pango 1.43.0 and 1.44.0
> might just be that Pango 1.44.0 uses Harfbuzz to implement more of its
> own functionality.
Looking at the “user-level” changes in the upstream documentation, that
is indeed what seems very plausible to my inexperienced eyes.
Cheers,
--
Cyril Brulebois (k...@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
