Created attachment 138997 [details]
Updated specfile

Created attachment 138998 [details]
Patch to remove non-core eyeD3 dependency

libgpod python bindings are useless without python-eye3D. 
I've built your package, but when you try to import gpod module in a python
console., it will fail.

Bah, I missed a little bit in the patch.  Sorry about my lack of attention to
detail on that.

The last few lines in __init__py need to be removed to get rid of the ipod.py
dependency.  Nick Piper is working on a more pythonic interface to libgpod,
which is what depends on eyeD3.  I'm not sure how far along the newer interface
is or how many people are using it.

After thinking about this more, perhaps it's simply better to not build the
python bindings at all?  They could perhaps be built as a package for extras
since python-eyeD3 is provided there?

Alternatively, I could remove the last few traces of the newer ipod interface
and still build the bindings.

Thoughts?

FYI 0.4 is now in core-development... but the python binding are still not being
built in either core nor extras-development.

Is anyone in contact with the maintainer(s) for libgpod in Core at the moment?
Is there an active maintainer for this package or is it essentially in limbo in
Core?

Matthias Clasen is listed as the last person to touch the package in Core
development, but I'm not sure if he's the primary maintainer or not.

There needs to be some consensous agreement as to how to handle the python
bindings. Do they need to be built as part of Core or Extras at the moment?

And there needs to be some consensous concerning wtf to do about updating
libgpod in fc6/fc5.   Since application functionality in Extras is being
affected by the age of this library, the packaging community needs some explicit
guidance as to what the Core maintainer(s) are willing to do about updating.

-jef

No, I'm not the primary maintainer. See my comment in the other bug about the
python bindings. They were not needed when we pulled libgpod in as a rhythmbox
dependency.  If they are in fact needed by extras apps, then we should package
them as a subpackage. 

However, earlier comments in this bug seem to indicate that the python bindings
need some other python modules which are not in core ? Maybe the python bindings
are better off in a separate package in extras then ?

I'm the new maintainer of this package. I am willing to update it in FC6,
although updateing FC5 at this time seems a bit iffy.

I have no idea about the python issue though (having no experience with
libgpod), and i'm open to suggestions on how to do it. Opinions?

Jef, thanks for the heads up on 0.4.0 making it into devel, I'll have a peak at
that.

The python bindings have a dependency on eyeD3 to do mp3 tag parsing.  eyeD3 is
in extras as python-eyed3.

How feasible is it to build without python for core and then rebuild with for
extras?  I'm not up enough on the policies and complexities of the build systems
to know.  If some simple build time defines can be passed to get or not get the
bindings that'd be excellent.

Updating even without the python bindings would be good, IMO, as there are many
things that simply aren't handled in the currently packaged version of libgpod
(newer ipods, artwork support and such).

At the moment there is one issue that will come up when updating.  There were
API and ABI cincompatible changes made but the so version wasn't updated.  So
rythmbox and anything else that depends on libgpod.so.0 would need to be rebuilt
to work.  Sometime in the next week or so libgpod author Jorg Schuler is looking
to release 0.4.1 which will bump the so version to ease the packaging of both
libgpod.so.0 (<=0.4) and libgpod.so.1 (0.4.1).

I've been packaging these things up for my own systems for a while now and if I
can help at all with testing or packaging things I'd be glad to do so.

Ugh, if 0.4.0 is not ABI compat then its seems bad to do updates for FC5/FC6.

If we update to 0.3.2 for FC5/FC6, is that good enough?

0.3.2 fixes a few potential segfaults and other bugs.  It doesn't add many
features so if there aren't bug reports here with people finding these bugs it's
probably not worth the trouble.

When 0.4.1 is released and the so version is bumped, then perhaps an update to
that and a libgpod0 package containing the old .so would be alright?  I've built
a libgpod0 package for myself but haven't tested it extensively as most of my
uses for libgpod require newer versions.  I'll attach the specfile and the small
patch to rename from libgpod to libgpod0 in case they're somewhat useful.

Created attachment 141678 [details]
specfile for libgpod0 compat package

Created attachment 141679 [details]
rename libgpod to libgpod0

