Your message dated Wed, 12 Aug 2026 10:30:42 +0200
with message-id <[email protected]>
and subject line Re: Bug#1144127: qa.debian.org: qpdf package transition
blocked by outdated binary packages
has caused the Debian Bug report #1144127,
regarding qa.debian.org: qpdf package transition blocked by outdated binary
packages
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1144127: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1144127
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: qa.debian.org
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.
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.
--- End Message ---
--- Begin Message ---
On 2026-08-11 17:51:09 -0400, Jay Berkenbilt wrote:
>
>
> On Tue, Aug 11, 2026, at 3:04 PM, Sebastian Ramacher wrote:
> > > [...]
> > >
> > > So then this sounds like a toolchain issue on the debian side? Come to
> > > think of it, when I released 12.3.2, there was some churn on the
> > > toolchain, and I was unable to build in my local chroot -- binutils
> > > had been updated about four hours earlier. I waited a few days and
> > > tried again, and it was successful...but perhaps my previous upload
> > > was timed poorly, and I got stuck with a tooling issue.
> > >
> > > If I'm reading your response correctly, the solution would be to
> > > rebuild qpdf's downstream dependencies perhaps a rebuild 12.3.2 and
> > > then see if the 12.4.0 transition is able to go? Let me know if
> > > there's anything I need to do on my side. Thanks for the quick
> > > responses in looking into this issue.
> >
> > Could you check whether libqpdf30 in stable exported the std:: symbols
> > with @LIBQPDF_30? Thanks
>
> It is not exported on stable, only on testing, based on the test below:
>
> Output of this:
>
> objdump -T /usr/lib/x86_64-linux-gnu/libqpdf.so.30 | grep
> _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm
>
> stable:
>
> root@b5ea4aa75427:/# objdump -T /usr/lib/x86_64-linux-gnu/libqpdf.so.30 |
> grep _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm
> 0000000000000000 DF *UND* 0000000000000000 (GLIBCXX_3.4.21)
> _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm
>
> testing:
>
> root@76d76b9a021d:/# objdump -T /usr/lib/x86_64-linux-gnu/libqpdf.so.30 |
> grep _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm
> 00000000000c9150 w DF .text 0000000000000134 LIBQPDF_30
> _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm
>
> unstable:
>
> root@a539b0c8067e:/# objdump -T /usr/lib/x86_64-linux-gnu/libqpdf.so.30 |
> grep _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm
> 0000000000000000 DF *UND* 0000000000000000 (GLIBCXX_3.4.21)
> _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm
Thanks for checking. So that build system of qpdf is working as expted
but the toolchain produced broken results. I have scheduled rebuilds of
packages that link the template instantations with the LIBQPDF_30 symbol
version in unstable. I am closing this bug. If qpdf remains unable to
migrate after the rebuild and reruns of the autopkgtests, please let us
know.
Cheers
--
Sebastian Ramacher
--- End Message ---
