[Pkg-freeradius-maintainers] Bug#1147278: freeradius built without PCRE2 support, silently falls back to POSIX regex (\w etc. broken)

[Bernhard Schmidt]

Hi,

thanks for the report.

> The freeradius binary package for trixie (and confirmed still present
> in current unstable/testing, 3.2.10+dfsg-1) is built without PCRE2
> support. debian/control for these source versions lists no
> libpcre2-dev (nor the deprecated libpcre3-dev) in Build-Depends.

Right, pcre3 was dropped due to

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000031

That bug is linked against

https://github.com/FreeRADIUS/freeradius-server/issues/2315

which is closed and states that "We're not going to add pcre2 support 
for v3". So yes, PCRE support was dropped from FreeRADIUS completely.

It looks like upstream has changed their mind though, there is a commit 
from 2025 that adds pcre2.

https://github.com/FreeRADIUS/freeradius-server/commit/430ed115ca58b0b99f6ea372d4e32b573aa5d0fd

That has been included in FreeRADIUS 3.2.8

I will test and enable it with the next upload.

> Suggested fix: add libpcre2-dev to Build-Depends in debian/control.
> Confirmed the same gap persists in 3.2.10+dfsg-1 (current
> unstable/testing) via the .dsc Build-Depends field directly, so this
> is not a stable-only regression needing only a deb13u backport — it
> needs fixing at the source-package level so it doesn't ride forward
> into the next stable release as well.

It will be. However, there will be no backport of that to Trixie. It's a 
new build dependency, it might alter behaviour with a stable update (as 
you demonstrated, just the other way around) and it needs a large patch 
(+800 lines, and there are quite a few more in FreeRADIUS upstream that 
touch that code, I'm not going to backport all of them.

I'm considering a trixie-backports upload though.

Bernhard