Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

2024-02-25 Thread Jonathan Wiltshire 
Control: tag -1 confirmed

On Sun, Feb 25, 2024 at 04:50:55PM +1100, Hugh McMaster wrote:
> I've prepared a source debdiff for the proposed freetype 
> 2.12.1+dfsg-5+deb12u3.
> 
> This update includes the original patch and the additional typo fix
> identified by Ben Wagner.
> 
> In terms of testing, grepping for PUT_COLOR_LAYERS_V1 or
> TT_SUPPORT_COLRV1 yields almost the same group of packages.
> 
> chromium, firefox-esr, godot, thunderbird all have GUIs. These launch
> and function as expected on my bookworm test system.
> 
> I also tested some of the openjdk-* demos, where the openjdk version
> is installable on bookworm.

Please go ahead as a source-only upload.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

2024-02-24 Thread Hugh McMaster 
Control: tag -1 -moreinfo
Control: retitle -1 bookworm-pu: package freetype/2.12.1+dfsg-5+deb12u3

Hi Jonathan,

On Sun, 11 Feb 2024 at 01:40, Jonathan Wiltshire wrote:
>
> On Sat, Feb 10, 2024 at 12:23:06AM +1100, Hugh McMaster wrote:
> > When is the next point release scheduled for?
>
> It isn't yet, but the normal candence is approximately every two months.
> You need to allow plenty for time for review and testing though. Please
> propose a source debdiff as usual.

I've prepared a source debdiff for the proposed freetype 2.12.1+dfsg-5+deb12u3.

This update includes the original patch and the additional typo fix
identified by Ben Wagner.

In terms of testing, grepping for PUT_COLOR_LAYERS_V1 or
TT_SUPPORT_COLRV1 yields almost the same group of packages.

chromium, firefox-esr, godot, thunderbird all have GUIs. These launch
and function as expected on my bookworm test system.

I also tested some of the openjdk-* demos, where the openjdk version
is installable on bookworm.

Hugh


freetype-2.12.1+dfsg-5+deb12u3.debdiff
Description: Binary data

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

2024-02-10 Thread Jonathan Wiltshire 
On Sat, Feb 10, 2024 at 12:23:06AM +1100, Hugh McMaster wrote:
> Hi Jonathan,
> 
> On Wed, 7 Feb 2024 at 04:47, Jonathan Wiltshire wrote:
> 
> > What's your plan at this point? We have skipped this update in two point
> > releases now and it needs a resolution.
> 
> 
> Thanks for following up. I’d actually forgotten about this.
> 
> I’d still like to disable the incomplete and incompatible COLRv1 support in
> Bookworm’s FreeType library.
> 
> The additional patch Ben Wagner identified is required.
> 
> Chromium seems to have fixed the bug we encountered last year, as I tested
> a build of FreeType as originally submitted and had no issues.
> 
> To avoid any surprises though, we should add the extra patch.
> 
> When is the next point release scheduled for?

It isn't yet, but the normal candence is approximately every two months.
You need to allow plenty for time for review and testing though. Please
propose a source debdiff as usual.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

2024-02-09 Thread Hugh McMaster 
Hi Jonathan,

On Wed, 7 Feb 2024 at 04:47, Jonathan Wiltshire wrote:

> What's your plan at this point? We have skipped this update in two point
> releases now and it needs a resolution.


Thanks for following up. I’d actually forgotten about this.

I’d still like to disable the incomplete and incompatible COLRv1 support in
Bookworm’s FreeType library.

The additional patch Ben Wagner identified is required.

Chromium seems to have fixed the bug we encountered last year, as I tested
a build of FreeType as originally submitted and had no issues.

To avoid any surprises though, we should add the extra patch.

When is the next point release scheduled for?

Hugh

>

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

2024-02-06 Thread Jonathan Wiltshire 
Control: tag -1 moreinfo

Hi,

On Fri, Sep 29, 2023 at 12:22:41AM +1000, Hugh McMaster wrote:
> After discussing the timing of Debian 12.2 with a release manager, I’ll
> revert the change shortly.
> 

What's your plan at this point? We have skipped this update in two point
releases now and it needs a resolution.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

2023-09-28 Thread Andres Salomon 
Thanks! Can we also roll that fix into the freetype bookworm p-u? Looks 
pretty simple to me; just ensuring that sfnt->get_colr_glyph_paint 
isn't NULL before calling it.




On Thu, Sep 28 2023 at 11:33:45 AM -04:00:00, Ben Wagner 
 wrote:

