On Sat, 2014-08-09 at 11:49 +0200, Emilio Pozuelo Monfort wrote:
> Why is that? Did libpcre break the ABI without bumping the SONAME? Did it change
> something else in an incompatible way? Is that something supposed to be public
> and used by rdeps? Do we need stricter dependencies in rdeps to prevent breakage
> like this in the future?
pcre3 allows compiling regexes to another format. Sometimes that other
format changes, leading to crashes if the pcre3 versions that generate
it and interpret it are different enough. The apertium language packages
contain the compiled regex data.
http://sources.debian.net/src/apertium/3.1.0-2/apertium/apertium_re.cc?hl=39#L39
http://sources.debian.net/src/apertium/3.1.0-2/apertium/transfer_data.cc?hl=179#L179
I was thinking that pcre3 should provide virtual packages related to the
compiled regex format version they interpret and packages storing that
data could then depend on that, but I can't see any sort of version
number in the code for compilation.
http://sources.debian.net/src/pcre3/1:8.35-3/pcre_compile.c
Apparently libselinux has the same problem but it is able to fall back
on normal regexes because it stores both. It appears that a number of
packages access the compiled regex even though pcre_compile(3) calls it
"internal data" and saying that it returns "a private data structure". I
didn't check if any of them write the data to a file though but I would
guess that they do. The pcre_compile(3) manual page also warns about
this issue with crashes across versions:
Note that compiling regular expressions with one version
of PCRE for use with a different version is not
guaranteed to work and may cause crashes.
http://manpages.debian.org/man0/pcre_compile
http://codesearch.debian.net/search?q=pcre_fullinfo.*PCRE_INFO_SIZE
In any case, apertium is broken right now so those binNMUs are needed.
Some discussion from IRC:
<pabs> is there something wrong with PCRE recently? apertium seems to
segfault again in the pcre library. I seem to remember that last time
this happened it needed a rebuild
* pabs attempts a local rebuild
<pabs> hmm no luck
<KiBi> pcre rings sad bells
<KiBi> bigon and raphael discussed possible incompatible changes a few
days ago (2014-07-31)
<KiBi> they discuss the opportunity of opening a rc bug but I don't see
anyone opened by either of them on the src:pcre3 BTS view.
<KiBi> pabs: end of memory^Wlog excerpt
<pabs> ok, the fix for apertium seems to be just to rebuild all the
language packages - apertium-en-es etc
<pabs> hmm, what is this apertium-pcre2 virtual package...
<pabs>
https://packages.qa.debian.org/a/apertium-es-ca/news/20140712T171843Z.html
<pabs> I'll request a binNMU for the remaining ones
<pabs> hmm, how do I tell when a binNMU for a particular package
happened?
<SamB> pabs: build logs? look at the changelog.$arch file?
<pabs> good points
<bigon> pabs, KiBi: yes the binary format for pre-compiled regex has
changed and if your application is storing it on disk (like libselinux
does) it could go wrong
* pabs filed #757539 about that
-zwiebelbot/#debian-release- Debian#757539: nmu: apertium language
packages due to pcre3 update - https://bugs.debian.org/757539
<pabs> bigon: is there any way to know which packages need to be rebuilt
after a pcre3 update? just wait for crash reports?
<pabs> I wonder if pcre3 could Provides: pcre3-binary-format-X and
packages storing the format could depend on that
<bigon> mmmh I don't know actually, for what I understood for
libselinux, the onlything needed is to ignore the precompiled file if
the version has changed
<bigon> I was not aware that some pkg were requiring a binNMU
<pabs> apertium (automated written language translation software)
language packages definitely do
<bigon> so I'm not sure it's 100% related to what I was talking the
other day
<pabs> hmm, ok
<bigon> pabs: oh, yes these pkg includes some .bin files
<bigon> so yes maybe related to the format change
<bigon> the problem is I've no clue if the internal representation of
pcre was ever supposed to be stable
<pabs> hmm
<bigon> libselinux has added some kind of headers in the file and they
patched it to add the libpcre version used to generate it
--
bye,
pabs
http://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part