On Sun, Jan 27, 2013 at 8:36 PM, Thomas Vander Stichele < [email protected]> wrote:
> Hi Rocky, > > > > 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' > > > >>> > > > > > > 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/ > > > >