We already have another bug open specifically requesting an  0.4 update to fix a
crasher condition in rhythmbox.  If this is true, do we really need to worry
about ABI compatibility? Rhythmbox is the only thing in fedora space which
requires libgpod at the moment and it may very well need the 0.4 version to fix
a crash issue.

Reference:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211823

jef: That is not true, at least the following packages require libgpod.so.0:
gtkpod
rhythmbox
amarok

Waiting for 0.4.1 and doing a libgpod-compat and a libgpod 0.4.1 update seems to
be a good approach. All the packages require libgpod.so.0, so they will pull in
libgpod-compat. The only package which requires "libgpod" is rhythmbox, but the
libgpod packages will be parallel installable, so that shouldn't be a problem
(and we'll be releaseing an updated rhythmbox too).

The only problem will be rebuildability. Some packages might stop rebuilding due
to changes in the libgpod API. Thats probably ok if we coordinate the updates
though.

Todd: Do you know when the 0.4.1 release is scheduled?

AFAIK, gtkpod, rhythmbox, and amarok should all compile fine against the latest
libgpod.  I've been building gtkpod and libgpod from CVS for a while now.  I
briefly tested Amarok  since the changes in the libgpod API and I think I at
least built Rhythmbox but I'd have to try again to be sure.  Gtkpod is written
by Jorg Schuler as is libgpod, so they don't get out of sync.  Some of the
Amarok devs are on the libgpod devel list as well and they keep up on the latest
changes.  Also, Christophe Fergeau is another of the libgpod authors and he's a
Rhythmbox dev too.

All that is to say I think all of the software that depends on libgpod is ready
to roll with a rebuild against any updated libgpod.  I can test Amarok and
Rhythmbox more thoroughly and confirm if it will help.  (I use Gtkpod almost
daily so I know it works well. :)

As far as when 0.4.1 will be released, Jorg said 1 or 2 weeks on November 11[1].
 Giving time to allow for his schedule and any other daily distractions, it
ought to be sometime fairly soon now.

Speaking of rhythmbox depending explicitly on libgpod, anyone know why that is?
 I would have thought the automatic libgpod.so.0 dep would have been sufficient.

[1] http://sourceforge.net/mailarchive/message.php?msg_id=37283604

(In reply to comment #15)
> jef: That is not true, at least the following packages require libgpod.so.0:
> gtkpod
> rhythmbox
> amarok

I should drink more coffee before doing a repoquery.

I'm fine with waiting for a libgpod-compat approach, as long as everyone is cool
with seeing that package added to fe6 to ease the ABI issue, even if its a
non-issue for the affected applications.

I'll help test srpms when you have them ready.

Created attachment 141822 [details]
updated specfile for libgpod0 compat package

Here's an updated specfile for the potential libgpod0 compat package.  I
removed the devel subpackage since there doesn't seem to be any reason why
someone would want to compile against this old version (and it would be more
work to patch things to install alongside the 0.4 version).  I also added calls
to ldconfig in %post and %postun since I missed the fact that they weren't
included in the 0.3.0 specfile which I used as a base for this package.

Do any of you guys know what list would be most appropriate to ask about how the
python bindings may get built and included?  I'm not sure if fedora-extras or
fedora-packaging are best, if there's another list I'm missing, or if the best
place is right here.

fedora-extras and fedora-maintainers would be best.  I started this new push to
update the lib in fedora-maintainers list, you could follow up on my thread for
example.

Since the Core maintainer has already sort of decided it would be best
maintained as part of Extras for fc6 at least, becasue of the eye3d dep which is
in Extras currently, opening up to fedora-extras for discussion would also be good. 

Essentially what we are going to end up doing is taking the libgpod tarball and
building a new srpm, that excludes everything but the bits of the python
bindings during the package building. Sort of the inverse of what the Core srpm is.

If you can spin that srpm up, present it to fedora-extras and fedora-maintainers
and explain again why its going to Extras and not part of the Core package.
We see if there is any torches or pitchforks shaken in your general direction
and then I come in to the threads and kneecap anyone who dares complain too
loudly about this being sub-optimal.

Once that "discussion" is over, we decide who is going to be the maintainer
(that will be you or me or someone with a compelling reason to keep this
maintained like the current listen maintainer) and shove that through the review
process.  Do you have contributor status in Extras currently?

-jef

> Waiting for 0.4.1 and doing a libgpod-compat and a libgpod 0.4.1 update seems to
be a good approach.
Looks like a fair deal.

@jef: I don't have contributor status currently.  I just went through the
account setup stuff, so I've now got a freshly accepted, signed CLA and a client
cert.

I've whipped up a python-gpod-0.4.0 package which will hopefully suffice to get
things started and by the time it gets checked out and changed as necessary,
0.4.1 should be out and we can coordinate rolling it out along with a libgpod
update in core.

SPEC: http://pobox.com/~tmz/fedora/python-gpod.spec
SRPM: http://pobox.com/~tmz/fedora/python-gpod-0.4.0-1.fc6.src.rpm.

I'll send a mail to the extras list to start a discussion about getting this
included.

@jef: The "discussion" on -extras was rather easy.  Hope you're not disappointed
that you didn't get to kneecap anyone.  I submitted the package for review as
Thorsten suggested.  If you get a minute and are in a position to review/sponsor
it that'd be great.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217066

Now that I have recovered from turkey coma. I should have time to go through the
review process on this tonite. I can not sponser however. Once I get through the
review we'll see if there's a little more poke in my eye-poking stick to get a
sponsor for you, or get this into Extras under my name if there is some hold up
for your sponsorship.  

-jef

Okay, python-gpod is now available in extras-development.  If anyone wants to
wack at it and feed bugzilla mail to me, the doors are now open.  (Thanks for
the poking Jef, I owe you some marshmallows for your stick someday.  :)

Alex, I'll ping here when libgpod-0.4.1 is released.  Then perhaps we can see
about getting it into FC[56] to fix up some of the rhythmbox issues with the
current libgpod and enable us to add the bindings to extras for users of FC[56].

*** Bug 214779 has been marked as a duplicate of this bug. ***

Does anybody have this bug:
when I update to libgpod-0.4 amarok doesn't crash but all songs transfered to my
ipod nano (tested with 1.2 and 1.3 firmware) can't play any of the songs
transfered !?!?

Is this a new bug?

(In reply to comment #27)
> Does anybody have this bug:
> when I update to libgpod-0.4 amarok doesn't crash but all songs transfered to my
> ipod nano (tested with 1.2 and 1.3 firmware) can't play any of the songs
> transfered !?!?
> 
> Is this a new bug?

Where did you get your libgpod-0.4.0 package?
Did you completely remove libgpod-0.3.0 (and any corresponding -devel) package(s)?
Did you recompile Amarok against libgpod-0.4.0?

If you didn't compile Amarok against a clean libgpod-0.4.0 install, that's
likely the problem as there were some incompatible API/ABI changes made between
libgpod-0.3.0 and 0.4.0.

If you did recompile Amarok and still have this problem, you might get more help
from either the Amarok or libgpod lists.

I got libgpod form freshrpms repository, and I didn't compile amarok, I use rpm
packages.

My understanding is that libraries have standard api trough applications talk to
them, and it is they that do the actual work, so aplication that should't care
if it is libgpod 0.3 or 0.4. 
If I'm mistaken then it is my bad. Shoud I need to recompile amarok for using
different version of libgpod? And if so why doesn't freshrpm manitainer compile
and make it available?

here is the link:
http://zod.freshrpms.net/rpm.html?id=244

Why doesn't official fedora repositories have libgpod 0.4 and amarok that is
compiled for it? Can you please make it, but first test it that this not libgpod
0.4 bug to that you don't break something.

Thank you.

I thought that 0.4.x was ABI compatible with 0.3.x when I pushed it to freshrpms
as a requirement to the latest gtkpod. My basic testing with rhythmbox didn't
show any problems, so I just went ahead.
It turns out no one really seems to know if it should be or not ABI
compatible... the soname didn't change, which seems plain wrong if it isn't, but
it wouldn't be the first library to make that mistake.
The ideal solution here would be to get a recent 0.4.x package into Extras, have
everything rebuilt and working against it.

0.4.0 is not 100% API or ABI compatible with 0.3.x.  It may work well for
Rhythmbox because I don't thin RB uses libgpod that heavily but it won't work
for many other apps, Gtkpod for sure will crash if compiled for 0.3 and run with
0.4.0.

Changing the soname was discussed on the libgpod/gtkpod devel list and it wasn't
implemented at that time due to the way the autoconf stuff was setup (following
the gnome templates).  This may seem wrong but recall that libgpod is not at 1.0
yet and keep this statement from the libgpod website in mind:

"Official Release (Actually just snapshots -- expect frequent updates and
numerous changes. The tar balls are provided so that package providers can get a
head start on providing packages.)"

So the API/ABI is not expected to be solid and unchanging quite yet. :)

All that said, during the discussion on whether to bump the soname I submitted a
patch to the list and it was applied to CVS after the 0.4.0 release to ease the
task of packagers[1].

Now we're just waiting on a 0.4.1 release.  I asked on the libgpod list last
week but I'm not sure if the message reached Jorg Schuler or not as SF seemed to
be having some issues about that time.  I'll ping him directly today and see if
he's got some time to roll a 0.4.1 tarball soon.

[1] http://sourceforge.net/mailarchive/message.php?msg_id=36647909

I noticed this in the Rhytmbox 0.9.7 release announcement the other day:

"The only dependency change for this release is that iPod support now
requires libgpod 0.4.0, as it contains vital bug fixes."

So rhythmbox is ready for the latest libgpod when it comes out.  I know that
amarok tracks the development pretty closely as well and is ready too, with one
minor patch needed due to one of the unknown iTunesDB fields being renamed.  The
patch is in amarok's CVS and I've sent a note to Aurelien Bompard (amarok
maintainer in FE) about this, so that we can coordinate a release properly and
ensure all the stuff that uses the library works seemlessly.

libgpod-0.4.2 was released today.  I've built rpms for libgpod, python-gpod, and
a compat-libgpod (0.3.2) for FC6.  Those are available, along with specfiles and
mock logs at:

http://pobox.com/~tmz/fedora/

I can build these for rawhide if that's preferred.

I've tested this with Rhythmbox and Amarok from Core and Extras resp.  Rhythmbox
has an uneccesary dep on libgpod, so it pulls in both the updated libgpod as
well as compat-libgpod.  Both apps work as far as my testing.  Rhythmbox is
read-only AFAIK.  Amarok read and wrote my iTunesDB without err.  I don't use
either of these apps though, so testing by someone more familiar with them would
be welcome.

Please let me know if you find any problems with them.  If there aren't any
found, I can send a diff against the libgpod.spec in CVS.

Give me a day or two and I can test this with listen.

-jef

Thanks Jef.  I've never had any luck with listen.  Are you using it from
subversion or 0.5 beta1 that's in extras?  It loads up but the playlists show on
the ipod contain a bunch of the same track.  The master view of the ipod shows
the right number of songs in parens but it only displays a few hundred of them.
 On startup, there are a large number of these error lines:

E:Ipod:Failed to load track ...

I tried to update libgpod:

# rpm -Uvh libgpod-0.4.2-0.1.fc6.i386.rpm 
warning: libgpod-0.4.2-0.1.fc6.i386.rpm: Header V3 RSA/SHA1 signature: NOKEY,
key ID beaf0ce3
error: Failed dependencies:
        libgpod.so.0 is needed by (installed) gtkpod-0.99.8-1.fc6.i386
        libgpod.so.0 is needed by (installed) amarok-1.4.4-4.fc6.i386

any ideas?

# locate libgpod
/usr/lib/libgpod.so.0
/usr/lib/libgpod.so.0.300.0


# ls -al /usr/lib/libgpod.so.0
lrwxrwxrwx 1 root root 18 Nov 28 10:33 /usr/lib/libgpod.so.0 -> libgpod.so.0.300.0


# rpm -e libgpod
error: Failed dependencies:
        libgpod.so.0 is needed by (installed) gtkpod-0.99.8-1.fc6.i386
        libgpod.so.0 is needed by (installed) amarok-1.4.4-4.fc6.i386


I needed a bigger hammer :)

