Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 267124 - media-video/mplayer, fixes in ebuild
Summary: media-video/mplayer, fixes in ebuild
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Media-video project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-22 17:38 UTC by Andrew Savchenko
Modified: 2009-08-01 05:43 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
fix issue #0 (mplayer-9999.ebuild.p00.diff,817 bytes, patch)
2009-04-28 21:25 UTC, Andrew Savchenko
Details | Diff
fix issue #1 (mplayer-9999.ebuild.p01.diff,384 bytes, patch)
2009-04-28 21:27 UTC, Andrew Savchenko
Details | Diff
fix issue #2 (mplayer-9999.ebuild.p02.diff,1.86 KB, patch)
2009-04-28 21:29 UTC, Andrew Savchenko
Details | Diff
fix issue #3 (mplayer-9999.ebuild.p03.diff,353 bytes, patch)
2009-04-28 21:32 UTC, Andrew Savchenko
Details | Diff
fix issue #4 (mplayer-9999.ebuild.p04.diff,349 bytes, patch)
2009-04-28 21:33 UTC, Andrew Savchenko
Details | Diff
fix issue #5 (mplayer-9999.ebuild.p05.diff,364 bytes, patch)
2009-04-28 21:34 UTC, Andrew Savchenko
Details | Diff
fix issue #6 (mplayer-9999.ebuild.p06.diff,1.91 KB, patch)
2009-04-28 21:35 UTC, Andrew Savchenko
Details | Diff
fix issue #7 (mplayer-9999.ebuild.p07.diff,406 bytes, patch)
2009-04-28 21:35 UTC, Andrew Savchenko
Details | Diff
fix issue #8 (mplayer-9999.ebuild.p08.diff,969 bytes, patch)
2009-04-28 21:36 UTC, Andrew Savchenko
Details | Diff
fix issue #9 (mplayer-9999.ebuild.p09.diff,2.03 KB, patch)
2009-04-28 21:37 UTC, Andrew Savchenko
Details | Diff
fix issue #10 (mplayer-9999.ebuild.p10.diff,450 bytes, patch)
2009-04-28 21:39 UTC, Andrew Savchenko
Details | Diff
fix issue #11, part 1 (mplayer-9999.ebuild.p11a.diff,376 bytes, patch)
2009-04-28 21:41 UTC, Andrew Savchenko
Details | Diff
fix issue #11, part 2 (mplayer-9999.ebuild.p11b.diff,337 bytes, patch)
2009-04-28 21:43 UTC, Andrew Savchenko
Details | Diff
fix issue #12 (mplayer-9999.ebuild.p12.diff,1.73 KB, patch)
2009-04-28 21:45 UTC, Andrew Savchenko
Details | Diff
fix issue #13 (mplayer-9999.ebuild.p13.diff,590 bytes, patch)
2009-04-28 21:46 UTC, Andrew Savchenko
Details | Diff
fix issue #14 (mplayer-9999.ebuild.p14.diff,422 bytes, patch)
2009-04-28 21:53 UTC, Andrew Savchenko
Details | Diff
fix issue #15 (mplayer-9999.ebuild.p15.diff,680 bytes, patch)
2009-04-28 21:54 UTC, Andrew Savchenko
Details | Diff
proposed fix for #16 (mplayer-9999.ebuild.p16.diff,542 bytes, patch)
2009-04-28 22:00 UTC, Andrew Savchenko
Details | Diff
fix for issue #17 (mplayer-9999.ebuild.p17.diff,2.85 KB, patch)
2009-04-28 22:02 UTC, Andrew Savchenko
Details | Diff
fix issue #18 (mplayer-9999.ebuild.p18.diff,309 bytes, patch)
2009-04-28 22:03 UTC, Andrew Savchenko
Details | Diff
fix issue #19 (mplayer-9999.ebuild.p19.diff,754 bytes, patch)
2009-04-28 22:05 UTC, Andrew Savchenko
Details | Diff
fixes issue #13, v2 (mplayer-9999.ebuild.p13.diff,593 bytes, patch)
2009-04-28 22:23 UTC, Andrew Savchenko
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Savchenko gentoo-dev 2009-04-22 17:38:54 UTC
Hello,

some time ago I modified mplayer-9999.ebuild to fit my own purposes, as a developer I need fresh svn head with a lot of features enabled, some of them original ebuild could not satisfy fully. Obviously, most of changes will also apply to non-svn snapshot ebuilds.

