Hi, On Thu, Jun 08, 2023 at 08:34:00PM +0200, Paul Gevers wrote: > > > > sure, but the package itself has not changed. I think without > > tests we could't have discovered this. > > Sure. That's very common with c-libraries that change their ABI but not > their API. The SONAME of the library gets bumped, the package maintainer > ships a new binary package (which matches the SONAME), our tooling detects > that and we can schedule rebuilds. You *seem* to be in a similar situation, > except there was no SONAME bump involved, our tooling didn't detect it and > everything went unnoticed until now.
I see, > I guess > https://www.debian.org/doc/debian-policy/ch-sharedlibs.html and maybe > https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#libraries > can be good reads. thanks, I'm going to review these. > > libnginx-mod-http-modsecurity uses one of the PCRE packages: the > > OLD PCRE, or the NEW, PCRE2 library. > > > > This is decided when we compile the source. > > Again sounds not uncommon. But apparently either nginx or libmodsecurity3 > changed it's ABI as a result of that, which broke the reverse dependencies > that weren't rebuild. I understand. > > As I wrote above, libnginx-mod-http-modsecurity does not have any > > control options to decide which PCRE version wants to use, but > > during the compile time it sets the symbols. > > > This is why it compiled to use the OLD PCRE, but not the Nginx, > > neither the libmodsecurity3 don't use it. > > > > Hope now it's clear - let me know if I can help you in this. > > I'm not a library expert, but this really, really looks wrong to me. do you have any opinion, how could be it fixed? I do not participate in development of Nginx, but in libmodsecurity3. Is there anything what we can do there? > > > Raise the severity of the bug and document it in the release notes. > > > > Sorry for the dumb question, but in which release notes do I need > > to document? > > https://www.debian.org/releases/bookworm/releasenotes which has its source > here: https://salsa.debian.org/ddp-team/release-notes/ thanks, > > uhm, that's a bad news. > > > > How can we fix it in unstable? > > Figure out what went wrong. I expect a new library package needs to be > uploaded (please use experimental for that). Once that's done, a transition > can be requested, see https://wiki.debian.org/Teams/ReleaseTeam/Transitions many thanks. > > Because it is decided at compile time. > > One the transition is ACK'ed the rebuild will be scheduled by the release > team. okay. > > https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/CHANGES#L6 > > https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/src/ngx_http_modsecurity_module.c#L41 > > > > The ABI isn't changed, but the code itself was aligned to > > Nginx. > > I a symbol is dropped, that means a break in the ABI. ah, I think I see the point now. > > I guess you remember my last e-mail in connection with > > libapache2-mod-security issue: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037024 > > > > This situation is similar: there is a dependency (there: libapr1, > > here: Nginx), which changed the version since the affected > > package (there: modsecurity-apache, here: > > libnginx-mod-http-modsecurity) but here the dependent package > > changed the 3rd-party library, which has a hard effect for the > > package in subject. > > That situation was different (at least from the symptoms). The problem there > was that it was emitting a *warning*, nothing broke. The warning is bad but > not a real problem. Missing symbols is a problem. sure, I got it. > > I hope I could help to understand the situation. > > I hope you can figure out more what's wrong. We can't really fix it properly > otherwise. yes, now I see - many thanks for your help. a.
