December 2005 - MPlayer-DOCS - lists.mplayerhq.hu

CVS: homepage/src projects.src.en,1.190,1.191
by syncmail＠mplayerhq.hu 02 Dec '05

02 Dec '05

CVS change done by Diego Biurrun CVS Update of /cvsroot/mplayer/homepage/src In directory mail:/var2/tmp/cvs-serv24152/src Modified Files: projects.src.en Log Message: Goo player link update Index: projects.src.en =================================================================== RCS file: /cvsroot/mplayer/homepage/src/projects.src.en,v retrieving revision 1.190 retrieving revision 1.191 diff -u -r1.190 -r1.191 --- projects.src.en 24 Nov 2005 21:47:54 -0000 1.190 +++ projects.src.en 2 Dec 2005 15:06:15 -0000 1.191 @@ -257,7 +257,7 @@ simple GUI frontend by Yua CaVan</li> <li><a href="http://dividedsky.net/~ods15/MPW15/">MPlayerWin15</a><br> simple MPlayer frontend by Oded Shimon</li> - <li><a href="http://pavcules.com/index.php?option=com_remository&Itemid=60&func=select&i…">Goo Player & DVD Ripper</a><br> + <li><a href="http://pavcules.com/index.php?option=com_remository&Itemid=27&func=select&i…">Goo Player & DVD Ripper</a><br> VB6 MPlayer and MEncoder frontends by Richard Didd</li> <li><a href="http://pantis.infeline.org/mlaunch/">mlaunch</a><br> TV and remote control MPlayer frontend by Anton Ragnarsson</li>

1 0

Re: [MPlayer-DOCS] letter to distro mplayer packagers?
by Diego Biurrun 02 Dec '05

02 Dec '05

On Fri, Dec 02, 2005 at 01:54:42PM +0100, Christian Marillat wrote: > Diego Biurrun <diego(a)biurrun.de> writes: > > > To me this feels as if you are hesitant to cooperate. Why? > > Re-read my first reply : > > ,---- > | I hope you know why I've never send any patches or suggestions to you ? > `---- Re-read my reply to your first reply: I have no idea. Are you referring to some old quarrel with Gabucino (and Arpi) maybe? If that should be the case then let us please forget about stories from a few years ago and move on. I really have no idea. I have never had a problem with you and I wouldn't know why you should have a problem with me. So please spare us the suspense and speak your mind openly. What is the problem? What was the problem in the past? What is the problem now? Whatever it is, can we please forget about it now and move on to have a constructive discussion? Regards Diego

1 0

Re: [MPlayer-DOCS] letter to distro mplayer packagers?
by Diego Biurrun 02 Dec '05

02 Dec '05

On Fri, Dec 02, 2005 at 10:10:58AM +0100, Christian Marillat wrote: > Diego Biurrun <diego(a)biurrun.de> writes: > > > On Thu, Dec 01, 2005 at 11:44:48PM +0100, Christian Marillat wrote: > >> Dominik 'Rathann' Mierzejewski <dominik(a)rangers.eu.org> writes: > > >> I don't intent to package a binary with this sort of warning. The warning > >> is clear, don't use this package : > >> > >> recompile MPlayer with --disable-runtime-cpudetection > > > > Well, just for best performance, which is true. Maybe the message is a > > bit loud. What would you suggest instead? > > Nothing, this message is true, keep the choise for distribution to > replace this messsage, then when you read "Compiled for Debian" you know > were the package come from. Well, we like to make the job of packagers easier and we try to provide an upstream source that requires minimal if any changes by packagers. If you wish to mark the the package as yours - which is a good idea - just patch the version string in version.h, this is the official way. So if you have a suggestion about that message, just speak up, we're willing to change it. Diego

1 0

Re: [MPlayer-DOCS] letter to distro mplayer packagers?
by Dominik 'Rathann' Mierzejewski 02 Dec '05

02 Dec '05