# rpm -e libgpod --nodeps


# rpm -ivh libgpod-0.4.2-0.1.fc6.i386.rpm 
warning: libgpod-0.4.2-0.1.fc6.i386.rpm: Header V3 RSA/SHA1 signature: NOKEY,
key ID beaf0ce3
Preparing...                ########################################### [100%]
   1:libgpod                ########################################### [100%]


but then amarok complained on missing libgpod.so.0

]# ls -al /usr/lib/libgpod.so.1
lrwxrwxrwx 1 root root 16 Jan 16 08:54 /usr/lib/libgpod.so.1 -> libgpod.so.1.0.0


So I made an link to it:

# ln -s /usr/lib/libgpod.so.1.0.0 /usr/lib/libgpod.so.0


I'm testing libgpod-0.4.2 now with amarok which is downloading 10 new podcasts
that I'll sync with my iPod Nano and tell you the results.

Amarok has crashed! We are terribly sorry about this :(

But, all is not lost! You could potentially help us fix the crash. Information
describing the crash is below, so just click send, or if you have time, write a
brief description of how the crash happened first.

Many thanks.







The information below is to help the developers identify the problem, please do
not modify it.



======== DEBUG INFORMATION  =======
Version:    1.4.4
Engine:     xine-engine
Build date: Dec 19 2006
CC version: 4.1.1 20061011 (Red Hat 4.1.1-30)
KDElibs:    3.5.5-0.2.fc6 Fedora-Core
Qt:         3.3.7
TagLib:     1.4.0
CPU count:  1
NDEBUG:     true
==== file `which amarokapp` =======
/usr/bin/amarokapp: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
stripped


==== (gdb) bt =====================
Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1208485152 (LWP 6917)]
[New Thread -1233867888 (LWP 7083)]
[New Thread -1259562096 (LWP 6931)]
[New Thread 155675536 (LWP 6930)]
[New Thread 145185680 (LWP 6929)]
[New Thread 33475472 (LWP 6928)]
[New Thread -1211774064 (LWP 6927)]
0x0064a402 in __kernel_vsyscall ()
#0  0x0064a402 in __kernel_vsyscall ()
#1  0x009a9cb6 in nanosleep () from /lib/libc.so.6
#2  0x009e293c in usleep () from /lib/libc.so.6
#3  0x005edac3 in IpodMediaDevice::writeITunesDB ()
   from /usr/lib/kde3/libamarok_ipod-mediadevice.so
