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

On 2026-08-11 10:48:05 -0400, Jay Berkenbilt wrote:
> 
> 
> On Tue, Aug 11, 2026, at 10:32 AM, Sebastian Ramacher wrote:
> > Hi Jay,
> > 
> > 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?
> 
> Oh, you're right -- I didn't catch that. I haven't touched that aspect of the qpdf build in years, so I'm not sure how it got in there to begin with. I'll have to scrutinize this.
> 
> > qpdf/libqpdf.map.in still seems to broad so that I think this
> > still needs some work upstream first to only apply the symbol version to
> > the actual symbols from libqpdf.
> 
> 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? I'll have to get to the
> bottom of why non-QPDF symbols are sneaking in there with the symbol
> version. Regarding the breadth of the map, that was set up ages ago,
> and at the time, the advice I was given by the release team was to do
> something broad like that because trying to deal with real symbols
> with C++ name mangling is very complex. That said, I can automate it
> in some way. (I am upstream also BTW.)

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.

Cheers