Re: [Libcdio-devel] pycdio 0.18 missing symbols

[Thomas Vander Stichele]

> > > >   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 <address@hidden> 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/