> > > > File "/usr/lib64/python2.7/site-packages/pycdio.py", line 411, in > > > > <module> > > > > CDTEXT_ARRANGER = _pycdio.CDTEXT_ARRANGER > > > > AttributeError: 'module' object has no attribute 'CDTEXT_ARRANGER'
My final two cents on this on this list. - pycdio.py in 0.18 *always* does CDTEXT_ARRANGER = _pycdio.CDTEXT_ARRANGER no matter what the version of libcdio - _pycdio.so contains CDTEXT_ARRANGER if libcdio is pre-0.90 and CDTEXT_FIELD_ARRANGER if libcdio is 0.90 - hence, pycdio.py 0.18 simply cannot be imported if it was built against libcdio 0.90 I originally thought it might have been my fault or Fedora's (because I prefer to blame from inwards out, starting with me, and because I was under the impression that it worked on Ubuntu based on reports). But in fact: - this doesn't work in fedora rawhide - according to my user's reports, the same problem exists in ArchLinux - Debian and Ubuntu don't even package pycdio at all; the users that had reported the issue of MIN_VER and had built pycdio from source against a 0.83 libcdio package (so they had an importable pycdio.py) Feel free to point out if I misread anything in the code; from my current reading it looks like pycdio 0.18 simply cannot be used with libcdio 0.90 Thomas > > > > >>> > > > > > > > > Apparently it's now CDTEXT_FIELD_ARRANGER in _pycdio ? > > > > > > > > Any idea why things are like this? > > > > > > > > > > My suggestion is to start *reading* libcdio-devel rather than merely > > using > > > as a public forum for griping. > > > > I'm not sure why you're taking offense? I'm not griping, I'm merely > > reporting something fishy. pycdio.py as shipped and packaged by Fedora > > tries to access _pycdio.CDTEXT_ARRANGER which is simply not there. > > _pycdio is built using swig. > > > > Adrian Reber posted a while ago about this. Again, doesn't appear that you > noticed that. > > > > > > As I'd find it hard to believe that this would actually be a bug in your > > releases that went uncaught so far, I'm showing it to the list in case > > anyone knows > > a) what the name of the symbol is supposed to be in _pycdio > > b) whether pycdio.py is importing it wrong, or whether swig on Fedora > > Rawhide is building _pycdio wrong. > > > > If the list is not for sharing problems using libcdio, feel free to let > > me know. > > > > The developer list was intended for development discussions. There is a help > list <[email protected]> for how to use libcdio and there is a bug > tracker <https://savannah.gnu.org/bugs/?group=libcdio>bugs-like things. > > But if you are reporting a problem regarding packaging on a particular > distribution, then probably the distribution has a way to report problems. > > > > > > > > One thread discussing this can be find at > > > http://lists.gnu.org/archive/html/libcdio-devel/2012-02/index.html > > > > I went through all those threads again just now. I am assuming you are > > referring to: > > http://lists.gnu.org/archive/html/libcdio-devel/2012-02/msg00056.html > > > > It doesn't mention changes in the header symbols, or any other clues as > > to what may be wrong in pycdio or _pycdio. > > > > Before I originally mailed I had grepped the list archive for > > CDTEXT_FIELD and it came up empty. Maybe that's not enough due > > diligence before mailing? > > > > > > > One of the biggest problems in moving forward is that when the work goes > > on > > > and requests are made for comments and feedback there little or none. > > > Likewise, when I ask for people to try things out in advance of a release > > > (once a year) generally people and packagers don't. > > > > Sure. I'm a maintainer too. You're now using your own public forum for > > griping :) Everyone knows that it's hard to have people and packagers > > test (which is precisely why I became a packager of my own stuff in the > > first place). It sounds like you are frustrated about this, which I can > > understand. Just as I am frustrated that I did not have a crystal ball > > that said that CDText changes (which I do not use myself) would cause my > > limited use of pycdio to break. I'm not griping, I'm actively trying to > > report bugs and at the same time figure out what's going on. > > > > > > > > That's okay, but then when decisions are made and releases are cut, sorry > > > it's too late to change things. Either figure out how to use the old code > > > -- maybe you can petition in your endearing way that FC should have > > > compatibility libraries -- or fix your code to work with the new. > > > > As soon as I can figure out what I'm supposed to be fixing in my code, I > > will! After catching up on sleep, I will try and figure out why > > pycdio.py as shipped cannot find symbols in _pycdio.so. > > > > > > Thomas > > > > -- > > > > Ok, either I'm borrowing all your albums or I'm moving in. > > > > savon - Saving your work to svn > > https://apestaart.org/thomas/trac/ > > > > > > > > -- too tired to eat too hungry to sleep URGent, best radio on the net - 24/7 ! http://urgent.fm/
