I've been a Debian Developer since 2005 (qjb@debian.org), 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.

* Jay Berkenbilt <ejb@ql.org> [260811 14:23]:

Reassigning this to release.d.o, as qa.d.o is only the messenger.
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.

Hi Jay,

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

Oh, you're right -- I didn't catch that. I haven't touched that aspect of the qpdf build in years, so I'm not sure how it got in there to begin with. I'll have to scrutinize this.

Right. I don't want to do a major version bump...this isn't really an
ABI change to qpdf though it is an ABI change to the debian packaged
qpdf library binary. I'll either have to change the soname in the
debian package until my next version bump using a suffix or something
or else, well, I'm not sure actually. I guess in the meantime, I
should revert by uploading a 12.4.0.1~really-12.3.2 or something. It's
been years since I've had anything other than a completely routine
upload. Is this a sensible approach for now? I'll have to get to the
bottom of why non-QPDF symbols are sneaking in there with the symbol
version. Regarding the breadth of the map, that was set up ages ago,
and at the time, the advice I was given by the release team was to do
something broad like that because trying to deal with real symbols
with C++ name mangling is very complex. That said, I can automate it
in some way. (I am upstream also BTW.)

We also had changes in the toolchain since the upload of 12.3.2-1. If
this aspect did not change in qpdf, this could also be change in the
toolchain. So before suggesting any actions, I would like to understand
where it is coming from. A rebuild of 12.3.2 may suffer the same issue.

Cheers

It may be a couple of days before I can dig into this, but I'll try to
find time as soon as possible. I have automation in CI for qpdf that
dumps the symbols and compares so that accidental ABI breakage is
supposed to be impossible. I may filter on standard library, so I may
have shot myself in the foot. I will be able to tell for sure though
whether a local build of 12.3.2 and 12.4.0 on the same system behave
correctly with respect to exported symbols. Right now, if I determine
that I have accidentally done something to make this get tagged and it
disappeared, I'll do something to make it reappear and fix it for real
with qpdf 13.0.0. If it turns out to be a debian toolchain issue, I'll
stand by. I'll reply to this bug report when I have some information,
and if I determine that it's my mistake and I can fix it, then I'll
upload a fix and close the bugs in the changelog.

I'll report back soon either way. Thanks!

* Jay Berkenbilt <ejb@ql.org> [260811 17:26]:

[..]
[..]

Indeed rebuilding qpdf 12.3.2-1 in unstable causes _M_replace and
other (weak) symbols to disappear from @LIBQPDF_30.

Best,
Chris

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

Cheers

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

Nothing has changed. Have the rebuilds been scheduled? I don't see evidence of cups having been rebuilt. Thanks.

https://buildd.debian.org/status/package.php?p=libcupsfilters&suite=sid
and others. We are still waiting for some builds to be completed. When
all of them are done, I'll hint qpdf into testing.

Cheers