I have been able to figure out what is going on. The crash is due to a
typo in FreeType which was recently fixed [0]. This change is also
needed. I can confirm in a local build that with this typo fix the
reported Chromium crash (in libfreetype.so.6) is fixed. To be clear,
this FreeType change [0] is needed in addition to the the COLRv1
disable [1].

[0] 

[1] 



On Thu, Sep 28, 2023 at 10:36 AM Ben Wagner > wrote:


 I will take a look into this, but I am confused.
 FT_Get_Color_Glyph_Paint cannot be NULL as it is a regular exported
 function. This change will affect its behavior to always return 0
 (false) but that often happens anyway even without this change (most
 fonts don't have COLRv1 tables). For now it's fine to to revert the
 change as the original issue does not currently affect many users, 
but

 it is an issue that will need to be addressed.

 On Thu, Sep 28, 2023 at 10:22 AM Hugh McMaster > wrote:

 >
 > On Thu, 28 Sep 2023 at 21:44, Hugh McMaster wrote:
 >>
 >> Hi Andres,
 >>
 >> On Thu, 28 Sept 2023 at 18:49, Andres Salomon wrote:
 >> >
 >> > Control: affects -1 chromium
 >> >
 >> >
 >> > On Thu, 28 Sep 2023 01:24:00 +0900 SuperCat wrote:
 >> > > Hi,
 >> > >
 >> > > In chromium source code, function 
SkScalerContext::GlyphMetrics

 >> > > SkScalerContext_FreeType::generateMetrics() will call
 >> > > FT_Get_Color_Glyph_Paint() if macro TT_SUPPORT_COLRV1 
exists. Somehow
 >> > > FT_Get_Color_Glyph_Paint will be a NULL pointer if this 
patch applied, and

 >> > > chromium will not be able to run.
 >> >
 >> >
 >> > This smells like an ABI change that doesn't really seem 
appropriate for a point release update. I can patch 
TT_SUPPORT_COLRV1 out of bookworm's Chromium, but I wonder if any 
other packages are using it on bookworm?

 >> >
 >> > For the record, Skia has the following code:
 >> >
 >> > #ifdef TT_SUPPORT_COLRV1
 >> >
 >> > // So undefine TT_SUPPORT_COLRV1 before 2.11.1 but not if 
FT_STATIC_CAST is defined.

 >> > #if (((FREETYPE_MAJOR)  < 2) || \
 >> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR)  < 11) || \
 >> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) == 11 && 
(FREETYPE_PATCH) < 1)) && \

 >> > !defined(FT_STATIC_CAST)
 >> > #undef TT_SUPPORT_COLRV1
 >> >
 >> >
 >> > So on bullseye (with freetype 2.10) it doesn't try to use 
COLRV1. On sid (with freetype 2.13) it will use COLRV1. If 
freetype's COLRV1 is going to remain disabled on bookworm via the 
proposed-update (with chromium being the only broken package), then 
I'll probably just bump that version check to only allow 
TT_SUPPORT_COLRV1 with FREETYPE_MINOR >= 13.

 >>
 >> FreeType 2.12.1 was released with experimental COLRv1 support 
enabled.
 >> This was unintentional, as the implementation shipped in this 
release

 >> was incomplete and incompatible with the final COLRv1 API.
 >>
 >> Upstream's intention was to enable COLRv1 support in FreeType 
2.13.0,

 >> which has a stable and complete COLRv1 API.
 >>
 >> I'm surprised Chromium actually used an experimental API, 
although

 >> this version check copied above seems like a bug.
 >>
 >> Grepping for TT_SUPPORT_COLRV1 yields a small number of packages.
 >> firefox*, godot and paraview are fine. Most of the openjdk-* 
packages

 >> aren't in bookworm.
 >
 >
 > After discussing the timing of Debian 12.2 with a release 
manager, I’ll revert the change shortly.

 >
 > Hugh

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

2023-09-28 Thread Ben Wagner 
I have been able to figure out what is going on. The crash is due to a
typo in FreeType which was recently fixed [0]. This change is also
needed. I can confirm in a local build that with this typo fix the
reported Chromium crash (in libfreetype.so.6) is fixed. To be clear,
this FreeType change [0] is needed in addition to the the COLRv1
disable [1].

[0] 
https://gitlab.freedesktop.org/freetype/freetype/-/commit/16f311d72582c117796a23e22074fe9624760ee1
[1] 
https://salsa.debian.org/debian/freetype/-/commit/f65637c7f84fa2ccfb14c11d0ed0f315fe83636d

