This needs to be done at the same time with reverse deps. See bugs linked to this bug. Test and mark stable. Thanks.
*** Bug 278496 has been marked as a duplicate of this bug. ***
Test suite is restricted because it doesn't really run any tests, but it fails when dejagnu is installed (I've submitted a patch for that to upstream.) I guess best way to test is to grab a MP4/M4A sample (in AAC format) from... http://samples.mplayerhq.hu/A-codecs/AAC/ And play something with e.g. amaroK this bug deps on...
amd64/x86 stable
Uhm I don't know if this right location to post or whether at all :-/ Well, it seems that with this version coming stable I have to choose between amarok or kid3 (both are stable version). !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: media-libs/libmp4v2:0 ('installed', '/', 'media-libs/libmp4v2-1.5.0.1-r2', 'nomerge') pulled in by <media-libs/libmp4v2-1.9.0 required by ('installed', '/', 'media-sound/kid3-1.0', 'nomerge') ('ebuild', '/', 'media-libs/libmp4v2-1.9.1', 'merge') pulled in by >=media-libs/libmp4v2-1.9.0 required by ('ebuild', '/', 'media-libs/faac-1.28-r1', 'merge') >=media-libs/libmp4v2-1.9 required by ('ebuild', '/', 'media-libs/tunepimp-0.5.3-r2', 'merge')
(In reply to comment #4) > !!! Multiple package instances within a single package slot have been pulled > !!! into the dependency graph, resulting in a slot conflict: Sorry about this but kid3 (or any other one application) can't be holding back major media libs from entering stable so I've removed 1.0 from tree to sanitize deptree. Keyword 1.2 if you want to keep using it.
The kid3-1.2 ebuild depends on KDE4 and isn't of much use for a stable KDE3 system. However, I was able to build kid3 1.2 for KDE3 from source without hassle; is there a possibility to introduce a slot for it while KDE3 is still in portage?
Created attachment 201896 [details] kid3 ebuild with KDE3 and KDE4 support OK, as the Gentoo KDE maintainers are eager to spread KDE4 though being still masked, here's a kid3 ebuild that supports both KDE3 (default) and KDE4 (kde4 use flag). Be warned, I'm a beginner when it comes to ebuilds, so this one may have issues (it's a copy of the current kid3-1.2-r2 from portage where I added a use flag and RDEPENDs). However, it compiles for me. Here's a short description if you want to use it in your local portage overlay: - Extend /etc/make.conf by "PORTDIR_OVERLAY=/usr/local/portage". - Create /usr/local/portage/media-sound/kid3/ - Copy the ebuild into that dir and change to it. - Create a manifest with "ebuild kid3-1.2-r3.ebuild manifest". - Unmask/-keyword kid3 in /etc/portage/packages.[unmask|keywords]. - Now see if "emerge -pv kid3" chooses the new ebuild. If yes, emerge it as usual. If not, I may have forgotten some magic spell.
Sorry, I didn't think of that: The name of the ebuild file should be "kid3-1.2-r3.ebuild".
Comment on attachment 201896 [details] kid3 ebuild with KDE3 and KDE4 support This is not a kid3 bug.
> This is not a kid3 bug. Indeed, seems more like a bug in decision-making to me :-( I'd like to point out that from my, a user's, point of view the decision to gradually drop support for proven KDE3 apps while their KDE4 counterparts and KDE4 in general are still masked (or not satisfyingly usable as replacement) is incomprehensible and irritating, perhaps even contradicting Gentoo principles, as pointed out elsewhere. The more as there is a simple solution to it (or even two, as changing the inherit declaration seems to work, too), at least as far as kid3 is concerned. And no, I don't see using KDE3 and 4 in parallel as a good solution, as it entails double the overhead (both space *and* compile time when updating world; think of older laptops where you can't just put in another 500GB drive) when all you want is to work on with *one* window/desktop manager. Another thing I can't resist to point out: If the time for discussions about this topic would instead have been used to provide proper ebuilds, there'd be less time wasted and less frustration on either side...
Stable for HPPA.
Stbale on alpha.
ppc stable
ppc64 stable
arm stable
ia64/sh/sparc stable, closing
