Bug#1118572: pcre2 10.47 behaviour change: different error for ^(a)\g{3

Control: severity -1 important
Control: tags -1 = ftbfs moreinfo

On Tue, 11 Aug 2026 at 15:26:55 +0100, Matthew Vernon wrote:
>As part of prepping for PCRE 10.48, I revised 10.47-2 in experimental, 
>and the glib2.0 tests failed:
>
>https://debusine.debian.net/debian/developers/work-request/998509/
>
>Following your reproducer at the top of this bug report (thank you!), 
>I am able to reproduce the failure - after
>apt install libpcre2-8-0/experimental
>
>/usr/libexec/installed-tests/glib/regex
>
>fails as before:
>
># Compiling pattern /^(a)\g"3/ failed with error: Error while 
>compiling regular expression ?^(a)\g"3? at char 6: \g is not followed 
>by a braced, angle-bracketed, or quoted name or number, or by a plain 
>number
>ok 96 /regex/new-fail/78
>**
>ERROR:../../../glib/tests/regex.c:133:test_new_fail: assertion failed 
>(error == (g-regex-error-quark, 157)): Error while compiling regular 
>expression ?^(a)\g{3? at char 8: syntax error in subpattern number 
>(missing terminator?) (g-regex-error-quark, 0)
>not ok /regex/new-fail/79 - 
>ERROR:../../../glib/tests/regex.c:133:test_new_fail: assertion failed 
>(error == (g-regex-error-quark, 157)): Error while compiling regular 
>expression ?^(a)\g{3? at char 8: syntax error in subpattern number 
>(missing terminator?) (g-regex-error-quark, 0)

When I rebuild glib2.0 against the updated pcre2, the regex test passes.

I think what's happening here is that the test suite of a glib2.0 that 
was compiled against the old pcre2 won't accept the new pcre2 behaviour, 
but the test suite of a glib2.0 that was compiled against the new pcre2 
will. You'll see why if you look at the upstream fix for this bug, in 
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4884/diffs: it 
can't possibly handle PCRE2_ERROR_MISSING_NUMBER_TERMINATOR if it was 
compiled against an older version of pcre2 that didn't define that error 
code.

So I think that when you're ready to upload a new pcre2 to unstable, 
glib2.0 will have to be recompiled against it (either asking the release 
team for a binNMU, or via a sourceful upload), and then they can migrate 
to testing together. But until then, this bug report doesn't seem 
actionable: there is nothing reasonable that we can do in unstable that 
will make glib2.0 handle error codes that don't yet exist in unstable. 
(I don't think it seems like a good idea to do an #ifndef/#define 
hard-coding the value we expect newer versions of pcre2 to assign to 
the new error code...)

If you're checking whether pcre2 (>= 10.48) will make glib2.0 regress, 
please check that by compiling glib2.0 from source, rather than using 
its pre-existing binaries.

Thanks,
     smcv