On Thu, Sep 28, 2023 at 10:36 AM Ben Wagner  wrote:
>
> I will take a look into this, but I am confused.
> FT_Get_Color_Glyph_Paint cannot be NULL as it is a regular exported
> function. This change will affect its behavior to always return 0
> (false) but that often happens anyway even without this change (most
> fonts don't have COLRv1 tables). For now it's fine to to revert the
> change as the original issue does not currently affect many users, but
> it is an issue that will need to be addressed.
>
> On Thu, Sep 28, 2023 at 10:22 AM Hugh McMaster  wrote:
> >
> > On Thu, 28 Sep 2023 at 21:44, Hugh McMaster wrote:
> >>
> >> Hi Andres,
> >>
> >> On Thu, 28 Sept 2023 at 18:49, Andres Salomon wrote:
> >> >
> >> > Control: affects -1 chromium
> >> >
> >> >
> >> > On Thu, 28 Sep 2023 01:24:00 +0900 SuperCat wrote:
> >> > > Hi,
> >> > >
> >> > > In chromium source code, function SkScalerContext::GlyphMetrics
> >> > > SkScalerContext_FreeType::generateMetrics() will call
> >> > > FT_Get_Color_Glyph_Paint() if macro TT_SUPPORT_COLRV1 exists. Somehow
> >> > > FT_Get_Color_Glyph_Paint will be a NULL pointer if this patch applied, 
> >> > > and
> >> > > chromium will not be able to run.
> >> >
> >> >
> >> > This smells like an ABI change that doesn't really seem appropriate for 
> >> > a point release update. I can patch TT_SUPPORT_COLRV1 out of bookworm's 
> >> > Chromium, but I wonder if any other packages are using it on bookworm?
> >> >
> >> > For the record, Skia has the following code:
> >> >
> >> > #ifdef TT_SUPPORT_COLRV1
> >> >
> >> > // So undefine TT_SUPPORT_COLRV1 before 2.11.1 but not if FT_STATIC_CAST 
> >> > is defined.
> >> > #if (((FREETYPE_MAJOR)  < 2) || \
> >> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR)  < 11) || \
> >> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) == 11 && 
> >> > (FREETYPE_PATCH) < 1)) && \
> >> > !defined(FT_STATIC_CAST)
> >> > #undef TT_SUPPORT_COLRV1
> >> >
> >> >
> >> > So on bullseye (with freetype 2.10) it doesn't try to use COLRV1. On sid 
> >> > (with freetype 2.13) it will use COLRV1. If freetype's COLRV1 is going 
> >> > to remain disabled on bookworm via the proposed-update (with chromium 
> >> > being the only broken package), then I'll probably just bump that 
> >> > version check to only allow TT_SUPPORT_COLRV1 with FREETYPE_MINOR >= 13.
> >>
> >> FreeType 2.12.1 was released with experimental COLRv1 support enabled.
> >> This was unintentional, as the implementation shipped in this release
> >> was incomplete and incompatible with the final COLRv1 API.
> >>
> >> Upstream's intention was to enable COLRv1 support in FreeType 2.13.0,
> >> which has a stable and complete COLRv1 API.
> >>
> >> I'm surprised Chromium actually used an experimental API, although
> >> this version check copied above seems like a bug.
> >>
> >> Grepping for TT_SUPPORT_COLRV1 yields a small number of packages.
> >> firefox*, godot and paraview are fine. Most of the openjdk-* packages
> >> aren't in bookworm.
> >
> >
> > After discussing the timing of Debian 12.2 with a release manager, I’ll 
> > revert the change shortly.
> >
> > Hugh

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

