The latest version of libdiscid is 0.2.1... http://musicbrainz.org/doc/libdiscid I'm willing to co-maintain if you like...
(In reply to comment #0) > The latest version of libdiscid is 0.2.1... > > http://musicbrainz.org/doc/libdiscid > > I'm willing to co-maintain if you like... Happy for you to co-maintain. However, I would ask that you test the update with picard (which is the other package that depends on libdiscid) before you push to stable. I'm not sure if has a specific API requirement and it seems that going from 0.1 to 0.2 there may be an API bump.
picard is mostly in python and it doesn't directly link in the libdiscid library (hence picard has an explict "Requires: libdiscid"). Also it seems that libdiscid doesn't export an soname so there would be no a priori way to know whether this will break API compatibility.
(In reply to comment #2) > picard is mostly in python and it doesn't directly link in the libdiscid library > (hence picard has an explict "Requires: libdiscid"). Also it seems that > libdiscid doesn't export an soname so there would be no a priori way to know > whether this will break API compatibility. Yeah, I've been looking at both picard and python-musicbrainz2. Neither is linked directly to libdiscid but they use python-ctypes to dynamically load 'libdiscid.so.0' - of course libdiscid 0.2.1 bumped the soname to .1. The only ABI changes that I can see are an additional function, the signatures of the existing functions is unchanged. It's a fairly simple patch to get picard and python-musicbrainz2 to look for either soname, but I ran out of time to patch/test picard before I left work. I'll probably get to it later tonight.
What's the status of this at the moment? FYI I just updated picard to 0.10 in rawhide (see bug #460752) and about to do so for F-9 and F-8.
I was thinking if we do need to patch picard for this change, it would be nice to roll the patch for picard into an update (and including the libdiscid version bump in the bodhi push to updates-testing so all go out at the same time).
(In reply to comment #3) > Yeah, I've been looking at both picard and python-musicbrainz2. Neither is > linked directly to libdiscid but they use python-ctypes to dynamically load > 'libdiscid.so.0' - of course libdiscid 0.2.1 bumped the soname to .1. The only > ABI changes that I can see are an additional function, the signatures of the > existing functions is unchanged. It's a fairly simple patch to get picard and > python-musicbrainz2 to look for either soname, but I ran out of time to > patch/test picard before I left work. I'll probably get to it later tonight. It's been a while... so... ping? Is it safe to update libdiscid? (It will require a rebuild of libmusicbrainz3 which does compile against a specific soname).
Sorry it's been a while since I updated this. I just saw that there is now a version 0.2.2: > libdiscid-0.2.2: > > - Set libtool version number to 2:1:2 because it is backwards compatible > with versions 0.1.x. Thanks to Luks for spotting this. So it seems we can update to 0.2.2 and not worry about patching picard or rebuilding libmusicbrainz3.
(In reply to comment #7) > Sorry it's been a while since I updated this. I just saw that there is now a > version 0.2.2: > > > libdiscid-0.2.2: > > > > - Set libtool version number to 2:1:2 because it is backwards compatible > > with versions 0.1.x. Thanks to Luks for spotting this. > > So it seems we can update to 0.2.2 and not worry about patching picard or > rebuilding libmusicbrainz3. OK, thanks, but that it implies it might be API-compatible (i.e. doesn't require any code patches), but may not be ABI-compatible (i.e. libmusicbrainz3 would still require a rebuild). Can you check locally? Then I can do an update/push.
Did a rawhide build: https://koji.fedoraproject.org/koji/buildinfo?buildID=72251 and it seems to export libdiscid.so.0 and so doesn't break libmusicbrainz3 AFAICT. Will check compatibility with picard locally here and then push to bodhi. From the ChangeLog it looks like most the changes since 0.1.x are pretty much Windows or other operating-system specific in any case.
libdiscid-0.2.2-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/libdiscid-0.2.2-1.fc10
picard with 0.2.2 seems to work fine.
libdiscid-0.2.2-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/libdiscid-0.2.2-1.fc9
libdiscid-0.2.2-1.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/libdiscid-0.2.2-1.fc8
libdiscid-0.2.2-1.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update libdiscid'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-10572
libdiscid-0.2.2-1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update libdiscid'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-10690
libdiscid-0.2.2-1.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update libdiscid'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-10702
Jeffrey: these work fine for me. Can you test them with picard on your system and if all is well (feel free to karma +1 on bodhi), then I'll push them to stable.
libdiscid-0.2.2-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
libdiscid-0.2.2-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
libdiscid-0.2.2-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.