With the new pcre2 in experimental, GLib's "as-installed" tests fail
during autopkgtest. This can most easily be reproduced in a container
(in this example Podman, but use whatever is your favourite
chroot/container techology):

$ podman run --rm -it docker.io/debian:sid-slim
# sed -i -e 's/Suites: sid/& experimental/' /etc/apt/sources.list.d/debian.sources
# apt update
# apt upgrade
# apt install --no-install-recommends libglib2.0-tests
# /usr/libexec/installed-tests/glib/regex; echo $?
...
0
# apt install libpcre2-8-0/experimental
# /usr/libexec/installed-tests/glib/regex ; echo $?
...
not ok /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)
Bail out!
Aborted                    (core dumped) /usr/libexec/installed-tests/glib/regex
134

I'm reasonably sure this would also make glib2.0 FTBFS (hence the ftbfs
tag) although I haven't verified this.

The test failure is that GLib is expecting that compiling the
(incomplete) regex "(a)\g{3" will produce PCRE2_ERROR_BACKSLASH_G_SYNTAX
(which it translates to GRegexError number 157,
G_REGEX_ERROR_MISSING_BACK_REFERENCE), but in fact it saw some error code
that is not specifically handled by translate_compile_error() in
glib/gregex.c, resulting in the default error, G_REGEX_ERROR_COMPILE.

Was this an intentional behaviour change in PCRE?

There might be other assertion failures after this one is addressed, I
haven't checked that yet.

    smcv

Hi,

Yes, it does (per debusine).