#4  0x005edd05 in IpodMediaDevice::synchronizeDevice ()
   from /usr/lib/kde3/libamarok_ipod-mediadevice.so
#5  0x0229dda4 in MediaDevice::transferFiles () from /usr/lib/libamarok.so.0
#6  0x0229ef9c in MediaBrowser::transferClicked ()
   from /usr/lib/libamarok.so.0
#7  0x022a698e in MediaBrowser::qt_invoke () from /usr/lib/libamarok.so.0
#8  0x0636fb51 in QObject::activate_signal ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#9  0x0637071d in QObject::activate_signal ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#10 0x06703bcc in QButton::clicked () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#11 0x06413c7d in QButton::mouseReleaseEvent ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#12 0x06e21dc1 in KToolBarButton::mouseReleaseEvent ()
   from /usr/lib/libkdeui.so.4
#13 0x063ad095 in QWidget::event () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#14 0x06e99b41 in KToolBarButton::event () from /usr/lib/libkdeui.so.4
#15 0x06306e6b in QApplication::internalNotify ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#16 0x063084c7 in QApplication::notify ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#17 0x0043ad82 in KApplication::notify () from /usr/lib/libkdecore.so.4
#18 0x0629e9c6 in QETWidget::translateMouseEvent ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#19 0x0629d4c6 in QApplication::x11ProcessEvent ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#20 0x062af14b in QEventLoop::processEvents ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#21 0x063203f0 in QEventLoop::enterLoop ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#22 0x063202a6 in QEventLoop::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#23 0x0630697f in QApplication::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#24 0x0804bb7a in QGList::~QGList$delete ()
#25 0x00931f2c in __libc_start_main () from /lib/libc.so.6
#26 0x0804b221 in QGList::~QGList$delete ()
#0  0x0064a402 in __kernel_vsyscall ()
No symbol table info available.
#1  0x009a9cb6 in nanosleep () from /lib/libc.so.6
No symbol table info available.
#2  0x009e293c in usleep () from /lib/libc.so.6
No symbol table info available.
#3  0x005edac3 in IpodMediaDevice::writeITunesDB ()
   from /usr/lib/kde3/libamarok_ipod-mediadevice.so
