Hey, I have been lurking following the progress on this since I discovered this bug reported on gvfs-backends https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886278 which I traced back to libcdio.
And yes, as I commented there, the solution seems to get 2.0.0 out. > As I look at Debian packages for libcdio, I think it is early enough in > the packaging of the 1.x that changing to 2.0 rather than 1.x wouldn't be a > big deal. Right? 1.0.0 has already been packaged, and from what I can see from the NEWS file, the ABI changed twice between 1.0.0 and 2.0 (once to 1.1 and then again to 2.0), which AFAIK means it needs a transition to recompile dependent programmes on the new version. http://git.savannah.gnu.org/cgit/libcdio.git/tree/NEWS?id=908ec296cdffbee8bfe9ff9196caa13a49262b91 Matthias Klose, whom I have CC'ed here, uploaded 2.0.0 to experimental on the 30th January, which auto-generated the transition tracker for this: https://release.debian.org/transitions/html/auto-libcdio.html I don't know the current state of play, Matthias Klose stated back in November 2017 that they were orphaning libcdio but still doing the then current transition, i.e. from 0.83 (libcdio13) to 0.94 (libcdio16), and they did the Ubuntu transition as well which they did before getting the all clear to begin the transition from experimental to unstable. No transition was needed from 0.94 to 1.0.0 as there was no ABI change. I would offer to take take over the orphaned package, but I don't know how much time it would take (I have very little time at the moment), and I know almost nothing about packaging, so far only working on upstream projects in python. The current Ubuntu transition exists here, but the Ubuntu transitioning process seems even more unclear than the Debian one: http://people.canonical.com/~ubuntu-archive/transitions/html/html/libcdio.html Okay, that documents everything I know so far about the status of this. Best, Jack
