Closed Matt07211 closed 6 years ago
A little digging, I figured out that pycdio didn't support the newer versions of libcdio by my system. I came to the conclusion from the following info.
I first symlinked the libcdio.so to libcdio.so.16 for testing
sudo ln -s /usr/lib64/libcdio.so /usr/lib64/libcdio.so.16
I then re-ran whipper
$ whipper cd rip -p -U --track-template='%A/(%y) %d/%t. %n' --disc-template='%A/(%y) %d/%A - %d'
Traceback (most recent call last):
File "/usr/bin/whipper", line 11, in <module>
load_entry_point('whipper==0.6.0', 'console_scripts', 'whipper')()
File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 572, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2755, in load_entry_point
return ep.load()
File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2408, in load
return self.resolve()
File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 2414, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/usr/lib/python2.7/site-packages/whipper-0.6.0-py2.7.egg/whipper/command/main.py", line 11, in <module>
from whipper.command import cd, offset, drive, image, accurip, debug
File "/usr/lib/python2.7/site-packages/whipper-0.6.0-py2.7.egg/whipper/command/cd.py", line 22, in <module>
import cdio
File "/usr/lib/python2.7/site-packages/cdio.py", line 20, in <module>
import pycdio
File "/usr/lib/python2.7/site-packages/pycdio.py", line 25, in <module>
_pycdio = swig_import_helper()
File "/usr/lib/python2.7/site-packages/pycdio.py", line 24, in swig_import_helper
return importlib.import_module('_pycdio')
File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
ImportError: /usr/lib64/libcdio.so.16: version `CDIO_16' not found (required by /usr/lib/python2.7/site-packages/_pycdio.so)
I noticed the pycdio expected and tried to verify the version of libcdio, and since the above test failed I removed the symlink and updated pycdio to the newest version (2.0, but the README suggests 0.20...)
Collecting pycdio
Downloading pycdio-2.0.0.tar.gz (242kB)
100% |████████████████████████████████| 245kB 39kB/s
Installing collected packages: pycdio
Found existing installation: pycdio 0.20
Uninstalling pycdio-0.20:
Successfully uninstalled pycdio-0.20
Running setup.py install for pycdio ... done
Successfully installed pycdio-2.0.0
I have now re-run the whipper command and all seems good so far (disc is currently ripping).
OK. We should check if the API changes for the newer pycdio. If so, we can support both for a while, but suggest the newer package. (Let's not jump now, since that might bite distros)
Please let us know of the outcome of that rip.
Everything looks like it should, ripped fine, no errors have showed up, I've been ripping a few discs since that last comment from me and nothing has exploded.
As for pycdio, https://git.savannah.gnu.org/cgit/libcdio/pycdio.git/ , this info may be of relavence
2018-01-25 rocky <rocky@gnu.org>
* .gitignore, README.txt, __pkginfo__.py,
admin-tools/how-to-make-a-release.md, cdio.py, setup.py,
swig/device.swg, swig/device_const.swg, swig/pyiso9660.i,
test/test-cdio.py: Ready for Release 2.0.0 * Update API to 2.0.0. Assume version 2.0.0 or greater of libcdio. * remove old compatibilty code. * Update usual Python administrivia and package info.
The Travis builds are currently broken, and this version bump seems a likely suspect.
First breakage: https://travis-ci.org/JoeLametta/whipper/jobs/338013828
So if libcdio >= 18 use pycdio 2.00 Else libcdio <18 use pycdio 0.20, correct?
So what's the correct way of handling this moving forward, just documenting it in the readme?
This is already documented in the README:
to avoid bugs please use pycdio 0.20 & libcdio >= 0.90 or, with previous libcdio versions, pycdio 0.17
This was added more than a year ago, maybe updated version information needs to be put there. (Though be careful when you talk about "libcdio >= 18", because I think you are talking about the soname version number, which is not at all the same as the libcdio project version number.)
Yea, I probably was using soname but it definitely seemed to correlate to the actual software version so...
Either way, the readme does need to be update to make mention that newer versions of libcdio wont work nicely with the 0.20 version of pycdio.
OK. We should check if the API changes for the newer pycdio.
It does but I'm not sure we're affected (a section of libcdio's NEWS
file):
2017-12-31 version 2.0.0
This release bumps library version numbers and bumps the
major release number. We should have gone from 1.0.0 to 2.0.0
in the last release since there is an API incompatability.
In addition...
- Add NetBSD drive detection; correct drive detection in cd-info.c
Patches from Onno van der Linden
- Fix some MinGW and Windows portability issues
- Remove some memory leaks in some tests
- Lint (a little) with clang static analyzer
There are some programs and bindings that will need to be updated
if you want to use them with this library. Specifically:
- Device::Cdio (2.0.0 or greater)
- vcdimager (2.0.0 or greater)
- pycdio (2.0.0 or greater)
- rbcdio (2.0.0 or greater)
2017-12-10 version 1.1.0 Dr. Gecko
Caveats:
pycdio and Deveice::Perl will be broken but that'll be fixed later
- Remove many remaining memory leaks, invalid
reads, writes (as per valgrind) in library,
test and demo code
- Types CdioISO9660{Dir,File}List_t, have been added
and iso9660_{dir,file}list_{new,free} have been added.
- cdio_list_free() now takes an additional parameter: a function to
free list items. This is not compatible with 1.0.0
More work is needed on MacOS and other OS's where I don't have
valgrind accessible.
AIX is left untouched - that is probably heading for removal in the
future.
2017-11-21 version 1.0.0 Thanksgiving
This is an API breaking change
- Remove deprecated items:
* OS/2 driver (never really was supported)
* BSDI driver remnants
* mmc_isrc_track_read_subchannel
* CDIO_MIN_DRIVER, CDIO_MIN_DEVICE_DRIVER, CDIO_MAX_DRIVER, CDIO_MAX_DEVICE_DRIVER
* CdioList, CdioListNode
- Apple Darwin OS X -> macOS
- Subdir objects breaks symbol versioning. See https://savannah.gnu.org/bugs/?49907
- Handle bad iso 9660 better. Fixes Savannah bug https://savannah.gnu.org/bugs/?52091
- Apple (High) Sierra compatiablity
- NetBSD patches
- Fixes for Rock Ridge SUSP (Thomas Schmitt)
- Reduce MinGW compilation warnings
- Add asserts to test memory allocations and misc bug fixes (Pete Batard)
- Enable CD drivers on current and future versions of FreeBSD and macOS,
so we do not have to add every new OS version explicitly. (Robert Kausch)
- Cross-compiling friendliness (Ozkan Sezer)
- Small texinfo doc fixes (Wieland Hoffmann)
- Simplify making doc from autogen.sh
- Bug fix for https://savannah.gnu.org/bugs/?45015 (Thomas Schmitt)
- Bug fixes for #45017,#52265, and #52264
- Add more compiler warning flags, i.e. -Wshadow, -Wundef, ...
- Reduce numerous memory leaks (more though remain)
libcdio-paranoia's last release seems to be still based upon libcdio 0.94
.
Quick grep (find command was taking to long...) of /usr indicates that I do have the libcdio.so liibrary, but a newer version that what the program is looking for.
OS: Solus Python 2.7.14