No symbol table info available.
#4  0x005edd05 in IpodMediaDevice::synchronizeDevice ()
   from /usr/lib/kde3/libamarok_ipod-mediadevice.so
No symbol table info available.
#5  0x0229dda4 in MediaDevice::transferFiles () from /usr/lib/libamarok.so.0
No symbol table info available.
#6  0x0229ef9c in MediaBrowser::transferClicked ()
   from /usr/lib/libamarok.so.0
No symbol table info available.
#7  0x022a698e in MediaBrowser::qt_invoke () from /usr/lib/libamarok.so.0
No symbol table info available.
#8  0x0636fb51 in QObject::activate_signal ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
No symbol table info available.
#9  0x0637071d in QObject::activate_signal ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
No symbol table info available.
#10 0x06703bcc in QButton::clicked () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
No symbol table info available.
#11 0x06413c7d in QButton::mouseReleaseEvent ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
No symbol table info available.
#12 0x06e21dc1 in KToolBarButton::mouseReleaseEvent ()
   from /usr/lib/libkdeui.so.4
No symbol table info available.
#13 0x063ad095 in QWidget::event () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
No symbol table info available.
#14 0x06e99b41 in KToolBarButton::event () from /usr/lib/libkdeui.so.4
No symbol table info available.
#15 0x06306e6b in QApplication::internalNotify ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
No symbol table info available.
#16 0x063084c7 in QApplication::notify ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
No symbol table info available.
#17 0x0043ad82 in KApplication::notify () from /usr/lib/libkdecore.so.4
No symbol table info available.
#18 0x0629e9c6 in QETWidget::translateMouseEvent ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
No symbol table info available.
#19 0x0629d4c6 in QApplication::x11ProcessEvent ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
No symbol table info available.
#20 0x062af14b in QEventLoop::processEvents ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
No symbol table info available.
#21 0x063203f0 in QEventLoop::enterLoop ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
No symbol table info available.
#22 0x063202a6 in QEventLoop::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
No symbol table info available.
#23 0x0630697f in QApplication::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
No symbol table info available.
#24 0x0804bb7a in QGList::~QGList$delete ()
No symbol table info available.
#25 0x00931f2c in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#26 0x0804b221 in QGList::~QGList$delete ()
No symbol table info available.
==== (gdb) thread apply all bt ====
Thread 7 (Thread -1211774064 (LWP 6927)):
#0  0x0064a402 in __kernel_vsyscall ()
#1  0x00a9342c in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
#2  0x01038c19 in _x_metronom_init () from /usr/lib/libxine.so.1
#3  0x00a8f3db in start_thread () from /lib/libpthread.so.0
#4  0x009e926e in clone () from /lib/libc.so.6
Thread 6 (Thread 33475472 (LWP 6928)):
#0  0x0064a402 in __kernel_vsyscall ()
#1  0x009df6d3 in poll () from /lib/libc.so.6
#2  0x030e5fdd in ?? ()
   from /usr/lib/xine/plugins/1.1.3/xineplug_ao_out_alsa.so
