On Wed, May 19, 2021 at 05:50:49PM +0200, Cyril Brulebois wrote:
>Simon McVittie (2021-05-19):
...
>> 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
Control: clone 987587 -2 -3
Control: reassign -2 libgtk2.0-0-udeb 2.24.33-1
Control: retitle -2 libgtk2.0-0-udeb: should avoid GtkTextView relayout loop if
width from Pango oscillates
Control: tags -2 + patch pending
Control: reassign -3 cdebconf-gtk-udeb 0.257
Control: retitle -3
Simon McVittie (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
On Mon, 17 May 2021 at 23:54:01 +0200, Cyril Brulebois wrote:
> Simon McVittie (2021-05-17):
> > 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.
>
> Without looking into the code, one might try
Hi Simon!
Simon McVittie (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
On Mon, 17 May 2021 at 18:12:35 +0200, Cyril Brulebois wrote:
> 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
Cyril Brulebois, le lun. 17 mai 2021 18:12:35 +0200, a ecrit:
> 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
Cyril Brulebois (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
Hi Simon,
Simon McVittie (2021-05-13):
> Adding a udeb-specific hack in one of those packages seems reasonable,
> *if* we can find a suitable hack.
>
> pango1.0 just has one build shared between the udeb and the full .deb,
> so if the hack goes there, a prerequisite would be to build it twice
>
On Tue, 04 May 2021 at 15:47:03 +0200, Cyril Brulebois wrote:
> 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
Hi Simon,
And thanks a lot for debugging/digging/sharing!
Simon McVittie (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
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
>
On Thu, 29 Apr 2021 at 18:54:56 +0200, Cyril Brulebois wrote:
> Version 1.44.4 is the first one I was able to build, using the packaging
> from debian/1.44.6-1 (first 1.44.x version that was packaged and that's
> also known to be buggy).
I've been able to hack together packaging for 1.43.0
* Cyril Brulebois [210430 09:47]:
> Anyway, looking at the diffstat between 1.43.0 (last known good) and
> 1.44.4 (first known bad), we have this:
> 179 files changed, 19157 insertions(+), 7045 deletions(-)
>
> Between 1.43.0 and 1.44 (if it were an earlier known bad):
> 165 files changed,
Chris Hofstaedtler (2021-04-29):
> > Alright, I think I'm hitting my limits here.
> >
> > Versions 1.44, 1.44.2, and 1.44.3 all fail in a similar way:
> ../pango/pangofc-font.c:371:44: error: ‘HB_OT_METRICS_UNDERLINE_SIZE’
> undeclared (first use in this function); did you mean
>
Cyril Brulebois, le jeu. 29 avril 2021 18:54:56 +0200, a ecrit:
> Versions 1.44, 1.44.2, and 1.44.3 all fail in a similar way:
>
> ../pango/pangofc-font.c: In function ‘get_face_metrics’:
> ../pango/pangofc-font.c:371:44: error: ‘HB_OT_METRICS_UNDERLINE_SIZE’
> undeclared (first use in
* Cyril Brulebois [210429 18:03]:
> Cyril Brulebois (2021-04-29):
> > This time around, testing 1.43.0 with debian/ carried over from
> > debian/1.42.4-8, adjusted for docs (some files are missing) and symbols
> > (one new symbol), the problem cannot be triggered in an obvious manner.
> >
> >
Cyril Brulebois (2021-04-29):
> This time around, testing 1.43.0 with debian/ carried over from
> debian/1.42.4-8, adjusted for docs (some files are missing) and symbols
> (one new symbol), the problem cannot be triggered in an obvious manner.
>
> Moving to 1.44* tags now.
Alright, I think I'm
Cyril Brulebois (2021-04-26):
> - I'm *not yet* certain this also triggers direct failures for Netinst
>images for several languages, tracked at:
> https://bugs.debian.org/987449
…
>I'll try to confirm this in the next few days.
It's been confirmed, so I've added a “block” between
Package: libpango1.0-udeb
Version: 1.44.7-3
Severity: grave
Tags: d-i
Justification: renders package unusable
X-Debbugs-Cc: debian-b...@lists.debian.org
Hi,
In the “better late than never” department… I've completed a debugging session
that shows that upgrading libpango1.0-udeb from 1.42.4-8 to
20 matches
Mail list logo
