Re: [Libcdio-devel] pycdio 0.18 missing symbols

[Rocky Bernstein]

On Sun, Jan 27, 2013 at 8:36 PM, Thomas Vander Stichele <
address@hidden> 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 <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/
>
>
>
>