#3  0x00a8f3db in start_thread () from /lib/libpthread.so.0
#4  0x009e926e in clone () from /lib/libc.so.6
Thread 5 (Thread 145185680 (LWP 6929)):
#0  0x0064a402 in __kernel_vsyscall ()
#1  0x00a931a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x010474d2 in _x_ao_channels2mode () from /usr/lib/libxine.so.1
#3  0x0104a78a in xine_get_next_audio_frame () from /usr/lib/libxine.so.1
#4  0x00a8f3db in start_thread () from /lib/libpthread.so.0
#5  0x009e926e in clone () from /lib/libc.so.6
Thread 4 (Thread 155675536 (LWP 6930)):
#0  0x0064a402 in __kernel_vsyscall ()
#1  0x00a931a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x0103c2b0 in _x_dummy_fifo_buffer_new () from /usr/lib/libxine.so.1
#3  0x01043129 in _x_audio_decoder_init () from /usr/lib/libxine.so.1
#4  0x00a8f3db in start_thread () from /lib/libpthread.so.0
#5  0x009e926e in clone () from /lib/libc.so.6
Thread 3 (Thread -1259562096 (LWP 6931)):
#0  0x0064a402 in __kernel_vsyscall ()
#1  0x00a931a6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x0104bde0 in xine_event_wait () from /usr/lib/libxine.so.1
#3  0x0104be6c in xine_event_wait () from /usr/lib/libxine.so.1
#4  0x00a8f3db in start_thread () from /lib/libpthread.so.0
#5  0x009e926e in clone () from /lib/libc.so.6
Thread 2 (Thread -1233867888 (LWP 7083)):
#0  0x0064a402 in __kernel_vsyscall ()
#1  0x00a96cbb in waitpid () from /lib/libpthread.so.0
#2  0x0804d011 in Amarok::Crash::crashHandler ()
#3  <signal handler called>
#4  0x00eea700 in write_one_podcast_group () from /usr/lib/libgpod.so.0
#5  0x00eeb53c in itdb_write_file () from /usr/lib/libgpod.so.0
#6  0x00eecdfd in itdb_write () from /usr/lib/libgpod.so.0
#7  0x005f8c3f in IpodWriteDBJob::doJob ()
   from /usr/lib/kde3/libamarok_ipod-mediadevice.so