After today discussion on #mplayerdev I realized they may be usefull for community.

I will not send the whole patch because it will contain a lot of independent changes neither a lot of small patches, because most of them will depend on the others (not logically, but due to changes in nearby strings). So I'll post and discuss the code here.

The topmost problem is that some packages are out of the main tree. But they are available from other sources (overlays, bugzilla, etc).

The order of discussion below is mostly from the beginning till the end of the original diff file between mplayer-9999.ebuild and my local version. Code will be emphasized by '---'.

Obviously, whenever new features are added, USE flags and metadata.xml should be updated as appropriate. I'll not mention this anymore below.

And, please, please, please: do not tell like "this feature is rarely need", I do not enforce things, I just add a possibility to use them for those who need them, also this enables truly full-featured MPlayer setup.

0) First of all, we'll need
---
EAPI=2
---
from now on due to reasons like USE deps.

1) Despite original binary realcodecs are masked, it is possible to unmask and use them. There are several reasons for this: rv30 and rv40 are not free of bugs, so binary codecs are useful for both testing and comparison and as a fallback alternative.

I use the following code for them:
---
    !bindist? (
        x86? (
            win32codecs? ( media-libs/win32codecs )
            realcodecs? ( media-libs/win32codecs[real] )
            )
        amd64? ( realcodecs? ( media-libs/amd64codecs ) )
    )
---

2) bs2b is a new audiofilter mplayer supports, its ebuild is already wandering on bugzilla:
http://bugs.gentoo.org/260407

Currently mplayer svn supports r86 of libbs2b. 3.0.0 will be supported in several days I hope (patches are in discussion).
---
       bs2b? ( media-libs/libbs2b )
---
And flags:
---
-       for x in alsa arts esd jack ladspa nas openal; do
+       for x in alsa arts bs2b esd jack ladspa nas openal; do
---

3) faad dependency. Users sould be able not only to select between external and internal version, but to disable it at all.

---
    use faad-internal || myconf="${myconf} --disable-faad-internal"
---

Note: both external and internal faad versions can't coexist. configure script will prefer internal version. So if both USE flags are set either warning or error should be issued. I'll will be happy with any of these solutions.

4) Original ebuild lacks jack dependency. This is awesome!
---
       jack? ( media-sound/jack-audio-connection-kit )
---

5) libnemesi is a good replacement for live libs. Its ebuild and ebuild for netembryo library it requires is available in one of the overlays:
http://gentoo-overlays.zugaina.org/lu_zero/portage/media-video/libnemesi-git/libnemesi-git-0.1.ebuild
http://gentoo-overlays.zugaina.org/lu_zero/portage/media-video/netembryo-git/netembryo-git-0.1.ebuild

---
       nemesi? ( media-libs/libnemesi )
---
(Yes, I disagree with lu_zero placed it in media-video. This is the media-library, not application! The same with netembryo: it is a network library at all, read the homepage: "network abstraction library". The fact media-library utilizes it doesn't make it video application itself.)

6) Libnut is an interesting container format from (some part of) mplayer development team.
---
       nut? ( media-libs/libnut )
---
And configure flag:
---
       use nut || myconf="${myconf} --disable-nut"
---

7) Not only unrar or unrar-gpl, but also rar may be used as unrar program.
---
    rar? ( || (
            app-arch/unrar-gpl
            app-arch/unrar
            app-arch/rar
        ) )
---

8) vesa videocard support (a.k.a. -vo vesa). Current ebuild lacks both proper deps and proper flags for vesa to build.

First of all, proper treatment of deps:
---
    video_cards_vesa? ( media-libs/libvbe
                        sys-libs/lrmi )
---
Ebuild for libvbe is on bugzilla for ages:
http://bugs.gentoo.org/141589
And it requires one extra flag:
---
    if use video_cards_vesa;
    then
        myconf="${myconf} --extra-cflags=-I/usr/include/libvbe";
    else
        myconf="${myconf} --disable-vesa";
    fi
---

9) TiVo a.k.a. vstream-client. Ebuild is here:
http://www.gentoo.org/proj/en/sunrise/
And dependency is here:
---
       tivo? ( media-libs/vstream-client )
---

