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