On Friday, 02 December 2005 at 10:10, Christian Marillat wrote: > Diego Biurrun <diego(a)biurrun.de> writes: > > > On Thu, Dec 01, 2005 at 11:44:48PM +0100, Christian Marillat wrote: > >> Dominik 'Rathann' Mierzejewski <dominik(a)rangers.eu.org> writes: > > [...] > > >> I don't intent to package a binary with this sort of warning. The warning > >> is clear, don't use this package : > >> > >> recompile MPlayer with --disable-runtime-cpudetection > > > > Well, just for best performance, which is true. Maybe the message is a > > bit loud. What would you suggest instead? > > Nothing, this message is true, keep the choise for distribution to > replace this messsage, then when you read "Compiled for Debian" you know > were the package come from. You're free to keep doing it, of course, but consider this: by changing this message you're changing its meaning. I've already suggested a possible change to this message that should be acceptable for you. Why can't you modify the version string instead? Regards, R. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"

1 0

Re: [MPlayer-DOCS] letter to distro mplayer packagers?
by Diego Biurrun 02 Dec '05

02 Dec '05

On Fri, Dec 02, 2005 at 10:08:46AM +0100, Christian Marillat wrote: > Dominik 'Rathann' Mierzejewski <dominik(a)rangers.eu.org> writes: > > > On Thursday, 01 December 2005 at 23:44, Christian Marillat wrote: > >> Dominik 'Rathann' Mierzejewski <dominik(a)rangers.eu.org> writes: > > >> > * sparc and ppc patches: why not submit them to mplayer-dev-eng? > >> > >> Sparc patch doesn't exist. On others patches aren't mine. > > > > What can I say to that? Is it possible to contact their authors and > > tell them to submit these to us? > > Why to not use these diff ? Dominik (or I for that matter) said nothing about not using them. We want you to send patches upstream. It's in the best interest for all of us. To me this feels as if you are hesitant to cooperate. Why? Diego

1 0

Re: [MPlayer-DOCS] letter to distro mplayer packagers?
by Diego Biurrun 02 Dec '05

02 Dec '05

On Thu, Dec 01, 2005 at 11:44:48PM +0100, Christian Marillat wrote: > Dominik 'Rathann' Mierzejewski <dominik(a)rangers.eu.org> writes: > > > * help_mp-en.h patch: why you change it like this is beyond me. > > -#define MSGTR_CompiledWithRuntimeDetection "Compiled with runtime CPU detection - WARNING - this is not optimal!\nTo get best performance, recompile MPlayer with --disable-runtime-cpudetection.\n" > > +#define MSGTR_CompiledWithRuntimeDetection "Compiled for Debian\n" > > What's the point of this change? The recommended method is to modify > > MPlayer's version string. > > I don't intent to package a binary with this sort of warning. The warning > is clear, don't use this package : > > recompile MPlayer with --disable-runtime-cpudetection Well, just for best performance, which is true. Maybe the message is a bit loud. What would you suggest instead? Diego

1 0

Re: [MPlayer-DOCS] letter to distro mplayer packagers? NOSPAM
by Dominik 'Rathann' Mierzejewski 01 Dec '05

01 Dec '05

