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.
