Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null
Control: severity -1 normal -- Ondřej Surý (He/Him) > On 4. 12. 2021, at 17:14, Matthew Vernon wrote: > > Hi, > >> On 22/11/2021 09:16, Ondřej Surý wrote: >> >> I analysed the problem in: >> https://github.com/PhilipHazel/pcre2/issues/56 > > Thanks! I've had a read of that, and AIUI it's a behaviour change (matching > that of perl) rather than an ABI change? > > >> I guess bumping the version in the symbols file like this should do the >> trick: > >> - pcre2_set_compile_extra_options_8@Base 10.32 >> + pcre2_set_compile_extra_options_8@Base 10.38 > > Making this change will cause some things that will work fine with 10.32 to > incorrectly state a dependency on >=10.38, yes? But leaving things as-is > means that some code that uses a particular flag will not work if compiled > with >=10.38 and run against <10.38? > > I think that probably means on balance we should make the change you suggest, > but I wanted to check I'd understood correctly :) > > Regards, > > Matthew
Processed: Re: Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null
Processing control commands: > severity -1 normal Bug #999693 [php8.1-common] php8.1: Regular expression functions warn "Compilation failed" and return null Severity set to 'normal' from 'grave' -- 999693: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999693 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null
Hi, On 22/11/2021 09:16, Ondřej Surý wrote: I analysed the problem in: https://github.com/PhilipHazel/pcre2/issues/56 Thanks! I've had a read of that, and AIUI it's a behaviour change (matching that of perl) rather than an ABI change? I guess bumping the version in the symbols file like this should do the trick: - pcre2_set_compile_extra_options_8@Base 10.32 + pcre2_set_compile_extra_options_8@Base 10.38 Making this change will cause some things that will work fine with 10.32 to incorrectly state a dependency on >=10.38, yes? But leaving things as-is means that some code that uses a particular flag will not work if compiled with >=10.38 and run against <10.38? I think that probably means on balance we should make the change you suggest, but I wanted to check I'd understood correctly :) Regards, Matthew
Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null
Hi Matthew, I analysed the problem in: https://github.com/PhilipHazel/pcre2/issues/56 Seems like there’s BC ABI/API-incompatible change that isn’t expressed in the symbols. I guess bumping the version in the symbols file like this should do the trick: diff --git a/debian/libpcre2-8-0.symbols b/debian/libpcre2-8-0.symbols index 9e3dd2f..e242fa3 100644 --- a/debian/libpcre2-8-0.symbols +++ b/debian/libpcre2-8-0.symbols @@ -46,7 +46,7 @@ libpcre2-8.so.0 libpcre2-8-0 #MINVER# pcre2_set_bsr_8@Base 10.22 pcre2_set_callout_8@Base 10.22 pcre2_set_character_tables_8@Base 10.22 - pcre2_set_compile_extra_options_8@Base 10.32 + pcre2_set_compile_extra_options_8@Base 10.38 pcre2_set_compile_recursion_guard_8@Base 10.22 pcre2_set_depth_limit_8@Base 10.32 pcre2_set_glob_escape_8@Base 10.32 Ondrej -- Ondřej Surý (He/Him) ond...@sury.org > On 15. 11. 2021, at 16:01, Matthew Vernon wrote: > > Hi, > > On 15/11/2021 14:34, Ondřej Surý wrote: > >> This appears when built with 10.39, but the runtime version is less than >> that. My guess is that this needs manual debian/libpcre2-8.shlibs override. >> (Or just mangle the symbols file, so it always generates correct versioned >> dependency.) > > I've had a look at the Changelog from 10.36 (previous packaged version), and > there's nothing obvious there. > > Is it possible to work out what is happening lower down the stack to cause > this error message? I don't feel I have something I can even refer to > upstream yet... > > Thanks, > > Matthew
Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null
Hi, On 15/11/2021 14:34, Ondřej Surý wrote: This appears when built with 10.39, but the runtime version is less than that. My guess is that this needs manual debian/libpcre2-8.shlibs override. (Or just mangle the symbols file, so it always generates correct versioned dependency.) I've had a look at the Changelog from 10.36 (previous packaged version), and there's nothing obvious there. Is it possible to work out what is happening lower down the stack to cause this error message? I don't feel I have something I can even refer to upstream yet... Thanks, Matthew
Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null
This appears when built with 10.39, but the runtime version is less than that. My guess is that this needs manual debian/libpcre2-8.shlibs override. (Or just mangle the symbols file, so it always generates correct versioned dependency.) We can also as upstream, perhaps this is something that should be solved there? Ondřej -- Ondřej Surý (He/Him) > On 15. 11. 2021, at 15:17, Matthew Vernon wrote: > > Hi, > >> On 15/11/2021 14:03, Ondřej Surý wrote: >> It’s still a bug, but I think it might be a bug in pcre2. The other Matthew >> (in CC) might need to bump the shlibs on the shared lib to >= 10.39 > > I'm slightly confused - this appears to be an issue in a php function that > went away after an upgrade? Or, at least, I'm not sure what you are > suggesting needs changing... > > [the .symbols files are automatically checked during build] > > Regards, > > Matthew
Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null
Hi, On 15/11/2021 14:03, Ondřej Surý wrote: It’s still a bug, but I think it might be a bug in pcre2. The other Matthew (in CC) might need to bump the shlibs on the shared lib to >= 10.39 I'm slightly confused - this appears to be an issue in a php function that went away after an upgrade? Or, at least, I'm not sure what you are suggesting needs changing... [the .symbols files are automatically checked during build] Regards, Matthew
Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null
It’s still a bug, but I think it might be a bug in pcre2. The other Matthew (in
CC) might need to bump the shlibs on the shared lib to >= 10.39
--
Ondřej Surý (He/Him)
> On 15. 11. 2021, at 14:54, Matthew Krauss wrote:
>
> After running apt upgrade, it works fine. I honestly thought I had upgraded
> everything earlier, but had somehow missed doing that one machine. Very
> embarrassing, sorry for the waste of time!
>
> Sent from Yahoo Mail on Android
>
> On Mon, Nov 15, 2021 at 2:04 AM, Ondřej Surý
> wrote:
> Hi,
>
> is your system fully upgraded?
>
> What’s libpcre2 version?
>
> Ondřej
> --
> Ondřej Surý (He/Him)
>
> > On 15. 11. 2021, at 2:51, Matthew Krauss wrote:
> >
> > Package: php8.1-common
> > Version: 8.1.0~rc5-1
> > Severity: grave
> > Justification: renders package unusable
> > X-Debbugs-Cc: zeros0and1o...@yahoo.com
> >
> > Dear Maintainer,
> >
> > After installing php8.1 on testing, I found that most PHP packages are
> > failing. For instance, composer, whether installed directly from
> > getcomposer.org, or through the Debian package, is broken by this bug,
> > as well as likely the vast majority of PHP based software.
> >
> > The problem seems to be in an underlying regexp library, I *think*,
> > and seems to break most of the built in php regexp functions.
> >
> > Simple demonstration, with both php7.4 and php8.1 installed:
> >
> > $ php7.4 -r 'var_export(preg_replace("/foo/", "bar", "some foo here"));
> > echo "\ndone\n";'
> > 'some bar here'
> > done
> >
> > $ php8.1 -r 'var_export(preg_replace("/foo/", "bar", "some foo here"));
> > echo "\ndone\n";'
> > PHP Warning: preg_replace(): Compilation failed: unrecognised compile-time
> > option bit(s) at offset 0 in Command line code on line 1
> > NULL
> > done
> >
> > The php7.4 command runs correctly and is what I would expect. The php8.1
> > command generates a warning, as well as incorrect output.
> >
> >
> > -- System Information:
> > Debian Release: bookworm/sid
> > APT prefers testing
> > APT policy: (500, 'testing')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU threads)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
> > not set
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages php8.1 depends on:
> > ii libapache2-mod-php8.1 8.1.0~rc5-1
> > ii php8.1-common 8.1.0~rc5-1
> >
> > php8.1 recommends no packages.
> >
> > php8.1 suggests no packages.
> >
> > Versions of packages php8.1-common depends on:
> > ii libc6 2.31-17
> > ii libffi83.4.2-3
> > ii libssl1.1 1.1.1l-1
> > ii php-common 2:76
> > ii ucf3.0043
> >
> > -- no debconf information
> >
>
Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null
Hi,
is your system fully upgraded?
What’s libpcre2 version?
Ondřej
--
Ondřej Surý (He/Him)
> On 15. 11. 2021, at 2:51, Matthew Krauss wrote:
>
> Package: php8.1-common
> Version: 8.1.0~rc5-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: zeros0and1o...@yahoo.com
>
> Dear Maintainer,
>
> After installing php8.1 on testing, I found that most PHP packages are
> failing. For instance, composer, whether installed directly from
> getcomposer.org, or through the Debian package, is broken by this bug,
> as well as likely the vast majority of PHP based software.
>
> The problem seems to be in an underlying regexp library, I *think*,
> and seems to break most of the built in php regexp functions.
>
> Simple demonstration, with both php7.4 and php8.1 installed:
>
> $ php7.4 -r 'var_export(preg_replace("/foo/", "bar", "some foo here")); echo
> "\ndone\n";'
> 'some bar here'
> done
>
> $ php8.1 -r 'var_export(preg_replace("/foo/", "bar", "some foo here")); echo
> "\ndone\n";'
> PHP Warning: preg_replace(): Compilation failed: unrecognised compile-time
> option bit(s) at offset 0 in Command line code on line 1
> NULL
> done
>
> The php7.4 command runs correctly and is what I would expect. The php8.1
> command generates a warning, as well as incorrect output.
>
>
> -- System Information:
> Debian Release: bookworm/sid
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages php8.1 depends on:
> ii libapache2-mod-php8.1 8.1.0~rc5-1
> ii php8.1-common 8.1.0~rc5-1
>
> php8.1 recommends no packages.
>
> php8.1 suggests no packages.
>
> Versions of packages php8.1-common depends on:
> ii libc6 2.31-17
> ii libffi8 3.4.2-3
> ii libssl1.1 1.1.1l-1
> ii php-common 2:76
> ii ucf 3.0043
>
> -- no debconf information
>