If you look at the changes to testdata/testoutput2 you'll see at lines
7855 and 7855 that the error number and text for
/^(a)\g{3/

have changed from:
Failed: error 157 at offset 6: \g is not followed by a braced,
angle-bracketed, or quoted name/number or by a plain number
         here: ^(a)\g |<-->| {3

to:
Failed: error 219 at offset 8: syntax error in subpattern number
(missing terminator?)
         here: ^(a)\g{3 |<--|Because there's a new and more-specific
error code PCRE2_ERROR_MISSING_NUMBER_TERMINATOR

in the error case that was previously just handled as
PCRE2_ERROR_BACKSLASH_G_SYNTAX So I think this will need fixing in the
glib2 build-time test suite?
Regards,

Matthew

Hi,

Sorry, my MUA rather mangled that.
Is I think better.

We believe that the bug you reported is fixed in the latest version of
glib2.0, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1118572@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated glib2.0 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 03 Nov 2025 18:50:56 +0000
Source: glib2.0
Architecture: source
Version: 2.86.1-2
Distribution: unstable
Urgency: medium
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Closes: 1118572
Changes:
 glib2.0 (2.86.1-2) unstable; urgency=medium
 .
   * d/p/gresolver-Fix-loopback-detection-of-IPv6-addresses.patch,
     d/p/glib-tests-regex-Add-a-future-proof-test-case-for-missing.patch,
     d/p/gregex-Handle-PCRE2_ERROR_MISSING_NUMBER_TERMINATOR-if-de.patch,
     d/p/tests-regex-Add-the-error-messages-to-tests.patch,
     d/p/gutils-Strip-all-trailing-slashes.patch:
     Add bug fixes from upstream glib-2-86 branch up to 2.86.1-8-g61384f791d.
     In particular this should fix test failures with pcre2 10.47
     (Closes: #1118572)
   * d/control: Drop B-D on docbook-xml, docbook-xsl, xsltproc.
     The man pages are now written in reStructuredText rather than Docbook
     XML, so we no longer need these.
   * d/control: Add comments clarifying the meaning of non-trivial build
     profile conditions
   * d/watch: Convert to uscan format v5
Checksums-Sha1:
 674282104536d312c41c45381892af9fee5082f5 5063 glib2.0_2.86.1-2.dsc
 5662ffbaf8b3836bcc4f90fc7053642bdaae3478 143428 glib2.0_2.86.1-2.debian.tar.xz
 6beacfee777af25c5e0ce263d3d0f2794641e0c9 16242040 glib2.0_2.86.1-2.git.tar.xz
 f4e327303c3af1723ea259944e0b6cb60cd656a2 18222 glib2.0_2.86.1-2_source.buildinfo
Checksums-Sha256:
 3c6d7a5546ca1d8dc8b6b35648e1f7aace385f182eee128585b12f8859f5fc3a 5063 glib2.0_2.86.1-2.dsc
 51250cbc1dd11b614545f7f0f7248dec1b1ff7bea3954cfe0a51add4a921e1b4 143428 glib2.0_2.86.1-2.debian.tar.xz
 21e9036fdb49faef09281cb25facb3ec233932ff85b5d5914f7bbea590b6e0c5 16242040 glib2.0_2.86.1-2.git.tar.xz
 a9781e24d9dd236705faadc949a508eb73fb453ca5aa2ddbc4a3b3386875d235 18222 glib2.0_2.86.1-2_source.buildinfo
Files:
 3040b8e2da445b8989ef122f73a6df90 5063 libs optional glib2.0_2.86.1-2.dsc
 2d95f0798a4beeb6d0a74b269c627dce 143428 libs optional glib2.0_2.86.1-2.debian.tar.xz
 30cdcabfe7861de67abe71cf4e7862fb 16242040 libs optional glib2.0_2.86.1-2.git.tar.xz
 e5f86cf81969940ee87855c60ee5d239 18222 libs optional glib2.0_2.86.1-2_source.buildinfo
Git-Tag-Info: tag=c258d7e548f32cd31d333251f021b643476f5da9 fp=7a073ad1ae694fa25bff62e5235c099d3eb33076
Git-Tag-Tagger: Simon McVittie <smcv@debian.org>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEN02M5NuW6cvUwJcqYG0ITkaDwHkFAmkJI3cACgkQYG0ITkaD
wHlS0g/9GLkSa9xCAOhJGIw19Dm4dwQOWvTndjvM5+Hf3O8vjT/POk8oEl5ejkVf
+TtfQi+4dR9zT+8PbpHM+umKmjBNQW/27vg8HWD3TUYsj87ZeSq0LZkgLcfsuQ/q
8RnhfqQUynLwdh6lEyX5vppnewCinOy4stIgIbPC0CrAed8MdnRCXZOrxJlDgTpw
Wp4vck8kjCLCBQzPhZ88TdDapp9tmMzlp4A+bnnmtJy5B1RD0nsQ+cTwNMfvKuTd
QbP1R+kMrJbzN5yDBq5DfQp4A0MIbRn6bfvM/Jt8XXx7EGCGSli+cEy3nMFfK4uo
8ZF2uzibxbYC8GIb/pOaYWeUn64t7hM2xDjE5p2EOCdBI/l/9EKGgrASO5JUriv5
lJdpgDzU0rNCKCvzeS+wGkm4YBEuc+5+kpIA1giPZoNSDTOSctEQtCwCPoI0eOpq
AUlnvIk0QVMJ09x39l8j0qNGtZWROKzEENDw0LlqRo5FA6tim8jtObUYzR346mgn
sgX+7FgKSWWSebiOr31RDfYq90jSqpWOYrUOHZT0bX/ax6sa5wBJsCTIsYDVTFfC
eUs3jIE6+krBQTt15Bz8benoszREYaA8gJB2XwJQ/4S36uaotuaegx/qATqvyQ4M
hYILzh/L41OvyrPXidZUsWwbrgF39yOSV5i/SZCHM8DAiEzIryM=
=ccxT
-----END PGP SIGNATURE-----

Hi,

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)
Bail out!

Regards,

Matthew

Sorry, that should be "revisited"; 10.47-2 is from ages ago.

Regards,

Matthew

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

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

Hi

Noted.

Thanks for this; I (after a bit of wrangling) have got debusine to
test-build pcre2 10.47's direct rev-deps (including glib2.0), and
glib2.0 does build OK there, so I should be able to do equivalent
testing with a 10.48 RC once it's available.

Regards,

Matthew