#8  0x023f484c in ThreadWeaver::Thread::run () from /usr/lib/libamarok.so.0
#9  0x062ff20c in QThreadInstance::start ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#10 0x00a8f3db in start_thread () from /lib/libpthread.so.0
#11 0x009e926e in clone () from /lib/libc.so.6
Thread 1 (Thread -1208485152 (LWP 6917)):
#0  0x0064a402 in __kernel_vsyscall ()
#1  0x009a9cb6 in nanosleep () from /lib/libc.so.6
#2  0x009e293c in usleep () from /lib/libc.so.6
#3  0x005edac3 in IpodMediaDevice::writeITunesDB ()
   from /usr/lib/kde3/libamarok_ipod-mediadevice.so
#4  0x005edd05 in IpodMediaDevice::synchronizeDevice ()
   from /usr/lib/kde3/libamarok_ipod-mediadevice.so
#5  0x0229dda4 in MediaDevice::transferFiles () from /usr/lib/libamarok.so.0
#6  0x0229ef9c in MediaBrowser::transferClicked ()
   from /usr/lib/libamarok.so.0
#7  0x022a698e in MediaBrowser::qt_invoke () from /usr/lib/libamarok.so.0
#8  0x0636fb51 in QObject::activate_signal ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#9  0x0637071d in QObject::activate_signal ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#10 0x06703bcc in QButton::clicked () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#11 0x06413c7d in QButton::mouseReleaseEvent ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#12 0x06e21dc1 in KToolBarButton::mouseReleaseEvent ()
   from /usr/lib/libkdeui.so.4
#13 0x063ad095 in QWidget::event () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#14 0x06e99b41 in KToolBarButton::event () from /usr/lib/libkdeui.so.4
#15 0x06306e6b in QApplication::internalNotify ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#16 0x063084c7 in QApplication::notify ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#17 0x0043ad82 in KApplication::notify () from /usr/lib/libkdecore.so.4
#18 0x0629e9c6 in QETWidget::translateMouseEvent ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#19 0x0629d4c6 in QApplication::x11ProcessEvent ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#20 0x062af14b in QEventLoop::processEvents ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#21 0x063203f0 in QEventLoop::enterLoop ()
   from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#22 0x063202a6 in QEventLoop::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#23 0x0630697f in QApplication::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#24 0x0804bb7a in QGList::~QGList$delete ()
#25 0x00931f2c in __libc_start_main () from /lib/libc.so.6
#26 0x0804b221 in QGList::~QGList$delete ()
#0  0x0064a402 in __kernel_vsyscall ()


==== kdBacktrace() ================

The point that I guess you will tell me that I can't use this library if I don't
compile amarok to use it... but at least I tried :)

(In reply to comment #40)
> The point that I guess you will tell me that I can't use this library if I don't
> compile amarok to use it... but at least I tried :)

I believe that the compat-libgpod package provides the backwards-compatible
version of the library for apps that haven't been recompiled to use the new
version (like amarok), which would solve the dependency problem in comment #37.

To test the new version of the libgpod library with one of the apps such as
amarok or rhythmbox, yes, you will need to recompile it.

Valent, you don't want to force installation or make symbolic links to
differently versioned libraries.  That will almost always break things (if it
didn't, the libraries wouldn't have version numbers at all :).

