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. > > > -- Sebastian Ramacher