2023-09-28 Thread Ben Wagner 
I will take a look into this, but I am confused.
FT_Get_Color_Glyph_Paint cannot be NULL as it is a regular exported
function. This change will affect its behavior to always return 0
(false) but that often happens anyway even without this change (most
fonts don't have COLRv1 tables). For now it's fine to to revert the
change as the original issue does not currently affect many users, but
it is an issue that will need to be addressed.

On Thu, Sep 28, 2023 at 10:22 AM Hugh McMaster  wrote:
>
> On Thu, 28 Sep 2023 at 21:44, Hugh McMaster wrote:
>>
>> Hi Andres,
>>
>> On Thu, 28 Sept 2023 at 18:49, Andres Salomon wrote:
>> >
>> > Control: affects -1 chromium
>> >
>> >
>> > On Thu, 28 Sep 2023 01:24:00 +0900 SuperCat wrote:
>> > > Hi,
>> > >
>> > > In chromium source code, function SkScalerContext::GlyphMetrics
>> > > SkScalerContext_FreeType::generateMetrics() will call
>> > > FT_Get_Color_Glyph_Paint() if macro TT_SUPPORT_COLRV1 exists. Somehow
>> > > FT_Get_Color_Glyph_Paint will be a NULL pointer if this patch applied, 
>> > > and
>> > > chromium will not be able to run.
>> >
>> >
>> > This smells like an ABI change that doesn't really seem appropriate for a 
>> > point release update. I can patch TT_SUPPORT_COLRV1 out of bookworm's 
>> > Chromium, but I wonder if any other packages are using it on bookworm?
>> >
>> > For the record, Skia has the following code:
>> >
>> > #ifdef TT_SUPPORT_COLRV1
>> >
>> > // So undefine TT_SUPPORT_COLRV1 before 2.11.1 but not if FT_STATIC_CAST 
>> > is defined.
>> > #if (((FREETYPE_MAJOR)  < 2) || \
>> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR)  < 11) || \
>> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) == 11 && (FREETYPE_PATCH) 
>> > < 1)) && \
>> > !defined(FT_STATIC_CAST)
>> > #undef TT_SUPPORT_COLRV1
>> >
>> >
>> > So on bullseye (with freetype 2.10) it doesn't try to use COLRV1. On sid 
>> > (with freetype 2.13) it will use COLRV1. If freetype's COLRV1 is going to 
>> > remain disabled on bookworm via the proposed-update (with chromium being 
>> > the only broken package), then I'll probably just bump that version check 
>> > to only allow TT_SUPPORT_COLRV1 with FREETYPE_MINOR >= 13.
>>
>> FreeType 2.12.1 was released with experimental COLRv1 support enabled.
>> This was unintentional, as the implementation shipped in this release
>> was incomplete and incompatible with the final COLRv1 API.
>>
>> Upstream's intention was to enable COLRv1 support in FreeType 2.13.0,
>> which has a stable and complete COLRv1 API.
>>
>> I'm surprised Chromium actually used an experimental API, although
>> this version check copied above seems like a bug.
>>
>> Grepping for TT_SUPPORT_COLRV1 yields a small number of packages.
>> firefox*, godot and paraview are fine. Most of the openjdk-* packages
>> aren't in bookworm.
>
>
> After discussing the timing of Debian 12.2 with a release manager, I’ll 
> revert the change shortly.
>
> Hugh

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

2023-09-28 Thread Hugh McMaster 
On Thu, 28 Sep 2023 at 21:44, Hugh McMaster wrote:

> Hi Andres,
>
> On Thu, 28 Sept 2023 at 18:49, Andres Salomon wrote:
> >
> > Control: affects -1 chromium
> >
> >
> > On Thu, 28 Sep 2023 01:24:00 +0900 SuperCat wrote:
> > > Hi,
> > >
> > > In chromium source code, function SkScalerContext::GlyphMetrics
> > > SkScalerContext_FreeType::generateMetrics() will call
> > > FT_Get_Color_Glyph_Paint() if macro TT_SUPPORT_COLRV1 exists. Somehow
> > > FT_Get_Color_Glyph_Paint will be a NULL pointer if this patch applied,
> and
> > > chromium will not be able to run.
> >
> >
> > This smells like an ABI change that doesn't really seem appropriate for
> a point release update. I can patch TT_SUPPORT_COLRV1 out of bookworm's
> Chromium, but I wonder if any other packages are using it on bookworm?
> >
> > For the record, Skia has the following code:
> >
> > #ifdef TT_SUPPORT_COLRV1
> >
> > // So undefine TT_SUPPORT_COLRV1 before 2.11.1 but not if FT_STATIC_CAST
> is defined.
> > #if (((FREETYPE_MAJOR)  < 2) || \
> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR)  < 11) || \
> >  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) == 11 &&
> (FREETYPE_PATCH) < 1)) && \
> > !defined(FT_STATIC_CAST)
> > #undef TT_SUPPORT_COLRV1
> >
> >
> > So on bullseye (with freetype 2.10) it doesn't try to use COLRV1. On sid
> (with freetype 2.13) it will use COLRV1. If freetype's COLRV1 is going to
> remain disabled on bookworm via the proposed-update (with chromium being
> the only broken package), then I'll probably just bump that version check
> to only allow TT_SUPPORT_COLRV1 with FREETYPE_MINOR >= 13.
>
> FreeType 2.12.1 was released with experimental COLRv1 support enabled.
> This was unintentional, as the implementation shipped in this release
> was incomplete and incompatible with the final COLRv1 API.
>
> Upstream's intention was to enable COLRv1 support in FreeType 2.13.0,
> which has a stable and complete COLRv1 API.
>
> I'm surprised Chromium actually used an experimental API, although
> this version check copied above seems like a bug.
>
> Grepping for TT_SUPPORT_COLRV1 yields a small number of packages.
> firefox*, godot and paraview are fine. Most of the openjdk-* packages
> aren't in bookworm.


