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

Hi Jay,

On 2026-08-11 16:01:02 +0200, Chris Hofstaedtler wrote:
> Control: reassign -1 release.debian.org
> 
> * Jay Berkenbilt <[email protected]> [260811 14:23]:
> > Package: qa.debian.org
> 
> Reassigning this to release.d.o, as qa.d.o is only the messenger.
> 
> > Severity: important
> > X-Debbugs-Cc: [email protected], [email protected]
> > 
> > I've been a Debian Developer since 2005 ([email protected]), but for many
> > years, I've been maintaining only qpdf, for which I am also upstream.
> > I apologize if I have just forgotten or overlooked some standard
> > process here.
> > 
> > Tl;Dr: libcupsfilters and r-cran-qpdf are blocking transition of qpdf,
> > and I think the resolution is to just rebuild them. This is not an
> > issue of ABI breakage in qpdf itself.
> > 
> > Justification for important: the result of this issue is that printing
> > breaks for people on unstable when the install the latest qpdf. See
> > bugs 1144072 and 1144111.
> > 
> > In the latest upstream release, qpdf started using C++-20 features
> > internally, while the API remains C++-17-compatible. With the upload
> > of 12.4.0-1 to unstable, several regressions were introduced:
> > 
> > https://qa.debian.org/excuses.php?package=qpdf
> > 
> > These are for packages whose binary packages haven't been built
> > recently enough to link with a C++ library that contains all the C++
> > functions. In particular, the builds are failing because this symbol
> > is not found:
> > 
> > std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::_M_replace(unsigned long, unsigned long, char const*, unsigned long)
> > 
> > This is an overload of std::string::replace that was introduced in
> > C++-20.
> 
> 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?

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.

Cheers

> 
> Note the @LIBQPDF_30 suffix - this is not a symbol that never existed. This
> symbol did exist, but disappeared!
> That sounds like real ABI breakage.
> 
> > My recollection is that this situation should automatically trigger
> > binary NMU (or rebuild or whatever it is these days) of the binary
> > packages, currently libcupsfilters and r-cran-qpdf, but it's been a
> > couple of days since upload, so I'm not sure if I have to do something
> > to poke this.
> > 
> > Please let me know:
> > * If I just waited, would this "automatically" resolve?
> > * If I have to poke, is this the right place to poke?
> > * Have I misdiagnosed this? If so, I can create a patch that removes
> >  the C++-20 call, but I don't think it should be necessary to do
> >  that. I plan on introducing additional C++-20 calls in upcoming qpdf
> >  versions.
> > 
>