This is track the update of libgpod to 0.5.2 and (changes to | rebuilds of)
packages that depend on it.
Created attachment 160625 [details]
libgpod-0.5.2 compatibility patch for quodlibet
I think quodlibet is the only package that needs patched for the libgpod
update. I sent a note upstream about this, but since I'm not subscribed the
the quodlibet list I'm not sure if it got through their moderation system.
There are 2 other details I noticed in testing quodlibet.
1) They store the bitrate * 1000, so tracks look to be encoded at 192000kbps in
gtkpod and other apps. I think this is only a cosmetic annoyance, but I'm not
sure of that. The tracks seemed to play fine on my iPod.
2) Rebuilding the package, desktop-file-install tossed some warnings and errors
about the .desktop file. An updated spec that works around those warnings is
gpodder 0.9.4 should show up in rawhide real-soon-now. It was updated post freeze.
It has a dep on python-gpod
Thanks Jef. Gpodder should be good to go without any rebuild or changes AFAIK.
Gpodder author Thomas Perl got some help on the gtkpod-devel list with some
patches for the changes in libgpod 0.5.x. Hopefully once we build things you'll
be able to confirm that.
If you want to get a head start on that, check out the packages I put up at:
Any chances we will see these in f7? gtkpod 0.99.10 is said to support gapless
albums, which is a nice feature and will save the necessity to reboot into
windows for iTunes.
It depends on whether(In reply to comment #4)
> Any chances we will see these in f7?
I'd like to see that. But I'm biased as a gtkpod maintainer. :) We'll have to
see how the other maintainers feel about pushing the update for F7 once we get
it into devel.
> gtkpod 0.99.10 is said to support gapless
> albums, which is a nice feature and will save the necessity to reboot into
> windows for iTunes.
Yeah, gapless support is indeed in 0.99.10. It only works for mp3's currently,
and even then only for mp3's which have a LAME tag. (If you've got non-lame
encoded mp3's or another ipod supported format and want to help out, post to the
gtkpod-devel list. Michael Tiffany, the gentleman that did most of the work on
the gapless support could likely use some help testing and working on supporting
other file types, especially if you can help with iTunes compatibility testing.)
(In reply to comment #1)
> Created an attachment (id=160625) 
> libgpod-0.5.2 compatibility patch for quodlibet
> I think quodlibet is the only package that needs patched for the libgpod
> update. I sent a note upstream about this, but since I'm not subscribed the
> the quodlibet list I'm not sure if it got through their moderation system.
The patches for Quod Libet have been applied to devel and should be aviailable
from the mirrors.
Okay, so there's some saying about the best laid plans... I was waiting to hear
back from rel-eng to make sure I did the push properly and handled the merging
of the python-gpod package and then we'd be good to go. But ajax beat me to it
and rebuilt libgpod this morning. :)
So, amarok, kipi-plugins, gtkpod, quodlibet, and rhythmbox should be rebuilt
before the next rawhide push. I'm going to do kipi-plugins, gtkpod, and
rhythmbox in the next hour or so. If there's no objection, I'll do the same for
amarok and quodlibet soon after that (so that no one gets any broken-dep nag mails).
Sorry for the late notice.
After waking up a little more, I realized that quodlibet is already good (thanks
Jeff :). So I built kipi-plugins, gtkpod, and rhythmbox a few hours ago and
just kicked off a rebuild of amarok.
If no problems are found after allowing this to stew in rawhide for a week,
would any of your guys have an objection to pushing this update for F-7? I'd
like to update gtkpod to pick up some new features. I don't think it would
cause much trouble for any third-party packages (nothing a rebuild wouldn't fix
that is). I'd be happy to work out any patches needed by third-party apps that
need libgpod, if there are any that a simple rebuild doesn't work for.