On Thursday, 01 December 2005 at 23:44, Christian Marillat wrote: > Dominik 'Rathann' Mierzejewski <dominik(a)rangers.eu.org> writes: > > On Thursday, 01 December 2005 at 16:37, Christian Marillat wrote: [...] > >> You are talking about what exactly ? > > > > Well, much of the diff you apply to mplayer source comprises various > > files and patches. Let me comment on some of them. > > * example.conf, which is a sample mplayer.conf: we provide our own example > > file, so why not just use that instead? Maybe patch it if you want, but > > why provide a whole new file? Additionally, what's the point of providing > > more than one? Doesn't it make updating all of them harder? > > As explained in a previous e-mail, the default example.conf doesn't > work. As explained in a previous mail, you can comment out all settings and it should just work. And Diego fixed the 3dfx problem. Anyway, you can still patch it. I just don't see the point of providing full multiple config files. > > * help_mp-en.h patch: why you change it like this is beyond me. > > -#define MSGTR_CompiledWithRuntimeDetection "Compiled with runtime CPU detection - WARNING - this is not optimal!\nTo get best performance, recompile MPlayer with --disable-runtime-cpudetection.\n" > > +#define MSGTR_CompiledWithRuntimeDetection "Compiled for Debian\n" > > What's the point of this change? The recommended method is to modify > > MPlayer's version string. > > I don't intent to package a binary with this sort of warning. The warning > is clear, don't use this package : > > recompile MPlayer with --disable-runtime-cpudetection All right, you have a point there. How about removing just the " - WARNING ..." part _and_ modifying the version string? You see, the "compiled with runtime cpu detection" message is vital when reading through user-supplied mplayer -v output. You shouldn't remove it just because you don't like it. ;) > > * configure patch: modifying live555 paths is ok, but using shared > > libavcodec and libpostproc is definitely not, because neither of them > > have a stable api. Shared libpostproc support was removed on purpose. > > The documentation doesn't said the same. From codecs.html : > > ,---- > | If you use an MPlayer release you have libavcodec right in the > | package, just build as usual. If you use MPlayer from CVS you have to > | extract libavcodec from the FFmpeg CVS tree as FFmpeg releases are very > | rare. The CVS is mostly stable and offers the most features. In order to > | achieve this do: > `---- Well, these are user docs. Developer/packager docs are in DOCS/tech and the packaging guidelines clearly state that static linking is required. If you think it shouldn't be, please say why you think so. > Anyway this is my problem to check if nothing is broken before > uploading news packages. I might have missed it, but are they packaged separately? If not, then this _should_ be ok, but what's the point of having shared libs if no other binaries are using them? It's best to link them statically. > > * sparc and ppc patches: why not submit them to mplayer-dev-eng? > > Sparc patch doesn't exist. On others patches aren't mine. What can I say to that? Is it possible to contact their authors and tell them to submit these to us? > > * 05_heap_overflow.dpatch: looks like a bugfix, please submit to us > > This patch isn't applied. OK. > For all Debian stuff read the Debian Reference documentation > http://qref.sourceforge.net/ > > > * preinst script can be simplified by removing code duplication > > > > I see you no longer provide config.mak and config.h files (which I do > > think was bad, because they are supposed to be generated during build). > > This is good. > > No, the diff still contains the *.mak, config.h and version.h Huh? I haven't noticed them and a simple grep doesn't find any config.mak. I'm looking at: ftp://ftp.nerim.net/debian-marillat/pool/main/m/mplayer/mplayer_1.0-pre7cvs… The only reference to config.mak appears when you're substituting march/mcpu cflags using perl -pe. > because the > Makefile is broken and these generated files (by configure) aren't > removed when doing a make distclean. It's may be a bug in the buildsystem then. We'll look at it. Thanks for reporting. > > One more thing: you shouldn't use --enable-option for options that are > > autodetected. Just provide the correct -dev packages and let ./configure > > do the rest. > > No, because some options depends on the hardware, like v4l, 3dfx or > mga And in most of these cases, I agree. But, there are others: vstream, amr codecs, freetype, fribidi, xinerama, gl, dxr3, smb, live, v4l(2). Their detection depends only on the existence of certain libs and headers, not device files like for fb/directfb, lirc and others. The only --enable options I'm using in the official RPMs are: gui, runtime-cpudetection, largefiles, mga, xmga, tdfxfb, directfb, fbdev, joystick, lirc, menu and xmms. v4l(2) detection doesn't depend on hardware existence, so if it doesn't get detected despite having kernel support, it may be a bug and you should report it. > and yes these options are necessaries because any packaging system > must support a maximum of hardware/options. Supporting most options is a matter of philosophy, so I won't argue with you there. Maybe it's a Debian thing, too. One more thing: could you explain why some of the configure lines have --disable-mencoder and some don't? And why provide mplayer-i586 compiled with 3DNow(Ex)! (in other words, please explain how you are building non-i386 x86 packages without runtime CPU detection)? Thanks in advance. Best regards, R. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"

1 1

Re: [MPlayer-DOCS] letter to distro mplayer packagers?
by Dominik 'Rathann' Mierzejewski 01 Dec '05

01 Dec '05