10) Set proper SVN version. This fixes bug #266843. The problem is that portage strips .svn directory from the workdir, but this directory is required to obtain SVN version. Proposed fix utilizes subversion_wc_info to bypass this problem:
---
       # Set version #
       subversion_wc_info
       sed -i s/UNKNOWN/${ESVN_WC_REVISION}/ "${S}/version.sh"
---

11) Compilation, spelling problems, etc.

Please report the following upstream:
---
       # Fix hppa compilation
       use hppa && sed -i -e "s/-O4/-O1/" "${S}/configure"
---
I have not access to this kind of hardware to verify.

And the following:
---
    # Fix polish spelling errors
    [[ -n ${LINGUAS} ]] && sed -e 's:Zarządano:Zażądano:' -i help/help_mp-pl.h
---
I do not know Polish, so I can't verify.

Developers are open for discussion, so please do not keep any local hacks.

12) WTF menu is enabled unconditionally? Users must be able to choose.
---
       use menu && myconf="${myconf} --enable-menu"
---
should be used instead.

13) If lirc is disabled, apple-ir should be disabled too:
---
       use lirc || myconf="${myconf} --disable-lirc --disable-lircc --disable-apple-ir"
---

14) Really I can't understand why libcdio is preferred over cdparanoia. The latter should be more functional. But I do not insist here, I'm just curious.

15) v4l2 should be fully disabled when required:
---
-               use v4l2 || myconf="${myconf} --disable-tv-v4l2"
+               use v4l2 || myconf="${myconf} --disable-v4l2 --disable-tv-v4l2 --disable-radio-v4l2"
---

16) dxr3 support. The original bugreport #223587 lacks configure.log and I can do nothing so far. But this bug should be reported upstream with an appropriate log to be fixed globally.

17) Custom CPU flags. Why shm, altivec, amrv5te, amrv6, amrv6t2, amrvfp, iwmmxt are dropped?
---
               for x in 3dnow 3dnowext mmx mmxext sse sse2 ssse3; do
               for x in 3dnow 3dnowext mmx mmxext sse sse2 ssse3 shm altivec amrv5te amrv6 amrv6t2 amrvfp iwmmxt; do
---
(This doesn't imply I recommend to override autodetected flags, but a choise is a choise).

18) Not only CFLAGS and CXXFLAGS should be unset:
---
               unset CFLAGS CXXFLAGS CPPFLAGS LDFLAGS YASMFLAGS
---

19) This one is yummy )). We do not need to install all possible html-docs. We must install only those present in $LINGUAS and of course we must check each language if mplayer provides docs in it.