After discussing the timing of Debian 12.2 with a release manager, I’ll
revert the change shortly.

Hugh

>

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

2023-09-28 Thread Hugh McMaster 
Hi Andres,

On Thu, 28 Sept 2023 at 18:49, Andres Salomon wrote:
>
> Control: affects -1 chromium
>
>
> On Thu, 28 Sep 2023 01:24:00 +0900 SuperCat wrote:
> > Hi,
> >
> > In chromium source code, function SkScalerContext::GlyphMetrics
> > SkScalerContext_FreeType::generateMetrics() will call
> > FT_Get_Color_Glyph_Paint() if macro TT_SUPPORT_COLRV1 exists. Somehow
> > FT_Get_Color_Glyph_Paint will be a NULL pointer if this patch applied, and
> > chromium will not be able to run.
>
>
> This smells like an ABI change that doesn't really seem appropriate for a 
> point release update. I can patch TT_SUPPORT_COLRV1 out of bookworm's 
> Chromium, but I wonder if any other packages are using it on bookworm?
>
> For the record, Skia has the following code:
>
> #ifdef TT_SUPPORT_COLRV1
>
> // So undefine TT_SUPPORT_COLRV1 before 2.11.1 but not if FT_STATIC_CAST is 
> defined.
> #if (((FREETYPE_MAJOR)  < 2) || \
>  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR)  < 11) || \
>  ((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) == 11 && (FREETYPE_PATCH) < 
> 1)) && \
> !defined(FT_STATIC_CAST)
> #undef TT_SUPPORT_COLRV1
>
>
> So on bullseye (with freetype 2.10) it doesn't try to use COLRV1. On sid 
> (with freetype 2.13) it will use COLRV1. If freetype's COLRV1 is going to 
> remain disabled on bookworm via the proposed-update (with chromium being the 
> only broken package), then I'll probably just bump that version check to only 
> allow TT_SUPPORT_COLRV1 with FREETYPE_MINOR >= 13.

FreeType 2.12.1 was released with experimental COLRv1 support enabled.
This was unintentional, as the implementation shipped in this release
was incomplete and incompatible with the final COLRv1 API.

Upstream's intention was to enable COLRv1 support in FreeType 2.13.0,
which has a stable and complete COLRv1 API.

I'm surprised Chromium actually used an experimental API, although
this version check copied above seems like a bug.

Grepping for TT_SUPPORT_COLRV1 yields a small number of packages.
firefox*, godot and paraview are fine. Most of the openjdk-* packages
aren't in bookworm.

Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup

2023-09-28 Thread Andres Salomon 

Control: affects -1 chromium


On Thu, 28 Sep 2023 01:24:00 +0900 SuperCat  
wrote:

> Hi,
>
> In chromium source code, function SkScalerContext::GlyphMetrics
> SkScalerContext_FreeType::generateMetrics() will call
> FT_Get_Color_Glyph_Paint() if macro TT_SUPPORT_COLRV1 exists. Somehow
> FT_Get_Color_Glyph_Paint will be a NULL pointer if this patch 
applied, and

> chromium will not be able to run.


This smells like an ABI change that doesn't really seem appropriate for 
a point release update. I can patch TT_SUPPORT_COLRV1 out of bookworm's 
Chromium, but I wonder if any other packages are using it on bookworm?


For the record, Skia has the following code:

#ifdef TT_SUPPORT_COLRV1

// So undefine TT_SUPPORT_COLRV1 before 2.11.1 but not if 
FT_STATIC_CAST is defined.

#if (((FREETYPE_MAJOR)  < 2) || \
((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR)  < 11) || \
((FREETYPE_MAJOR) == 2 && (FREETYPE_MINOR) == 11 && 
(FREETYPE_PATCH) < 1)) && \

   !defined(FT_STATIC_CAST)
#undef TT_SUPPORT_COLRV1


So on bullseye (with freetype 2.10) it doesn't try to use COLRV1. On 
sid (with freetype 2.13) it will use COLRV1. If freetype's COLRV1 is 
going to remain disabled on bookworm via the proposed-update (with 
chromium being the only broken package), then I'll probably just bump 
that version check to only allow TT_SUPPORT_COLRV1 with FREETYPE_MINOR 
>= 13.