Hi Frank, Tony, Thanks for the quick replies.
Frank, you're right that code compiled against the 6.15 headers works, since those members are now generated inline. The problem is binaries that were already built against 6.11 headers, like filtermail 1.07.01-1 currently in unstable: they still reference the out-of-line symbols, and 6.15 no longer exports them, so they fail at startup. Bumping filtermail's Build-Depends alone won't fix that. It only takes effect when filtermail is rebuilt, and even then nothing stops apt from upgrading libbobcat6 while keeping an old filtermail binary. I think what's needed is: - binNMUs of the libbobcat6 reverse dependencies against 6.15.01 (at least filtermail; the others only work today because ~Pattern() happens to still be exported, and with -flto=auto, as in Ubuntu, flexc++, bisonc++, gpg-remailer, oxref and stealth break too) - Breaks: on the pre-binNMU versions in libbobcat6, e.g. filtermail (<< 1.07.01-1+b1) - the symbols file in the same upload, to catch this in the future (A soname bump would also work, if you prefer that route.) Thanks, Sebastien On Wed, 7 Oct 2026 at 09:28, Frank Brokken <[email protected]> wrote: > Dear Tony Mancill, you wrote: > > > > Hello Sebastian, > > > > Thank for the detailed bug report. I will work with the upstream author > > to add the symbols file and the binNMU. > > > > On Mon, Oct 05, 2026 at 11:18:52PM +0200, Sebastien Bacher wrote: > > > Package: libbobcat6 > > > Version: 6.15.01-1 > > > Severity: serious > > > Justification: Policy 8.6.2 (ABI change without soname bump), breaks > > > filtermail > > > Control: affects -1 filtermail > > > And, Sebastian, of course, also thank you from my side :-) > > Indeed, you're right: the mentioned Pattern members aren't mentioned in the > recent bobcat version. Mainly because in bobcat 6.13.00 a segfault when > using > static Pattern objects was fixed, and the Pattern members you mentioned > > > > FBB::Pattern::Pattern(FBB::Pattern&&) > > > FBB::Pattern::operator=(FBB::Pattern&&) > > > FBB::Pattern::operator=(FBB::Pattern const&) > > > FBB::Pattern::copy(FBB::Pattern const&) > > > FBB::Pattern::destroy() > > are, because of that, available by default. E.g., the following program > runs > OK and shows 'matched' twice: > > #include <iostream> > #include <string> > > #include <bobcat/pattern> > > using namespace std; > using namespace FBB; > > int main(int argc, char **argv) > { > Pattern hello("^hello"); > > Pattern hello2; > hello2 = hello; > > Pattern hello3{ move(hello) }; > Pattern hello4; > hello4 = move(hello2); > > string hw{"hello world"}; > > if (hello3 << hw) > cout << "matched\n"; > > if (hello4 << hw) > cout << "matched\n"; > } > > Also, valgrind reports: > > ==2899== HEAP SUMMARY: > ==2899== in use at exit: 0 bytes in 0 blocks > ==2899== total heap usage: 130 allocs, 130 frees, 93,524 bytes > allocated > ==2899== > ==2899== All heap blocks were freed -- no leaks are possible > ==2899== > ==2899== For lists of detected and suppressed errors, rerun with: -s > ==2899== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > > But what's clearly wrong is that the required version of libbobcat-dev in > filtermail's control file is still at 6.11.00: > > Build-Depends: ... > libbobcat-dev (>= 6.11.00), > ... > > So I propose to update libbobcat-dev's version in filtermail's control file > instead of adding members that are already available by default in > libbobcat's > version 6.15.01. Software using bobcat's Pattern class might need > recompilation when linking to 6.15.01 and should, after that, work as > before. > > And, of course, an new bobcat version (6.15.01) can then add the symbols > file. > > Is that an option? > > -- > Frank B. Brokken > (+31) 6 5353 2509 > Public PGP key ID: D33B 84A5 F9C5 54FA F193 E972 F612 0FE2 3B50 D0C5 >