The following peace of code do this:
---
-       use doc && make -C DOCS/xml html-chunked
+
+       use doc && {
+               if [[ -z $LINGUAS ]]
+               then
+                       make -C DOCS/xml html-chunked
+               else
+               # select available languages from $LINGUAS
+               LINGUAS=${LINGUAS/zh/zh_CN}
+               local a1=( cs de en es fr hu it pl ru zh_CN )
+               local a2=( $LINGUAS )
+               for (( i=0; i<${#a1[*]}; i++ )); do
+                       for (( j=0; j<${#a1[*]}; j++ )); do
+                               [[ ${a1[i]} == ${a2[j]} ]] && make -C DOCS/xml html-chunked-${a2[j]}
+                       done
+               done
+               fi
+       }
---

That's all!
I hope (some of) this will be useful not only for me )).
Comment 1 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2009-04-23 21:45:18 UTC
Please attach unified diffs (diff -u) when you did changes to an ebuild. That would be much more handy for our devs.
Comment 2 Szymon Zygmunt 2009-04-24 21:51:11 UTC
(In reply to comment #0)
[...] 
> And the following:
> ---
>     # Fix polish spelling errors
>     [[ -n ${LINGUAS} ]] && sed -e 's:Zarządano:Zażądano:' -i
> help/help_mp-pl.h
> ---
> I do not know Polish, so I can't verify.

Yes, now it's correct :)
Comment 3 Andrew Savchenko gentoo-dev 2009-04-27 21:44:09 UTC
(In reply to comment #2)
[...]
> > I do not know Polish, so I can't verify.
> 
> Yes, now it's correct :)
> 

Fixed in r29241.
Comment 4 Andrew Savchenko gentoo-dev 2009-04-27 21:45:29 UTC
(In reply to comment #1)
> Please attach unified diffs (diff -u) when you did changes to an ebuild. That
> would be much more handy for our devs.
> 

OK, I'll post them tomorrow, but some of patches will depend on the others. Due to USE flags there is no way to make them completely independent.
Comment 5 Andrew Savchenko gentoo-dev 2009-04-28 21:25:58 UTC
Created attachment 189743 [details, diff]
fix issue #0
Comment 6 Andrew Savchenko gentoo-dev 2009-04-28 21:27:14 UTC
Created attachment 189745 [details, diff]
fix issue #1
Comment 7 Andrew Savchenko gentoo-dev 2009-04-28 21:29:34 UTC
Created attachment 189746 [details, diff]
fix issue #2

Currently upstream supports libbs2b as of svn revision ~86.
Update for 3.0.0 release is currently under discussion, may be committed soon.
Comment 8 Andrew Savchenko gentoo-dev 2009-04-28 21:32:45 UTC
Created attachment 189747 [details, diff]
fix issue #3

Forget what I wrote above concerning faad-internal: aac use flag already do this.

However, if both faad and aac are specified, the latter (i.e. internal faad) will be used by configure in favour of an external one, so there is no need for dependency on media-libs/faad2 in this case.
Comment 9 Andrew Savchenko gentoo-dev 2009-04-28 21:33:25 UTC
Created attachment 189748 [details, diff]
fix issue #4
Comment 10 Andrew Savchenko gentoo-dev 2009-04-28 21:34:21 UTC
Created attachment 189751 [details, diff]
fix issue #5
Comment 11 Andrew Savchenko gentoo-dev 2009-04-28 21:35:03 UTC
Created attachment 189755 [details, diff]
fix issue #6
Comment 12 Andrew Savchenko gentoo-dev 2009-04-28 21:35:48 UTC
Created attachment 189756 [details, diff]
fix issue #7
Comment 13 Andrew Savchenko gentoo-dev 2009-04-28 21:36:40 UTC
Created attachment 189757 [details, diff]
fix issue #8
Comment 14 Andrew Savchenko gentoo-dev 2009-04-28 21:37:40 UTC
Created attachment 189759 [details, diff]
fix issue #9
Comment 15 Andrew Savchenko gentoo-dev 2009-04-28 21:39:01 UTC
Created attachment 189760 [details, diff]
fix issue #10

this one is related only to svn version of ebuild
Comment 16 Andrew Savchenko gentoo-dev 2009-04-28 21:41:22 UTC
Created attachment 189761 [details, diff]
fix issue #11, part 1

This one removes hack for hppa.

I have found no related bugreports in bugzilla, and this hack seems to be several years old. IMHO it is good idea to disable it until there will be a reasonable bugreport, if it will be at all.
Comment 17 Andrew Savchenko gentoo-dev 2009-04-28 21:43:41 UTC
Created attachment 189762 [details, diff]
fix issue #11, part 2

Polish spelling is fixed upstream now.
There is no need for this fix in ebuild anymore.
And please, report such problems and bugs to upstream instead of just fixing them locally.
Comment 18 Andrew Savchenko gentoo-dev 2009-04-28 21:45:13 UTC
Created attachment 189763 [details, diff]
fix issue #12

Yes, menu should be conditional ;)
Comment 19 Andrew Savchenko gentoo-dev 2009-04-28 21:46:02 UTC
Created attachment 189764 [details, diff]
fix issue #13
Comment 20 Andrew Savchenko gentoo-dev 2009-04-28 21:53:43 UTC
Created attachment 189765 [details, diff]
fix issue #14

At this moment I'm not quite sure which cdda interface (cdparanoia vs libcdio) should be preferred if both are specified.

Bugreport #184783 was too subjective: it stated cdparanoia is outdated and unmaintained, but the last version was issued on October 2008; yes, later than original bugreport, so some progress wase made, perhaps... Reporter referenced to numerous kernel warnings, but none was shown.

Any way, until I'll be damn quite sure I'm doing the right thing I do not want to change the order of preference.

But one issue still remains: there is no need in dependency on media-sound/cdparanoia if cdio was specified too, because cdparanoia will never be used under such conditions.
Comment 21 Andrew Savchenko gentoo-dev 2009-04-28 21:54:58 UTC
Created attachment 189766 [details, diff]
fix issue #15

This one should be better fix than I proposed earlier.
Comment 22 Andrew Savchenko gentoo-dev 2009-04-28 22:00:36 UTC
Created attachment 189768 [details, diff]
proposed fix for #16

I just looked into the latest em8300 sources:
http://sourceforge.net/project/downloading.php?group_id=5165&filename=em8300-0.17.2.tar.gz

The DOES contain include/linux/em8300.h, so MPlayer's check for DXR3 is correct. If Gentoo em8300 package doesn't contain this header, then it should be fixed instead, but not this ebuild.
Comment 23 Andrew Savchenko gentoo-dev 2009-04-28 22:02:27 UTC
Created attachment 189770 [details, diff]
fix for issue #17

This one adds support for ARM CPU istruction sets and treats altivec in the same way as the others.
Comment 24 Andrew Savchenko gentoo-dev 2009-04-28 22:03:24 UTC
Created attachment 189771 [details, diff]
fix issue #18
Comment 25 Andrew Savchenko gentoo-dev 2009-04-28 22:05:33 UTC
Created attachment 189772 [details, diff]
fix issue #19

The main idea is to install only docs for languages met both requirements:
1) User requested them by $LINGUAS variable.
2) MPlayer provides docs for those languages.
Comment 26 Andrew Savchenko gentoo-dev 2009-04-28 22:23:11 UTC
Created attachment 189774 [details, diff]
fixes issue #13, v2

There was a typo in v1. Original patch still works ok and is appliable, but with fuzz 2 8-/.
Comment 27 Steve Dibb (RETIRED) gentoo-dev 2009-04-29 13:00:59 UTC
(In reply to comment #0)

Just a few quick notes on *some* of these ...

> 1) Despite original binary realcodecs are masked, it is possible to unmask and
> use them. There are several reasons for this: rv30 and rv40 are not free of
> bugs, so binary codecs are useful for both testing and comparison and as a
> fallback alternative.

Agreed, but the real reason I removed the dep is that I want to phase out the binary realplayer support completely and eventually remove it from the tree.

> 3) faad dependency. Users sould be able not only to select between external and
> internal version, but to disable it at all.
> 
> ---
>     use faad-internal || myconf="${myconf} --disable-faad-internal"
> ---
> 
> Note: both external and internal faad versions can't coexist. configure script
> will prefer internal version. So if both USE flags are set either warning or
> error should be issued. I'll will be happy with any of these solutions.

(off the top of my head) I think if you disable both, it'll remove all AAC support.  Can't remember.

I know I set the USE flag defaults to prefer one or the other, can't remember which.  Probably internal.
 
> 6) Libnut is an interesting container format from (some part of) mplayer
> development team.
> ---
>        nut? ( media-libs/libnut )
> ---
> And configure flag:
> ---
>        use nut || myconf="${myconf} --disable-nut"
> ---

There was some reason I wasn't adding it as a dep ... sure can't remember now.  I think it would be more appropriate to add a svn live ebuild for libnut, and depend on that one.

> 7) Not only unrar or unrar-gpl, but also rar may be used as unrar program.
> ---
>     rar? ( || (
>             app-arch/unrar-gpl
>             app-arch/unrar
>             app-arch/rar
>         ) )
> ---

Ah, didn't know you could use rar.

> 12) WTF menu is enabled unconditionally? Users must be able to choose.
> ---
>        use menu && myconf="${myconf} --enable-menu"
> ---
> should be used instead.

