Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 211648
Summary: | RFE: update libgpod to 0.4.0 which supports more recent ipods and contains many bugfixes | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Todd Zullinger <tmz> | ||||||||||||
Component: | libgpod | Assignee: | Alexander Larsson <alexl> | ||||||||||||
Status: | CLOSED NEXTRELEASE | QA Contact: | |||||||||||||
Severity: | medium | Docs Contact: | |||||||||||||
Priority: | medium | ||||||||||||||
Version: | 5 | CC: | alex, bjohnson, bnocera, cs, gauret, jspaleta, matthias, valent.turkovic | ||||||||||||
Target Milestone: | --- | ||||||||||||||
Target Release: | --- | ||||||||||||||
Hardware: | All | ||||||||||||||
OS: | Linux | ||||||||||||||
Whiteboard: | |||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||
Clone Of: | Environment: | ||||||||||||||
Last Closed: | 2007-01-17 12:21:29 UTC | Type: | --- | ||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||
Documentation: | --- | CRM: | |||||||||||||
Verified Versions: | Category: | --- | |||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
Embargoed: | |||||||||||||||
Attachments: |
|
Description
Todd Zullinger
2006-10-20 16:30:27 UTC
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) |