I got you point of view. If we are going to stay with one single package i think we should have a no-gui version. This way we will be using upstream's default. Also, we have smplayer for those who wants a GUI and ABS/AUR for those who wants to enable a GUI version in the mplayer package. Lets see what the others devs thinks about this. -- Hugo

2009/4/18 Pierre Schmitz :

Just disable the gtk gui then. Those who really want to use gmplayer will find a solution and put it into AUR.

Personally I don't use gmplayer, mplayer is enough. +1 for this. -- Andrea `BaSh` Scarpino Arch Linux Developer

disabling the GUI, might be the best idea, I use the mplayer-nogui-svn package in AUR. So there you go, since I use smplayer. It would be better have it this way, because the original GUI of mplayer is ugly, and not that usable, the front ends are much better and advanced.

Anyone else? I really want to end this. -- Hugo

On Wednesday 22 April 2009 11:22:01 am Aaron Griffin wrote:

On Wed, Apr 22, 2009 at 9:07 AM, Hugo Doria wrote:

...

Anyone else? I really want to end this.

-- Hugo

My opinion is the same as it was in that bug. I think our mplayer packages should only be mplayer, not gmplayer. That doesn't necessarily mean someone needs to package gmplayer, but I'm sure someone would.

My vote - kill off the gui version in our package I completely agree with this. So please, go this way.

On Wed, Apr 22, 2009 at 11:22, Aaron Griffin wrote:

On Wed, Apr 22, 2009 at 9:07 AM, Hugo Doria wrote:

...

Anyone else? I really want to end this.

-- Hugo

My opinion is the same as it was in that bug. I think our mplayer packages should only be mplayer, not gmplayer. That doesn't necessarily mean someone needs to package gmplayer, but I'm sure someone would.

My vote - kill off the gui version in our package

+1

Oh no. There will be another "ArchLinux revolts against" thread somewhere. I am sure that are some people calling us "ArchLinux against the machine" already. I am building mplayer without his horrible UI already. ;D -- Hugo

There is a mplayer 29188-1, without the gui, on [testing] now. Enjoy. :) -- Hugo

Pierre, Can you try to build it without these options: --extra-cflags="-I/usr/lib/live-media" --disable-nemesi Also, can you check your fribidi version? Can someone else try to build on x86_64 to confirm this problem? -- Hugo

With --disable-fribidi (instead of --enable-fribidi) it's building fine, right? This seems to be related to fribidi and its a x86_64 specific problem. I am trying to find a solution but, for now, we could just disable fribidi. -- Hugo

Hugo Doria schrieb:

With --disable-fribidi (instead of --enable-fribidi) it's building fine, right?

This seems to be related to fribidi and its a x86_64 specific problem. I am trying to find a solution but, for now, we could just disable fribidi.

No, it is not. This is mplayer's brain-dead, stupid and completely unlogical buildsystem. This is how the logic works in autotools: ./configure Feature foo is enabled if all necessary libraries are detected and disabled otherwise. ./configure --enable-foo Feature foo is always enabled, if some libraries are missing, configure bails out with an error. ./configure --disable-foo No tests are run for the feature foo, it is always disabled. Now, the mplayer configure applies a different, badly documented and brain-dead logic to the --enable-foo case: ./configure --enable-foo Feature foo is always enabled and all tests for necessary libraries are skipped. Furthermore, no -L, -l and -I flags are added to gcc that would be necessary to compile feature foo. It is expected that the user adds those flags to the Makefile himself (but it is completely undocumented WHERE they should be added). This means that if --enable-foo requires any additional compiler flags, using it essentially breaks the whole build process. Some people on the mplayer team seem to think this is a good idea, but it is actually counter-intuitive and unhelpful for distribution packages. If you want to actually --enable-fribidi, you can do so by NOT adding any configure flag. If you are not building in a clean chroot, then you have to add --disable-foo flags for all features you want to disable. And there is no way to make sure a feature was actually enabled, unless you carefully check the full output of configure.

Hugo Doria schrieb:

Uow! This explains a lot.

...

...

From the configure script we have:

--./configure --help | grep fribidi --enable-fribidi enable the FriBiDi libs [autodetect]

Then i think that we can remove the --enable-fribidi option. Can a x86_64 owner test it?

It doesn't explain why it worked on i686, but there might be some weirdness we are not seeing. You probably want to remove most --enable-feature flags from mplayer's configure line (some of them behave differently, but you should remove all that are autodetected).

Hugo Doria wrote:

There is a mplayer 29188-1, without the gui, on [testing] now. Enjoy. :)

Does this really still need the gtk2 dep? I thought the whole point of getting rid of the GUI was to remove that dep... Allan