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
signature.asc
Description: This is a digitally signed message part