The compat-libgpod package provides libgpod.so.0.  It is what you need to keep
amarok happy until it is recompiled to use the newer libgpod package.

I'm guessing that your gtkpod package is from FreshRPMS.  If so, Matthias also
provides a libgpod-0.4.0 package that gtkpod is compiled for.  There were some
changes between 0.4.0 and 0.4.2 that will require gtkpod to be recompiled using
the updated libgpod.

If you're comfortable rebuilding the amarok and gtkpod packages, then install
libgpod-devel and rebuild them.  Otherwise, just hold on until the packages make
it into the repositories.

Also, for large amounts of text like backtraces it is preferable to add them as
attachments. :)

(In reply to comment #41)
> To test the new version of the libgpod library with one of the apps such as
> amarok or rhythmbox, yes, you will need to recompile it.

Indeed.  In the case of Amarok a small patch is needed for 1.4.4 (which Aurelien
Bompard, Amarok maintainer in Extras, knows about).  I think all most of the
maintainers of packages using libgpod are on the CC list for this bug, so I've
no doubt that we can coordinate a smooth update of libgpod and the apps using it
shortly afterward. 

# rm /usr/lib/libgpod.so.0
rm: remove symbolic link `/usr/lib/libgpod.so.0'? y


# rpm -e libgpod


# rpm -ivh compat-libgpod-0.3.2-0.1.fc6.i386.rpm 
warning: compat-libgpod-0.3.2-0.1.fc6.i386.rpm: Header V3 RSA/SHA1 signature:
NOKEY, key ID beaf0ce3
Preparing...                ########################################### [100%]
   1:compat-libgpod         ########################################### [100%]


]# ls -al /usr/lib/libgpod.so.0
lrwxrwxrwx 1 root root 18 Jan 16 09:17 /usr/lib/libgpod.so.0 -> libgpod.so.0.302.0


Amarok 1.4.4 works great with compat-libgpod-0.3.2 !
I synced some 10 or so new podcasts to my Nano and it syncs and plays great!

Hope this helps.

I build this for fc6 and requested an update push. It'll be out soon.

*** Bug 211823 has been marked as a duplicate of this bug. ***

Thanks Alex!

I'll get the python-gpod package ready in Extras for FC6 a while, for anyone who
wants to those bindings.

libgpod-0.4.2-0.1.fc6 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

libgpod-0.4.2-0.1.fc6 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

The Amarok package is compiled against the older version. The shuffle doesn't
work with this libgpod in ctkpod or amarok.

Meant to say gtkpod. Files are immediately orphaned. I had to revert to an older
version.

(In reply to comment #51)
> Meant to say gtkpod. Files are immediately orphaned. I had to revert to an older
> version.

You should probably file a request against gtkpod (which is Extras?) to ask them
to rebuild against the new libgpod (currently it probably uses the
compat-libgpod library to provide the backwards compatible libgpod 0.3.x version).

The libgpod update just hit updates yesterday, so give Amarok maintainer
Aurelien Bompard a few days or so to push a rebuilt version.  Until then it
should continue to work as well as it did before the update because of the
compat-libgpod package that provides libgpod.so.0.

gtkpod isn't in core or extras.  If you got it from FreshRPMS, give Matthias a
few days or so to rebuild it against the new libgpod.  It will be broken until
then because his version was built for libgpod-0.4.0, which isn't compatible
with the compat-libgpod-0.3.2 or updated libgpod-0.4.2 packages unfortunately.

Matthias, if you're reading this, there's a small patch needed for gtkpod to
build with libgpod-0.4.2.  It's available on sourceforge:

http://downloads.sourceforge.net/gtkpod/gtkpod-0.99.8_libgpod-0.4.2.diff

(In reply to comment #53)
> Matthias, if you're reading this, there's a small patch needed for gtkpod to
> build with libgpod-0.4.2.  It's available on sourceforge:
> 
> http://downloads.sourceforge.net/gtkpod/gtkpod-0.99.8_libgpod-0.4.2.diff

Thanks for notifying as well as the pointer! Expect new gtkpod packages in a few
minutes.

Amarok has been successfully rebuilt for the new libgpod in FC6 (in devel I'm
still having a problem with the new libmtp)