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

On 2026-08-11 13:56:48 -0400, Jay Berkenbilt wrote:
> 
> 
> On Tue, Aug 11, 2026, at 12:35 PM, Chris Hofstaedtler wrote:
> > * 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
> 
> So then this sounds like a toolchain issue on the debian side? Come to
> think of it, when I released 12.3.2, there was some churn on the
> toolchain, and I was unable to build in my local chroot -- binutils
> had been updated about four hours earlier. I waited a few days and
> tried again, and it was successful...but perhaps my previous upload
> was timed poorly, and I got stuck with a tooling issue.
> 
> If I'm reading your response correctly, the solution would be to
> rebuild qpdf's downstream dependencies perhaps a rebuild 12.3.2 and
> then see if the 12.4.0 transition is able to go? Let me know if
> there's anything I need to do on my side. Thanks for the quick
> responses in looking into this issue.

Could you check whether libqpdf30 in stable exported the std:: symbols
with @LIBQPDF_30? Thanks

Cheers