My experience: # sudo emerge media-video/smplayer These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds to satisfy "media-video/mplayer2[bidi(-),libass,png,X]". (dependency required by "media-video/smplayer-14.3.0" [ebuild]) (dependency required by "media-video/smplayer" [argument]) # eix -e mplayer2 [U] media-video/mplayer2 Available versions: 2.0_p20130126 (~)2.0_p20130428-r1 (**)9999 {3dnow 3dnowext +X +a52 +alsa altivec aqua bluray bs2b cddb +cdio cpudetection debug directfb doc +dts +dv dvb +dvd +dvdnav +enca +faad fbcon ftp gif +iconv ipv6 jack joystick jpeg ladspa lcms +libass libcaca lirc mad md5sum +mmx mmxext mng +mp3 +network nut +opengl oss png pnm portaudio +postproc pulseaudio pvr (+)quvi radio +rar +rtc samba sdl selinux +shm +speex sse sse2 ssse3 symlink tga +theora +threads +unicode v4l vcd vdpau +vorbis xanim xinerama +xscreensaver +xv xvid yuv4mpeg KERNEL="linux"} Installed versions: 2.0_p20130428-r1(18:01:56 02.04.2014)(X alsa cddb cdio dvd dvdnav enca gif iconv jpeg ladspa lcms libass mmx mng mp3 network opengl png postproc quvi shm sse sse2 ssse3 threads unicode xscreensaver xv -3dnow -3dnowext -altivec -aqua -bluray -bs2b -cpudetection -debug -directfb -doc -dvb -ftp -ipv6 -jack -joystick -libcaca -lirc -md5sum -mmxext -oss -pnm -portaudio -pulseaudio -pvr -radio -samba -selinux -symlink -tga -v4l -vcd -vdpau -xinerama -yuv4mpeg) Homepage: http://www.mplayer2.org/ Description: Media Player for Linux If I remove bidi(-) from the ebuild, the problem goes away.
+ 13 Apr 2014; Lars Wendler <polynomial-c@gentoo.org> smplayer-14.3.0.ebuild: + Attempt to fix installation with mplayer2 (bug #507588). + Please try again. If it still fails please reopen this bug. If if doesn't fail anymore please set the bug to RESOLVED FIXED. Thanks.
(In reply to Lars Wendler (Polynomial-C) from comment #1) > Please try again. If it still fails please reopen this bug. If if doesn't > fail anymore please set the bug to RESOLVED FIXED. Thanks. Looks fixed to me. Thank you!
@@ -21,7 +21,7 @@ DEPEND="dev-qt/qtcore:4 dev-qt/qtgui:4" -MPLAYER_USE="[bidi(-),libass,png,X]" +MPLAYER_USE="[bidi(+),libass,png,X]" RDEPEND="${DEPEND} || ( media-video/mplayer${MPLAYER_USE} This means that when the user doesn't have USE="bidi" enabled (which is likely) portage will always prefer pulling in mplayer2 if neither are installed, or if mplayer is already installed with USE="-bidi". Most people are going to be using mplayer as the backend (isn't mplayer2 dead upstream?) and it's what smplayer defaults to. Even if you allow mplayer2 to be installed to satisfy the dependency you end up getting errors at runtime about mplayer not being built with bidi support. Adding a bidi USE flag to mplayer2 should fix this.
(In reply to Ryan Hill from comment #3) > > This means that when the user doesn't have USE="bidi" enabled (which is > likely) portage will always prefer pulling in mplayer2 if neither are > installed, or if mplayer is already installed with USE="-bidi". Most people > are going to be using mplayer as the backend (isn't mplayer2 dead upstream?) > and it's what smplayer defaults to. Even if you allow mplayer2 to be > installed to satisfy the dependency you end up getting errors at runtime > about mplayer not being built with bidi support. > + 18 Apr 2014; Lars Wendler <polynomial-c@gentoo.org> smplayer-14.3.0.ebuild: + Another attempt to fix USE-flag dependencies for mplayer and mplayer2. + How about this?
Sorry that's the exact same thing, just written differently. caribou ~ # emerge -pv mplayer mplayer2 [ebuild R ] media-video/mplayer-1.2_pre20130729 USE="X a52 alsa dts dvd dvdnav encode gif iconv jpeg libass mad mmx mmxext network opengl osdmenu png rar rtc sdl shm sse sse2 ssse3 theora truetype twolame unicode vdpau vorbis x264 xv xvid xvmc -3dnow -3dnowext -aalib (-altivec) (-aqua) -bidi -bindist -bl -bluray -bs2b -cddb -cdio -cdparanoia -cpudetection -debug -dga -directfb -doc -dv -dvb -dxr3 -enca -faac -faad -fbcon -ftp -ggi -gsm -ipv6 -jack -joystick -jpeg2k -ladspa -libcaca -libmpeg2 -lirc -live -lzo -md5sum -mng -mp3 -nas -nut -openal -oss -pnm -pulseaudio -pvr -radio -rtmp -samba -speex -tga -toolame -tremor -v4l (-vidix) -xanim -xinerama -xscreensaver -zoran" VIDEO_CARDS="-mga -s3virge -tdfx" [ebuild N ] media-video/mplayer2-2.0_p20130428-r1 USE="X alsa dvd dvdnav gif iconv jpeg libass mmx mmxext network opengl png postproc shm sse sse2 ssse3 threads unicode vdpau xv -3dnow -3dnowext (-altivec) (-aqua) -bluray -bs2b -cddb -cdio -cpudetection -debug -directfb -doc -dvb -enca -ftp -ipv6 -jack -joystick -ladspa -lcms -libcaca -lirc -md5sum -mng -mp3 -oss -pnm -portaudio -pulseaudio -pvr -quvi -radio -samba (-selinux) -symlink -tga -v4l -vcd -xinerama -xscreensaver -yuv4mpeg" caribou ~ # emerge -pv smplayer [ebuild N ] media-video/mplayer2-2.0_p20130428-r1 USE="X alsa dvd dvdnav gif iconv jpeg libass mmx mmxext network opengl png postproc shm sse sse2 ssse3 threads unicode vdpau xv -3dnow -3dnowext (-altivec) (-aqua) -bluray -bs2b -cddb -cdio -cpudetection -debug -directfb -doc -dvb -enca -ftp -ipv6 -jack -joystick -ladspa -lcms -libcaca -lirc -md5sum -mng -mp3 -oss -pnm -portaudio -pulseaudio -pvr -quvi -radio -samba (-selinux) -symlink -tga -v4l -vcd -xinerama -xscreensaver -yuv4mpeg" 0 kB [ebuild U ] media-video/smplayer-14.3.0 [0.8.6] USE="-debug" If you don't want to add a bidi USE flag to mplayer2, you could instead make mplayer a hard dependency of smplayer. I think this makes sense anyways since it's the default. You could add a postinst message about mplayer2 like we do for other packages that have optional runtime features/backends/plugins.
(In reply to Ryan Hill from comment #5) > > If you don't want to add a bidi USE flag to mplayer2, you could instead make > mplayer a hard dependency of smplayer. I think this makes sense anyways > since it's the default. You could add a postinst message about mplayer2 > like we do for other packages that have optional runtime > features/backends/plugins. The problem is that mplayer2 unlike mplayer doesn't provide any fribidi configure option but still works with smplayer-14. On the other hand smplyer-14 refuses to run with mplayer unless fribidi is enabled.
I understand, and I think the best way to ensure that it's enabled is to make mplayer[bidi] an unconditional dependency. If a user wants to use mplayer2 instead they can always just install it themselves. Or maybe you could add an mplayer2 USE flag to pull it in?
(In reply to Ryan Hill from comment #7) > I understand, and I think the best way to ensure that it's enabled is to > make mplayer[bidi] an unconditional dependency. If a user wants to use > mplayer2 instead they can always just install it themselves. Or maybe you > could add an mplayer2 USE flag to pull it in? I don't really follow that logic. What wrong with depending on || ( mplayer[bidi] mplayer2 ) ? Polynomial sounds like that would be right.
It installs an extra, useless package while leaving the package that most people are using built without the needed support.
Fix it or don't, I don't really care.
(In reply to Ryan Hill from comment #10) > Fix it or don't, I don't really care. This needs proper fixing. So let's keep this bug open until it's properly fixed.
A "broken" version is now stable and users are complaining, can we please fix this asap?
(In reply to Davide Pesavento from comment #12) > A "broken" version is now stable and users are complaining, can we please > fix this asap? Broken in what way? This is what I see: # fgrep -C1 media-video/mplayer *.ebuild smplayer-14.3.0.ebuild- || ( smplayer-14.3.0.ebuild: media-video/mplayer[bidi,${COMMON_USE}] smplayer-14.3.0.ebuild: media-video/mplayer2[${COMMON_USE}] smplayer-14.3.0.ebuild- )" -- smplayer-14.9.0.ebuild- || ( smplayer-14.9.0.ebuild: media-video/mplayer[bidi,${COMMON_USE}] smplayer-14.9.0.ebuild: media-video/mplayer2[${COMMON_USE}] smplayer-14.9.0.ebuild- )" Unless I'm missing something, this looks sane to me.
See comments #3 and #9... or was this fixed in cvs without updating the bug?
(In reply to Davide Pesavento from comment #14) > See comments #3 and #9... or was this fixed in cvs without updating the bug? The update from comment #4 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-video/smplayer/smplayer-14.3.0.ebuild?r1=1.2&r2=1.3 is the latest related updated in CVS. > A "broken" version is now stable and users are complaining, [..] What are users complaining about?
Why is media-video/smplayer now pulling in mplayer2 instead of only mplayer after this smplayer bug fix/commit? If I'm not mistaken, media-video/smplayer2 is for pulling in mplayer2? (ie. "Dead project. Probably still better than SMPlayer if you're going to use mplayer2 though." https://github.com/lachs0r/SMPlayer2 ) For the past months, mplayer2 has been also stated as being a stale project versus the original mplayer project. Should there now be a USE flag within media-video/smplayer for pulling in either mplayer or mplayer2? Because of smplayer depending now on mplayer2 explicitly, I've had to remove smplayer from my system as I mainly use mplayer.
(In reply to Roger from comment #16) > Why is media-video/smplayer now pulling in mplayer2 instead of only mplayer > after this smplayer bug fix/commit? > > If I'm not mistaken, media-video/smplayer2 is for pulling in mplayer2? smplayer and smplayer2 are two distinct projects. Let's focus on smplayer here please, which does support using mplayer2 to my understanding. > Because of smplayer depending now on mplayer2 explicitly, I've had to remove > smplayer from my system as I mainly use mplayer. Had to remove why? Do you have mplayer installed with USE=bidi? With that, installing smplayer with no mplayer2 around should work fine. What am I missing?
(In reply to Sebastian Pipping from comment #17) > Do you have mplayer installed with USE=bidi? With that, > installing smplayer with no mplayer2 around should work fine. What am I > missing? IIUC, the problem happens when mplayer is already installed but has USE=-bidi. In such scenarios, portage resolver prefers installing mplayer2 instead of telling the user to enable bidi for mplayer.
(In reply to Davide Pesavento from comment #18) > IIUC, the problem happens when mplayer is already installed but has > USE=-bidi. In such scenarios, portage resolver prefers installing mplayer2 > instead of telling the user to enable bidi for mplayer. To my understanding, that's not a bug in the ebuild. What do you propose for a fix?
As I understand it, mplayer2 is basically a dead project. Maybe we should drop it from our dependencies altogether? On the other hand, is bidi really required? I don't use that functionality myself, and neither will most of our users. Could we make this optional?
(In reply to Ben de Groot from comment #20) > As I understand it, mplayer2 is basically a dead project. Maybe we should > drop it from our dependencies altogether? +1 It's a dead horse. Punt it for good! > On the other hand, is bidi really required? I don't use that functionality > myself, and neither will most of our users. Could we make this optional? Yes, it's required unfortunately. If you want to test this, just re-emerge mplayer[-bidi] and try to start smplayer. You get greeted with a nice error message that smplayer requires mplayer with bidi support.
(In reply to Lars Wendler (Polynomial-C) from comment #21) > Yes, it's required unfortunately. If you want to test this, just re-emerge > mplayer[-bidi] and try to start smplayer. You get greeted with a nice error > message that smplayer requires mplayer with bidi support. Confirmed. +*smplayer-14.9.0-r1 (07 Oct 2014) + + 07 Oct 2014; Sebastian Pipping <sping@gentoo.org> +smplayer-14.9.0-r1.ebuild, + +files/smplayer-14.9.0-zero-bidi.patch: + Guard passing -noflip-hebrew to mplayer 1.x by USE=bidi (bug #507588) +
Tested on "x86_64-pc-linux-gnu" here and =media-video/smplayer-14.9.0-r1 (+bidi) seems to compile and run fine hear alongside =media-video/mplayer-1.2_pre20130729. Thanks for fixing.
=media-video/smplayer-14.9.0-r1 is still masked and needs to be pushed to stable for other users to use this fix!
Stable request for 14.9.0-r1 filed in bug #538346. And because it is a dead project, mplayer2 support dropped in 14.9.0.6690 (still masked due to mpv/libav mask).
