Jay Berkenbilt <q...@debian.org> wrote: >> I have been able to reproduce the problem locally. It doesn't look like >> the result of an ABI change. I have yet to determine for sure whether >> the problem is in libqpdf or whether it's in pdftopdf, but I'm assuming >> libqpdf until I prove otherwise. I will refrain from posting again >> until I have something more definitive to say. > > Well, it does look like it must be an ABI change, though I can't yet > figure out how as I'm looking very carefully at the bad commit and don't > see anything that should constitute an ABI change. However, I can > reproduce it now using only qpdf by doing a trivial operation, linking > with the old library and then running with the new one. If I can't > figure it out fast, I'll bump the soname and do a new release. I will > also add a stronger check for ABI changes as part of my release > checklist since I apparently don't have as complete a picture in my mind > as I thought I did about what constitutes an ABI change.
I have reverted the ABI change, and unfortunately the bug fix that caused it, and have uploaded a new version to unstable. Since the ABI breakage was only in unstable for a few days and qpdf doesn't have very many reverse dependencies, I think it should be okay to just rebuild any package that built with 4.2.0-1 once 4.2.0-2 hits the archive in a few minutes. I will also upload 5.0.0-1 to experimental to get it through NEW. That will include a bumped soname, acknowledging the ABI change, and will require bin-nmus of reverse dependencies. I still don't know what about the change caused the ABI to break, but I will figure it out or at least build into my testing procedures something that will prevent me from repeating this error. -- Jay Berkenbilt <q...@debian.org> -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
