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

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'

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