On Thursday, 01 December 2005 at 23:44, Christian Marillat wrote: > Dominik 'Rathann' Mierzejewski <dominik(a)rangers.eu.org> writes: > > On Thursday, 01 December 2005 at 16:37, Christian Marillat wrote: [...] > >> You are talking about what exactly ? > > > > Well, much of the diff you apply to mplayer source comprises various > > files and patches. Let me comment on some of them. > > * example.conf, which is a sample mplayer.conf: we provide our own example > > file, so why not just use that instead? Maybe patch it if you want, but > > why provide a whole new file? Additionally, what's the point of providing > > more than one? Doesn't it make updating all of them harder? > > As explained in a previous e-mail, the default example.conf doesn't > work. As explained in a previous mail, you can comment out all settings and it should just work. And Diego fixed the 3dfx problem. Anyway, you can still patch it. I just don't see the point of providing full multiple config files. > > * help_mp-en.h patch: why you change it like this is beyond me. > > -#define MSGTR_CompiledWithRuntimeDetection "Compiled with runtime CPU detection - WARNING - this is not optimal!\nTo get best performance, recompile MPlayer with --disable-runtime-cpudetection.\n" > > +#define MSGTR_CompiledWithRuntimeDetection "Compiled for Debian\n" > > What's the point of this change? The recommended method is to modify > > MPlayer's version string. > > I don't intent to package a binary with this sort of warning. The warning > is clear, don't use this package : > > recompile MPlayer with --disable-runtime-cpudetection All right, you have a point there. How about removing just the " - WARNING ..." part _and_ modifying the version string? You see, the "compiled with runtime cpu detection" message is vital when reading through user-supplied mplayer -v output. You shouldn't remove it just because you don't like it. ;) > > * configure patch: modifying live555 paths is ok, but using shared > > libavcodec and libpostproc is definitely not, because neither of them > > have a stable api. Shared libpostproc support was removed on purpose. > > The documentation doesn't said the same. From codecs.html : > > ,---- > | If you use an MPlayer release you have libavcodec right in the > | package, just build as usual. If you use MPlayer from CVS you have to > | extract libavcodec from the FFmpeg CVS tree as FFmpeg releases are very > | rare. The CVS is mostly stable and offers the most features. In order to > | achieve this do: > `---- Well, these are user docs. Developer/packager docs are in DOCS/tech and the packaging guidelines clearly state that static linking is required. If you think it shouldn't be, please say why you think so. > Anyway this is my problem to check if nothing is broken before > uploading news packages. I might have missed it, but are they packaged separately? If not, then this _should_ be ok, but what's the point of having shared libs if no other binaries are using them? It's best to link them statically. > > * sparc and ppc patches: why not submit them to mplayer-dev-eng? > > Sparc patch doesn't exist. On others patches aren't mine. What can I say to that? Is it possible to contact their authors and tell them to submit these to us? > > * 05_heap_overflow.dpatch: looks like a bugfix, please submit to us > > This patch isn't applied. OK. > For all Debian stuff read the Debian Reference documentation > http://qref.sourceforge.net/ > > > * preinst script can be simplified by removing code duplication > > > > I see you no longer provide config.mak and config.h files (which I do > > think was bad, because they are supposed to be generated during build). > > This is good. > > No, the diff still contains the *.mak, config.h and version.h Huh? I haven't noticed them and a simple grep doesn't find any config.mak. I'm looking at: ftp://ftp.nerim.net/debian-marillat/pool/main/m/mplayer/mplayer_1.0-pre7cvs… The only reference to config.mak appears when you're substituting march/mcpu cflags using perl -pe. > because the > Makefile is broken and these generated files (by configure) aren't > removed when doing a make distclean. It's may be a bug in the buildsystem then. We'll look at it. Thanks for reporting. > > One more thing: you shouldn't use --enable-option for options that are > > autodetected. Just provide the correct -dev packages and let ./configure > > do the rest. > > No, because some options depends on the hardware, like v4l, 3dfx or > mga And in most of these cases, I agree. But, there are others: vstream, amr codecs, freetype, fribidi, xinerama, gl, dxr3, smb, live, v4l(2). Their detection depends only on the existence of certain libs and headers, not device files like for fb/directfb, lirc and others. The only --enable options I'm using in the official RPMs are: gui, runtime-cpudetection, largefiles, mga, xmga, tdfxfb, directfb, fbdev, joystick, lirc, menu and xmms. v4l(2) detection doesn't depend on hardware existence, so if it doesn't get detected despite having kernel support, it may be a bug and you should report it. > and yes these options are necessaries because any packaging system > must support a maximum of hardware/options. Supporting most options is a matter of philosophy, so I won't argue with you there. Maybe it's a Debian thing, too. One more thing: could you explain why some of the configure lines have --disable-mencoder and some don't? And why provide mplayer-i586 compiled with 3DNow(Ex)! (in other words, please explain how you are building non-i386 x86 packages without runtime CPU detection)? Thanks in advance. Best regards, R. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"

1 0

Re: [MPlayer-DOCS] letter to distro mplayer packagers?
by Diego Biurrun 01 Dec '05

