Re: [Libcdio-devel] pycdio 0.18 missing symbols

[Rocky Bernstein]

On Mon, Jan 28, 2013 at 2:46 PM, Thomas Vander Stichele <
address@hidden> wrote:

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

That's what you said the last time :-)  Open a bug report and I'll try to
take a look when I can. Also, there's a separate mailing list for pycdio.



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