[From nobody Wed Sep  9 17:01:05 2026
Received: (at submit) by bugs.debian.org; 22 Oct 2025 09:42:00 +0000
X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
 (2024-03-25) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-116.1 required=4.0 tests=BAYES_00,
 BODY_INCLUDES_PACKAGE,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,
 DKIM_VALID_AU,DKIM_VALID_EF,FOURLA,FROMDEVELOPER,FUZZY_CPILL,
 HAS_PACKAGE,SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY,
 USER_IN_DKIM_WELCOMELIST autolearn=ham autolearn_force=no
 version=4.0.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 22; hammy, 150; neutral, 103; spammy,
 0. spammytokens:
 hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin,
 0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311,
 0.000-+--H*RT:311, 0.000-+--H*RT:108
Return-path: <smcv@debian.org>
Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:49956)
 by buxtehude.debian.org with esmtps
 (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
 (Exim 4.96) (envelope-from <smcv@debian.org>) id 1vBVM0-00FMHh-08
 for submit@bugs.debian.org; Wed, 22 Oct 2025 09:42:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; 
 s=smtpauto.stravinsky;
 h=X-Debian-User:Content-Type:MIME-Version:Message-ID:
 Subject:To:From:Date:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:
 Content-Description:In-Reply-To:References;
 bh=wBlTKmzZReduOmXAmdW1gZFB5YpohIdhxD2MLxluK84=; b=BU2TqW3CEwcfozy26iamcz1h82
 WIZKoHqvumPifKP0uSRh5fQYloEUA3L0H33nJ9u7qaO/TSfZiPpAHtbXEJ8xJR2jrQTrNjisL+O6B
 PwAVnaSx90IEDrlXkrD2feUfVVGpgICHpk+UMxvgBXmvQDK6Bu9wdd+5XVgIvS3amuKJHGMM4Srm3
 3wRgHC+bKLfRt5I5nEqemd8KOjIoOpMXoEnKEJ/avBaUr8RZ1xZSlDokBHzO/yefgby7YxSdOzbU8
 xznaneI/YomRU3xKTtd7djku6bwA6hYVH5OTofU4S27vWWJvnOJAbDXQ5SPqcwQ81hA1uc0J8A7FE
 GteqcikQ==;
Received: from authenticated user by stravinsky.debian.org with esmtpsa
 (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
 (Exim 4.94.2) (envelope-from <smcv@debian.org>) id 1vBVLy-007IVL-C5
 for submit@bugs.debian.org; Wed, 22 Oct 2025 09:41:58 +0000
Date: Wed, 22 Oct 2025 10:41:55 +0100
From: Simon McVittie <smcv@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: libpcre2-8-0: pcre2 10.47 behaviour change: different error for
 ^(a)\g{3
Message-ID: <aPim42Hahi-dUHBj@remnant.pseudorandom.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Mutt-Fcc: =.lists.debian/
X-Reportbug-Version: 13.2.0
X-Debian-User: smcv
Delivered-To: submit@bugs.debian.org

Package: libpcre2-8-0,libglib2.0-0
Severity: serious
Control: found -1 pcre2/10.47-1
Control: found -1 glib2.0/2.86.1-1
User: debian-ci@lists.debian.org
Usertags: regression
Tags: ftbfs experimental
Control: block 902060 by -1

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
]