I don't want to upgrade to xorg-7 but the ebuild of mplayer has hard deps on libXi etc., which means I need to upgrade to xorg-7. Is it posssible to upgrade mplayer without upgrading xorg? Is xorg-6.8 not supported anymore by Gentoo? $ emerge -p mplayer These are the packages that would be merged, in order: Calculating dependencies... done! [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-misc/util-macros-1.0.2) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-proto/kbproto-1.0.2) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-proto/xextproto-7.0.2) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-proto/xf86bigfontproto-1.1.2) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-proto/inputproto-1.3.2) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/libX11-1.0.3) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-proto/xproto-7.0.7) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/libXau-1.0.1) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-proto/bigreqsproto-1.0.2) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/libXdmcp-1.0.1) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-proto/xcmiscproto-1.1.2) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/xtrans-1.0.1) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/libXext-1.0.1) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/libXv-1.0.1) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-proto/videoproto-2.2.2) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-proto/xf86dgaproto-2.0.2) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/libXvMC-1.0.2) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-proto/xineramaproto-1.1.2) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/libXinerama-1.0.1) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-proto/xf86vidmodeproto-2.2.2) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/libXxf86vm-1.0.1) [blocks B ] <=x11-base/xorg-x11-6.9 (is blocking x11-libs/libXi-1.0.1) [ebuild N ] x11-misc/util-macros-1.0.2 USE="-debug" [ebuild U ] sys-devel/binutils-2.17 [2.14.90.0.8-r1] USE="multislot% -nls* -test% -vanilla%" [ebuild N ] x11-proto/kbproto-1.0.2 USE="-debug" [ebuild N ] x11-proto/xextproto-7.0.2 USE="-debug" [ebuild N ] x11-proto/xf86bigfontproto-1.1.2 USE="-debug" [ebuild N ] x11-proto/inputproto-1.3.2 USE="-debug" [ebuild N ] x11-proto/xproto-7.0.7 USE="-debug" [ebuild N ] x11-libs/libXau-1.0.1 USE="-debug" [ebuild N ] x11-proto/bigreqsproto-1.0.2 USE="-debug" [ebuild N ] x11-libs/libXdmcp-1.0.1 USE="-debug" [ebuild N ] x11-proto/xcmiscproto-1.1.2 USE="-debug" [ebuild N ] x11-libs/xtrans-1.0.1 USE="-debug" [ebuild N ] x11-libs/libX11-1.0.3 USE="-debug -ipv6" [ebuild N ] x11-libs/libXext-1.0.1 USE="-debug" [ebuild N ] x11-proto/videoproto-2.2.2 USE="-debug" [ebuild N ] x11-libs/libXv-1.0.1 USE="-debug" [ebuild N ] x11-proto/xf86dgaproto-2.0.2 USE="-debug" [ebuild N ] x11-libs/libXvMC-1.0.2 USE="-debug" [ebuild N ] x11-proto/xineramaproto-1.1.2 USE="-debug" [ebuild N ] x11-libs/libXinerama-1.0.1 USE="-debug" [ebuild N ] x11-proto/xf86vidmodeproto-2.2.2 USE="-debug" [ebuild N ] x11-libs/libXxf86vm-1.0.1 USE="-debug" [ebuild N ] x11-libs/libXi-1.0.1 USE="-debug" [ebuild UD] media-video/mplayer-1.0_pre8-r1 [1.0.20060415] USE="-amr% -enca% -iconv%"
*** This bug has been marked as a duplicate of 140015 ***
reopening because my concerns are not addressed in the other bug. 'emerge mplayer' is broken with 6.8 and it should be fixed. Please provide a technical reason for not providing this support. Is the ebuild not fixable for 6.8?
(In reply to comment #2) > mplayer' is broken with 6.8 and it should be fixed. Please provide a technical > reason for not providing this support. Is the ebuild not fixable for 6.8? No, it's not fixable. There's no xvmc support in xorg 6.8. *** This bug has been marked as a duplicate of 140015 ***
I never enabled xvmc support in mplayer. Hard dep on libXi is not because of xvmc support anyway. So, I don't know what you are talking about.
We won't and can't fix this, period. There's no way to not use a USE flag it you have xorg 6.8 and use it when you have xorg-7.x. Either don't upgrade mplayer or live with and upgrade xorg. Stop reopening this bug. *** This bug has been marked as a duplicate of 140015 ***
I don't understand this still. I don't have xvmc USE flag. So, why do you keep referring to it? Its not a USE flag issue at all. As far as end user is concerned the issue is simple: mplayer should support 6.8 as long as gentoo supports it. Just look at how many issues are there with xorg 7 and nvidia. Its a major upgrade and rolling it back will be a major pain as well. I just can't upgrade at this time because xorg 7 and nvidia don't work together yet and I can't take downtime for xorg.
Don't upgrade if you dislike it. We won't be fixing this.
Closed.
Sorry: mplayer should support 6.8 as long as gentoo supports it. should read: mplayer should support 6.8 as long as mplayer(upstream) and gentoo support it.
Its not about disliking it dude! Its about whether I have options. Gentoo and mplayer both support 6.8. mplayer ebuild cannot drop the support by itself.
Look, stop messing with this bug. It WON'T be fixed. I've already explained several times why it can't be fixed, it's explained on the other bug as well. WONTFIX, don't reopen this bug.
Closing.
You didn't explain at all. Please explain for the last time. And not by just closing, don't upgrade if you dislike, upgrade xorg etc. Give a proper technical reason. If you can't justify it to the end user with a proper explanation, you don't have the right to close this bug. Let someone else handle it.
(In reply to comment #13) > You didn't explain at all. Please explain for the last time. And not by just > closing, don't upgrade if you dislike, upgrade xorg etc. I've already explained it couple of times. xvmc? ( x11-libs/libXvMC ) ) x11-libs/libXvMC is *only* available for modular X. Won't work w/ 6.8 - and read comment #5.
CLOSED!
I haven't set xvmc USE flag. What is your response to that? You didn't answer that the last time either. Your explanation was and is incomplete.
You are on your best way to get bugzilla account suspended for abuse. Read the comment #5 and do some research on how dependencies work instead of reopening this bug.
*Really* closed.
you can explain how deps work instead of being nasty about it and just closing the bug. I still don't understand why the ebuild should pull libXvmc if xvmc is not present in the USE flags. That's precisely the use flags are for. The problem with the ebuild is coming from hard deps on libXi etc. and not from libXvmc. I don't understand how this is abuse of bugzilla. I have a problem and I am explaning everything in detail while you just close it with one liners. Please try to understand that I am not fond of wasting your time and I don't have anything personal against you. So, please please please, explain things rather than getting upset about it.
> The problem with the ebuild is coming from hard deps on libXi etc. and not from > libXvmc. No need to support not-even-latest-xorg-x11-in-stable in mplayer marked as ~arch.
This is what you get by not upgrading your stable system, but still wanting to upgrade parts of it from unstable. Worst mixing I've witnessed in a while.
I had a similar problem and "emerge moo" fixed it for me.
I have a full ~x86 system. So, its not a mix&match. But I am just not ready to upgrade xorg because there are known problems with nvidia (I don't know when they will release a fix). What is the point of trying to upgrade when I know its going to freeze on me like it did on so many folks. And then I can't even go back. But mplayer doesn't require xorg 7. And that's what I have been trying to convey but I think I have upset some people in the process. I apologize to whomever I might have upset. This bug report has left a lot to be desired. I think I just I expected better responses from people around here.
*** Bug 141334 has been marked as a duplicate of this bug. ***
To answare Sunil's search of a technical reason: There is none. Using the patch I upploaded to Bug #140015 mplayer works 100% on xorg-6.8 unless you specify USE=xvmc, in which case it requires modular Xorg. Just as you wanted it. I have a amd64 system, but needed the fixes in x264-svn-20060810, which doesn
To answare Sunil's search of a technical reason: There is none. Using the patch I upploaded to Bug #140015 mplayer works 100% on xorg-6.8 unless you specify USE=xvmc, in which case it requires modular Xorg. Just as you wanted it. I have a amd64 system, but needed the fixes in x264-svn-20060810, which doesnät work with mplayer-1.0_pre8, so I put "~media-libs/x264-svn-20060810" and "~media-video/mplayer-1.0_pre20060810" in /etc/portage/packaces.keywords, which is supposed to be supported (in the sence that bugs you find is supposed to be fixed).
but Mr. Jakub here claims that I don't understand dependency resolution and ebuild is not fixable with the current portage technology, because "There's no way to not use a USE flag it you have xorg 6.8 and use it when you have xorg-7.x." Well, he is the "expert", so shut up Jon....just kidding...:) Thanks for the patch but I have no real need to upgrade mplayer, it is just that emerge -uD world should not require so much manual stuff. In my world, that's breakage. We are asked to file bugs regarding any breakage in the portage and, this one is particularly confusing for regular users. Its not difficult to work around or even fix this problem. That was not the point. But I think it got personal somewhere. I have extensively gone thru portage code (even ported it to Solaris and made changes for an /opt/portage/ install instead of /) and being treated like a newb troll was a bit hard to swallow. I think I got pissed by one liners and general attitude, and was myself over the line sometimes but I apologized for that already. So, its all good, Jon!
Folks, this is not a chatroom, take it somewhere else. Thanks.
(In reply to comment #27) > Folks, this is not a chat room, take it somewhere else. Thanks. We aren't chatting, we are discussing this bug, and how to solve it. I'm sorry if we went *slightly* of topic in discussion whether the bug was solvable at all, including the fact that you, the expert, firmly stated it wasn't, without giving an explanation, when it obviously was (considering I later did it). To go back on topic, do you have any *technical* reason my patch can't make it into the official portage tree? If so, please explain it to me so I can fix my patch. If not, please apply it. Also, could we please do try to engage in a *technical* discussion from now on. Please, both of you.
