Summary: | media-video/mplayer, fixes in ebuild | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrew Savchenko <bircoph> |
Component: | New packages | Assignee: | Gentoo Media-video project <media-video> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dabbott |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
fix issue #0
fix issue #1 fix issue #2 fix issue #3 fix issue #4 fix issue #5 fix issue #6 fix issue #7 fix issue #8 fix issue #9 fix issue #10 fix issue #11, part 1 fix issue #11, part 2 fix issue #12 fix issue #13 fix issue #14 fix issue #15 proposed fix for #16 fix for issue #17 fix issue #18 fix issue #19 fixes issue #13, v2 |
Description
Andrew Savchenko
2009-04-22 17:38:54 UTC
Please attach unified diffs (diff -u) when you did changes to an ebuild. That would be much more handy for our devs. (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 :) (In reply to comment #2) [...] > > I do not know Polish, so I can't verify. > > Yes, now it's correct :) > Fixed in r29241. (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. Created attachment 189743 [details, diff]
fix issue #0
Created attachment 189745 [details, diff]
fix issue #1
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.
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.
Created attachment 189748 [details, diff]
fix issue #4
Created attachment 189751 [details, diff]
fix issue #5
Created attachment 189755 [details, diff]
fix issue #6
Created attachment 189756 [details, diff]
fix issue #7
Created attachment 189757 [details, diff]
fix issue #8
Created attachment 189759 [details, diff]
fix issue #9
Created attachment 189760 [details, diff]
fix issue #10
this one is related only to svn version of ebuild
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.
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.
Created attachment 189763 [details, diff]
fix issue #12
Yes, menu should be conditional ;)
Created attachment 189764 [details, diff]
fix issue #13
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.
Created attachment 189766 [details, diff]
fix issue #15
This one should be better fix than I proposed earlier.
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. 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.
Created attachment 189771 [details, diff]
fix issue #18
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.
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-/.
(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. (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) 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? (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. (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. (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. :) (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. :) (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. Note to self: add a build dep for dev-lang/yasm (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. (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. 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. |