Re: [Libcdio-devel] pycdio 0.18 missing symbols

[Thomas Vander Stichele]

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.

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.


> 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/