Summary: | media-libs/libmpcdecsv7 removal request (was: fails with autoconf 2.65) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | New packages | Assignee: | Gentoo Sound Team <sound> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | 4nykey |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 295051, 297903, 297910, 301304 | ||
Bug Blocks: | 294167 | ||
Attachments: | Build log |
Description
Diego Elio Pettenò (RETIRED)
2009-11-25 11:48:09 UTC
Created attachment 211145 [details]
Build log
The real solution is to lastrite this dummy transition package I added, http://tinderbox.x86.dev.gentoo.org/misc/rindex/media-libs/libmpcdecsv7 From those new audacious can play SV8 format by ffmpeg now, old k3b will be removed, and rest can just drop their USE musepack since it's only for SV7 anyway. It's a shame xine-lib is unable to use ffmpeg's musepack backend to play modern SV8 format though :( xine's dead… (In reply to comment #3) > xine's dead… > Heh, but it Darren Salt still ported latest xine-lib to the new libmpcdec API in latest (now in portage) so that's resolved. The rest can simply lose the dep, and this can be masked and removed Only need those 2 open bugs, 295051 and 301304 closed and this can be killed off tree. So this b0rks because of a regression(*) in an autoconf version that is ~arch masked. If it's a patched tarball, why it needs eautoreconf in the first place? That aside, very few actually ported their apps to the new API, and who didn't just loses musepack USE flag. Sounds like a plan. -- * http://lists.gnu.org/archive/html/bug-autoconf/2010-02/msg00011.html (In reply to comment #6) > So this b0rks because of a regression(*) in an autoconf version that is ~arch > masked. If it's a patched tarball, why it needs eautoreconf in the first place? > > That aside, very few actually ported their apps to the new API, and who didn't > just loses musepack USE flag. > > Sounds like a plan. Sorry, but I fail to see a valid reason why this hack should be kept in tree. All the reverse deps, including xine-lib, k3b, audacious, ffmpeg, gstreamer, vlc... support the new API. I know of only media-sound/cmus and media-sound/moc that don't support it yet. And with this old lib they wouldn't be able to play any newly encoded files anymore, as the old API does not support the SV8 format. So removing as planned. (In reply to comment #7) > I know of only media-sound/cmus and media-sound/moc that don't support it yet. media-libs/tunepimp also; plus media-sound/mpd has issues when built with sv8 lib Too bad, these happen to be the only apps that I for one care of. > And with this old lib they wouldn't be able to play any newly encoded files > anymore, as the old API does not support the SV8 format. Yes, and knowing this, one wouldn't encode to the new format for the time being. (In reply to comment #8) > (In reply to comment #7) > > I know of only media-sound/cmus and media-sound/moc that don't support it yet. > > media-libs/tunepimp also; plus media-sound/mpd has issues when built with sv8 > lib > Too bad, these happen to be the only apps that I for one care of. libtunepimp is dead too; "libtunepimp uses the old RDF WebService and should not be used in new development." [1] we should look into lastriting soon. [1] http://musicbrainz.org/doc/libtunepimp and I've tested mpd with new musepack when we did the migration, and it worked fine. whatever issues you might have with it, the solution is not to preserve dead API... (In reply to comment #9) > libtunepimp is dead too; "libtunepimp uses the old RDF WebService and should > not be used in new development." [1] we should look into lastriting soon. > > [1] http://musicbrainz.org/doc/libtunepimp Okay, but that's a note for software developers, not package maintainers. And there are few packages in the tree that still depend on tunepimp. Oh wait, I know, USE=-musicbrainz, right? > and I've tested mpd with new musepack when we did the migration, and it worked > fine. whatever issues you might have with it, the solution is not to preserve > dead API... I see. Well, actually I don't. Only if you meant to say 'decision' instead of 'solution'? media-sound/moc, and media-sound/cmus fixed to support SV8 API. USE musepack restored in both. media-libs/tunepimp was always broken with it (it was automagic depend, and the ebuild never listed it as depend in the first place) and since the library is dead wrt upstream, pending removal when they close the RTF service for good media-sound/mpd is fine with new API, open a new bug with sufficient information for reproducing the said "problems" libmpcdec* removed from tree, handled by blockers from musepack-tools instead now (In reply to comment #11) > media-sound/moc, and media-sound/cmus fixed to support SV8 API. USE musepack > restored in both. Good. > media-libs/tunepimp was always broken with it (it was automagic depend, and the > ebuild never listed it as depend in the first place) Kudos to tunepimp maintainer. > media-sound/mpd is fine with new API, open a new bug with sufficient > information for reproducing the said "problems" Well, if you don't use the software on the daily basis and briefly tested it, you'll hardly spot them "problems", so I count those quotes to typical ignorance. I'll file the bug upstream, though the mpd devs aren't the most friendliest devs out there either. |