Eh, this was one of those that there was no real intelligent reason to turn it off, or something.  Can't remember.  Either way, might fall in the case of another random use flag that'd just confuse people, so leave it out.  "menu" is pretty generic.
 
> 14) Really I can't understand why libcdio is preferred over cdparanoia. The
> latter should be more functional. But I do not insist here, I'm just curious.

This one, I'm pretty sure, was that we don't want to support cdparanoia, and I vaguely recall upstream mentioning a preference for this one.
 
> 17) Custom CPU flags. Why shm, altivec, amrv5te, amrv6, amrv6t2, amrvfp, iwmmxt
> are dropped?
> ---
>                for x in 3dnow 3dnowext mmx mmxext sse sse2 ssse3; do
>                for x in 3dnow 3dnowext mmx mmxext sse sse2 ssse3 shm altivec
> amrv5te amrv6 amrv6t2 amrvfp iwmmxt; do
> ---
> (This doesn't imply I recommend to override autodetected flags, but a choise is
> a choise).

I know altivec shows up somewhere else.
 
> 19) This one is yummy )). We do not need to install all possible html-docs. We
> must install only those present in $LINGUAS and of course we must check each
> language if mplayer provides docs in it.
> 
> The following peace of code do this:
> ---
> -       use doc && make -C DOCS/xml html-chunked
> +
> +       use doc && {
> +               if [[ -z $LINGUAS ]]
> +               then
> +                       make -C DOCS/xml html-chunked
> +               else
> +               # select available languages from $LINGUAS
> +               LINGUAS=${LINGUAS/zh/zh_CN}
> +               local a1=( cs de en es fr hu it pl ru zh_CN )
> +               local a2=( $LINGUAS )
> +               for (( i=0; i<${#a1[*]}; i++ )); do
> +                       for (( j=0; j<${#a1[*]}; j++ )); do
> +                               [[ ${a1[i]} == ${a2[j]} ]] && make -C DOCS/xml
> html-chunked-${a2[j]}
> +                       done
> +               done
> +               fi
> +       }
> ---

There's been a similar bug open for a while, definitely needs to be addressed.
Comment 28 Steve Dibb (RETIRED) gentoo-dev 2009-04-29 13:23:55 UTC
(In reply to comment #0)

> 8) vesa videocard support (a.k.a. -vo vesa). Current ebuild lacks both proper
> deps and proper flags for vesa to build.
> 
> First of all, proper treatment of deps:
> ---
>     video_cards_vesa? ( media-libs/libvbe
>                         sys-libs/lrmi )
> ---
> Ebuild for libvbe is on bugzilla for ages:
> http://bugs.gentoo.org/141589

Same argument exists on comment #6 ... it's dead upstream, don't wanna add a new  ebuild for it still.

Last Changed Date: 2006-07-01 02:00:59 -0600 (Sat, 01 Jul 2006)
Comment 29 Andrew Savchenko gentoo-dev 2009-05-01 21:29:54 UTC
Hello,

(In reply to comment #27)
[...]
> > 1) Despite original binary realcodecs are masked, it is possible to unmask and
> > use them. There are several reasons for this: rv30 and rv40 are not free of
> > bugs, so binary codecs are useful for both testing and comparison and as a
> > fallback alternative.
> 
> Agreed, but the real reason I removed the dep is that I want to phase out the
> binary realplayer support completely and eventually remove it from the tree.

Why? Due to security? There are a lot of packages with recurring security issues in the tree. Binary package? Yes, this is bad, but no one talks about removing opera, etc. My option is simple: do not remove it until FFmpeg's rv?0 will replace them completely (e.g. without regressions).
 
> > 3) faad dependency. Users sould be able not only to select between external and
> > internal version, but to disable it at all.
> > 
> > ---
> >     use faad-internal || myconf="${myconf} --disable-faad-internal"
> > ---
> > 
> > Note: both external and internal faad versions can't coexist. configure script
> > will prefer internal version. So if both USE flags are set either warning or
> > error should be issued. I'll will be happy with any of these solutions.
> 
> (off the top of my head) I think if you disable both, it'll remove all AAC
> support.  Can't remember.

Yes, it will. And user may want to disable its support. Anyway forget about new use flag and look at p03 patch: there is no need to depend on faad2 if aac is enabled, because internal version will override external if both are specified.

> I know I set the USE flag defaults to prefer one or the other, can't remember
> which.  Probably internal.

Huh? Where? I can't see this dep in current ebuild.

> > 12) WTF menu is enabled unconditionally? Users must be able to choose.
> > ---
> >        use menu && myconf="${myconf} --enable-menu"
> > ---
> > should be used instead.
> 
> Eh, this was one of those that there was no real intelligent reason to turn it
> off, or something.  Can't remember.  Either way, might fall in the case of
> another random use flag that'd just confuse people, so leave it out.  "menu" is
> pretty generic.

This is not pretty generic. This is an OSD menu, not OSD status or subtitles, you need to run mplayer with -menu and bind something to the menu key to actually use it. Definitely not all people need this, thus for most majority this is just binary size grower, moreover sometimes in cause some troubles. There is no reason to keep it always enabled.
 
> > 14) Really I can't understand why libcdio is preferred over cdparanoia. The
> > latter should be more functional. But I do not insist here, I'm just curious.
> 
> This one, I'm pretty sure, was that we don't want to support cdparanoia,

Why?

> and I vaguely recall upstream mentioning a preference for this one.

Are you sure? I searched trough entire mplayer-dev-eng maillist archives on freenet and was unable to find such kind of recommendation. And it is even simplier without are mail search: if it was actually preferred, this is very easy to change MPlayer's configure to prefer libcdio over cdparanoia, but this wasn't done.

> > 17) Custom CPU flags. Why shm, altivec, amrv5te, amrv6, amrv6t2, amrvfp, iwmmxt
> > are dropped?
> > ---
> >                for x in 3dnow 3dnowext mmx mmxext sse sse2 ssse3; do
> >                for x in 3dnow 3dnowext mmx mmxext sse sse2 ssse3 shm altivec
> > amrv5te amrv6 amrv6t2 amrvfp iwmmxt; do
> > ---
> > (This doesn't imply I recommend to override autodetected flags, but a choise is
> > a choise).
> 
> I know altivec shows up somewhere else.

Can you explain what do you mean in more details?

> > 19) This one is yummy )). We do not need to install all possible html-docs. We
> > must install only those present in $LINGUAS and of course we must check each
> > language if mplayer provides docs in it.
> > 
> > The following peace of code do this:
> > ---
> > -       use doc && make -C DOCS/xml html-chunked
> > +
> > +       use doc && {
> > +               if [[ -z $LINGUAS ]]
> > +               then
> > +                       make -C DOCS/xml html-chunked
> > +               else
> > +               # select available languages from $LINGUAS
> > +               LINGUAS=${LINGUAS/zh/zh_CN}
> > +               local a1=( cs de en es fr hu it pl ru zh_CN )
> > +               local a2=( $LINGUAS )
> > +               for (( i=0; i<${#a1[*]}; i++ )); do
> > +                       for (( j=0; j<${#a1[*]}; j++ )); do
> > +                               [[ ${a1[i]} == ${a2[j]} ]] && make -C DOCS/xml
> > html-chunked-${a2[j]}
> > +                       done
> > +               done
> > +               fi
> > +       }
> > ---
> 
> There's been a similar bug open for a while, definitely needs to be addressed.
> 

Yes, something similar is pending since 2006. Why not applied then?
Comment 30 Andrew Savchenko gentoo-dev 2009-05-01 21:35:38 UTC
(In reply to comment #28)
> (In reply to comment #0)
> 
> > 8) vesa videocard support (a.k.a. -vo vesa). Current ebuild lacks both proper
> > deps and proper flags for vesa to build.
> > 
> > First of all, proper treatment of deps:
> > ---
> >     video_cards_vesa? ( media-libs/libvbe
> >                         sys-libs/lrmi )
> > ---
> > Ebuild for libvbe is on bugzilla for ages:
> > http://bugs.gentoo.org/141589
> 
> Same argument exists on comment #6 ... it's dead upstream, don't wanna add a
> new  ebuild for it still.
> 
> Last Changed Date: 2006-07-01 02:00:59 -0600 (Sat, 01 Jul 2006)
> 

1) "It wasn't updated for some time" is bad argument in general. There are hundreds if not thousands of ebuilds for different utilities which were not updated for a year or two. This is normal, if program works ok there is nothing to be updated (excluding some minor cosmetics).

2) Comment #6 a.k.a. libnut completely differs:
$ svn log -r head svn://svn.mplayerhq.hu/nut/
------------------------------------------------------------------------
r662 | michael | 2009-04-16 00:20:55 +0400 (Thu, 16 Apr 2009) | 3 lines
[...]
So it is definitely not dead.
Comment 31 Steve Dibb (RETIRED) gentoo-dev 2009-05-02 14:23:11 UTC
(In reply to comment #29)

> Can you explain what do you mean in more details?

Just yammering, is all.  I already looked at all the patches, the only ones I'm gonna reject is the realplayer one and anything where the dep isn't in the tree.
Comment 32 Steve Dibb (RETIRED) gentoo-dev 2009-05-02 14:24:09 UTC
(In reply to comment #30)
> (In reply to comment #28)
> > (In reply to comment #0)
> > 
> > > 8) vesa videocard support (a.k.a. -vo vesa). Current ebuild lacks both proper
> > > deps and proper flags for vesa to build.
> > > 
> > > First of all, proper treatment of deps:
> > > ---
> > >     video_cards_vesa? ( media-libs/libvbe
> > >                         sys-libs/lrmi )
> > > ---
> > > Ebuild for libvbe is on bugzilla for ages:
> > > http://bugs.gentoo.org/141589
> > 
> > Same argument exists on comment #6 ... it's dead upstream, don't wanna add a
> > new  ebuild for it still.
> > 
> > Last Changed Date: 2006-07-01 02:00:59 -0600 (Sat, 01 Jul 2006)
> > 
> 
> 1) "It wasn't updated for some time" is bad argument in general. There are
> hundreds if not thousands of ebuilds for different utilities which were not
> updated for a year or two. This is normal, if program works ok there is nothing
> to be updated (excluding some minor cosmetics).

Either way, I'm not going to put dead projects in the tree, since it implies that we are going to be supporting it if/when something breaks.
 
> 2) Comment #6 a.k.a. libnut completely differs:
> $ svn log -r head svn://svn.mplayerhq.hu/nut/
> ------------------------------------------------------------------------
> r662 | michael | 2009-04-16 00:20:55 +0400 (Thu, 16 Apr 2009) | 3 lines
> [...]
> So it is definitely not dead.
> 

I never said I wasn't gonna add that one. :)
Comment 33 Andrew Savchenko gentoo-dev 2009-05-03 19:07:55 UTC
(In reply to comment #32)
[...]
> > 2) Comment #6 a.k.a. libnut completely differs:
> > $ svn log -r head svn://svn.mplayerhq.hu/nut/
> > ------------------------------------------------------------------------
> > r662 | michael | 2009-04-16 00:20:55 +0400 (Thu, 16 Apr 2009) | 3 lines
> > [...]
> > So it is definitely not dead.
> > 
> 
> I never said I wasn't gonna add that one. :)

Good. :)
Comment 34 Andrew Savchenko gentoo-dev 2009-05-03 23:07:53 UTC
(In reply to comment #7)
> Created an attachment (id=189746) [edit]
> fix issue #2
> 
> Currently upstream supports libbs2b as of svn revision ~86.
> Update for 3.0.0 release is currently under discussion, may be committed soon.
> 

The latest libbs2b-3.0.0 is supported now.
Comment 35 Steve Dibb (RETIRED) gentoo-dev 2009-05-07 16:21:35 UTC
Note to self: add a build dep for dev-lang/yasm
Comment 36 Steve Dibb (RETIRED) gentoo-dev 2009-05-28 03:14:08 UTC
(In reply to comment #21)
> Created an attachment (id=189766) [edit]
> fix issue #15
> 
> This one should be better fix than I proposed earlier.
> 

mmm, gonna pass on this one because it's only disabling TV v4l2, and then immediately afterwards checks to see if radio is set, then disable those ... which could be affected by turning off all v4l2 stuff.

It might be a candidate to be cleaned up a bit, but I think it's fine as is right now.  Either way, if you disable *all* the v4l/dvb/radio use flags, they get all passed anyway.
Comment 37 Steve Dibb (RETIRED) gentoo-dev 2009-05-28 03:30:26 UTC
(In reply to comment #23)
> Created an attachment (id=189770) [edit]
> fix for issue #17
> 
> This one adds support for ARM CPU istruction sets and treats altivec in the
> same way as the others.
> 

mplayer isn't keyworded for arm, so gonna skip all of these except altivec, which was already in there ... so it'll just get moved to in here.
Comment 38 Steve Dibb (RETIRED) gentoo-dev 2009-05-29 02:24:10 UTC
Alright, got a lot of these in here, committed in CVS to -9999.

Here's a short summary of what actually got changed:

0. EAPI-2 (fixed)
1. realcodecs (rejected)
2. bs2b (new package)
3. faad deps (fixed)
4. jack deps(fixed)
5. libnemesi (new package, rejected)
6. libnut dep (fixed)
7. rar dep (fixed)
8. vesa deps (outdated deps, rejected)
9. tivo client (new package, rejected)
10. svn version (fixed)
11. hppa upstream (fixed)
12. osdmenu (fixed)
13. disable apple-ir w/no lirc (fixed)
14. cdda (unchanged)
15. disable v4l2 properly (rejected)
16. upstream (fixed)
17. cpu flags (partially fixed)
18. unset more flags on custom-cflags (fixed)
19. html docs (testing)

Was having problems with the html docs one, I didn't want it to hold up the ebuild since these have been waiting long enough, will look at it some more and get these changes backported to a snapshot as well.

Thanks, Andrew.