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

[Cyril Brulebois]

Simon McVittie <smcv at debian.org> (2021-05-19):
> It wasn't obvious to me where we'd keep track of this, or how correct
> it would be to do that - cache invalidation is reputed to be one of the
> hardest problems in computer science, and this would be one more thing
> that needs to be invalidated on at least those occasions when the layout
> has legitimately changed (but without invalidating it too often because
> that would destroy the workaround).
> 
> Having reproduced the English/rescue issue and got further with the
> Sinhala/install issue with the GTK MR referenced below, I think it can
> also happen that the layout flaps by an amount greater than 1 pixel
> (I think the most I've seen is 4px), so a special case for n/n+1 isn't
> going to be enough.
> 
> One of the reasons this took me a while is that I got distracted by the
> difference I was seeing being exactly 1px, which I thought might be to
> do with GTK adding 1px of extra width to make sure there's space for a
> cursor - but after tracing through it, it seemed like GTK is always
> adding/removing that width correctly.

Looking at the traces I saved when installing in Swedish with just the
GTK patch, I'm seeing a bunch of 1px to 4px differences, but it can even
reach 8px!

    […] we asked Pango to wrap text for width 186px but it now wants 194px. Clamping result to 186px!

> > > 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 works: https://salsa.debian.org/gnome-team/gtk2/-/merge_requests/2
> 
> The other thing I wanted to try was to make cdebconf create the
> GtkTextView in an empty state, and then populate it with text a little
> later (perhaps after layout but before drawing, or perhaps drawing one
> frame without text and then adding the text in the next frame, I'm not
> actually sure). And that also works:
> https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/6
> 
> Following the rule of thumb that bad interactions between two
> components should often be fixed on *both* sides, I'd be tempted to
> clone this bug, reassign to both gtk+2.0 and cdebconf, and apply both
> changes.

That looks good to me, I'll do so in a moment, and deal with (re)trying
to understand everything going on with your patch before merging and
uploading.

> As for Pango, I'm afraid figuring out whether it is doing something
> wrong here is beyond my expertise. If I can characterize the maybe-bug
> in a clear enough way I can try asking upstream - but as I said
> before, upstream will be very reluctant to touch this as soon as I
> mention GTK 2, which has been on life-support for a decade and is now
> officially dead.

As mentioned before, GTK 2 has been working just fine for us… until it
no longer did. It's *very*hugely*appreciated* that you've helped us that
much this time around. We'll do the work next time, and I don't think
it's important enough to try and dive into Pango some more at this
stage, unless someone experiences similar issues with a hrm more recent
and supported toolkit version…

Thanks again, you're a lifesaver!


Cheers,
-- 
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/20210519/e9436c7e/attachment-0003.sig>