01 Dec '05

On Thu, Dec 01, 2005 at 04:37:54PM +0100, Christian Marillat wrote: > Diego Biurrun <diego(a)biurrun.de> writes: > > > On Wed, Nov 30, 2005 at 03:27:34PM +0100, Christian Marillat wrote: > >> Diego Biurrun <diego(a)biurrun.de> writes: > >> > Why you include a skin uuencoded in the packaging patch and not create a > >> > skin package that the mplayer-gui package depends on remains a mystery > >> > to me. > >> > >> Why not. May be a good idea :) > > > > Well, it makes it hard to swap out one skin for another and it makes the > > packaging patch very bloated and hard to read... > > diffstats is your friend I'll look into it. > > At the very least it's completely unconventional, I haven't seen this in > > another Debian package. > > If people are providing a mplayer package build with --enable-gui without a skin > this package is broken. They don't need to include the skin, though. Making the mplayer-gui package depend on a skin package is enough. IMO an ideal solution would be to have several skin packages manage a link in /etc/alternatives/mplayer-skin that would point to /usr/share/mplayer/Skin/preferred_skin. > > What about the various copies of the config files and the various > > patches you apply? > > You are talking about what exactly ? You include several (modified) copies of the example configuration file, located at etc/example.conf in the source tree, in your packaging patch. You apply a number of patches to the vanilla MPlayer sources. Do you want me to list them? I would be interested to know what they are for, some of them could be interesting for upstream. Diego

1 0

Re: [MPlayer-DOCS] letter to distro mplayer packagers?
by Dominik 'Rathann' Mierzejewski 01 Dec '05

01 Dec '05

On Thursday, 01 December 2005 at 16:37, Christian Marillat wrote: > Diego Biurrun <diego(a)biurrun.de> writes: > > > On Wed, Nov 30, 2005 at 03:27:34PM +0100, Christian Marillat wrote: > >> Diego Biurrun <diego(a)biurrun.de> writes: > > [...] > > >> > Why you include a skin uuencoded in the packaging patch and not create a > >> > skin package that the mplayer-gui package depends on remains a mystery > >> > to me. > >> > >> Why not. May be a good idea :) Yes, but why uuencoded and in form of a patch? Is it a debian thing? > > Well, it makes it hard to swap out one skin for another and it makes the > > packaging patch very bloated and hard to read... > > diffstats is your friend > > > At the very least it's completely unconventional, I haven't seen this in > > another Debian package. > > If people are providing a mplayer package build with --enable-gui without a skin > this package is broken. Not necessarily, if the dependencies are set properly, although it does require either automatic depsolver like apt or yum, or sufficiently clueful user to figure out that you need to install both mplayer-gui and mplayer-skin-default. I did decide to include the skin in the mplayer-gui package, for different reason though. > [...] > > > What about the various copies of the config files and the various > > patches you apply? > > You are talking about what exactly ? Well, much of the diff you apply to mplayer source comprises various files and patches. Let me comment on some of them. * example.conf, which is a sample mplayer.conf: we provide our own example file, so why not just use that instead? Maybe patch it if you want, but why provide a whole new file? Additionally, what's the point of providing more than one? Doesn't it make updating all of them harder? * help_mp-en.h patch: why you change it like this is beyond me. -#define MSGTR_CompiledWithRuntimeDetection "Compiled with runtime CPU detection - WARNING - this is not optimal!\nTo get best performance, recompile MPlayer with --disable-runtime-cpudetection.\n" +#define MSGTR_CompiledWithRuntimeDetection "Compiled for Debian\n" What's the point of this change? The recommended method is to modify MPlayer's version string. * configure patch: modifying live555 paths is ok, but using shared libavcodec and libpostproc is definitely not, because neither of them have a stable api. Shared libpostproc support was removed on purpose. * sparc and ppc patches: why not submit them to mplayer-dev-eng? * 05_heap_overflow.dpatch: looks like a bugfix, please submit to us * preinst script can be simplified by removing code duplication I see you no longer provide config.mak and config.h files (which I do think was bad, because they are supposed to be generated during build). This is good. One more thing: you shouldn't use --enable-option for options that are autodetected. Just provide the correct -dev packages and let ./configure do the rest. We could discuss the list of features you've chosen to enable, but let's leave that for later. Best regards, R. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"

1 0