Bug#1144127: qa.debian.org: qpdf package transition blocked by outdated binary packages

* Jay Berkenbilt <[email protected]> [260811 17:26]:
>On Tue, Aug 11, 2026, at 11:03 AM, Sebastian Ramacher wrote:
>> On 2026-08-11 10:48:05 -0400, Jay Berkenbilt wrote:
>> > On Tue, Aug 11, 2026, at 10:32 AM, Sebastian Ramacher wrote:
>> > > On 2026-08-11 16:01:02 +0200, Chris Hofstaedtler wrote:
>> > > > I'm not the expert, but  the libcupsfilter log says:
>> > > > https://ci.debian.net/packages/libc/libcupsfilters/testing/arm64/74208469/
>> > > > /usr/bin/aarch64-linux-gnu-ld.bfd: /usr/lib/gcc/aarch64-linux-gnu/15/../../../aarch64-linux-gnu/libcupsfilters.so:
>> > > > undefined reference to `std::__cxx11::basic_string<char,
>> > > > std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long,
>> > > > unsigned long, char const*, unsigned long)@LIBQPDF_30'
>> > >
>> > > These symbols should have never existed in the first place. These are
>> > > symbols from template instantiations of the standard library that
>> > > shouldn't have gained a LIBQPDF_30 symbol version. Did upstream clean up
>> > > their build system to no longer export those symbols with that symbol
>> > > version?

[..]

>> > Right. I don't want to do a major version bump...this isn't really an
>> > ABI change to qpdf though it is an ABI change to the debian packaged
>> > qpdf library binary. I'll either have to change the soname in the
>> > debian package until my next version bump using a suffix or something
>> > or else, well, I'm not sure actually. I guess in the meantime, I
>> > should revert by uploading a 12.4.0.1~really-12.3.2 or something. It's
>> > been years since I've had anything other than a completely routine
>> > upload. Is this a sensible approach for now?
[..]

>> We also had changes in the toolchain since the upload of 12.3.2-1. If
>> this aspect did not change in qpdf, this could also be change in the
>> toolchain. So before suggesting any actions, I would like to understand
>> where it is coming from. A rebuild of 12.3.2 may suffer the same issue.
>
>It may be a couple of days before I can dig into this, but I'll try to
>find time as soon as possible. I have automation in CI for qpdf that
>dumps the symbols and compares so that accidental ABI breakage is
>supposed to be impossible. I may filter on standard library, so I may
>have shot myself in the foot. I will be able to tell for sure though
>whether a local build of 12.3.2 and 12.4.0 on the same system behave
>correctly with respect to exported symbols. Right now, if I determine
>that I have accidentally done something to make this get tagged and it
>disappeared, I'll do something to make it reappear and fix it for real
>with qpdf 13.0.0. If it turns out to be a debian toolchain issue, I'll
>stand by. I'll reply to this bug report when I have some information,
>and if I determine that it's my mistake and I can fix it, then I'll
>upload a fix and close the bugs in the changelog.

Indeed rebuilding qpdf 12.3.2-1 in unstable causes _M_replace and 
other (weak) symbols to disappear from @LIBQPDF_30.

Best,
Chris